VirtualBox VPN-laboratorio: pordega VM kontraŭ nurgastiga reto

Vi devas decidi, kiom da maŝinaro meritas via VPN-laboratorio. Enkursigita pordega VM inter du VirtualBox-segmentoj reproduktas la adresan tradukon, la revenan vojon kaj la fajroŝirman pozicion, malantaŭ kiu sidas reala kliento. Unu sola nurgastiga segmento donas al vi unu kontrolitan pordon kaj nenion alian. La pordega versio kostas tri gastojn kaj enkursigan tabelon, kiun vi prizorgas; la nurgastiga versio kostas unu gaston kaj unu politikon. Tri demandoj apartigas ilin, kaj la tria decidas, ĉu via testo entute povas sukcesi.

Respondu tri demandojn antaŭ ol kloni ion ajn

Komencu per tio, kion la VPN-servilo devas observi. Se la servilo devas vidi fontadreson, kiu ne estas tiu de la testa gasto, io devas traduki inter ili, kaj tiu io devas esti enkursigilo, kiun vi kontrolas. Nurgastiga retumado donas al la gastiganto adaptilon en la segmento de la gasto, ne tradukilon. Kiam la gasto poste bezonas atingi ion eksteren, vi alkroĉas NAT-adaptilon, kaj la propra NAT-motoro de VirtualBox reskribas la fonton sen demandi vin.

Poste demandu, ĉu la gasto rajtas atingi ion ajn krom tra la tunelo. Tiu respondo elektas internan aŭ nurgastigan, kaj ĝi estas la demando, kiun plej multaj laboratoriaj priskriboj preterlasas. Fine demandu, kio devas okazi, kiam la tunelo falas, ĉar tio decidas politikon anstataŭ topologion, kaj laboratorio, kiu pruvas nur la feliĉan vojon, preskaŭ nenion testis.

Konektu la tri rolojn per internaj retoj

Uzu tri gastojn kaj du nomitajn segmentojn, kun la pordego kiel la sola maŝino, kiu havas adaptilon sur ambaŭ:

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

Ne ekzistas aparta krea paŝo por interna reto. La ĉeno en --intnet1 estas la segmento: du maŝinoj dividas ĝin nur se la nomo kongruas ekzakte, kaj nenio sur la gastiganto estas alkroĉita al ĝi. Ĝuste tiu lasta eco estas la kialo, ke la laboratorio ripetiĝas pure, ĉar la vojoj de la gastiganto, ĝia propra VPN-kliento kaj ĝia fajroŝirmilo ne povas hazarde atingi la gastojn. Interna segmento ankaŭ ne havas DHCP-servilon, se vi ne aldonas unu, do statikaj adresoj estas la plej mallonga vojo.

Donu al la kliento nur ĝian WAN-adreson, kun defaŭlta pordego montranta al la WAN-adreso de la pordego. La servilo ricevas LAN-adreson kaj uzas la LAN-adreson de la pordego kiel sian defaŭltan pordegon. Gasto, kiu tenas du adresojn sur unu segmento, aŭ havas vagantan vojon al la alia segmento, havas vojon ĉirkaŭ la enkursigilo, kaj la subaj testoj mensogos al vi.

Mi tenas tekstodosieron apud la VM-nomoj kun la kvar adresoj kaj la du segmentnomoj, kaj gluas ĝin en ĉiun ŝelon. Semajnojn poste, kiam profilŝanĝo rompas ion, tiu dosiero estas la diferenco inter sencimigado de la profilo kaj sencimigado de mia propra memoro.

Elektu internan aŭ nurgastigan por la segmento, kiu ne rajtas liki

La nurgastiga reĝimo kreas virtualan adaptilon sur la gastiganto mem, kutime vboxnet0, kaj donas al la gastiganto adreson en la segmento de la gasto. Tio estas oportuna por administrado kaj mortiga por izoltesto, ĉar la gastiganto nun povas atingi la gaston rekte kaj ĉiu servo sur la gastiganta flanko fariĝas ebla vojo. La interna reĝimo tute ne havas gastigantan adaptilon. La du reĝimoj facile konfuziĝas en la retagorda panelo, do kontrolu la dokumentitan diferencon anstataŭ la etikedon (vidu la paĝon retaj detaloj de VirtualBox).

Por gasto, kiu devas uzi la tunelon, interna estas la pli sekura defaŭlto, kun la pordego kiel la sola elirejo. Se vi konservas nurgastigan, traktu la gastigantan adaptilon kiel administran vojon kaj diru tion laŭte: la gastiganto rajtas atingi la gaston, kaj la gasto ne rajtas povi uzi la gastiganton kiel elirejon.

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

