NEW만 다루는 방화벽 규칙은 모든 WAN 경로를 닫지 않는다

WAN에서 새 아웃바운드 연결을 거부하는 것은 실패 시 닫히는 정책처럼 보이지만, 보이는 것보다 좁은 약속입니다. 이미 존재하는 흐름에 속한 패킷은 이 규칙에 해당하지 않고, 많은 응답도 마찬가지입니다. 이 간극을 놓치기 쉬운 이유는 규칙이 인터페이스를 덮는 것처럼 읽히고 그 위의 한 연결 상태를 덮는 것으로 읽히지 않기 때문입니다. 상태 일치를 판정으로 읽는 것이 바로 닫혔다는 잘못된 느낌을 만듭니다.

상태는 일치 조건이지 판정이 아니다

연결 추적은 방화벽이 이미 본 것을 기준으로 패킷을 분류하며, 애플리케이션이 믿는 것을 기준으로 하지 않습니다. 양방향으로 관찰된 흐름은 설정된 것으로 간주되고, 그 이후 패킷은 아래 경로가 터널에서 일반 업링크로 바뀌어도 설정된 상태로 남습니다. 인바운드 연결에 대한 응답도 설정된 트래픽일 수 있습니다. 그 패킷들은 다시 새 것이 되지 않습니다.

그래서 새 연결만 대상으로 하는 규칙은 보호된 모든 패킷이 차단된다는 것을 입증할 수 없습니다. 다른 상태들은 규칙 집합의 나머지가 그것들을 어떻게 다루는지에 맡겨지며, 그것은 체인 앞쪽에 놓인 허용일 수 있습니다.

규칙을 주변과 함께 읽으십시오

차단 앞에 놓인 설정된 트래픽과 관련 트래픽에 대한 넓은 허용은 차단이 평가되기도 전에 패킷을 통과시킵니다. 뒤의 규칙에서 상태 조건을 제거해도 평가가 거기에 닿지 않으므로 바뀌지 않습니다. 결과는 순서가 결정하고, 어떤 패킷이 그 순서에 닿는지는 상태 일치가 결정합니다.

편집한 파일이 아니라 실제로 적용되는 규칙 집합을, 다른 체인으로의 점프와 플랫폼이 생성하는 모든 것을 포함해 점검하십시오. iptables로 관리되는 라우터에서는 체인을 나열하면 규칙 정의가 보이며, 그것이 참조하는 체인도 따라가야 합니다. 네이티브 nftables 시스템은 펌웨어가 동일한 체인을 생성하는 경우가 드물기 때문에 자체 규칙 집합과 훅 우선순위를 점검해야 합니다.

카운터는 어느 규칙이 실제로 일치했는지 알려 주며, 보통 결정 후에 찍은 패킷 캡처보다 정보가 많습니다. 카운터가 영인 규칙에는 위치가 무엇을 암시하든 도달하지 않았습니다.

금지를 상태와 독립적으로 표현하십시오

클라이언트 그룹이 터널 밖에서 인터넷에 절대 도달해서는 안 된다면, 하나의 상태로 근사하지 말고 그대로 말하십시오. 규칙은 연결 상태에 의존하지 않고 출발지, 출구, 목적지로 선택해야 하며, 이전 허용이 우회할 수 없는 위치에 있어야 합니다. 그러면 관리 접근과 로컬 네트워크 예외는 각자의 명시적 규칙을 갖게 되어 의도가 정책에 드러납니다.

drop 대신 reject를 선택하면 일치한 트래픽이 실패하는 방식이 달라지고, 규칙이 선택하는 패킷 집합이 커지지는 않습니다. 거부된 연결과 조용한 시간 초과는 같은 선택을 가리키는 서로 다른 증상입니다.

WAN을 통해 원격에서 시작된 접근에 대한 응답을 의도적으로 허용하는 정책은 정당화될 수 있습니다. 다만 터널만 통한 완전한 격리로 제시하지 말고 그렇게 설명해야 합니다.

그룹 안에 실제로 누가 있는지 확인하십시오

예시는 하나의 인터페이스에서 하나의 프리픽스로 전달되는 IPv4 트래픽을 다룹니다. IPv6, 두 번째 업링크, 라우터 자체가 생성하는 트래픽에 대해서는 아무 말도 하지 않습니다. DNS 확인자 역할을 하는 라우터는 자체 업스트림 질의를 보내며, 그것은 forward 체인을 전혀 지나지 않습니다.

그 밖으로 이동한 장치는 정책이 아니라 우연히 직접 연결되므로, 보호된 클라이언트가 여전히 선택한 프리픽스 안의 주소를 가지고 있는지 확인하십시오. 예외 설계를 검토하지 않고 차단을 LAN 전체로 넓히면 자신의 관리 경로를 없애기 쉽습니다.

iptables -S FORWARD
iptables -L FORWARD -v -n
cat /proc/net/nf_conntrack | grep -c ESTABLISHED

그다음 오래된 흐름을 새 흐름 옆에서 시험하십시오. 새 연결 시도와 이미 활성화된 양방향 전송은 이 규칙 아래에서 다르게 동작하며, 둘 다 시험해야 실제로 어떤 정책인지 드러납니다.