Gateway VPN VirtualBox pentru LAN: punte, rută, întoarcere

Utilizatorii la distanță trebuie să ajungă la o imprimantă și la un server de fișiere dintr-o LAN fizică, iar singura mașină Linux pornită mereu este o VM VirtualBox. Conectarea VM-ului la acea LAN prin punte este prima jumătate. A doua jumătate este o rută de întoarcere pe care fiecare dispozitiv din LAN o va folosi cu adevărat, și exact aceasta este partea pe care majoritatea configurațiilor o omit. Când lipsește, tunelul se conectează, clientul face ping la gateway, și nimic altceva nu răspunde.

Folosiți adrese care pot fi atinse

Setați adaptorul LAN al VM-ului în modul Bridged Adapter aprobat pentru acea rețea și dați-i o adresă prin procesul obișnuit de alocare. Atunci VM-ul apare în LAN-ul fizic ca orice alt host. Ruta sa implicită trebuie să folosească în continuare gateway-ul real, ca transportul criptat către partenerul VPN să rămână accesibil. Nu folosiți adresa NAT implicită a VirtualBox ca următor salt pentru LAN, deoarece acea adresă se află în spatele unui NAT virtual și nu este on-link pentru host sau pentru alte mașini din 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

Verificați suprapunerea cu rețelele de acasă ale utilizatorilor la distanță înainte de a alege pool-ul. Suprapunerea devine o ambiguitate de rutare pe care nicio configurație de server nu o repară.

Anunțați LAN-ul, apoi forwardați

Pentru un server a cărui autentificare și al cărui transport sunt deja gestionate, liniile de rețea arată așa. Push-ul îi spune clientului care acceptă cum să ajungă la LAN, și nu face VM-ul să forwardeze nimic de la sine.

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

Activați forwardarea IPv4 în configurația de rețea persistentă a VM-ului și permiteți pool-ului de clienți să ajungă la serviciile LAN dorite la limita de forwardare a VM-ului. Permisiunea de a ajunge la ascultătorul VPN este o regulă separată și funcționează deja dacă tunelul a urcat.

Ruta de întoarcere aparține routerului din LAN

Dispozitivele din LAN răspund prin gateway-ul lor implicit, care este routerul LAN la 192.168.70.1. Acel router nu are habar unde se află 10.80.0.0/24 dacă nu i se spune. Adăugați ruta pool-ului la configurația persistentă acceptată a routerului, îndreptată spre adresa LAN a VM-ului. Adăugarea ei doar pe hostul VirtualBox repară căile care întreabă acel host, iar aceasta nu este fiecare dispozitiv din LAN.

ip route add 10.80.0.0/24 via 192.168.70.10

Firewall-ul destinației trebuie totuși să permită pool-ul de clienți ca sursă. O rută duce pachetul; ea nu acordă serviciul.

Dacă routerul LAN nu poate fi modificat, alternativa este traducerea limitată de sursă pe VM. Aceasta face răspunsurile să revină fără rută și ascunde adresele individuale ale clienților față de serviciul LAN.

Urmați un pachet de la un capăt la altul

Un client la 10.80.0.25 trimite spre 192.168.70.40 prin tunel. VM-ul forwardează pachetul în LAN. Serviciul răspunde routerului său, care alege VM-ul pentru pool-ul de clienți, iar VM-ul returnează pachetul prin OpenVPN. Fiecare salt din acea propoziție este un loc unde designul poate eșua.

Testați cu aplicația reală de la un client la distanță, apoi repetați după reîncărcarea configurației gestionate atât pe VM, cât și pe router.

Dacă clientul ajunge la VM dar nu la serviciu, verificați mai întâi ruta routerului. Dacă serviciul primește cererea și clientul nu vede niciodată răspunsul, calea de întoarcere este suspectul.