Mit akadályoz meg valójában az OpenVPN route-nopull beállítása a szervernél

Begyújtötte a route-nopull beállítást egy kliensprofilba, hogy az alagút ne nyelje le az alapértelmezett útvonalát, és most az iroda alhálózata elérhetetlen, miközben a kliens továbbra is azt mondja, hogy csatlakozva van. Mindkét megfigyelés igaz, és semmi sem hibázott. A kapcsoló arra utasítja a klienst, hogy hagyja ki a szerver által küldött útvonalakat és DHCP-bejegyzéseket, ami szűkebb utasítás, mint amire a legtöbb ember számít, amikor hozzáadja. Ami marad, egy működő alagút, amelynek nincs véleménye arról, mely célpontok használják.

Ez a rés a teljes döntés, amelyről ez a cikk szól. Vagy a szerver írja le a hálózatot, vagy a kliens, és a kapcsoló ezt a feladatot a kliensnek adja át anélkül, hogy bármit is megtenne belőle Ön helyett.

Mit kapcsol ki a kapcsoló csatlakozáskor

Egy húzó OpenVPN kliens általában a hitelesítés után egy csomagot vesz át a szervertől: útvonalakat, az alapértelmezett átjáró átirányítását, DNS-szervereket és néhány hangolási direktívát. Ha a route-nopull érvényben van, a kliens továbbra is elfogadja a munkamenetet, továbbra is ellenőrzi a tanúsítványokat, továbbra is egyeztet a titkosításokról és a keepalive-ról, és továbbra is felhozza az interfészt. Amit eldob, az a küldött route sorok és a küldött dhcp-option sorok alkalmazása, a DNS-t is beleértve.

A zavart egy halott alkalmazás melletti zöld jelző okozza. Az alagút létezik; a célpontok hozzárendelése ehhez az alagúthoz nem. A kliens állapotpaneljén semmi sem különbözteti meg a „csatlakozva és útvonalat választ” állapotot a „csatlakozva és tétlen” állapottól, mert az alagút szemszögéből mindkettő ugyanaz az állapot.

Miért nem tud mégis semmit átirányítani egy élő alagút

Az interfész a saját címével jelenik meg, és egy pont-pont kapcsolatban gyakran nincs semmi konkrétabb, mint egy hosztútvonal a partner felé. Egy privát alhálózat csak akkor válik elérhetővé, ha valamilyen útvonal a megfelelő előtaggal erre az interfészre mutat, és a küldés kikapcsolásával ez az útvonal soha nem érkezik meg. A letöltött profil sem segít általában, mert abból a feltevésből írták, hogy a szerver pontosan ezt az információt szolgáltatja. Ezért tűnhet egészségesnek az interfész, miközben az alhálózat sötét marad.

A profil olvasása tehát nagyon keveset bizonyít. Olvassa inkább a futó állapotot a csatlakoztatott gépen:

ip addr show tun0
ip route show dev tun0
ip route get 10.20.5.10

Az alhálózati útvonal nélküli cím a második parancsban ennek a problémának a jele. A harmadik parancs aztán arra a kérdésre válaszol, amely igazán érdekli a felhasználókat, mert azt az interfészt jelenti, amelyet a kernel egy adott célponthoz választana, nem pedig azt a listát, amelyről remélte, hogy használni fogja. Ha a fizikai kapcsolatán keresztül válaszol, az alagút egyáltalán nincs az útvonalon.

A névfeloldás egy kapcsolódó ok miatt hibázik, nem egy különálló miatt. A küldött dhcp-option DNS bejegyzéseket ugyanaz a kapcsoló hagyja ki, így a belső hosztokra vonatkozó lekérdezések ahhoz a feloldóhoz mennek, amelyet a helyi hálózat biztosított. Annak a feloldónak nincs zónája az irodához, ezért a lekérdezés meghiúsul vagy nyilvános választ ad, és a hiba szerverproblémának tűnik, holott klienskonfigurációs probléma. A címnek a név előtti tesztelése az, ami elválasztja a kettőt.

Választás a kapcsoló és az előtagszűrő között

