Laborator VPN cu VirtualBox: VM poartă sau rețea doar pentru gazdă

Trebuie să decideți câtă mașinărie merită laboratorul vostru VPN. O VM poartă rutată între două segmente VirtualBox reproduce traducerea adreselor, calea de întoarcere și poziția firewall-ului în spatele căruia stă un client real. Un singur segment doar pentru gazdă vă dă o ușă controlată și nimic altceva. Versiunea cu poartă costă trei oaspeți și un tabel de rutare pe care îl întrețineți; versiunea doar pentru gazdă costă un oaspete și o politică. Trei întrebări le separă, iar a treia decide dacă testul vostru poate trece deloc.

Răspundeți la trei întrebări înainte de a clona ceva

Începeți cu ce trebuie să observe serverul VPN. Dacă serverul trebuie să vadă o adresă sursă care nu este a oaspetelui de test, ceva trebuie să traducă între ele, iar acel ceva trebuie să fie un router pe care îl controlați. Rețeaua doar pentru gazdă îi dă gazdei un adaptor în segmentul oaspetelui, nu un traducător. Când oaspetele trebuie apoi să ajungă la ceva din exterior, conectați un adaptor NAT, iar motorul NAT al VirtualBox rescrie sursa fără să vă întrebe.

Apoi întrebați dacă oaspetele poate ajunge la orice altceva decât prin tunel. Acel răspuns alege intern sau doar pentru gazdă, și este întrebarea pe care majoritatea descrierilor de laborator o sar. În final, întrebați ce trebuie să se întâmple când tunelul cade, pentru că asta decide politica și nu topologia, iar un laborator care dovedește doar calea fericită nu a testat aproape nimic.

Conectați cele trei roluri cu rețele interne

Folosiți trei oaspeți și două segmente numite, cu poarta ca singura mașină care are un adaptor pe ambele:

VBoxManage modifyvm lab-client --nic1 intnet --intnet1 WAN
VBoxManage modifyvm lab-server --nic1 intnet --intnet1 LAN
VBoxManage modifyvm lab-gw --nic1 intnet --intnet1 WAN --nic2 intnet --intnet2 LAN

Nu există un pas separat de creare pentru o rețea internă. Șirul din --intnet1 este segmentul: două mașini îl împart doar dacă numele se potrivește exact, și nimic de pe gazdă nu este conectat la el. Tocmai această ultimă proprietate este motivul pentru care laboratorul se repetă curat, deoarece rutele gazdei, propriul ei client VPN și firewall-ul ei nu pot ajunge la oaspeți din greșeală. Un segment intern nu are nici server DHCP decât dacă adăugați unul, așa că adresele statice sunt cea mai scurtă cale.

Dați clientului doar adresa lui WAN, cu o poartă implicită care indică adresa WAN a porții. Serverul primește o adresă LAN și folosește adresa LAN a porții ca poartă implicită. Un oaspete care ține două adrese pe un segment, sau are o rută rătăcită către celălalt segment, are o cale în jurul routerului, iar testele de mai jos vă vor minți.

Țin un fișier text lângă numele VM-urilor cu cele patru adrese și cele două nume de segment, și îl lipesc în fiecare shell. Săptămâni mai târziu, când o schimbare de profil strică ceva, acel fișier este diferența dintre depanarea profilului și depanarea propriei mele memorii.

Alegeți intern sau doar pentru gazdă pentru segmentul care nu trebuie să scurgă

Modul doar pentru gazdă creează un adaptor virtual pe gazda însăși, de obicei vboxnet0, și îi dă gazdei o adresă în segmentul oaspetelui. Este comod pentru administrare și fatal pentru un test de izolare, pentru că gazda poate acum să ajungă la oaspete direct și fiecare serviciu din partea gazdei devine o cale posibilă. Modul intern nu are niciun adaptor de gazdă. Cele două moduri se confundă ușor în panoul de setări de rețea, așa că verificați diferența documentată, nu eticheta (vedeți pagina detaliile de rețea ale VirtualBox).

Pentru un oaspete care trebuie să folosească tunelul, intern este valoarea implicită mai sigură, cu poarta ca singură ieșire. Dacă păstrați doar pentru gazdă, tratați adaptorul gazdei ca pe o cale de administrare și spuneți-o cu voce tare: gazda poate ajunge la oaspete, iar oaspetele nu trebuie să poată folosi gazda ca ieșire.

VBoxManage modifyvm lab-client --nic1 hostonly --hostonlyadapter1 vboxnet0

