포트 포워딩 없이 NAT 뒤의 워크스테이션에 접근하기
인바운드 포트가 없는 워크스테이션도 허브, 릴레이 또는 앱 브로커를 통해 접근할 수 있습니다. 하나를 고르기 전에 각 설계가 무엇을 보장하는지 비교하십시오.
통신사 NAT와 잠긴 사무실 라우터 뒤의 두 엔드포인트에는 전달할 인바운드 포트가 없는데도 반사적으로 포트를 요청하게 됩니다. 더 나은 질문은 어느 쪽이 밖으로 연결할 수 있으며 어떤 접근 가능한 서비스가 트래픽을 실어 나를 수 있느냐입니다. 네 가지 설계는 그 질문에 서로 다르게 답하며, 경로가 막히면 서로 다른 방식으로 실패합니다. 이들 중에서 고르는 일은 프로토콜 이름이 아니라 보장의 비교입니다.
네 가지 설계, 네 가지 다른 약속
아래 표는 짧은 판본입니다. 가운데 열은 시험해 볼 수 있는 약속으로, 오른쪽 열은 아무도 하지 않은 약속으로 읽으십시오.
| Design | Who initiates | Promise you get | Promise you do not get |
|---|---|---|---|
| Routed VPN hub | Both ends, outbound to the hub | A routed path to permitted prefixes | Access to services no policy allows |
| Peer traversal with ICE | Both peers to a rendezvous service | A path tested between the two peers | A direct path through every NAT |
| TURN relay | Client outbound to a relay | Transport that survives symmetric NAT | Peer discovery or a usable directory |
| Application broker | Workstation outbound to a broker | One audited application session | Subnet-wide reachability |
어느 행이 적용되는지는 선호가 아니라 작업에 달려 있습니다. 원격 데스크톱 세션 하나, 관리용 셸 하나, 그리고 사설 서브넷 전체에 대한 접근 은 우연히 같은 기계와 관련되더라도 같은 진입점을 필요로 하지 않는 세 가지 요구 사항입니다.
허브는 누가 밖으로 연결하는지를 바꿀 뿐, 무엇이 허용되는지는 바꾸지 않습니다
라우팅 허브 설계에서 원격 노트북과 워크스테이션, 또는 그 앞의 사이트 게이트웨이는 각각 양쪽이 도달할 수 있는 서비스로 나가는 터널을 엽니다. 워크스테이션의 라우터에서는 아무것도 요청되지 않은 연결을 받지 않으며, 바로 그렇기 때문에 이 설계는 NAT를 견디고 사이트에 고정 주소가 없어도 작동합니다. 그다음 허브는 자체 정책에 따라 두 내부 주소 사이의 트래픽을 라우팅합니다.
비용은 허브가 존재해야 하고, 양쪽에서 도달할 수 있어야 하며, 누군가 운영해야 한다는 점입니다. 아웃바운드 필터링이 전송을 허용해야 하며, 이를 차단하는 네트워크는 포트 포워딩이 필요 없었더라도 이 설계를 무너뜨립니다.
미묘한 부분은 도달 가능성과 권한 부여가 서로 다른 곳에서 내려지는 별개의 결정이라는 점입니다. 어떤 프리픽스로 가는 경로는 그 ID가 워크스테이션의 어떤 서비스를 쓸 수 있는지 말해 주지 않고, 터널을 허용하는 방화벽 규칙도 그 계정이 로그인할 수 있는지 말해 주지 않습니다. 둘 다 구성하고 둘 다 시험하며, 권한 부여 결정은 라우팅 테이블이 아니라 리소스를 소유한 시스템 곁에 두십시오.
트래버설은 두 스택이 모두 구현할 때만 작동합니다
피어 간 트래버설은 특정 시스템의 능력이지 VPN을 개선하는 설정이 아닙니다. Interactive Connectivity Establishment는 로컬 인터페이스의 호스트 후보, NAT가 드러내는 것으로 만든 서버 반사 후보, 릴레이에 할당된 릴레이 후보 등 여러 후보 주소를 모으고 하나가 작동할 때까지 짝을 시험합니다. 사설 주소만으로는, 상대편이 그곳으로 라우팅할 수 없기 때문에 경로가 아닙니다.
릴레이되는 경우는 버리기 전에 이해할 가치가 있습니다. RFC 8656 은 TURN을, 클라이언트가 서버에 릴레이된 전송 주소를 요청하고 서버가 그 클라이언트와 그 피어 사이에서 트래픽을 전달하는 프로토콜로 설명합니다. 따라서 데이터를 실어 나르는 것은 릴레이이며, 단지 엔드포인트가 만나도록 돕는 디렉터리와는 본질적으로 다릅니다. 릴레이 주소를 상대와 교환하는 것은 애플리케이션이 해야 하는 조정 단계입니다.
약속할 수 없는 것은 직접 경로이며, 대칭 NAT와 일부 기업 방화벽은 홀 펀칭을 무력화하고, 그럴 때 시스템은 릴레이로 물러서거나 실패합니다. 또한 번역된 두 엔드포인트가 결코 대화할 수 없다고 결론 내릴 수도 없습니다. 릴레이 폴백을 갖춘 지원 스택이 존재하는 것은 바로 그들이 자주 대화할 수 있기 때문입니다. 가용성과 직접성 중 무엇이 더 중요한지 정한 뒤, 행복한 경우를 가정하는 대신 배포가 실제로 어느 경로를 골랐는지 확인하십시오.
브로커는 네트워크보다 좁습니다
요구 사항이 애플리케이션 하나일 때는 앱 브로커나 워크스테이션이 시작한 역방향 연결이 가장 작은 답일 수 있습니다. 워크스테이션은 브로커로 밖으로 연결하고, 브로커는 원격 사용자를 인증하며, 오직 그 애플리케이션 세션만 전달됩니다. 워크스테이션의 서브넷으로 가는 경로는 만들어지지 않으므로 원격 세션이 침해되어도 옆에 있는 모든 기기에 이르는 경로를 물려받지 않습니다.
그 좁음에는, 추가 애플리케이션마다 자체 통합이 필요하고, 애플리케이션이 로컬 네트워크에 대해 가정하는 것, 예를 들어 가까운 서버에서 여는 파일 공유가 도달하지 못할 수 있다는 대가가 있습니다. 브로커는 정책과 로깅도 한곳에 모으는데, 그것은 그곳이 장애가 되기 전까지는 유용합니다.
신뢰 경계를 비교한 뒤 경로를 시험하십시오
터널을 종료하는 허브는 자신이 라우팅하는 트래픽을 읽을 수 있습니다. 애플리케이션이 종단 간 암호화를 하면 릴레이는 독립적으로 보호된 교환을 실어 나를 수 있고, 브로커는 보통 자신이 제시하는 세션을 종료합니다. 둘 다 암호화되어 있다는 이유로 두 설계가 동등하다고 결정하기 전에 보호가 실제로 어디서 끝나는지 확립하십시오.
위의 모든 설계가 그것에 의존하므로, 그다음 워크스테이션이 바깥으로 실제 어디까지 도달하는지 확인하십시오. 사용하려는 호스트 이름으로 바꾸어 이것을 워크스테이션에서 실행하십시오.
ss -lntup
nc -vz hub.example.com 443
curl -sS -o /dev/null -w "%{http_code}\n" https://hub.example.com허용된 ID 아래에서 의도한 원격 작업이 성공하고, 승인되지 않은 ID가 거부되며, 직접 또는 릴레이 경로를 쓸 수 없을 때의 동작이 알려져 문서화된 뒤에만 설계를 받아들이십시오. 사무실에서 LAN으로 시작한 세션은 원격 접근이 의존하는 무엇도 시험하지 않으므로, 재연결과 워크스테이션의 정상 시작 컨텍스트도 포함하십시오.