A VPN futtatása a gazdagépen vagy a VM-en belül? Döntési útmutató

A tunel vendégen belüli és gazdagépen való felépítése egyaránt megváltoztatja azt a címet, amelyet a böngésző jelent, és itt véget is ér a hasonlóság. A vendég tulajdonában lévő tunel a kulcsait, az alapértelmezett útvonalát és a feloldóját a vendég kernelében tartja, míg a gazdagép titkosított csomagokat továbbít egyetlen távoli címre. A gazdagép tulajdonában lévő tunel a tükörkép: a gazdagép kliense tartja a munkamenetet, és útvonalakat és házirendet alkalmaz, a vendég pedig kölcsönveszi, ami kijön. Rossz tulajdonost választva minden későbbi tünet a rossz géphez küldi Önt. Két parancs körülbelül egy perc alatt eldönti a kérdést, és ennek az útmutatónak a többi része az, hogy mit tegyen a válasszal.

Döntse el a tulajdonost, mielőtt hozzányúl a klienshez

A szabály arról szól, hol keletkezik a titkosított szöveg, nem arról, melyik gép mutat VPN-ikont. Ha a vendég állítja elő, a vendégnek működő útvonalra van szüksége a VPN-kiszolgálóhoz, és semmi másra a gazdagéptől. Ha a gazdagép állítja elő, a vendégnek a gazdagépen át vezető útnak túl kell élnie minden házirendet, amelyet a gazdagép kliense a helyi forgalomra kényszerít.

Három kérdés általában kiválasztja Önnek az elhelyezést. Túl kell élnie a vendég forgalmának egy vállalati kliens mellett a gazdagépen? Akkor a tunel a vendégben van. Több vendégnek kell egy hitelesítő adat és egy kilépési cím? Akkor a gazdagépen van, szándékosan beállított továbbítással. A vendég forgalmának teljesen kívül kell maradnia a gazdagép VPN-jén? Akkor a vendégben lévő tunel az egyetlen elrendezés, amely ezt a felépítéséből adódóan megadja.

Írja fel a választ egy sorban a VM neve mellé: guest-owned vagy host-owned. Hatgépes laborban ez a feljegyzés több időt takarít meg, mint bármelyik lenti lépés, mert megakadályozza, hogy olyan tunelt hibakeressen, amely soha nem is volt abban a gépben, amelyre bejelentkezett.

A WSL1 és a WSL2 ellentétes esetek

A WSL1 nem virtuális gép, ezért az elhelyezés kérdése jobbára elpárolog. Linux binárisai egy fordítórétegen keresztül a Windows hálózati verem ellen futnak, és egy Linux VPN-kliensnek nincsenek önálló felületei, amelyeket be kellene állítani. A működő elrendezés egy Windows-oldali tunel, ahol a disztribúció minden tulajdonlás nélkül használja az eredményt.

A WSL2 ennek az ellenkezője. Valódi kernelt futtat egy könnyű segéd-VM-ben egy Hyper-V virtuális kapcsoló mögött, és a címterét a gazdagép oldali adapteren keresztül NAT-olja. Ezért a disztribúción belüli Linux-kliens úgy viselkedik, mint egy fizikai Linux-dobozon: létrehozza a tun0 vagy wg0 interfészt, telepíti a saját útvonalait, és működik. A hiba a gazdagép oldalán él. Amikor egy Windows VPN-kliens olyan házirenddel kapcsolódik, amely blokkolja a helyi hálózatokon a forgalmat, a WSL2 alhálózatát nem megbízható helyi hálózatnak tekinti, és elvágja a NAT-útvonalat. A disztribúció ekkor elveszíti a DNS-t és a kimenő hozzáférést, miközben a saját tunelje még egészséges: a wg show kézfogást jelent, az ip route helyesnek tűnik, és a curl megakad.

Melyik javítást használhatja, a Windows buildjétől függ. A régebbi a gazdagép kliensében a WSL alhálózatára tett kivétel, amelyet a kliens helyi hálózati vagy osztott tunel beállításai alatt adnak hozzá. Az újabb, az ezt támogató Windows 11 buildeken a tükrözött hálózat: tegye a networkingMode=mirrored értéket a %UserProfile%\.wslconfig fájl [wsl2] szakaszába, futtassa a wsl --shutdown parancsot, és a disztribúció a gazdagép interfészeit osztja meg egy privát NAT-alhálózat helyett. A tükrözött mód a localhost és a bejövő portok viselkedését is megváltoztatja, ezért migrációként kezelje, ne kapcsolóként.

NAT, híd és mit láthat a gazdagép

NAT alatt a vendég tunelcsomagjai a VPN-kiszolgáló nyilvános címére címződnek, és titkosított UDP-ként vagy TCP-ként lépnek ki a gazdagép adapterén. A gazdagép egyetlen folyamot és annak bájtszámát látja, semmit a benne lévő célokról. Hídadapter alatt a vendégnek saját 2-es rétegbeli identitása van a fizikai LAN-on, saját DHCP-bérletet vesz fel, és minden MAC-alapú házirend számára második eszköznek látszik. Egyik mód sem engedi a gazdagépnek a tunel hasznos terhét olvasni; a hidalt vendég egyszerűen sokkal láthatóbb a körülötte lévő hálózat számára.

