Hogyan küldjünk csak egy privát alhálózatot a VPN-en át

Egy privát alhálózatot az alagúton és minden mást a szokásos útvonalon átvinni kicsi kérés, sokféle elrontási lehetőséggel. A végeredményt nem a split tunneling feliratú jelölőnégyzet dönti el, hanem az, hol érvényesül a döntés: magában az ügyfél útvonaltáblájában, a kiszolgáló által küldött útvonalban vagy a két végpont által tárgyalt házirendben. Válassza a rossz réteget, és vagy egy teljes alagutat kap, amelyet soha nem akart, vagy egy útvonalat egy olyan alagútba, amelyet a másik fél nem hajlandó elfogadni. Bármilyen konfiguráció megnyitása előtt három feltételes próbát használok, majd az alábbi mechanizmusok egyikét választom.

Három feltétel, amely eldönti a tervezést

Először is a pontos előtagra és maszkra van szüksége a hálózat tulajdonosától. A 10.x hálózat nem előtag; a 10.20.0.0/16 az. Győződjön meg arról, hogy nem fedi át az otthoni LAN-t, egy Docker-hidat vagy egy másik általa futtatott VPN-t, mert az átfedés kétértelművé teszi az útvonalat, és a kernel a nem kívánt bejegyzést választja.

Másodszor, ki válaszol a visszafelé irányuló forgalomra. Egy csomag alagútba irányítása csak a VPN-kiszolgálóig juttatja el. Ha az alhálózat egy másik útválasztó mögött van, amelynek nincs visszaútja az ügyfélkészletéhez, a kiszolgálónak maszkolnia kell a forgalmat, vagy annak az útválasztónak meg kell tanulnia a készletét. Semmilyen ügyféloldali útvonal nem pótol egy hiányzó visszautat.

Harmadszor, az érvényesítési pont. Egyes ügyfelek útvonalat telepítenek, a többit az operációs rendszer végzi. Mások házirendet tárgyalnak, és az átjáró által nem elfogadott házirend egyáltalán nem hoz létre alagutat: a csomagok nyilvánvaló hiba nélkül elvésznek. Bármi írása előtt derítse ki, melyik eset az öné.

WireGuard: az AllowedIPs az útvonaltábla

Az ügyfélen az AllowedIPs sorolja fel azokat a célokat, amelyek beléphetnek az alagútba, az wg-quick pedig minden bejegyzést közönséges útvonallá alakít. Tehát a feladat ügyféloldali fele egyetlen sor.

[Peer]
PublicKey = ...
Endpoint = vpn.example.net:51820
AllowedIPs = 10.20.0.0/16

Most hasonlítsa össze a kiszolgáló bejegyzését ugyanahhoz az ügyfélhez. Az azt írja le, amit a kiszolgáló küldeni fog az ügyfélnek, ami rendszerint az ügyfél alagútcíme, nem a privát alhálózat.

[Peer]
PublicKey = ...
AllowedIPs = 10.99.0.2/32

E kettő felcserélése a leggyakrabban látott hiba. Ha a 10.20.0.0/16 a kiszolgáló peer szakasza alá kerül, az azt állítja, hogy a teljes alhálózat e mögött az ügyfél mögött van, ami hely-hely közötti igény, nem engedély. Azok a csomagok, amelyek egyetlen peer AllowedIPs-ének sem felelnek meg, csendben elvésznek, így a hibás bejegyzés pontosan tűzfalproblémának látszik.

Ha saját maga kezeli az útvonalakat, állítsa be a Table = off beállítást a [Interface] alatt, és adja hozzá a kívánt útvonalat. Akkor semmi sem kerül be automatikusan, ezért az útvonal ahhoz tartozik, ami felhozza az interfészt.

OpenVPN: küldje el az útvonalat, majd győződjön meg róla, hogy megérkezik

Egy szokásos kiszolgálón a változás egyetlen utasítás a kiszolgáló konfigurációjában, az ügyfélkészlet mellett.

push "route 10.20.0.0 255.255.0.0"

Az ügyfél csatlakozáskor hozzáadja. A hibaállapot akkor jelenik meg, ha ugyanaz a profil a redirect-gateway beállítást is elküldi, vagy ha valaki már hozzáadta a route-nopull beállítást: az első teljes alagúttá teszi a munkamenetet, a második pedig minden elküldött útvonalat eldob, a sajátját is.

Az ügyfélnek, amelynek szűk viselkedésre van szüksége egy teljes alagútú kiszolgálóval szemben, csak azokat a részeket kell figyelmen kívül hagynia, amelyeket nem akar. Az OpenVPN 2.4 és újabb verzióiban az pull-filter pontosan erre való.

pull-filter ignore "redirect-gateway"
route 10.20.0.0 255.255.0.0

Tartsa külön a címcsaládokat: az elküldött IPv4-útvonal semmit sem tesz egy olyan belső szolgáltatásért, amely IPv6-ra oldódik fel, és az a szolgáltatás elbukik az alagúton, miközben minden más rendben lévőnek látszik.

