VPN은 연결됐지만 방화벽이 여전히 차단한다: 어느 쪽인지 구분하는 방법

터널은 올라가 있는데 한 포트만 계속 실패한다. 경로를 읽고, 다음으로 각 계층의 정책을 읽고, 둘 중 하나를 끄는 대신 가장 좁은 규칙을 바꾼다.

클라이언트는 연결됐다고 하고, 리소스는 여전히 거부하며, 다음의 흔한 수법은 무언가를 끄는 것입니다. 그 문장의 두 제어는 서로 다른 일을 합니다. VPN은 보호되는 트래픽의 경로를 만들고, 방화벽은 연결마다 통과 여부를 정합니다. 거부하는 정책을 가진 정상 터널은 사용자 자리에서는 고장 난 터널과 똑같이 보이므로, 어느 계층이 답하는지 찾는 것이 일입니다. 제가 따르는 순서는 다음과 같고, 멈추라는 판독도 함께 둡니다.

경로와 정책을 분리한다

실패의 모양부터 봅니다. 무료 정보이기 때문입니다. 패킷 드롭은 시간 초과를 만듭니다. 클라이언트가 다시 시도하고, 아무것도 돌아오지 않으며, 명령은 포기할 때까지 매달립니다. 거부는 거절이나 재설정이며, 무언가가 답하고 아니라고 말한 것입니다. 듣지 않는 서비스는 호스트 자체에서 거부하며, 방화벽은 전혀 관여하지 않습니다.

그 세 결과는 서로 다른 계층을 가리킵니다. 시간 초과는 어딘가의 정책이 조용히 버리거나, 경로가 기계를 떠나지 않는다는 뜻입니다. 거부는 호스트에 도달했고 그 스택이나 호스트 방화벽이 거절했다는 뜻입니다. 완전한 침묵, 터널 인터페이스가 올라가 있고 목적지로 가는 경로가 없다면 경로가 틀렸고 어떤 방화벽 규칙도 고치지 못합니다.

경로를 한 번에 읽는다

규칙을 하나도 보기 전에 터널이 목적지를 덮는지 확인합니다. 사무실 서브넷만 나르는 분할 터널은 다른 범위로 요청을 보내지 않으며, 그때 실패는 방화벽 차단처럼 보이지만 그렇지 않습니다:

ip route get 10.20.4.15
ip -brief address show
wg show
sudo ipsec statusall

경로 출력은 패킷이 나갈 인터페이스와 그것이 지닐 출발지 주소를 알려줍니다. 그 인터페이스가 터널이 아니라 물리 네트워크 카드라면, 문제는 라우팅이나 터널의 허용 범위에 있고, 방화벽이 아니라 VPN 설정에 속합니다.

VPN에 특유한 함정 하나는 따로 점검할 가치가 있습니다. WireGuard에서 피어의 AllowedIPs 은 경로이자 암호학적 필터입니다. 출발지 주소가 피어의 허용 집합과 맞지 않는 패킷은 어떤 방화벽 규칙도 보기 전에 버려집니다. 그래서 완전히 올바른 호스트 방화벽이 정책처럼 보이는 조용한 버림 뒤에 있을 수 있고, 고침은 규칙이 아니라 키 설정 한 줄입니다.

답하는 계층에서 정책을 읽는다

경로가 맞으면 호스트에서 바깥으로 정책을 훑고, 카운터가 움직이는 단 하나의 계층을 보십시오:

ss -ltn | grep ':443'
sudo nft list ruleset
sudo iptables -S INPUT
sudo ufw status verbose

듣고 있는 소켓은 규칙과 다른 질문에 답합니다. 포트에서 아무것도 듣지 않으면 커널이 연결을 거부하고 어떤 인바운드 규칙도 관련이 없습니다. 소켓이 있고 원격 클라이언트의 연결이 시간 초과되면 경로 어딘가에서 버림이 일어나고 있으며, 규칙 카운터가 그것이 여기서 일어나는지 알려줍니다.

바깥에서 추측하는 대신 의심되는 프로필이나 체인에 로깅을 켭니다. 출발지, 목적지, 포트를 밝히는 버림 하나가 기록되면 계층과 규칙을 식별하고, 패킷이 도착했음도 증명합니다. 이는 클라이언트 쪽 어떤 시험도 확립할 수 없습니다.

터널이 거기서 끝나면 게이트웨이의 결정을 읽는다

사이트 간이나 원격 접속 게이트웨이에서 VPN은 사용자를 인증하고 정책은 리소스를 승인하며, 이는 별개의 부여입니다. 터널에 들어온 사용자가 모든 내부 호스트에 자동으로 들어가는 것은 아니며, 거부는 터널 자체가 건강한 채로 전달 규칙에서 오는 경우가 많습니다. 같은 분리는 IPsec에도 나타나는데, 트래픽을 고르는 보안 정책과 그것을 들여보내는 필터가 다르며, 그래서 둘은 RFC 4301.

돌아오는 경로도 가는 경로만큼 세심하게 확인합니다. 상태 기반 필터링은 응답을 봐야 한다, 그래서 터널을 지나는 한 방향과 그 주위를 도는 반대 방향의 비대칭 라우팅은 무작위로 보이고 일부 클라이언트에서만 재현되는 버림을 만듭니다. 트래픽이 게이트웨이에 닿아 멈추면, 무엇이든 넓히기 전에 전달 규칙과 돌아오는 경로를 함께 읽습니다.

게이트웨이는 NAT나 매스커레이드 규칙이 실제 출발지를 숨길 수 있는 곳이기도 합니다. 내부 호스트가 클라이언트 대신 게이트웨이 주소를 본다면, 클라이언트 풀에 맞아야 할 그들의 호스트 방화벽 규칙은 결코 맞지 않을 것이고, 고침은 각 서버가 아니라 게이트웨이에 속합니다.

가장 좁은 계층을 바꾸고 나서 검증한다

넓은 수리를 거부하십시오. 호스트 방화벽을 끄고, 모두 허용하는 규칙을 넣고, 모든 인터페이스를 신뢰 프로필로 밀어 넣는 것은 각각 제 일을 하던 제어를 없애며, 변경은 사고 이후에도 남습니다. 출발지 범위와 문제의 포트로 제한한 규칙은 검토하기 쉽고, 제거하기 쉽고, 기계의 나머지 정책을 온전히 남깁니다.

실패한 그 시험을 같은 클라이언트에서, 다시 연결한 뒤 한 번 더 검증하는 것은 터널이 재협상하기 전에 맞던 규칙이 그 뒤로 맞지 않을 수 있기 때문입니다:

nc -vz 10.20.4.15 443
curl -v --max-time 5 https://10.20.4.15/

닫기 전에:

  • 목적지로 가는 경로가 터널 인터페이스로 나가고, 출발지 주소가 정책이 기대하는 것과 맞는다.
  • 포트에서 무언가 듣고 있고, 거부나 시간 초과는 추정이 아니라 지목된 규칙에 귀속된다.
  • 게이트웨이가 양방향으로 전달하고, 목적지는 규칙을 쓴 출발지를 본다.
  • 시험을 통과시키려고 어떤 제어도 끄지 않았고, 마지막 변경은 하나의 출발지 범위와 하나의 포트를 지목한다.

관련 글