El kell döntenie, mennyi gépezetet érdemel a VPN-laborja. Két VirtualBox-szegmens között egy átjáró VM reprodukálja a címfordítást, a visszautat és annak a tűzfalnak a helyét, amely mögött egy valódi kliens ül. Egyetlen csak gazdagép-szegmens egyetlen ellenőrzött ajtót ad, és semmi mást. Az átjárós változat három vendéget és egy útválasztási táblát igényel, amelyet Ön tart fenn; a csak gazdagép-változat egy vendéget és egy házirendet. Három kérdés választja el őket, és a harmadik dönti el, hogy a tesztje egyáltalán átmehet-e.

Válaszoljon három kérdésre, mielőtt bármit klónozna

Kezdje azzal, mit kell a VPN-kiszolgálónak megfigyelnie. Ha a kiszolgálónak olyan forráscímet kell látnia, amely nem a tesztvendégé, valaminek fordítania kell közöttük, és annak a valaminek az Ön által vezérelt útválasztónak kell lennie. A csak gazdagép-hálózat adaptert ad a gazdagépnek a vendég szegmensén, nem fordítót. Amikor a vendégnek aztán valamit kívül el kell érnie, NAT-adaptert csatol, és a VirtualBox saját NAT-motorja átírja a forrást anélkül, hogy megkérdezné.

Ezután kérdezze meg, elérhet-e a vendég bármit az alagúton kívül. Ez a válasz a belső vagy a csak gazdagép mellett dönt, és ez az a kérdés, amelyet a legtöbb laborleírás kihagy. Végül kérdezze meg, mi történjen, amikor az alagút leesik, mert ez házirendet dönt el, nem topológiát, és egy labor, amely csak a boldog utat bizonyítja, szinte semmit nem tesztelt.

What the test requiresRouted gateway VMHost-only guest
Server sees a translated source addressYes, from your own MASQUERADE ruleNo, VirtualBox NAT does it instead
The guest has exactly one egressYes, while the second adapter faces the tunnelOnly until a NAT adapter is attached
Policy is testable during a tunnel failureRules live in one placeRules live on each guest

Kösse össze a három szerepet belső hálózatokkal

Használjon három vendéget és két elnevezett szegmenst, az átjáró legyen az egyetlen gép, amely mindkettőn adapterrel rendelkezik:

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

A belső hálózathoz nincs külön létrehozási lépés. A --intnet1 sztring a szegmens: két gép csak akkor osztja meg, ha a név pontosan egyezik, és a gazdagépen semmi nem csatlakozik hozzá. Ez az utolsó tulajdonság az oka annak, hogy a labor tisztán megismételhető, mivel a gazdagép útvonalai, saját VPN-kliense és tűzfala nem érhetik el véletlenül a vendégeket. A belső szegmensnek sincs DHCP-kiszolgálója, hacsak nem ad hozzá egyet, ezért a statikus címek a legrövidebb út.

Adjon a kliensnek csak a WAN-címét, az alapértelmezett átjáró pedig az átjáró WAN-címére mutasson. A kiszolgáló LAN-címet kap, és az átjáró LAN-címét használja alapértelmezett átjárójaként. Az a vendég, amely két címet tart egy szegmensen, vagy eltévedt útvonala van a másik szegmens felé, megkerülő úttal rendelkezik az útválasztó körül, és az alábbi tesztek hazudni fognak Önnek.

A VM-nevek mellett szöveges fájlt tartok a négy címmel és a két szegmensnévvel, és minden shellbe beillesztem. Hetekkel később, amikor egy profilváltozás elront valamit, ez a fájl a különbség a profil hibakeresése és a saját emlékezetem hibakeresése között.

A szivárgásmentes szegmenshez válasszon belsőt vagy csak gazdagép-módot

A csak gazdagép-mód virtuális adaptert hoz létre magán a gazdagépen, általában vboxnet0, és címet ad a gazdagépnek a vendég szegmensén. Ez kényelmes az adminisztrációhoz és végzetes az izolációs teszthez, mert a gazdagép most közvetlenül elérheti a vendéget, és minden gazdagép oldali szolgáltatás lehetséges úttá válik. A belső módnak egyáltalán nincs gazdagép-adaptere. A két mód könnyen összekeverhető a hálózati beállítások paneljén, ezért a dokumentált különbséget ellenőrizze, ne a címkét (lásd a VirtualBox hálózati részletei oldalt).

Az olyan vendéghez, amelynek az alagutat kell használnia, a belső a biztonságosabb alapértelmezés, az átjáró az egyetlen kijárat. Ha megtartja a csak gazdagép-módot, kezelje a gazdagép-adaptert felügyeleti útvonalként, és mondja ki hangosan: a gazdagép elérheti a vendéget, a vendég pedig nem használhatja a gazdagépet kijáratként.

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

