체인 이름은 훅이 아니다: iptables 대 nftables

두 방화벽 모두 전달되는 VPN 트래픽을 필터링할 수 있지만, 규칙을 패킷 경로에 붙이는 방식은 다릅니다. iptables에는 테이블 안에 내장 체인이 있어 FORWARD가 이름 있는 훅 지점으로 존재합니다. nftables는 체인의 이름을 유형, 훅, 우선순위와 분리하므로 FORWARD라는 이름의 일반 체인은 아무것도 필터링하지 않습니다. 두 모델을 비교하면 한 도구에서 맞아 보이는 항목이 다른 도구에서 효과가 없는 이유가 드러납니다.

체인은 그릇입니다. 커널이 그것을 참조하는지는 구현과 규칙 집합이 그것을 어떻게 붙이는지에 달려 있습니다.

두 모델, 두 가지 붙이는 방식

iptables에서 filter 테이블은 세 개의 내장 체인 INPUT, FORWARD, OUTPUT과 함께 제공되며, -N은 그중 하나에서 점프해야만 효력이 생기는 사용자 정의 체인을 만듭니다. 반면 nftables 설명서는 유형, 훅, 우선순위를 선언하는 베이스 체인과 그렇지 않은 일반 체인을 정의합니다. 베이스 체인은 어떤 이름이든 가질 수 있고, FORWARD라는 일반 체인은 라벨에서 아무런 속성도 얻지 못합니다. 그것이 전부이며, 규칙 텍스트만 보여 주는 자습서에서는 보이지 않습니다.

호환 백엔드는 명령 이름으로 동작을 추론하지 말아야 할 두 번째 이유를 더합니다. iptables 문서는 iptables-nft 아래에서 달라지는 작업을 언급하므로, 네이티브 nftables와 iptables-nft, 레거시 규칙 집합을 하나의 세 가지 표기가 아니라 세 가지 시스템으로 다루십시오.

오류를 실제 맥락에서 읽으십시오

없는 테이블, 권한 실패, 사용할 수 없는 커널 기능, 없는 이름의 체인은 서로 다른 네 가지 발견이며 그중 하나만 체인에 관한 것입니다. 도구 버전, 요청한 주소 체계와 테이블, 네트워크 네임스페이스, 첫 번째 정확한 오류를 기록하십시오. 그다음 규칙 집합을 누가 소유하는지 확인하십시오. 방화벽 서비스나 제품이 관리하는 게이트웨이는 자체 체인과 순서를 생성할 수 있습니다. 그 옆에 네이티브 체인을 추가하면 관리 정책은 그대로이고 목록만 더 혼란스러워집니다.

컨테이너의 네임스페이스는 호스트와 다른 규칙 집합을 가질 수 있으므로 잘못된 맥락에서 실행한 명령은 어느 체인이 전달된 패킷을 보았는지 보여 줄 수 없습니다. 기대한 체인이 보이지 않는다고 권한을 올리는 것은 진단이 아닙니다.

카운터는 도달을 증명할 뿐 판정은 아니다

규칙 카운터는 규칙에 도달했음을 알려 줍니다. 이후 규칙이 그 작업을 허용했는지 알려 주지 않고, 모든 대체 경로가 거부되었음을 증명하지도 않습니다. 무해한 승인된 흐름 하나를 흘리면서 규칙 순서와 체인 연결과 함께 읽고, 판정이 아니라 하나의 관찰로 다루십시오. drop 규칙의 카운터가 영이 아니면 트래픽이 그 규칙에 닿았다는 뜻이며, 닿지 않은 트래픽에 대해서는 아무것도 말하지 않습니다.

커널 IP 포워딩은 완전히 별개의 설정입니다. 체인이 존재한다고 포워딩이 활성화되지 않으며, 익숙한 라벨이 없다고 포워딩이 멈춘 것도 아닙니다.

보호하려는 흐름을 서술하십시오

캡슐 해제 후의 클라이언트 요청 하나를 적으십시오. 출발지, 목적지, 주소 체계, 그리고 게이트웨이에서 종료되는지 통과하는지입니다. 로컬 서비스 입력과 전달 트래픽은 서로 다른 지점에서 관찰되므로 다른 규칙과 다른 시험이 필요합니다. 브리지 VPN이라면 브리지 경로도 확인하십시오. IP 수준의 체인은 이더넷 프레임을 자동으로 감시하지 않습니다.

원격 게이트웨이를 바꾸기 전에 독립적인 복구 접근을 확보하십시오. 그런 다음 같은 규칙 집합 아래에서 의도한 흐름과 필요한 거부를 확인하십시오. 익숙한 이름의 새 빈 체인은 복구가 아닙니다.

비교는 하나의 질문으로 끝납니다. 이 패킷에 대해 커널이 실제로 호출하는 훅은 무엇입니까? 그 답을 얻으면 체인 이름은 더 이상 중요하지 않습니다.