VPN 뒤의 서비스에는 ufw allow 443 이 아무 효과가 없었습니다

VPN 클라이언트에서 ping은 성공하지만 TCP 서비스는 시간 초과되고 ufw allow 443/tcp 은 아무것도 바꾸지 않습니다. 애플리케이션이 게이트웨이 자체가 아니라 게이트웨이 뒤의 호스트에서 실행될 때, 그 허용은 잘못된 트래픽 경로에 작성된 것입니다. 패킷은 방화벽으로 향하지 않고 로컬 프로세스에 전달되지 않으므로 입력 규칙은 그 패킷을 결코 보지 못합니다. 해결책은 전달되는 흐름을 겨냥한 경로 규칙이며, 그 증거는 이미 로그에 있습니다.

목적지가 로컬인지 전달되는지 판단하세요

커널이 보는 그대로 패킷을 읽으세요. 게이트웨이의 서비스로 전달되는 트래픽은 로컬 입력입니다. 게이트웨이가 다른 호스트로 라우팅하는 트래픽은 전달되는 트래픽이며, UFW는 두 경로에 대해 별도의 규칙 집합을 유지합니다. 이 구분은 패킷이 도착한 인터페이스가 아니라 목적지 주소와 경로 조회가 결정합니다.

IN과 OUT 필드 모두에 같은 인터페이스를 표시하는 로그 줄도, 한 장치로 클라이언트를 들이고 내보내는 터널이 정확히 그렇게 보이기 때문에, 여전히 라우팅된 패킷을 설명할 수 있습니다. 목적지 주소가 인터페이스 이름보다 이 질문을 더 빨리 해결합니다. 같은 이름을 두 번 보는 것은 로컬 전달을 증명하지 않으며, 배포가 만든 적 없는 터널 인터페이스를 지어내도 도움이 되지 않습니다.

어떤 규칙을 추가하기 전에 차단을 읽으세요

승인된 연결 시도 하나를 재현하고 게이트웨이가 기록한 대로 출발지, 목적지, 프로토콜, 목적지 포트를 캡처하세요. 그 네 값을 로그 항목과 서비스의 실제 위치와 비교하세요. 이전의 성공한 ping은 그 자체의 교환만 허용되었음을 증명하며, 방화벽은 애플리케이션으로 향하는 TCP SYN을 전혀 다르게 처리할 수 있습니다.

sudo dmesg | grep "UFW BLOCK" | tail -n 5
sudo ufw status numbered

첫 번째 명령은 판정을 그 필드와 함께 반환하고, 두 번째는 무엇이 이미 로드되었고 어떤 순서인지 보여 줍니다. 규칙 위에 있는 이전의 거부가 빠진 규칙 없이도 같은 증상을 설명하므로, 무엇이든 편집하기 전에 둘 다 읽으세요.

가장 좁은 적합한 경로 규칙을 작성하세요

이 예에서 클라이언트는 172.20.8.0/24 에서 tun0 로 들어오고, 서비스는 10.30.0.15 의 8443 포트에서 수신하며, 게이트웨이는 ens5 을 통해 나갑니다. 이 값들은 클라우드 VPC 기본값인 10.0.0.0/16 이나 가정용 192.168.0.0/16 과 전혀 닮지 않도록 선택되었고, 8443 은 예제를 게이트웨이 자체의 443 수신기에서 멀리 둡니다.

sudo ufw --dry-run route allow in on tun0 out on ens5 proto tcp from 172.20.8.0/24 to 10.30.0.15 port 8443

드라이 런은 만들어질 규칙 집합을 출력하며, 규칙이 기존 거부 앞에 놓이는지 뒤에 놓이는지 보는 가장 저렴한 방법입니다. 인터페이스 이름과 내부 주소는 예제가 아니라 배포와 대조해 확인하고, 목적지 NAT가 먼저 실행되면 필터는 번역된 목적지를 본다는 점을 기억하세요.

반환 경로를 상태 기반으로 유지하세요

UFW는 허용된 연결을 추적하므로 허용된 전달 흐름에 대한 응답은 명시적인 역방향 규칙 없이 허용됩니다. 작동하게 하려고 반대 방향에 무제한 규칙을 추가하면 정책이 단일 서비스보다 훨씬 넓어지며 일반적인 요청-응답 교환에는 필요하지 않습니다. 반환 경로는 암묵적으로, 규칙 집합은 읽기 쉽게 유지하세요.

드라이 런이 의도와 일치한 뒤에만 규칙을 적용하고, 그다음 정렬된 목록이 예상 위치에 그것을 표시하는지 확인하세요. VPN 수신기와 관리 규칙은 별개의 사안으로 유지해야 하며, 그것들을 바꾸는 것은 애플리케이션 하나를 허용하는 것과 다른 결정입니다. 토폴로지가 적힌 같은 곳에 변경을 기록해, 다음 엔지니어가 패킷 캡처에서 그것을 다시 발견하지 않게 하세요.

sudo ufw route allow in on tun0 out on ens5 proto tcp from 172.20.8.0/24 to 10.30.0.15 port 8443
sudo ufw status numbered

UFW가 대신 강제할 수 없는 것을 확인하세요

올바른 규칙에도 여전히 커널 전달과 서비스에 도달하는 경로가 필요합니다. 방화벽을 두 번째로 탓하기 전에 둘 다 확인하세요.

sysctl net.ipv4.ip_forward
ip route get 10.30.0.15

그다음 호스트 밖을 보세요. 클라우드 인스턴스에서 게스트의 UFW 정책은 보안 그룹, 서브넷 ACL, 제공자의 자체 전달 구성을 대체하지 않으므로, 로컬 차단은 한 계층에 대한 증거이며 다른 모든 계층이 서비스를 허용한다는 증거는 아닙니다.

방화벽을 켠 상태에서 허용된 출발지와 무관한 출발지 양쪽에서 새 연결을 시험해 마무리하세요. UFW를 비활성화하면 같은 명령에서 증상이 사라지고 증거도 파괴되므로, 그것은 첫 번째가 아니라 마지막 실험이어야 합니다.