VirtualBox VPN-gateway for LAN: bro, rute, retur
Bro gateway-VM-en inn på LAN-et, annonser LAN-et til klientene og legg poolruten til i LAN-ruteren. Et gjennomarbeidet IPv4-eksempel med ekte returveier.
Eksterne brukere må nå en skriver og en filserver på et fysisk LAN, og den eneste Linux-boksen som alltid står på, er en VirtualBox-VM. Å bro VM-en inn på det LAN-et er første halvdel. Andre halvdel er en returrute som hver enhet på LAN-et faktisk vil bruke, og det er den delen de fleste oppsettene glemmer. Når den mangler, kobler tunnelen seg opp, klienten pinger gatewayen, og ingenting annet svarer.
Bruk adresser som kan nås
Sett LAN-adapteren til VM-en i Bridged Adapter-modus godkjent for nettverket, og gi den en adresse gjennom den vanlige tildelingsprosessen. Da vises VM-en på det fysiske LAN-et som enhver annen vert. Standardruten må fortsatt bruke den ekte gatewayen, slik at den krypterte transporten til VPN-peer-en forblir tilgjengelig. Ikke bruk standard NAT-adressen til VirtualBox som neste hopp for LAN-et, fordi den adressen ligger bak en virtuell NAT og er ikke on-link for verten eller andre 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
Sjekk for overlapp med hjemmenettverkene til eksterne brukere før du velger adressepoolen. Overlapp blir en rutinguklarhet som ingen serverkonfigurasjon retter opp.
Annonser LAN-et, og videresend deretter
For en server der autentisering og transport allerede administreres, ser nettverkslinjene slik ut. Push-en forteller en klient som godtar hvordan den når LAN-et, og den får ikke VM-en til å videresende noe av seg selv.
dev tun
topology subnet
server 10.80.0.0 255.255.255.0
push "route 192.168.70.0 255.255.255.0"
Slå på IPv4-videresending i den vedvarende nettverkskonfigurasjonen til VM-en, og la klientpoolen nå de tiltenkte LAN-tjenestene ved videresendingsgrensen til VM-en. Tillatelse til å nå VPN-lytteren er en egen regel, og den virker allerede hvis tunnelen kom opp.
Returruten hører hjemme på LAN-ruteren
Enheter på LAN-et svarer via standardgatewayen sin, som er LAN-ruteren på 192.168.70.1. Den ruteren aner ikke hvor 10.80.0.0/24 ligger med mindre den får beskjed. Legg poolruten til i den støttede vedvarende konfigurasjonen til ruteren, rettet mot LAN-adressen til VM-en. Å legge den til bare på VirtualBox-verten reparerer stier som spør den verten, og det er ikke hver enhet på LAN-et.
ip route add 10.80.0.0/24 via 192.168.70.10
Brannmuren til målet må fortsatt tillate klientpoolen som kilde. En rute bærer pakken; den gir ikke tjenesten.
Hvis LAN-ruteren ikke kan endres, er begrenset kildeoversettelse på VM-en alternativet. Det får svar til å komme tilbake uten ruten, og det skjuler de enkelte klientadressene for LAN-tjenesten.
Følg én pakke fra ende til annen
En klient på 10.80.0.25 sender til 192.168.70.40 gjennom tunnelen. VM-en videresender pakken til LAN-et. Tjenesten svarer ruteren sin, som velger VM-en for klientpoolen, og VM-en returnerer pakken gjennom OpenVPN. Hvert hopp i den setningen er et sted der designet kan svikte.
Test med den ekte applikasjonen fra en ekstern klient, og gjenta etter at du har lastet inn den administrerte konfigurasjonen på nytt både på VM-en og på ruteren.
Hvis klienten når VM-en men ikke tjenesten, sjekk ruten til ruteren først. Hvis tjenesten mottar forespørselen og klienten aldri ser svaret, er returveien den mistenkte.