VPN-klienst indítasz SSH-n keresztül? Előbb rögzítsd a saját útvonaladat

SSH-val belépsz egy build-gazdára, elindítod rajta a VPN-klienst, és a munkamenet abbahagyja a válaszadást. Semmi nem omlott össze, és semmi nem tűnik hibásan beállítottnak a nyilvánvaló értelemben. A kliens telepített egy alapértelmezett útvonalat, így a munkaállomásod felé menő válaszok most az alagúton keresztül távoznak, ahol a munkaállomásod címe nem irányítható. Az érdekes rész az, hogy ez az eredmény előre látható volt, és a javítás egyetlen útvonal, amelyet a kliens indulása előtt írnak. Tegyük fel, hogy van egy szerver egyetlen hálókártyával, 192.0.2.254 átjáróval és egy rendszergazda, aki 203.0.113.9 címről kapcsolódik.

Jegyezd fel az útvonalat, mielőtt elkezded

ip route show default megnevezi az aktuális átjárót és interfészt, míg ip route get 203.0.113.9 megmutatja, melyik interfészt és forrás-címet használná a kernel a munkamenetedhez. Őrizd meg mindkét kimenetet. Miután az alagút feljön, ennek a két parancsnak továbbra is a fizikai útvonalat kell leírnia, és ha helyette az alagutat írják le, a munkamenet már kölcsönvett időn él.

A már létrejött kapcsolat számít, ezért ne csak egy új bejelentkezéssel ellenőrizz. Egy új munkamenet rövid ideig sikerülhet olyan állapot révén, amellyel a régi már nem rendelkezik.

Rögzítsd a címet magának a kliensnek a konfigurációjában

A kézzel hozzáadott útvonal újraindításkor eltűnik és versenyzik a kliens saját táblafrissítéseivel, ezért tedd a kivételt oda, ahol a táblázatot kezelik. OpenVPN alatt a net_gateway kulcsszó arra az átjáróra oldódik fel, amely az alagút előtt létezett, így a route 203.0.113.9 255.255.255.255 net_gateway pontosan egy címet tart azon kívül. A WireGuard más megközelítést igényel, mert a wg-quick maga kezeli az útvonalakat: állítsd be a Table = off értéket, és add hozzá a kivételt a PostUp szakaszban, a hozzá tartozó PostDown kóddal, amely eltávolítja. Mindkét forma ugyanazt a szándékot fejezi ki, és mindkettő egyetlen címre korlátozza a kivételt ahelyett, hogy mindenre gyengítené az alagutat.

IPv6 esetén ugyanez az ötlet egyetlen gazda előtagot vesz, és érdemes megjegyezni a beágyazott szállítás esetét: ha magának az alagútnak a külső kapcsolata fix címen él, annak a címnek az általa szállított alagúton kívül kell maradnia, különben a kliens a saját szállítását önmagába irányítja.

Vagy vedd ki a fő táblázatot az egyenletből

Amikor a gazdán több szolgáltatásnak meg kell tartania a normál útvonalát, hagyd abba a fő táblázat szerkesztését, és adj a kliensnek sajátot. Egy veth-párral rendelkező hálózati névtér ezt tisztán teszi: a kliens alapértelmezett útvonala másik veremben él, és csak a benne indított folyamatok használják az alagutat. A szabályalapú irányítás egy célra hasonló helyre jut, az egyező forgalmat egy dedikált táblázatba küldve, amelynek alapértelmezése még mindig a fizikai átjáróra mutat. Mindkét megközelítés új alapértelmezett útvonal nélkül hagyja a gazda fő táblázatát, és ez az a tulajdonság, amely válaszadásban tartja az SSH-t.

Mindkettő több gépezet egyetlen gazdaútvonalnál, és mindkettő megéri, amikor egynél több dolognak kell túlélnie az alagutat a gépen.

Feltételezd, hogy a rögzítés meghiúsulhat

A jelenlegi nyilvános címedhez kötött útvonal abban a pillanatban eltörik, amikor a szolgáltatód újra kiosztja. Egy távoli szervernek akkor olyan útvonalra van szüksége, amely nem függ ettől a címtől: konzolra, egy második felügyeleti interfészre vagy egy ugró gazdára, amely az alagúton kívül marad.

Két védintézkedés tíz percbe kerül. Egy őrkutya, amely leállítja a klienst, ha néhány percen belül nem jelenik meg egy megerősítő bejelentkezés, a kizárást késleltetéssé alakítja, és a változtatás alatt nyitva tartott második SSH-munkamenet bizonyítja, hogy a kivétel működik, amíg az alagút áll. A keepalive-ok önmagukban itt nem segítenek, mert az útvonal eltűnt, nem tétlen; csak könnyebbé teszik a halál észrevételét.

A számító sorrendben ellenőrizd

Csatlakoztasd az alagutat, erősítsd meg, hogy a címedhez vezető útvonal továbbra is a fizikai átjárón keresztül távozik, majd nyiss új munkamenetet. Ha az új munkamenet működik és a régi mégis meghal, az ok a kapcsolatkövetés vagy egy állapotfüggő tűzfal, nem az irányítás, ami más javítás.

Írd be a rögzített címet és azt a parancsot, amely bizonyította, a változásnaplóba. A következő embernek, aki klienst indít azon a gazdán, mindkettőre szüksége lesz, és a cím addigra megváltozhatott.