Mi történik valójában, amikor VPN-t indít Linuxon

Nyomja meg a csatlakozást, és három dolog változik meg egy Linux gépen: megjelenik egy interfész, útvonalak telepítődnek, és a feloldó másképp kezd válaszolni. A beállítási hibák többsége abból ered, hogy a három közül az egyik a többi nélkül történik meg, vagy hogy két program nem ért egyet abban, ki birtokolja őket. A sorrend megértése gyorsabban megmagyarázza a hibát, mint egy kliens naplókimenetének olvasása.

Az interfész hamarabb megjelenik, mint hogy bármi működne

Az alagútügyfél virtuális interfészt nyit, és csomagokat ad át neki. A TUN eszköz IP-csomagokat továbbít, erre van szüksége egy útvonalazott VPN-nek; a TAP eszköz Ethernet-kereteket továbbít, erre van szüksége egy hídas kialakításnak. A rendszermagmodul biztosítja az eszközt, és az ügyfél birtokolja, ameddig a munkamenet tart.

Az interfész feljön, de ez nem ugyanaz, mint a működő alagút. Létezhet címmel, miközben a partner elérhetetlen, és ezért az interfészek listája az első ellenőrzés, nem az utolsó. Az az eszköz, amely feljöttnek jelenti magát, a rendszermag virtuális kapcsolatról alkotott képét írja le, nem a partner válaszkészségét.

Hagyja békén a kapott interfész módot. A TUN profil TAP-ra váltása nem tesz egy útvonalazott kiszolgálót hídassá, és általában olyan kapcsolatot eredményez, amely létrejön, de semmit nem továbbít.

Az útvonalakat az telepíti, aki az alagutat birtokolja

Az útvonalak a második változás, és a tulajdonjoguk fontosabb, mint a tartalmuk. Egy NetworkManager-profil, egy systemd-egység és egy kézzel indított ügyfél is telepíthet útvonalakat, és ha kettő ezt egyszerre teszi, olyan tábla keletkezik, amelyet később senki nem tud megmagyarázni.

ip -br addr show
ip route show
ip -6 route show

A teljes alagút profilja lecseréli az alapértelmezett útvonalat; a megosztott alagút profilja konkrétabb útvonalakat ad hozzá, és békén hagyja az alapértelmezettet. Mindkettő normális, és a második az oka annak, hogy az alapértelmezett útvonal törlése rossz első teszt egy távolról felügyelt gépen. Az eltávolítása a leggyorsabb módja annak is, hogy elveszítse a munkamenetet, amelyet a probléma javítására használ.

Olvassa a táblát ahelyett, hogy feltételezne. Egy konkrétabb útvonal vagy egy házirend-szabály eljuttathatja a forgalmat az alagútba, miközben az alapértelmezett útvonal még mindig a fizikai interfészre mutat, ami ellentmondásosnak tűnik, amíg el nem olvassa az egész táblát. Ez a kombináció normális a megosztott alagútnál, és zavaró mindenkinek, aki azt várja, hogy egy sor leírja a kialakítást. Keresse azt az útvonalat, amely a tényleges céljához illeszkedik, ne azt, amely az ábrához illeszkedik.

A feloldó kezet cserél

A DNS a harmadik változás, és az, amelyet a legvalószínűbben olyan helyen kezelnek, ahol nem nézett. Asztali gépen a NetworkManager kapcsolatonként továbbíthatja a feloldó beállításait. systemd-resolvedet használó rendszeren a beállítások kapcsolatonként érvényesülnek, és a /etc/resolv.conf lehet csonk vagy szimbolikus hivatkozás, nem olyan fájl, amelyet szerkesztenie kellene.

resolvectl status
readlink -f /etc/resolv.conf
cat /etc/resolv.conf

Ha a feloldófájl kézi szerkesztése eltűnik egy újracsatlakozás után, az annak a jele, hogy keresse meg az őt karbantartó komponenst, és helyette módosítsa a profilt. A generált fájl szerkesztése olyan változás, amelyet az újracsatlakozás töröl.

A privát nevekhez általában a belső feloldó és az üzemeltető által megadott keresési tartományok kellenek. Egy nyilvános feloldóval való helyettesítés éppen azt az erőforrást törheti el, amely miatt a VPN létezik, és a tünet útvonalazási hibának látszik, nem DNS-hibának. Tesztelje külön a nevet és a címet, mert ha az egyik működik és a másik nem, az pontosan megmondja, hova nézzen. Ez az egyetlen összehasonlítás egy óra útvonal-hibakeresést spórol meg.

Egy kezelő kapcsolatonként

A profil formátuma dönti el, melyik program használhatja. Az OpenVPN profilhoz OpenVPN vagy kompatibilis bővítmény kell, a WireGuard konfigurációnak pedig saját formátuma van partnerkulcsokkal és engedélyezett előtagokkal. Az importálási párbeszéd nem fordítja le az egyiket a másikra, bármit is sugall a fájlkiterjesztés.

Válasszon egy kezelőt, és hagyja, hogy az birtokolja a kapcsolatot. Ugyanazt az alagutat két eszközzel felhozni kétértelművé teszi az útvonaltáblát és az újracsatlakozási viselkedést, és általában a másodikként induló nyer olyan módokon, amelyeket nehéz reprodukálni.

Telepítse a disztribúciója által támogatott csomagokat, és szerezze be a profilt az üzemeltetőtől. Kezelje hitelesítő adatként, mert általában tartalmaz privát kulcsot vagy azzal egyenértékű anyagot, és ott tárolja, ahol a többi titka él. A letöltések mappában hagyott profil egy asztalon hagyott kulcs.

Mit ellenőrizzen, ha feljött, de nem működik

Ha az interfész feljött és a kliens sikert jelent, kifelé haladjon: az útvonaltábla az alagutat választja-e a célhoz, a feloldó válaszol-e a privát névre, és van-e a túloldalnak visszaútja. Mindegyiknek külön parancsa és külön gazdája van.

nmcli connection show --active
nmcli device status
wg show

Az nmcli-referencia dokumentálja az állapot- és kapcsolatparancsokat, ha a teljes készletre van szüksége. Itt az a fontos, hogy különbség van az aktív profil és a forgalmat vivő eszköz között, mert a kettő ellentmondhat egymásnak.

Csatlakozzon újra egyszer ugyanazon a kezelőn keresztül, mielőtt késznek nevezné a beállítást, és ellenőrizze, hogy a DNS a leválasztás után is működik-e. Az a konfiguráció, amely csak az első hálózati változásig működik, nem kész, csak éppen most működik.