A két lehetőség ugyanazon panasz különböző formáit oldja meg, és a rossz választás az, ami a csatlakozva-de-használhatatlan állapotot létrehozza. Az egyik teljesen lecseréli a küldött házirendet, a másik előtag szerint szerkeszti. A táblázat a rövid változatot adja, az utána következő bekezdés pedig azt a részt fedi le, amely meglepí az embereket.

A pull-filter három igés előtag-egyeztető, így képes egy sorcsaládot elfogadni, csendben figyelmen kívül hagyni, vagy a kapcsolatot teljesen elutasítani, amikor egy előtag megjelenik. Ez utóbbi viselkedés az, amit érdemes ismerni: az elutasítási szabály a házirend-vitát sikertelen kézfogássá változtatja a csendes kihagyás helyett. Az OpenVPN 2.6 kézikönyve felsorolja az elfogadott előtagokat és az egyes igék pontos jelentését.

Egy gyakori középút csak a redirect-gateway elutasítása, és hagyni, hogy az irodai útvonalak és a DNS a szándéknak megfelelően érkezzenek. Ez működésben tartja a küldést azoknál a részeknél, amelyeket a szerver jobban ért, mint Ön, miközben megakadályozza azt az egy sort, amely átvenné az alapértelmezett útvonalát.

Útvonalak és feloldó kézi hozzáadása

Ha megtartja a kapcsolót, a profilnak azt kell mondania, amit a szerver mondott volna. A kliensoldali route direktívák a kapcsolat létrejötte után érvényesülnek, tehát a kapcsoló mellett működnek, nem pedig blokkolja őket. Tegye őket a profilba, ne egy interaktív parancssorba, különben a következő újracsatlakozás nem állítja vissza a működő állapotot.

route-nopull
route 10.20.0.0 255.255.0.0
dhcp-option DNS 10.20.0.53

A DNS-sor kényelmetlen helyzetben van: kliensoldali direktíva, de néhány kliens csak a platform DNS-integrációján keresztül alkalmazza, amely felülírhatja, amikor a kapcsolat megváltozik. Egy systemd-gazdagépen kiszámíthatóbb a feloldót közvetlenül az alagút interfészén beállítani, mint abban bízni, hogy a kliens megnyeri a prioritási versenyt:

resolvectl dns tun0 10.20.0.53
resolvectl domain tun0 ~corp.example.com

Az útválasztási tartomány legalább olyan fontos, mint a cím. Nélküle a nyilvános nevekre vonatkozó lekérdezések is a belső feloldóhoz kerülhetnek, és minden belső feloldó, amely megtagadja a rekurziót, megtöri a böngészést, miközben a privát zóna tovább működik. Vele csak az adott utótag alatti nevek irányítódnak az alagút feloldójához, és minden más a fizikai kapcsolatot követi.

Az eredmény ellenőrzése: cím, név és a külső útvonal

Három teszt választja szét a lehetséges hibákat. Kérje le a privát címet IP szerint, majd ugyanazt a hosztot név szerint, majd egy közönséges nyilvános oldalt. A működő IP és a hibázó név a feloldóra utal; a hibázó IP és a működő név az útválasztásra utal; ha mindkettő hibázik, az általában azt jelenti, hogy az alagút nincs az útvonalon.

Aztán kifelé nézzen, ne befelé. Az alagút végpontjának saját útvonalának túl kell élnie a változást, és minden blokkoló hibát az alagútra kell korlátozni anélkül, hogy elkapná a végpontot. Az a kliens, amely az alagút leesése után is böngészik, házirendprobléma, nem útválasztási probléma, és a fenti három teszt egyikében sem jelenik meg.

Írja be a végleges listát a profil dokumentációjába: az útvonalakat, a feloldót, a tartományokat és az okot, amiért mindegyik létezik. Az az újracsatlakozás, amely ugyanazt a táblázatot állítja elő, az egyetlen bizonyíték arra, hogy a helyi házirend teljes. Ha az alkalmazások továbbra is hibáznak, miközben az alagút áll és mindhárom teszt átment, a következő hely, ahol érdemes nézni, a csatlakozva-de-offline problémák osztálya, nem pedig a már ellenőrzött tanúsítványok.