원격 사용자는 물리적 LAN의 프린터와 파일 서버에 접근해야 하는데, 항상 켜져 있는 유일한 Linux 장비가 VirtualBox VM입니다. 그 VM을 해당 LAN에 브리지하는 것이 전반부입니다. 후반부는 LAN의 모든 장치가 실제로 사용할 반환 경로이며, 대부분의 구성이 바로 이 부분을 빠뜨립니다. 이것이 없으면 터널은 연결되고 클라이언트는 게이트웨이에 ping할 수 있지만 그 밖의 무엇도 응답하지 않습니다.

도달할 수 있는 주소를 사용하세요

VM의 LAN 어댑터를 해당 네트워크에 승인된 Bridged Adapter 모드로 설정하고 일반 할당 절차로 주소를 부여하세요. 그러면 VM은 다른 호스트처럼 물리적 LAN에 나타납니다. 기본 경로는 계속 실제 게이트웨이를 사용해야 하며, 그래야 VPN 피어로 가는 암호화 전송이 도달 가능하게 유지됩니다. VirtualBox의 기본 NAT 주소는 가상 NAT 뒤에 있고 호스트나 다른 LAN 장치에게 on-link가 아니므로 LAN의 다음 홉으로 쓰지 마세요.

LAN router:          192.168.70.1/24
VirtualBox host:     192.168.70.5/24
VPN gateway VM:      192.168.70.10/24
Example LAN service: 192.168.70.40
VPN client pool:     10.80.0.0/24

주소 풀을 고르기 전에 원격 사용자의 가정 네트워크와 겹치는지 확인하세요. 겹침은 어떤 서버 구성으로도 고칠 수 없는 라우팅 모호성이 됩니다.

LAN을 알리고 나서 전달하세요

인증과 전송이 이미 관리되는 서버라면 네트워크 설정 줄은 이렇습니다. push는 연결을 수락하는 클라이언트에게 LAN에 도달하는 방법을 알려 주며, 그것만으로 VM이 무언가를 전달하게 만들지는 않습니다.

dev tun
topology subnet
server 10.80.0.0 255.255.255.0
push "route 192.168.70.0 255.255.255.0"

VM의 영구 네트워크 구성에서 IPv4 전달을 켜고, 클라이언트 풀이 VM의 전달 경계에서 의도한 LAN 서비스에 도달하도록 허용하세요. VPN 리스너에 도달하는 권한은 별도 규칙이며, 터널이 올라왔다면 이미 동작하고 있습니다.

반환 경로는 LAN 라우터에 있습니다

LAN 장치는 기본 게이트웨이, 즉 192.168.70.1의 LAN 라우터를 통해 응답합니다. 그 라우터는 알려 주지 않으면 10.80.0.0/24가 어디 있는지 모릅니다. 풀 경로를 라우터가 지원하는 영구 구성에 추가하고 VM의 LAN 주소를 가리키게 하세요. VirtualBox 호스트에만 추가하면 그 호스트에 묻는 경로만 고쳐지며, 그것이 LAN의 모든 장치는 아닙니다.

ip route add 10.80.0.0/24 via 192.168.70.10

목적지 자체의 방화벽은 여전히 클라이언트 풀을 출발지로 허용해야 합니다. 경로는 패킷을 나를 뿐 서비스를 허가하지는 않습니다.

LAN 라우터를 바꿀 수 없다면 VM에서 제한된 출발지 변환이 대안입니다. 이는 응답이 경로 없이 돌아오게 하고, LAN 서비스에서 개별 클라이언트 주소를 숨깁니다.

패킷 하나를 처음부터 끝까지 따라가 보세요

10.80.0.25의 클라이언트가 터널을 통해 192.168.70.40으로 보냅니다. VM이 패킷을 LAN으로 전달합니다. 서비스는 자기 라우터로 응답하고, 라우터는 클라이언트 풀에 대해 VM을 선택하며, VM은 OpenVPN을 통해 패킷을 되돌려 보냅니다. 그 문장의 모든 홉은 설계가 실패할 수 있는 지점입니다.

원격 클라이언트에서 실제 애플리케이션으로 시험하고, VM과 라우터 양쪽에서 관리 구성을 다시 불러온 뒤 반복하세요.

클라이언트가 VM에는 도달하지만 서비스에는 도달하지 못한다면 먼저 라우터의 경로를 확인하세요. 서비스가 요청을 받고도 클라이언트가 응답을 전혀 보지 못한다면 반환 경로가 의심스럽습니다.

관련 글