방화벽 규칙 변경이 작동하지 않음: 규칙 순서와 연결 상태

규칙을 편집하고 규칙 집합을 다시 불러왔는데 터널은 이전과 똑같이 동작합니다. 이 결과에는 흔한 원인이 두 가지가 있고, 각각 다른 테스트가 필요합니다. 새 규칙이 이미 패킷을 허용한 앞선 규칙 뒤에 있는지, 아니면 관찰 중인 교환이 변경으로는 다시 평가되지 않는 추적된 연결인지입니다. 파일 속 규칙은 의도를 표현할 뿐이고, 패킷을 결정하는 것은 그것이 실제로 만나는 활성 경로입니다. 아래 점검을 순서대로 진행하고 그동안 돌아갈 길을 확보해 두세요.

규칙 순서와 연결 상태는 서로 다른 고장이다

순서가 있는 체인은 위에서 아래로 평가되고, 최종 판정에 도달한 첫 규칙이 그 체인의 순회를 끝냅니다. 꼼꼼히 작성한 잠금 규칙 위에 넓은 허용을 두면 잠금 규칙은 문서가 됩니다. 규칙 집합에는 있지만 카운터는 영이고 어떤 패킷도 그곳에 도달하지 않습니다. 같은 내용을 다른 체인에 적용해도 아무것도 증명하지 못합니다. nftables에서는 기본 체인이 우선순위에 따라 훅에 연결되므로, 한 체인의 허용이 다른 훅이나 우선순위의 다른 체인이 같은 패킷을 보는 것을 막지 않습니다.

연결 추적이 두 번째 증상을 만들고, 밖에서 보면 완전히 똑같아 보입니다. 흐름이 상태 테이블에 들어가면 체인 상단 근처의 established-or-related 허용이 새 규칙을 참조하기도 전에 반환됩니다. NAT 매핑도 같은 성질을 지닙니다. 변환은 흐름이 시작될 때 고정되므로, 편집한 postrouting 규칙은 이미 실행 중인 세션을 다시 쓰지 않습니다. 09:00에 새 연결에서는 변경이 효과가 있는 것처럼 보이고 08:55에 누군가 연 세션에서는 아무 일도 하지 않는 것처럼 보이는 이유가 여기에 있습니다.

클라우드 보안 그룹은 iptables로 배운 사람들을 잡는 세 번째 모델을 더합니다. 인바운드 규칙은 첫 일치 순회가 아니라 집합으로 평가되는 허용 목록이고, 상태를 유지하며, 허용 규칙을 제거해도 이미 추적 중인 흐름은 종료되지 않습니다. 첫 일치 의미론이 없는 플랫폼에서 그것을 가정하면 확신에 찬 잘못된 결론에 이릅니다.

편집한 파일이 아니라 활성 규칙 집합을 읽으세요

커널이 지금 실제로 적용하는 것부터 시작하세요. 적용된 적 없는 저장 구성은 놀라울 만큼 많은 불변 동작을 설명해 주며, 배제하는 데는 명령 하나면 됩니다.

nft list ruleset
iptables-save

다음으로 규칙에 도달하기는 하는지 물어보세요. 패킷 카운터가 그것을 직접 알려 주고, 의도에 관한 어떤 추론보다 잘 알려 줍니다.

iptables -L FORWARD -v -n --line-numbers
nft list chain inet filter forward

실제 테스트 시도 뒤에도 패킷이 영인 잠금 규칙은 정책 문제가 아니라 위치 문제입니다. 옮기는 것은 한 줄짜리 변경이고, 원래 버그를 만든 것은 바로 그 문법입니다. iptables에서는 -I가 맨 앞에 삽입하고 -A가 끝에 추가합니다. nftables에서는 insert가 체인 맨 앞에 규칙을 놓고 add가 끝에 추가합니다. 규칙이 이겨야 한다면 우연히 로드된 순서를 믿는 대신 분명히 밝히세요.

흐름이 추적되는지 증명하기

규칙을 탓하기 전에 그 트래픽이 애초에 추적된 연결인지 확인하세요. 상태 테이블을 전부 쏟아내지 말고 해당 흐름만 물어보세요.