Ha a privát alhálózat nem a VPN-kiszolgálón van, hanem egy másik ügyfél mögött, a kiszolgálót értesíteni kell. Adjon hozzá ügyfelenkénti fájlt a client-config-dir használatával, amely tartalmazza a iroute 10.20.0.0 255.255.0.0 bejegyzést, valamint a megfelelő route bejegyzést, hogy a többi ügyfél megtanulja az útvonalat. A iroute nélkül a kiszolgálónak semmi oka sincs arra, hogy azt az előtagot éppen azon az alagúton küldje el.

IPsec: a forgalomszelektoroknak egyezniük kell

Az IPsecnél nincs elküldendő útvonal. A két végpont megtárgyalja, mely címek vannak az alagúton belül, és a megbeszélt szelektorokon kívüli forgalom sem titkosítva nincs, sem azon keresztül nem megy. Egy strongSwan-ügyfélen a szelektorok kifejezettek.

leftsubnet=192.168.1.0/24
rightsubnet=10.20.0.0/16

Ha az átjáró mindkét oldalon 0.0.0.0/0 beállítással van konfigurálva, az IKEv2 szűkítése általában a gyermek-SA-t a két ajánlat metszetére csökkenti, ami a kívánt eredmény. Egyes átjárók viszont elutasítják a konfigurált szelektoraikkal nem egyező ajánlatot, és a napló ilyenkor sikertelen gyermek-SA-t mutat, nem útvonalazási panaszt. Amikor ez történik, a változtatás az átjáróhoz tartozik, mert egy ügyfélútvonal nem tud alagutat létrehozni olyan szelektorhoz, amelyet a másik fél nem fogad el.

Windowson a beépített ügyfél ugyanezt a döntést két beállítás mögé rejti. Az alagút felosztásának bekapcsolva kell lennie, és az előtagot regisztrálni kell a profilnál.

Set-VpnConnection -Name Office -SplitTunneling $true
Add-VpnConnectionRoute -ConnectionName Office -DestinationPrefix 10.20.0.0/16

Az előtag regisztrálása az, ami túlélővé teszi egy újracsatlakozáskor, amit egy kézzel hozzáadott útvonal nem tesz meg.

Tartsa a végpontot és a DNS-t a döntésen kívül

A VPN végpontjának elérhetőnek kell maradnia az alagút nélkül, különben az alagút önmagába omlik. Ha csak a 10.20.0.0/16 van útvonalazva, ez automatikus, mert a végpont nyilvános cím. Teljes alagútú profilnál ez nem így van, és az ügyfélnek kifejezett hostútvonalra van szüksége a végpont felé, mielőtt az alagút feljön.

A DNS egy második döntés, amelyet az útvonalküldés nem hoz meg ön helyett. A belső nevek rendszerint olyan feloldón keresztül oldódnak fel, amelyet csak a privát hálózat érhet el. Ha a kiszolgáló küld egy DNS-kiszolgálót, minden név azon megy keresztül; ha nem, a belső nevek vagy elbuknak, vagy nyilvánosan oldódnak fel valamire, amit nem akart. A megosztott DNS egy keresési tartományt tart a belső feloldón, de ez az ügyfél támogatásától függ, ezért kezelje önálló feladatként, nem az útvonalazás mellékhatásaként.

Ellenőrizze, majd indítsa újra és ellenőrizze ismét

Három próba lefedi az útvonalazás kérdését. Kérdezze meg a kernelt, hova menne egy távoli cím, hozzon le valamit az alhálózat belsejéből, majd erősítse meg, hogy egy közönséges nyilvános kérés továbbra is a szokásos kapcsolatán keresztül megy ki.

ip route get 10.20.5.7
curl -sS http://10.20.5.7/health
curl -sS https://ifconfig.me

Az első sor egy interfészt nevez meg. Ha a fizikai interfészét nevezi meg, az útvonal soha nem érkezett meg. Windowson a Find-NetRoute -RemoteIPAddress 10.20.5.7 ugyanarra a kérdésre válaszol, és az utolsó próbának továbbra is a szokásos címét kell mutatnia, nem a VPN-kiszolgálóét.

Utána indítson újra. A kézzel hozzáadott útvonalak eltűnnek, míg a profilból, egy elküldött konfigurációból vagy az AllowedIPs beállításból származó útvonalak visszatérnek. Ha a szűk hozzáférés az újraindítás előtt működik és utána elbukik, a hiba abban van, hogyan indul az alagút, nem magában az útvonalban.

Mielőtt késznek nevezné, erősítsen meg négy dolgot: az előtag a hálózat tulajdonosától származik és semmivel sem fed át helyben, a visszaút létezik, vagy maszkolási szabály helyettesíti, a beállított mechanizmus az, amely a platformján érvényesíti az útvonalazást, és ugyanazok a próbák tiszta újraindítás után is átmennek. A strongSwan továbbítási megjegyzései érdemes elolvasni, ha a visszaút az a rész, amely folyton elbukik.