Izolarea pe care o puteți demonstra este izolarea pe care ați configurat-o. Un oaspete cu un adaptor intern, rută implicită la poartă și niciun adaptor NAT nu are nicio cale care ocolește poarta. Un oaspete cu adaptor doar pentru gazdă și adaptor NAT are două căi, și doar una dintre ele este cea pe care voiați să o testați.

Rutați și traduceți pe poartă, apoi faceți-o să eșueze închis

VirtualBox nu redirecționează între segmente; oaspetele o face. Cu VM-ul serverului VPN în spatele porții, activați redirecționarea și traduceți traficul clientului când iese spre server:

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE

Cu această regulă serverul vede adresa LAN a porții în locul celei a clientului, și exact așa arată un client real în spatele unui NAT de operator pentru un cap de rețea. Salvați valoarea sysctl în /etc/sysctl.d/ și regula în serviciul de firewall folosit de distribuție, altfel o repornire readuce laboratorul în tăcere la o stare rutată dar netradusă.

Redirecționarea nu este autorizare. Sub politica implicită FORWARD cu valoarea ACCEPT, un oaspete a cărui rută implicită indică poarta iese prin interfața pe care o alege tabelul de rutare, cu tunel sau fără. Dacă poarta are și un adaptor NAT pentru instalarea pachetelor, acel adaptor este o ieșire necriptată funcțională în momentul în care tunelul cade, iar testul vostru doar-VPN nu a fost niciodată un test doar-VPN.

Când serverul este la distanță și poarta însăși termină tunelul, aceeași decizie indică interfața tunelului, nu placa de rețea care ajunge la internet:

iptables -P FORWARD DROP
iptables -A FORWARD -i eth0 -o tun0 -j ACCEPT
iptables -A FORWARD -i tun0 -o eth0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Țineți transportul exterior propriu al tunelului și o rută de administrare în afara benzii separate de traficul redirecționat. Dacă singura cale de a repara poarta este prin tunelul pe care îl depanați, laboratorul devine un exercițiu de blocare. O consolă serială, un adaptor de administrare doar pentru gazdă sau un instantaneu al unei stări bune cunoscute sunt mai ieftine decât recuperarea manuală a unui router stricat.

Verificați calea dinspre oaspete, nu dinspre gazdă

Lucrați spre exterior. Confirmați că clientul ajunge la adresa WAN a porții, apoi la server prin poartă, apoi că o conexiune la portul VPN iese și se întoarce. O captură pe ambele interfețe ale porții arată dacă răspunsul ajunge și este aruncat pe calea de întoarcere, ceea ce o captură doar pe client nu poate distinge:

tcpdump -ni eth0 udp port 1194
tcpdump -ni tun0 udp port 1194

Apoi demonstrați ieșirea. Întrebați din oaspete un serviciu de reflexie a adreselor ce sursă vede și comparați cu adresa de ieșire a porții; dacă răspunsul se potrivește cu adresa gazdei, există o cale în jurul tunelului. Verificați ce resolver folosește de fapt oaspetele, și verificați IPv6 separat, pentru că un segment în care IPv6 este activat în timp ce tunelul transportă doar IPv4 scurge prin proiectare, nu din întâmplare.

În final, rupeți-l intenționat. Opriți tunelul, sau blocați portul lui exterior, și deschideți o conexiune nouă din oaspete. Trebuie să eșueze, iar motivul trebuie să fie unul pe care îl puteți numi: nicio rută, o regulă de respingere sau un resolver mort. Reporniți tunelul și confirmați că oaspetele se recuperează fără a reconstrui rețeaua. Dacă un VPN mesh precum Hamachi sau ZeroTier împarte laboratorul, amintiți-vă că un adaptor punte urmează numele adaptorului, nu mesh-ul, așa că puntea trebuie reorientată după ce clientul își instalează propriul adaptor virtual.

VBoxManage list bridgedifs
VBoxManage modifyvm lab-client --bridgeadapter1 <mesh-adapter-name>

Partajarea tunelului unui oaspete cu gazda reflectă problema. Direcționarea rutei implicite a gazdei către oaspete funcționează, și un proxy în interiorul oaspetelui la fel; NAT prin gazdă nu transportă tunelul oaspetelui pentru traficul pe care gazda l-a inițiat. Salvați numele segmentelor și regulile de firewall într-un singur loc, faceți un instantaneu al stării care funcționează și notați adresa sursă pe care serverul a observat-o. Următoarea schimbare de profil costă atunci o singură rulare de script în loc de un laborator reconstruit.