VirtualBox VPN-lab: gateway-VM tsjin allinnich-host-netwurk

Jo moatte beslisse hoefolle masjinerie jo VPN-lab fertsjinnet. In rûteare gateway-VM tusken twa VirtualBox-segmenten reprodusearret de adresfertaaling, it werompaad en de firewallposysje dêr't in echte klant efter sit. Ien inkeld allinnich-host-segment jout jo ien kontrolearre doar en fierders neat. De gateway-ferzje kostet trije gasten en in rûtingstabel dy't jo ûnderhâlde; de allinnich-host-ferzje kostet ien gast en ien belied. Trije fragen skiede se, en de tredde beslút oft jo test hielendal slagje kin.

Beäntwurdzje trije fragen foardat jo eat kloanje

Begjin mei wat de VPN-tsjinner waarnimme moat. As de tsjinner in boarneadres sjen moat dat net fan 'e testgast is, moat der eat tusken har oersette, en dat eat moat in rûter wêze dy't jo kontrolearje. Allinnich-host-netwurken jout de host in adapter op it segment fan 'e gast, gjin oersetter. As de gast dan eat bûten berikke moat, keppelje jo in NAT-adapter oan, en VirtualBox syn eigen NAT-motor skriuwt de boarne oer sûnder jo te freegjen.

Freegje dêrnei oft de gast eat berikke mei útsein troch de tunnel. Dat antwurd kiest yntern of allinnich-host, en it is de fraach dy't de measte labbeskriuwings oerslaan. Freegje úteinlik wat der barre moat as de tunnel falt, want dat bepaalt belied yn stee fan topology, en in lab dat allinnich it lokkige paad bewissiget, hat hast neat test.

Ferbyn de trije rollen mei ynterne netwurken

Brûk trije gasten en twa neamde segments, mei de gateway as de iennichste masine dy't op beide in adapter hat:

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

Der is gjin aparte oanmeitsstap foar in yntern netwurk. De tekenrige yn --intnet1 is it segment: twa masines diele it allinnich as de namme krekt oerienkomt, en neat op 'e host is deroan keppele. Krekt dy lêste eigenskip is de reden dat it lab skjin werhellet, om't de rûtes fan 'e host, syn eigen VPN-klant en syn firewall de gasten net by ûngelok berikke kinne. In yntern segment hat ek gjin DHCP-tsjinner, útsein as jo ien tafoegje, dus statyske adressen binne it koartste paad.

Jou de klant allinnich syn WAN-adres, mei in standertgateway dy't nei it WAN-adres fan 'e gateway wiist. De tsjinner krijt in LAN-adres en brûkt it LAN-adres fan 'e gateway as syn standertgateway. In gast dy't twa adressen op ien segment hâldt, of in fertoarne rûte nei it oare segment hat, hat in paad om 'e rûter hinne, en de tests hjirûnder sille jo beliegje.

Ik hâld in tekstbestân njonken de VM-nammen mei de fjouwer adressen en de twa segmintnammen, en plak it yn elke shell. Wike letter, as in profylferoaring eat brekt, is dat bestân it ferskil tusken it profyl debugge en myn eigen ûnthâld debugge.

Kies yntern of allinnich-host foar it segment dat net lekke mei

De allinnich-host-modus makket in firtuele adapter op 'e host sels, meastentiids vboxnet0, en jout de host in adres op it segment fan 'e gast. Dat is handich foar behear en deadlik foar in isolaasjetest, om't de host no de gast direkt berikke kin en elke tsjinst oan 'e hostkant in mooglik paad wurdt. De ynterne modus hat hielendal gjin hostadapter. De twa modi wurde maklik trochinoar helle yn it netwurkinstellingspaniel, dus kontrolearje it dokumintearre ferskil yn stee fan it label (sjoch de side VirtualBox-netwurkdetails).

Foar in gast dy't de tunnel brûke moat, is yntern de feiliger standert, mei de gateway as de iennichste útgong. As jo allinnich-host hâlde, behannelje de hostadapter as in behearpaad en sis it lûd: de host mei de gast berikke, en de gast mei de host net as útgong brûke kinne.

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

De isolaasje dy't jo bewissigje kinne, is de isolaasje dy't jo ynsteld hawwe. In gast mei ien ynterne adapter, in standertrûte by de gateway en gjin NAT-adapter hat gjin paad dat de gateway oerslacht. In gast mei in allinnich-host-adapter en in NAT-adapter hat twa paden, en mar ien dêrfan is dy't jo bedoelden te testen.