La izolado, kiun vi povas pruvi, estas la izolado, kiun vi agordis. Gasto kun unu interna adaptilo, defaŭlta vojo ĉe la pordego kaj sen NAT-adaptilo havas neniun vojon, kiu preterpasas la pordegon. Gasto kun nurgastiga adaptilo kaj NAT-adaptilo havas du vojojn, kaj nur unu el ili estas tiu, kiun vi intencis testi.

Enkursigu kaj traduku sur la pordego, poste igi ĝin fermiĝi ĉe fiasko

VirtualBox ne plusendas inter segmentoj; la gasto faras tion. Kun la VM de la VPN-servilo malantaŭ la pordego, ebligu plusendadon kaj traduku la trafikon de la kliento dum ĝi forlasas al la servilo:

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

Kun tiu regulo la servilo vidas la LAN-adreson de la pordego anstataŭ tiun de la kliento, kaj tiel aspektas reala kliento malantaŭ la NAT de provizanto al ĉefpunkto. Konservu la sysctl-valoron en /etc/sysctl.d/ kaj la regulon en kiu ajn fajroŝirmila servo, kiun la distribuo uzas, alie restarto silente redonas la laboratorion al enkursigita sed netradukita stato.

Plusendado ne estas rajtigo. Sub la defaŭlta politiko FORWARD kun valoro ACCEPT, gasto, kies defaŭlta vojo montras al la pordego, eliras tra tiu interfaco, kiun la enkursiga tabelo elektas, tunelo aŭ ne. Se la pordego ankaŭ havas NAT-adaptilon por pakaĵinstalado, tiu adaptilo estas funkcianta neĉifrita elirejo en la momento, kiam la tunelo falas, kaj via nur-VPN-testo neniam estis nur-VPN-testo.

Kiam la servilo anstataŭe estas fora kaj la pordego mem finas la tunelon, la sama decido montras al la tunela interfaco, ne al la retkarto, kiu atingas la interreton:

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

Tenu la propran eksteran transporton de la tunelo kaj eksterbendan administran vojon aparte de la plusendata trafiko. Se la sola maniero ripari la pordegon estas tra la tunelo, kiun vi sencimigas, la laboratorio fariĝas ekzerco pri ŝlosiĝo. Seria konzolo, nurgastiga administra adaptilo aŭ momenta kopio de konata bona stato estas pli malmultekostaj ol permane restarigi rompitan enkursigilon.

Kontrolu la vojon de la gasto, ne de la gastiganto

Laboru eksteren. Konfirmu, ke la kliento atingas la WAN-adreson de la pordego, poste la servilon tra la pordego, poste ke konekto al la VPN-pordo eliras kaj revenas. Registraĵo sur ambaŭ pordegaj interfacoj montras, ĉu la respondo alvenas kaj estas forĵetata sur la reena vojo, kion registraĵo nur sur la kliento ne povas distingi:

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

Poste pruvu la elirejon. Demandu de la gasto al adresreflekta servo, kian fonton ĝi vidas, kaj komparu tion kun la propra elira adreso de la pordego; se la respondo kongruas kun la adreso de la gastiganto, ekzistas vojo ĉirkaŭ la tunelo. Kontrolu, kiun solvilon la gasto efektive uzas, kaj kontrolu IPv6 aparte, ĉar segmento, kie IPv6 estas ŝaltita dum la tunelo portas nur IPv4, likas laŭ dezajno kaj ne hazarde.

Fine, rompu ĝin intence. Haltigu la tunelon, aŭ bloku ĝian eksteran pordon, kaj malfermu novan konekton de la gasto. Ĝi devas fiaski, kaj la kialo devas esti unu, kiun vi povas nomi: neniu vojo, rifuza regulo aŭ mortinta solvilo. Restartu la tunelon kaj konfirmu, ke la gasto resaniĝas sen rekonstrui la reton. Se mesh-VPN kiel Hamachi aŭ ZeroTier dividas la laboratorion, memoru, ke pontigita adaptilo sekvas la adaptilan nomon, ne la mesh-on, do la ponto devas esti reorientigita post kiam la kliento instalas sian propran virtualan adaptilon.

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

Dividi la tunelon de gasto kun la gastiganto spegulas la problemon. Direkti la defaŭltan vojon de la gastiganto al la gasto funkcias, kaj same prokuro ene de la gasto; NAT tra la gastiganto ne portas la tunelon de la gasto por trafiko, kiun la gastiganto originis. Konservu la segmentnomojn kaj la fajroŝirmilajn regulojn en unu loko, prenu momentan kopion de la funkcianta stato, kaj notu la fontadreson, kiun la servilo observis. La sekva profilŝanĝo tiam kostas unu skriptan kuron anstataŭ rekonstruitan laboratorion.