conntrack -L -p tcp --dport 1194
conntrack -E -p tcp --dport 1194

목록은 상태와 남은 타임아웃을 보여 주며, 이것으로 확립된 세션과 새 시도를 구분합니다. 이벤트 모드는 갱신을 발생하는 대로 출력하므로 클라이언트를 다시 연결할 때 유용합니다. 무엇이든 건드리기 전에 흐름이 확립된 상태로 존재한다면, 필터 규칙을 어떻게 편집해도 그 운명은 바뀌지 않습니다. 이것은 방화벽의 버그가 아니라 상태 기반 필터링의 계약입니다.

운영 게이트웨이에서 테이블 전체를 비우는 지름길에 저항하세요.conntrack -F는 사용할 수 있지만, 작업 중인 관리 세션과 셸을 나르는 터널을 포함해 머신의 모든 추적된 흐름을 파괴합니다. 개별 항목은 정말 필요할 때 삭제할 수 있지만, 새 소스 포트에서 만드는 새 흐름이 보통 더 깨끗한 실험입니다.

추적되지 않는 경로도 있고, 그쪽은 반대로 동작합니다. raw 테이블에서 notrack로 표시된 트래픽, 정상 훅을 우회하는 일부 터널, 흐름을 두 게이트웨이로 나누는 비대칭 라우팅은 모두 패킷을 하나씩 평가하게 만들거나 양쪽 끝에서 상태가 만들어지지 않게 합니다. 카운터가 패킷마다 움직인다면 순서를 의심하기 전에 그런 경로를 의심하세요.

돌아갈 길을 확보한 새 흐름에서 테스트하기

원격 접근을 끊을 수 있는 규칙을 시험하기 전에 복구 경로를 마련하세요. 공급자 콘솔, 시리얼 콘솔, 대역 외 관리 주소, 또는 그 규칙에 맞지 않는 두 번째 인터페이스입니다. 롤백 타이머도 합리적인 동반자인데, 테스트 도중 세션이 죽어도 이전 규칙 집합을 복원해 줍니다.

그다음 상태가 이미 덮을 수 없었던 교환으로 시험하세요. 클라이언트를 끊었다가 다시 연결해 새 다섯 요소 조합이 만들어지게 하고, 그동안 양쪽 끝을 관찰하세요.

tcpdump -ni eth0 'tcp port 1194'
journalctl -k -n 50 --no-pager

테스트는 양방향으로 수행하세요. 새 인바운드 핸드셰이크를 막는 규칙도 응답 경로는 허용할 수 있고 그 반대도 가능하며, 한 방향만 되는 결과가 잠금이 반만 작동하는 흔한 이유입니다. 테스트 후 한 번 더 다시 연결해 정상 상태를 확인하고, 정당한 관리 접근이 살아남았는지 점검하세요. 포트 하나에 맞춰 쓴 규칙은 의도보다 넓은 범위에 일치하는 습관이 있습니다.

규칙과 함께 목적과 위치를 기록하기

기록된 목적이 없는 규칙은 아무도 지우려 하지 않는 규칙입니다. 잠금 항목마다 보호하는 흐름, 그 흐름이 사는 체인과 훅, 더 넓은 허용에 대해 지켜야 할 위치, 그리고 그것을 증명한 테스트를 함께 남기세요. 반년 뒤 누군가 주변 규칙 집합을 편집할 때, 그 메모만이 이 위치가 의도적이었다는 유일한 경고입니다.

변경을 닫기 전에 네 가지를 확인하세요. 실행 중인 규칙 집합이 파일과 일치하는지, 새 시도 뒤에 새 규칙의 카운터가 영이 아닌지, 반대 방향과 관리 접근이 여전히 되는지, 그리고 변경 이전부터 이어진 세션이 아니라 정상 상태를 증명하기 위해 한 번 다시 연결했는지입니다. 이 중 하나라도 확인되지 않았다면 터널이 무엇을 하든 변경은 끝나지 않은 것입니다.