Rûtearje en oersette op 'e gateway, en lit it dan sletten mislearje

VirtualBox stjoert net troch tusken segments; de gast docht dat. Mei de VPN-tsjinner-VM efter de gateway, aktivearje trochstjoeren en oersette it ferkear fan 'e klant as it nei de tsjinner ta giet:

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

Mei dy regel sjocht de tsjinner it LAN-adres fan 'e gateway yn stee fan dat fan 'e klant, en sa sjocht in echte klant efter in provider-NAT der foar in haadein út. Bewarje de sysctl-wearde yn /etc/sysctl.d/ en de regel yn hokker firewaltsjinst de distribúsje ek brûkt, oars set in werstart it lab stil werom nei in rûtearre mar net oersette tastân.

Trochstjoeren is gjin autorisaasje. Under it standertbelied FORWARD fan ACCEPT giet in gast waans standertrûte nei de gateway wiist, troch de ynterface dy't de rûtingstabel kiest, tunnel of net. As de gateway ek in NAT-adapter hat foar pakketynstallaasjes, is dy adapter in wurkjende net-fersifere útgong op it stuit dat de tunnel falt, en jo allinnich-VPN-test wie nea in allinnich-VPN-test.

As de tsjinner ynstee op ôfstân is en de gateway sels de tunnel beëiniget, wiist deselde beslissing nei de tunnelinterface, net nei de NIC dy't it ynternet berikt:

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

Hâld it eigen bûtenste ferfier fan 'e tunnel en in bûtenbânse behear-rûte apart fan trochstjoerd ferkear. As de iennichste manier om de gateway te reparearjen troch de tunnel giet dy't jo debugge, wurdt it lab in útslút-oefening. In searje-konsoal, in allinnich-host-behearadapter of in momintopname fan in bekende goede tastân is goedkeaper as it mei de hân werombringe fan in stikken rûter.

Ferifiearje it paad fan 'e gast, net fan 'e host

Wurkje nei bûten. Befêstigje dat de klant it WAN-adres fan 'e gateway berikt, dan de tsjinner troch de gateway, dan dat in ferbining nei de VPN-poarte fuortgiet en weromkomt. In opname op beide gateway-ynterfaces lit sjen oft it antwurd oankomt en op it werompaad weilitten wurdt, wat in opname allinnich op 'e klant net ûnderskiede kin:

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

Bewissigje dan de útgong. Freegje fan 'e gast in adreswerkaatsingstsjinst hokker boarne it sjocht en fergelykje dat mei it eigen útgongadres fan 'e gateway; as it antwurd oerienkomt mei it adres fan 'e host, bestiet der in paad om 'e tunnel hinne. Kontrolearje hokker resolver de gast eins brûkt, en kontrolearje IPv6 apart, want in segment dêr't IPv6 oan stiet wylst de tunnel allinnich IPv4 draacht, lekt neffens it ûntwerp en net by ûngelok.

Brek it úteinlik mei opsetsin. Stop de tunnel, of blokkearje syn bûtenste poarte, en iepenje in nije ferbining fan 'e gast. It moat mislearje, en de reden moat ien wêze dy't jo neame kinne: gjin rûte, in ôfwizingsregel of in deade resolver. Start de tunnel opnij en befêstigje dat de gast him werstelt sûnder it netwurk op 'e nij te bouwen. As in mesh-VPN lykas Hamachi of ZeroTier it lab dielt, tink dan dat in oerbrêge adapter de adapternamme folget, net it mesh, dus de brêge moat op 'e nij rjochte wurde nei't de klant syn eigen firtuele adapter ynstallearret.

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

It dielen fan 'e tunnel fan in gast mei de host spegelet it probleem. De standertrûte fan 'e host nei de gast rjochtsje wurket, en in proxy yn 'e gast ek; NAT troch de host draacht de tunnel fan 'e gast net foar ferkear dat de host begûn. Bewarje de segmintnammen en de firewallregels op ien plak, nim in momintopname fan 'e wurkjende tastân, en registrearje it boarneadres dat de tsjinner waarnaam. De folgjende profylferoaring kostet dan ien skriptrin yn stee fan in werboude lab.