A bizonyítható izoláció az, amit beállított. Az egyetlen belső adapterrel, az átjárón alapértelmezett útvonallal és NAT-adapter nélkül rendelkező vendégnek nincs az átjárót megkerülő útja. A csak gazdagép-adapterrel és NAT-adapterrel rendelkező vendégnek két útja van, és csak az egyik az, amelyet tesztelni szeretett volna.

Irányítson és fordítson az átjárón, majd kényszerítse zárt meghibásodásra

A VirtualBox nem továbbít a szegmensek között; a vendég teszi. Amikor a VPN-kiszolgáló VM az átjáró mögött van, engedélyezze a továbbítást, és fordítsa a kliens forgalmát, amikor az a kiszolgáló felé elhagyja a hálózatot:

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

Ezzel a szabállyal a kiszolgáló a kliensé helyett az átjáró LAN-címét látja, és pontosan így néz ki egy valódi kliens egy szolgáltatói NAT mögött egy hálózati végpont számára. Mentse a sysctl értékét a /etc/sysctl.d/ alatt, a szabályt pedig abban a tűzfalszolgáltatásban, amelyet a disztribúció használ, különben az újraindítás csendben visszaállítja a labort irányított, de nem fordított állapotba.

A továbbítás nem felhatalmazás. A ACCEPT alapértelmezett FORWARD házirendje alatt az a vendég, amelynek alapértelmezett útvonala az átjáróra mutat, azon a felületen hagyja el a hálózatot, amelyet az útválasztási tábla választ, alagúttal vagy anélkül. Ha az átjárónak NAT-adaptere is van a csomagtelepítéshez, az az adapter a csomagtelepítés pillanatában működő titkosítatlan kijárat, amint az alagút leesik, és az Ön csak VPN-tesztje soha nem volt csak VPN-teszt.

Amikor a kiszolgáló távoli, és maga az átjáró fejezi be az alagutat, ugyanaz a döntés az alagút felületére mutat, nem az internetet elérő hálózati kártyára:

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

Tartsa az alagút saját külső szállítását és a sávon kívüli felügyeleti útvonalat külön a továbbított forgalomtól. Ha az átjáró javításának egyetlen módja az a alagút, amelyet hibakeres, a labor kizárási gyakorlattá válik. Egy soros konzol, egy csak gazdagép felügyeleti adapter vagy egy ismert jó állapot pillanatképe olcsóbb, mint egy elromlott útválasztó kézi helyreállítása.

A vendég felől ellenőrizze az utat, ne a gazdagép felől

Kifelé haladjon. Erősítse meg, hogy a kliens eléri az átjáró WAN-címét, majd az átjárón keresztül a kiszolgálót, majd hogy a VPN-portra irányuló kapcsolat kimegy és visszatér. Az átjáró mindkét felületén végzett rögzítés megmutatja, megérkezik-e a válasz, és eldobódik-e a visszaúton, amit a csak a kliensen végzett rögzítés nem tud megkülönböztetni:

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

Ezután bizonyítsa a kijáratot. Kérdezze meg a vendégből egy címvisszaverő szolgáltatástól, milyen forrást lát, és hasonlítsa össze az átjáró saját kijárati címével; ha a válasz egyezik a gazdagép címével, létezik az alagutat megkerülő út. Ellenőrizze, melyik feloldót használja a vendég valójában, és ellenőrizze az IPv6-ot külön, mert az a szegmens, ahol az IPv6 engedélyezett, miközben az alagút csak IPv4-et szállít, tervezés szerint szivárog, nem véletlenül.

Végül szándékosan törje el. Állítsa le az alagutat, vagy blokkolja a külső portját, és nyisson új kapcsolatot a vendégből. Meg kell hiúsulnia, és az oknak olyannak kell lennie, amelyet meg tud nevezni: nincs útvonal, van egy elutasító szabály, vagy halott a feloldó. Indítsa újra az alagutat, és erősítse meg, hogy a vendég a hálózat újjáépítése nélkül helyreáll. Ha egy mesh VPN, például a Hamachi vagy a ZeroTier osztozik a laboron, ne feledje, hogy az áthidalt adapter az adapter nevét követi, nem a mesht, ezért a hidat újra kell irányítani, miután a kliens telepítette a saját virtuális adapterét.

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

A vendég alagútjának megosztása a gazdagéppel ugyanazt a problémát tükrözi. A gazdagép alapértelmezett útvonalát a vendégre irányítani működik, és a vendégen belüli proxy is; a gazdagépen keresztüli NAT nem szállítja a vendég alagútját a gazdagép által indított forgalomhoz. Mentse a szegmensneveket és a tűzfalszabályokat egy helyre, készítsen pillanatképet a működő állapotról, és jegyezze fel azt a forráscímet, amelyet a kiszolgáló megfigyelt. A következő profilváltozás akkor egy szkriptfuttatásba kerül egy újjáépített labor helyett.

Kapcsolódó cikkek