nftables의 input 규칙이 전달 패킷을 막지 못하는 이유

nftables의 input hook은 로컬 시스템으로 라우팅된 패킷을 보고 forward hook은 로컬 호스트가 목적지가 아닌 중계 패킷을 봅니다. 라우터를 통과해 내부 서버로 향하는 패킷은 input 규칙이 아니라 forward 경로를 따라갑니다.

같은 hook에 여러 base chain이 있으면 priority 순서로 실행됩니다. 앞 chain의 accept도 뒤 priority chain의 평가를 항상 끝내지 않습니다. 실제 ruleset 전체를 읽어야 합니다.

패킷이 호스트로 향하는지 통과하는지 구분합니다

nftables에서 input과 forward는 임의의 규칙 이름이 아니라 패킷 처리 단계에 연결되는 hook입니다. input은 라우팅 결과 로컬 시스템으로 향하는 패킷을 봅니다. forward는 이 호스트가 목적지가 아니어서 다른 네트워크로 전달되는 패킷을 봅니다. 그러므로 라우터를 통과하는 연결을 input 규칙만 보고 허용 또는 차단됐다고 판단하면 틀릴 수 있습니다.

Netfilter 프로젝트 문서는 base chain을 hook에 등록해야 해당 처리 단계의 패킷을 본다고 설명합니다. chain 이름이 input처럼 보여도 hook에 연결되지 않은 regular chain은 패킷 흐름에 자동으로 참여하지 않습니다. 먼저 실제 ruleset에서 family, hook, priority, device 조건을 읽어야 합니다.

교육용 사례: 방화벽 SSH와 내부 서버 HTTPS

교육용 라우터 eth0에는 외부망이 연결되고 eth1에는 내부 서버가 있습니다. 관리자가 라우터 자체의 SSH 접속을 제어하고, 별도로 내부 웹 서버로 향하는 HTTPS 전달을 제어한다고 가정합니다. 실제 명령을 실행하거나 네트워크에 패킷을 보내는 사례가 아닙니다.

예를 들어 외부에서 들어온 패킷의 목적지가 내부 서버라면 라우팅 단계 뒤 forward hook을 통과합니다. input에 SSH 허용 규칙이 있어도 그 규칙이 내부 서버 HTTPS 전달을 제어하지는 않습니다. 반대로 목적지가 방화벽 자신의 관리 주소라면 로컬 프로세스에 전달되므로 input을 확인합니다.

같은 hook의 chain은 priority를 따라 이어집니다

하나의 hook에 여러 base chain이 등록될 수 있습니다. 공식 프로젝트 문서는 priority가 같은 hook의 chain 처리 순서를 정하며 낮은 수가 먼저 오는 예를 보여줍니다. 예를 들어 priority -1 chain은 priority 0 chain보다 먼저 처리됩니다. 같은 priority를 여러 chain에 쓰면 평가 순서가 보장되지 않을 수 있으므로 순서를 전제로 답을 만들면 안 됩니다.

중요한 차이는 accept와 drop입니다. accept는 그 chain의 판단에서 패킷을 다음 단계로 계속 보내지만 같은 hook의 뒤 chain이 남아 있다면 추가 평가를 받을 수 있습니다. 반면 drop은 즉시 적용됩니다. 따라서 한 파일에서 accept를 찾았다는 이유만으로 다른 관리 도구가 만든 chain과 정책을 무시할 수 없습니다.

읽기 전용으로 packet path를 따라가는 방법

1. 먼저 목적지가 라우터 자신인지 다음 홉 뒤의 서버인지 적습니다. 경로가 모호하면 route lookup 자료와 주소를 확인합니다.
2. nft list ruleset 결과를 읽고 table family와 base chain의 type, hook, priority, policy를 표시합니다. 조회 명령은 상태를 바꾸지 않습니다.
3. 패킷이 통과할 hook에 연결된 모든 base chain을 priority 순으로 나열합니다. 같은 priority의 순서를 가정하지 않습니다.
4. 일치하는 규칙을 위에서부터 따라가 accept, drop, counter와 후속 chain의 영향을 확인합니다.
5. 규칙 분석은 현재 표시된 ruleset의 해석입니다. 경로·커널 상태·다른 방화벽 관리자의 규칙이 바뀌면 결과도 달라질 수 있습니다.

nft list ruleset

자주 하는 실수: accept를 전체 허용으로 읽습니다

앞의 base chain에서 accept가 보이더라도 같은 hook에 뒤 chain이 있다면 계속 평가될 수 있습니다. 또한 input과 forward는 서로 다른 처리 경로라서 한 hook의 규칙만으로 다른 경로를 설명할 수 없습니다. 시험 문제나 점검표에서는 목적지, hook, priority, 최종 verdict를 차례로 적어 보세요.

일부 시스템에는 nftables 외에도 다른 서비스가 관리하는 규칙이 함께 있을 수 있습니다. 하나의 chain 조각만 보고 운영 전체 정책을 단정하지 말고, 확인한 범위를 기록해야 합니다. 이 글은 규칙을 안전하게 읽는 학습 자료이며 실제 방화벽 규칙 추가나 차단 시험을 권하지 않습니다.

회상 연습

교육용 질문입니다. 외부에서 들어온 TCP 연결의 목적지가 라우터 뒤 내부 서버입니다. priority 0의 forward chain은 accept했지만 priority 10의 forward chain은 policy drop입니다. 어떤 hook을 지나며, 최종 허용으로 볼 수 있나요?

방화벽과 네트워크 규칙의 적용 범위를 더 연습하려면 정보보안기사 덱 구성을 확인할 수 있습니다.