Az elkülönítésnek is van alsó határa. A vendég nem bújhat el a gép elől, amely a memóriáját birtokolja, és aki a gazdagépet irányítja, olvashat kulcsokat a vendég RAM-jából. Amit a vendégbeli tunel ad, az egy útválasztási és egy kártevő-határ, nem védelem a laptopot tartó személy ellen. Érdemes nyitva tartani a dokumentált adapter módokat a választás közben, mert a mód megváltoztatja azt is, amit a gazdagép lát, és azt is, amit a LAN lát.

Útmutató: helyezze el, állítsa be, bizonyítsa

Futtassa ezt a négy ellenőrzést sorrendben egy friss vendég-héjban, és álljon meg az elsőnél, amely nem egyezik a feljegyzett tulajdonossal.

1. A ip route get 1.1.1.1, amely tun0 vagy wg0 értéket ad vissza, vendég-tulajdont jelent, a eth0 privát következő ugrással pedig gazdagép-tulajdont.
2. resolvectl query example.com, vagy olvassa el a /etc/resolv.conf fájlt ott, ahol a vendég nem futtat feloldó szolgáltatást. Az a tunel, amely forgalmat visz, de DNS-t nem, a leggyakoribb félig beállított állapot.
3. Hasonlítsa össze a kilépéseket: curl -4 -s https://ifconfig.me a vendégben, szemben a curl.exe -4 -s https://ifconfig.me paranccsal a gazdagépen. Az eltérő címek azt jelentik, hogy a vendég birtokolja a tunelt, és az a gazdagép, amely VPN-en van, miközben a vendég az otthoni szolgáltatót mutatja, az a „semmit sem örökölt” eset.
4. Ismételje meg mindkettőt -6-tal. A csak v4-es tunel szivárogtatja a v6-ot, hacsak a kliens nem blokkolja vagy irányítja, és sok kliens alapértelmezés szerint a fizikai interfészen hagyja a v6-ot.

Gazdagép-átjárós kialakításnál, ahol több vendég osztozik egy tunelen, a gazdagépnek továbbítania és fordítania kell. Linux gazdagépen ez három darab, és a vendég csendben visszaesik a sima útvonalára, ha bármelyik hiányzik:

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o wg0 -j MASQUERADE
iptables -A FORWARD -i virbr0 -o wg0 -j ACCEPT
iptables -A FORWARD -i wg0 -o virbr0 -m state --state RELATED,ESTABLISHED -j ACCEPT

A WireGuard oldalán a gazdagép partnerének AllowedIPs bejegyzésének tartalmaznia kell a vendégek alhálózatát, például 192.168.122.0/24, különben a visszacsomagok soha nem érkeznek meg, és a beállítás tűzfalproblémának tűnik. Egy Windows gazdagép ugyanezt az eredményt éri el az Internetkapcsolat megosztással vagy egy NAT-szabállyal a Hyper-V kapcsolón, és ugyanarra a visszaút-ellenőrzésre van szüksége.

Amikor az elrendezés még nyitott, ez a táblázat a leggyakoribb elrendezéseket fedi le:

Két tunel, két vendég és a köztük lévő ütközések

Amikor egyszerre két kilépésre van szüksége, a tartós minta a vendégenként egy tunel. Minden VM megtartja a saját alapértelmezett útvonalát és feloldóját, a gazdagép a szokásos hálózaton marad, és a két tunel soha nem vitatkozik ugyanazon az útválasztási táblán. Két vendég áthidalása sem vonja össze az útvonalaikat: a virtuális hálózat utat ad, és minden kliensnek továbbra is el kell mondani, hogy ez a helyi forgalom megkerülheti a tunelt.

Egy gazdagép-tunel és egy vendég-tunel együttes futtatása jogszerű, és a szándékos egymásba ágyazás néha pontosan az, amit szeretne, a vendég a saját tuneljén át lép ki, és az a tunel a gazdagépén át lép ki. Az teszi kieséssé, hogy senki nem jegyezte fel, melyik végpont melyik rétegen át érhető el. Tartson kétoszlopos listát a célról és a tulajdonosról, és az útvonal-ütközés kereséssé válik egy felfedezéssel töltött délután helyett.

Ellenőrizze, majd hagyja a helyreállítást a tulajdonosnál

Tesztelje a vendég belsejéből friss alkalmazásfolyamattal: forgalom, névfeloldás, mindkét címcsalád, és hogy mi történik, amikor a tunel megszakad. A gazdagép VPN-ikonja semmit nem mond a vendég lefedettségéről, és ezen a területen ez a leggyakoribb hamis megerősítés.

A helyreállítás is a tulajdonosé. A vendég tulajdonában lévő tunelt a vendég saját kliense és az általa írt útvonalak állítják helyre. A gazdagép tulajdonában lévő kialakítást a gazdagép indítási sorrendje állítja helyre, és a továbbítási szabályok nem élik túl az újraindítást, hacsak egy unit vagy egy indítási feladat újra nem alkalmazza őket. A visszaállított pillanatkép telepítés, nem visszavonás, mert a lemezzel együtt régi hitelesítő adatokat és régi útvonalakat hoz vissza. Mielőtt késznek nyilvánítja a munkát, erősítse meg, hogy a tulajdonos még mindig megfelel a feljegyzett sornak, hogy a DNS és mindkét címcsalád feloldódik a vendégen belül, hogy egy halott tunel használható hálózatot hagy fekete lyuk helyett, és hogy egy újraindítás vagy pillanatkép-visszaállítás ugyanazt az állapotot állítja elő.