VPN은 켜져 있는데 VM에 닿지 않는다면? 문제는 아마 경로가 아니었습니다

VPN을 연결하면 일 분 전까지 응답하던 개발용 VM이 조용해집니다. 뻔한 이야기는 저절로 쓰이는데, 터널이 경로를 가져갔고 호스트가 이제 게스트 트래픽을 회사 네트워크로 보내며, 해결책은 정적 경로를 추가하거나 어댑터를 브리지 모드로 바꾸는 것입니다. 그 이야기가 맞을 때도 있습니다. 하지만 흔한 원인은 아니며, 그것을 먼저 믿고 움직이면 대개 다른 것이 깨집니다.

host-only 네트워킹은 호스트가 소유하고 게스트와 공유하는 소프트웨어 네트워크로, 어떤 물리적 연결과도 별개입니다. VPN 클라이언트 자체의 인터페이스는 그 네트워크를 바꾸지 않으므로, 손대기 전에 네 계층 중 어디가 실제로 실패했는지 알아내십시오.

경로는 보통 여전히 로컬입니다

라우팅 테이블의 첫 페이지가 아니라 커널에 물으십시오. 리눅스에서 ip route get 192.168.56.10은 실제로 쓰일 경로, 인터페이스, 원본 주소를 정확히 알려 주며, 이는 기본 경로를 읽고 추측하는 것과 다른 답입니다. 출력이 host-only 인터페이스를 지목한다면 그 경로에 터널은 전혀 관여하지 않습니다.

정말로 망가뜨릴 수 있는 것은 두 가지이며, 둘 다 VPN이 아니라 주소 문제입니다. host-only 프리픽스와 겹치는 원격 서브넷은 더 구체적인 경로를 이기게 하고, 더 낮은 메트릭으로 넓은 경로를 설치하는 VPN 클라이언트는 프리픽스를 끌어갈 수 있습니다. 둘 다 같은 명령에서 보이는데, 출력에 나오는 인터페이스가 터널이 되고 수정은 그 주소 계획의 소유자 몫입니다.

경로 선택과 패킷 허용은 다른 결정입니다

여기가 사고 모델이 흔히 놓치는 부분입니다. 완벽한 로컬 경로가 있어도 VPN 클라이언트는 패킷을 거부할 수 있습니다. 많은 클라이언트는 터널 밖에서 어떤 목적지가 허용되는지 결정하는 로컬 네트워크 접근 정책을 적용하며, 연결된 서브넷이 그 목록을 자동으로 갱신하지는 않습니다.

그래서 응용 프로그램 쪽에서는 라우팅 문제와 똑같이 보이고, 클라이언트 쪽에서는 전혀 다르게 보입니다. ip route get이 올바른 인터페이스를 지목하는데도 연결이 시간 초과된다면 경로 편집을 멈추고, 대신 클라이언트의 문서화된 로컬 접근 동작을 읽으십시오. 로컬 서브넷 허용 목록을 제공하는 클라이언트도 있고, 터널이 아닌 모든 것을 막는 클라이언트도 있으며, 킬 스위치가 켜져 있을 때만 막는 클라이언트도 있습니다.

이 구분이 중요한 이유는 수정이 서로 바꿀 수 없기 때문입니다. 경로를 추가해도 필터를 만족시킬 수 없고, 게스트 하나에 닿기 위해 필터를 끄는 것은 증상이 암시하는 것보다 훨씬 큰 결정입니다.

게스트가 아니오라고 말하는 세 가지 방법

인터넷을 탐색할 수 있는 게스트는 원하는 서비스에 대해 아무것도 증명하지 못했습니다. 리스너가 게스트 내부에서 127.0.0.1에 묶여 있다면 경로가 아무리 좋아도 호스트의 요청은 도달할 수 없습니다. 게스트에서 ss -ltn으로 확인하고 포트만이 아니라 로컬 주소 열을 보십시오.

다음은 게스트 자체의 방화벽입니다. 제한적인 기본값을 가진 개발 이미지는 호스트의 패킷을 받아 서비스 경계에서 버릴 수 있고, 그러면 라우팅 블랙홀과 똑같아 보이는 시간 초과가 생깁니다. 마지막으로 서비스 자체의 구성이 있는데, 특정 호스트 이름에 묶인 웹 앱이나 클라이언트 주소 허용 목록은 모든 패킷이 도착해도 host-only 서브넷에서 오는 요청을 거부합니다.

VM의 네트워크 모드를 바꾸기 전에 이 세 가지를 차례로 확인하십시오. 각각은 게스트 연결을 다시 설계하는 것보다 작은 변경이며, 각각 명확한 시험이 있습니다.

브리지란 무엇이고 무엇을 치르는가

어댑터를 브리지 모드로 바꾸는 것은 host-only 경로의 수리가 아닙니다. 게스트를 다른 네트워크, 보통 물리 LAN에 두는 결정이며, 그곳에서 같은 장소에 있는 다른 모든 것에 보이게 됩니다. 그것이 원하는 바일 수도 있습니다. 하지만 원래 구성이 하던 일은 아닙니다.

게스트가 정말로 그 LAN의 동등한 구성원이어야 하고 노출이 승인된 경우에 쓰십시오. 서비스 하나가 응답을 멈췄다고 쓰는 것은, 그 변경이 개발을 안전하게 만들었던 격리에서 게스트를 빼낼 수 있어 피하십시오.

승인된 수정 뒤에는 호스트에서 게스트로의 새 요청, 터널을 통한 필수 회사 리소스, 터널을 내린 상태의 의도된 거부 동작이라는 정해진 순서로 시험하십시오. 마지막이 더 이상 성립하지 않으면 수정이 문제를 넘어섰습니다.

VirtualBox의 host-only 네트워킹 절은 호스트 쪽 소프트웨어 인터페이스와 브리지 연결과의 차이를 설명하며, 두 모드가 호환된다고 가정하기 전에 읽을 만한 참고 자료입니다.