VPN 터널 주소가 인바운드 포트를 열지 않는 이유
터널 주소는 해당 주소로 라우팅할 수 있는 피어에게 클라이언트를 식별시킬 뿐이며 결코 리스너를 만들지 않습니다. 바인딩, 반환 경로, 그다음 정책을 확인하세요.
사무실 VPN에 연결하고 포트 8443에서 작은 서비스를 시작한 뒤 터널 주소를 동료에게 보내면, 클라이언트는 여전히 연결됨을 보고하는데 연결은 실패합니다. 터널에는 아무것도 고장 나지 않았고 주소는 할당되었으며 세션은 살아 있고, 응답을 실어 나를 패킷이 그저 한 번도 허용되지 않을 뿐입니다. 아래 세 가지 점검을 순서대로 수행하고, 각각 해결책이 다르며 그중 하나만 VPN과 관련이 있으므로 실패하는 지점에서 멈추세요.
소켓이 실제로 어디에 바인딩되어 있는지부터 시작하세요
무언가가 라우팅되기 전에, 호출자가 도달할 수 있는 주소에서 무언가가 수신하고 있어야 합니다. 개발 서버가 흔한 원인인데, 많은 서버가 기본적으로 loopback에 바인딩되어 같은 머신에서 시작된 연결만 받아들이기 때문입니다. 터널 주소는 그 바인딩을 바꾸지 않으며, 운영 체제는 VPN이 관여하기 훨씬 전에 연결을 거부합니다.
ss -ltnp | grep 8443
netstat -ano | findstr 8443상태가 아니라 로컬 주소 열을 읽으세요. 127.0.0.1:8443은 loopback만을 뜻하며, 해결책은 0.0.0.0 또는 터널 주소 자체에 바인딩하는 것입니다. 0.0.0.0:8443은 모든 인터페이스에서 받아들이는데, 이는 머신에 공인 주소도 있을 때 대부분이 의도하는 것보다 넓습니다. 10.64.7.15:8443은 동료가 도달할 수 있는 곳에서만 수신하는 좁은 버전입니다. 같은 출력에서 프로세스 이름도 보세요. 이전 테스트에서 남은 인스턴스가 포트가 열린 것처럼 보이고 잘못된 내용으로 응답하는 흔한 원인입니다.
그다음 그 주소로 라우팅할 수 있는 것이 있는지 물으세요
터널 주소는 그 프리픽스를 터널로 보내도록 구성된 피어에게만 의미가 있습니다. 동료의 머신에는 자체 테이블이 있고, 터널 서브넷에 대한 경로가 없으면 패킷은 기본 게이트웨이로 가서 주소가 존재하는지 모르는 곳에서 사라집니다. 이것은 호출자 쪽의 라우팅 문제이지 당신 쪽의 권한 문제가 아닙니다.
| Symptom from the caller | What it usually means | Where to look next |
|---|---|---|
| Connection refused immediately | Nothing is listening on the address the packet reached | The bind address and the process owning the port |
| Connection times out with no reply | A policy dropped the packet, or no route returns | Server forwarding, host firewall, cloud security group |
| Works from the same machine only | Listener is on loopback, or no route reaches the tunnel address | Bind address, then the caller's route to that prefix |
두 클라이언트 사이의 서버도 마찬가지로 중요합니다. 일반적인 원격 접속 설계에서는 각 클라이언트가 게이트웨이로 아웃바운드 연결을 열고 게이트웨이가 그 플로우의 상태를 유지하므로, 응답은 이미 알고 있는 경로로 돌아옵니다. 한 클라이언트에서 다른 클라이언트로의 연결은 게이트웨이가 받아들여 전달해야 하는 새 플로우이며, 많은 배포가 클라이언트를 서로 격리하기 위해 이를 의도적으로 끕니다. 소비자용 VPN 서비스는 보통 기본적으로 격리하고, 기업 게이트웨이는 때때로 그룹별로 허용합니다.
호스트에서 무엇이든 바꾸기 전에 방향을 확인하세요. 터널 주소가 게이트웨이 자체에서는 응답하지만 피어에서는 응답하지 않는다면 차이는 게이트웨이의 클라이언트 간 설정이며, 로컬 방화벽 편집으로는 결코 대신할 수 없습니다.
마지막으로, 플로우를 허용하는 정책을 찾으세요
라우팅된 패킷과 응답하는 서비스 사이에는 세 개의 정책 계층이 있습니다. VPN 서버의 전달 결정, 호스트 방화벽, 그리고 인스턴스 앞의 클라우드 보안 그룹입니다. 셋 모두 일치해야 하고 서로 다른 방식으로 실패하므로, 위 표의 증상이 브라우저의 오류 메시지보다 유용합니다.
호스트 방화벽은 바인딩에 성공한 뒤 사람들이 잊는 계층입니다. LAN 인터페이스에서 포트를 허용하는 규칙이 터널 인터페이스에서도 자동으로 허용하지는 않습니다. 인터페이스 단위 규칙은 올바른 설계이며, 사무실에서는 되고 집에서는 안 되는 서비스의 흔한 원인이기도 합니다. 규칙의 포트 번호가 아니라 적용 범위를 읽으세요.
상태 기반 필터링은 반대 경우를 설명합니다. 노트북에서 나가는 연결은 상태를 만들고, 그에 대한 응답은 인바운드 규칙 없이 허용됩니다. 동료의 연결은 뒤에 상태가 없는 완전히 새로운 플로우이므로 명시적 허용이 필요합니다. 이 비대칭성이 바로 자신의 머신에서 동작하는 브라우저 세션이 외부 접근 가능성에 대해 아무것도 말해 주지 않는 이유입니다.
한 가지 점검이 실패하면 터널이 아니라 설계를 바꾸세요
동료가 당신의 로컬 서비스를 열어야 한다는 요구라면, 정직한 답은 보통 인바운드 접근을 위해 만들어진 메커니즘입니다. 역방향 SSH 터널이 가장 작습니다. 당신의 머신이 동료가 이미 도달할 수 있는 호스트로 아웃바운드 연결하고, 리스너는 그 호스트에 존재합니다.
ssh -N -R 8443:127.0.0.1:8443 [email protected]릴레이에는 SSH 서버 구성에서 GatewayPorts clientspecified가 필요합니다. 그렇지 않으면 전달된 리스너가 릴레이의 loopback에 바인딩되어 동료가 이전과 같은 거부를 겪습니다. 한나절보다 오래 유지되는 것에는 상태 확인과 게시된 이름의 인증서를 갖춘 로드 밸런서나 ingress가 더 나은 도구이고, 두 네트워크가 정말로 통신해야 할 때는 두 서브넷 모두에 대한 경로가 있는 사이트 간 터널이 정답입니다.
이 설계 각각은 노출을 명시적으로 만듭니다. 그것이 핵심입니다. VPN은 이미 사용 권한이 있던 네트워크 사이에서 패킷을 옮길 뿐이며, 서비스를 게시하지 않고 노트북을 인터넷에 노출된 호스트로 바꾸지도 않습니다. 세 계층 중 무엇을 바꿀지 결정하는 것이 과제이고, 터널이 그중 하나인 경우는 드뭅니다.