VirtualBox VPN-gateway för LAN: brygga, rutt, retur

Fjärranvändare behöver nå en skrivare och en filserver på ett fysiskt LAN, och den enda Linux-burk som alltid är på är en VirtualBox-VM. Att brygga in VM:en på det LAN:et är första halvan. Andra halvan är en returrutt som varje enhet på LAN:et faktiskt kommer att använda, och det är den delen som de flesta konfigurationer missar. När den saknas kopplas tunneln upp, klienten pingar gatewayen och inget annat svarar.

Använd adresser som går att nå

Ställ in VM:ens LAN-adapter på det Bridged Adapter-läge som är godkänt för nätverket och ge den en adress via den vanliga tilldelningsprocessen. Då dyker VM:en upp på det fysiska LAN:et som vilken annan värd som helst. Dess standardrutt måste fortfarande använda den riktiga gatewayen, så att den krypterade transporten till VPN-peer:n förblir nåbar. Använd inte VirtualBox standard-NAT-adress som nästa hopp för LAN:et, eftersom den adressen ligger bakom en virtuell NAT och inte är on-link för värden eller andra maskiner på LAN:et.

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

Kontrollera överlappning med fjärranvändarnas hemnätverk innan du väljer adresspoolen. Överlappning blir en routingoklarhet som ingen serverkonfiguration rättar till.

Annonsera LAN:et och vidarebefordra sedan

För en server vars autentisering och transport redan hanteras ser nätverksraderna ut så här. Pushen berättar för en klient som accepterar hur den når LAN:et, och den får inte VM:en att vidarebefordra något av sig själv.

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

Aktivera IPv4-vidarebefordran i VM:ens beständiga nätverkskonfiguration och låt klientpoolen nå de avsedda LAN-tjänsterna vid VM:ens vidarebefordringsgräns. Tillstånd att nå VPN-lyssnaren är en separat regel, och den fungerar redan om tunneln kom upp.

Returrutten hör hemma på LAN-routern

Enheter på LAN:et svarar via sin standardgateway, vilket är LAN-routern på 192.168.70.1. Den routern har ingen aning om var 10.80.0.0/24 ligger om den inte får veta det. Lägg till poolrutten i routerns stödda beständiga konfiguration, riktad mot VM:ens LAN-adress. Att lägga till den bara på VirtualBox-värden reparerar vägar som frågar den värden, och det är inte varje enhet på LAN:et.

ip route add 10.80.0.0/24 via 192.168.70.10

Målets egen brandvägg måste fortfarande tillåta klientpoolen som källa. En rutt bär paketet; den ger inte tjänsten.

Om LAN-routern inte kan ändras är begränsad källöversättning på VM:en alternativet. Det får svar att komma tillbaka utan rutten, och det döljer de enskilda klientadresserna för LAN-tjänsten.

Följ ett paket från början till slut

En klient på 10.80.0.25 skickar till 192.168.70.40 genom tunneln. VM:en vidarebefordrar paketet till LAN:et. Tjänsten svarar sin router, som väljer VM:en för klientpoolen, och VM:en skickar tillbaka paketet genom OpenVPN. Varje hopp i den meningen är en plats där designen kan fallera.

Testa med den riktiga applikationen från en fjärrklient och upprepa sedan efter att du laddat om den hanterade konfigurationen både på VM:en och på routern.

Om klienten når VM:en men inte tjänsten, kontrollera routerns rutt först. Om tjänsten tar emot begäran och klienten aldrig ser svaret, är returvägen den misstänkta.