nftables: 드롭 핸들 앞에 VPN 허용 규칙 삽입하기

허용 규칙을 잘못된 위치에 두면 허용 규칙이 아예 없는 것처럼 동작합니다. nftables에서 insert와 add 중 무엇을 고르느냐가 참조된 규칙의 어느 쪽에 새 문장이 놓이는지를 결정하며, 핸들은 행 번호가 아니라 라이브 규칙 집합 안의 규칙을 가리킵니다. 위치가 틀리면 패킷은 드롭에 먼저 도달합니다.

아래 비교는 고정된 피어 하나와 외부 리스너 교환 하나만 사용합니다. 의도적으로 좁게 잡았으므로, 체인 전체를 교체하는 것은 위험 프로필이 다른 또 다른 변경입니다.

두 가지 배치, 두 가지 다른 결과

insert 는 참조된 규칙 앞에 규칙을 둡니다. add 는 그 뒤에 둡니다. 참조된 규칙이 흐름의 최종 드롭이라면, 규칙 텍스트가 같더라도 이 두 명령은 반대 결과를 냅니다.

위치를 생략하면 나름의 기본 동작이 있으므로, 무엇에 고정되어 있는지 읽지 않고 포럼의 명령을 복사하지 말아야 하는 또 하나의 이유가 됩니다. 고정 지점이 결정의 전부입니다. 명령을 입력하기 전에 의도한 쪽을 적어 두십시오. 파일에서 insert와 add는 한 단어 차이입니다.

배치는 특정 체인에 있는 규칙을 기준으로 합니다. 같은 문장을 다른 체인이나 다른 hook 우선순위로 옮기면 규칙 구문이 맞아 보여도 어떤 패킷을 보는지가 달라집니다.

핸들은 행 번호가 아니라 규칙을 식별합니다

42 같은 핸들은 현재 규칙 집합 상태에서의 식별자입니다. 마흔두 번째 규칙이 아니며, 호스트, 재구축, 또는 구성을 다시 로드하는 관리자 사이에서 안정적이지 않습니다.

고정 지점을 고르기 전에 체인과 실제 최종 드롭을 찾으십시오. 그런 다음 드롭을 보여 주는 같은 목록에서 그 규칙의 핸들을 확인하여 번호와 규칙을 함께 읽도록 하십시오. 오래된 목록에서 읽은 핸들은 이미 다른 규칙의 것일 수 있습니다. 변경을 적용할 세션에서 다시 읽으십시오.

iptables --version
nft -a list ruleset

iptables 버전은 어떤 백엔드가 사용 중인지 알려 줍니다. iptables-nft 규칙 집합과 독립적으로 관리되는 네이티브 테이블은 공존할 수 있으므로, 한 프런트엔드의 목록이 자동으로 완전한 필터링 그림은 아닙니다. 체인을 고르기 전에 두 보기를 모두 확인하십시오.

실제로 드롭하는 체인과 규칙을 찾으십시오

input hook, 체인 우선순위, 그리고 이 리스너 흐름을 거부하는 규칙을 읽으십시오. inet 테이블은 두 주소 패밀리를 모두 담을 수 있지만, 개별 규칙은 여전히 IPv4에만 일치할 수 있습니다.

승인된 피어 하나를 택하고, 예로 문서용 대역의 198.51.100.25를 사용하십시오. 검토된 네이티브 파일은 핸들 42 앞에 외부 허용을 둘 수 있습니다:

insert rule inet filter input handle 42 iifname "eth0" ip saddr 198.51.100.25 udp dport { 500, 4500 } counter accept

점검 후 패밀리, 테이블, 체인, 핸들, 인그레스 인터페이스, 피어를 바꾸십시오. 예제는 nft 1.0.9용으로 문서화된 핸들 위치 형식을 사용하며, 이는 입력 파일에 속하고, 명령을 대화식으로 입력할 때의 중괄호 인용은 별개의 문제입니다.

구성 소유자를 분명히 하십시오. 규칙을 다시 만드는 관리자는 런타임 편집을 덮어쓸 수 있고, 오래된 핸들을 하드코딩한 부팅 스크립트는 실패하거나 잘못된 규칙에 붙습니다.

허용은 범위가 있고, 드롭은 최종적입니다

허용 판정은 현재 경로에서 평가를 끝내지만, 나중에 적용되는 기본 체인이 여전히 패킷을 드롭할 수 있습니다. 드롭 판정은 최종적입니다. 그래서 증가하는 허용 카운터는 흐름이 성공했다는 증거가 아닙니다.

체인 하나를 따로 보지 말고 관련된 모든 hook 우선순위를 점검하십시오. 패킷은 input 필터를 통과하고도 다른 우선순위의 다른 테이블 hook에서 거부될 수 있습니다. 흐름을 볼 수 있는 모든 기본 체인을 나열하십시오.

그 규칙은 외부 리스너 교환만 다룹니다. 전송 계층으로 캡슐화된 ESP, 네이티브 ESP, IPv6 피어, 터널 안에서 복호화된 트래픽은 모두 각자의 정책이 필요합니다. 이것은 사이트 VPN의 완전한 방화벽이 아닙니다.

파일을 확인한 다음 라이브 결과를 검증하십시오

적용하기 전에 검토된 파일에서 구문 및 트랜잭션 검사를 실행하십시오. 검사 모드는 nft가 변경을 파싱하고 준비할 수 있는지 보고할 뿐, 적용하지 않으며 다른 hook이 패킷을 허용할 것인지 증명하지 않습니다. 파일은 소유자가 적용할 때까지 제안으로 남습니다:

nft -c -f reviewed-vpn-rule.nft

소유자의 통제된 절차로 적용하고 복구 접근을 유지하십시오. 규칙이 틀리면 앞에 두려던 드롭이 고치는 데 쓰는 경로까지 끊을 수 있습니다.

변경 후 새로 허용된 피어 시도를 관찰하고 승인된 피어 밖의 출처가 여전히 거부되는지 확인한 다음, 지속 규칙은 규칙 집합을 소유한 관리자로 옮기십시오. 런타임 핸들은 현재 객체를 찾을 뿐 부팅 사이에서 식별하지 않기 때문입니다.