VirtualBox NAT 뒤에서 게스트 VPN이 실패하는 이유

가상 머신 안의 브라우저는 작동하는데, 같은 게스트의 VPN 클라이언트는 데이터를 전달하지 못합니다. 게스트에 연결성이 분명히 있으므로, 실패는 VPN의 외부 프로토콜이 요구하는 것과 가상 NAT가 통과시킬 것 사이에 있습니다. 결과를 좌우하는 조건은 세 가지입니다. 어느 프로세스가 VPN을 소유하는지, 외부 교환이 회선에서 어떻게 보이는지, 어댑터 모드가 생각하는 그 모드인지입니다. 바꿀 수 있는 조건을 지목하는 것이 결정의 전부입니다.

네트워크를 탓하기 전에 VPN 프로세스를 찾으십시오

먼저 VPN이 게스트 안에서 도는지 호스트에서 도는지 정하십시오. 두 배치는 다르게 실패합니다. 게스트 안의 클라이언트는 게스트 어댑터와 그 뒤의 변환을 통해 자체 외부 연결을 만듭니다. 호스트 VPN은 호스트와 하이퍼바이저 정책에 따라 게스트 트래픽을 잡는데, 이는 자체 규칙을 가진 별도의 캡처 지점입니다. 둘이 동시에 돌아 증거를 흐릴 수 있으므로, 어느 쪽이든 건드리기 전에 이 트래픽을 실어야 할 쪽이 어느 것인지 밝히십시오.

무엇이든 바꾸기 전에 지금 게스트의 어댑터 모드를 적어 두십시오. 그 한 값이 이후의 대부분을 설명하며, 나중에 누구든 가장 먼저 묻는 것이 바로 그것입니다.

외부 교환이 호환성을 결정합니다

VirtualBox 네트워킹 안내서는 여기서 중요한 NAT 제한을 열거합니다. TCP와 UDP 외의 프로토콜은 통과시키지 않고, GRE는 지원되지 않는 것으로 언급되며, PPTP는 영향을 받는 예로 제시됩니다. PPTP는 제어 교환에 TCP를, 데이터에 GRE를 사용하므로 제어 연결은 성공해도 데이터 경로는 같은 경계를 넘지 못할 수 있습니다. 이는 서로 다른 두 증거이며, 그중 하나만 트래픽 전달에 관한 것입니다. 방화벽 규칙에서 TCP 포트 47을 허용하는 것은 IP 프로토콜 47을 허용하는 것과 같지 않으며, 둘은 늘 혼동됩니다.

제한은 NAT라는 단어를 쓰는 모든 장치가 아니라 이 NAT 배치에 붙여 두십시오. 물리 라우터는 GRE를 불평 없이 통과시킬 수 있지만 가상 NAT는 이를 버리며, 다른 하이퍼바이저는 무엇을 전달할지 스스로 고릅니다. 조직이 TCP나 UDP 안에서 승인된 전송을 제공한다면 그 경로에는 그 지원 클라이언트와 프로필을 쓰십시오. 호환성은 여러 요구 중 하나이며, 서버 신뢰나 계정 권한이나 작동하는 사설 경로를 확립하지 않습니다.

브리지가 실제로 바꾸는 것

브리지는 게스트의 MAC 주소를 변환 뒤에 숨기는 대신 물리 세그먼트에 넘깁니다. 그러면 게스트는 그 세그먼트를 서비스하는 어떤 DHCP 서버에서든 주소를 받고, 그 주소에 대해 ARP로 응답하며, 업스트림 스위치에는 포트 하나 더로 보입니다. 이것이 가상 변환 경로를 없애며, 오래된 방법이 브리지를 권하는 이유가 바로 그것이고, 동시에 다른 세 가지도 바꿉니다. 주소 지정은 이제 하이퍼바이저가 아니라 로컬 세그먼트에서 오고, 노출은 게스트가 그 세그먼트에 보인다는 뜻이며, 허용은 스위치 포트와 그 정책에 달려 있습니다. 어느 것이든 변경을 거부할 이유가 될 수 있고, 어느 것도 VPN 프로토콜에 관한 것이 아닙니다.

브리징은 빠진 플러그인을 설치하지 않고, 쓸 수 없는 비밀 에이전트를 공급하지 않으며, 인증 거부를 고치지 않습니다. 또한 낡은 프로토콜을 좋은 선택으로 만들지 않으며, 운영자에게 유지되는 대안이 있으면 결정은 하이퍼바이저를 바꾸는 것이 아니라 그것입니다. 포트 포워딩은 전혀 다른 세 번째 역할입니다. 들어오는 서비스를 게시할 뿐, 나가는 클라이언트의 외부 프로토콜에는 아무것도 하지 않습니다.

두 터널, 두 증거의 흔적

게스트 VPN은 어떤 내부 주소나 사설 경로가 중요해지기 전에 게스트 인터페이스에서 상대까지 쓸 수 있는 경로가 필요합니다. 호스트 VPN이 있으면 자체 정책에 따라 그 외부 교환을 중계하거나 차단할 수 있고, 게스트의 내부 터널은 외부가 성공한 뒤에야 시작됩니다. 어느 계층의 범위도 연결된 아이콘 하나나 호스트 브라우저의 공인 주소에서 읽을 수 없습니다.

마지막이 아니라 첫 오류 메시지를 남기십시오. 가장 이른 실패가 계층을 지목하기 때문입니다. 지원되는 네트워크 배치를 한 번에 하나씩 바꾸고, 같은 게스트 프로필과 같은 자격 증명을 쓰십시오. 그래야 비교가 의미를 갖습니다. 실패로 어느 단계가 끊겼는지 정하십시오. 로컬 통합, 전송, 인증, 또는 터널이 올라온 뒤의 자원 접근입니다. 각각 담당이 다르고, 하이퍼바이저 문제는 하나뿐입니다.

실제로 막고 있는 조건은 무엇인가

이제 결정은 답이 다른 세 질문으로 좁혀집니다. 외부 프로토콜이 TCP와 UDP 밖에 있으면 NAT 모드가 제약이고, 앞으로 나아갈 길은 브리지나 승인된 TCP/UDP 전송입니다. 외부 교환은 끝나는데 데이터 경로가 안 되면 제약은 두 번째 증거에서 본 것과 같습니다. 터널은 올라오는데 자원이 응답하지 않으면 문제는 이미 하이퍼바이저를 지나 라우팅이나 정책으로 넘어갔습니다.

답은 어댑터 모드와 나란히 적어 두십시오. 그러지 않으면 다음 사람이 같은 오후를 반복합니다. 수정한 뒤에는 게스트 안에서 실제 애플리케이션과 이름 해석을 시험하고, 다시 연결해 실패 정책을 연습하십시오. 터널을 통해 열리는 웹 페이지는 웹 경로가 작동한다는 것만 증명하며, 그것은 그 순간 느껴지는 것보다 작은 주장입니다.