A teljes alagút megölte az SSH-munkamenetedet: rögzítsd a visszaútvonalat

Indíts egy OpenVPN klienst azon a gépen, amelyen SSH-n keresztül dolgozol, és a parancs közepén a munkamenet lefagy. Az alagút azt jelenti, hogy csatlakozott, a hoszt eléri rajta keresztül az internetet, és a billentyűleütéseid továbbra is megérkeznek, miközben semmi nem jön vissza. Ami megváltozott, nem az alagút: a hozzád címzett csomagok visszaútja az, amely most megfelel az új alapértelmezett útvonalnak, és olyan alagútba lép, amelyet a távoli átjáró nem fog használni az asztalod eléréséhez.

Mit telepít valójában a redirect-gateway

A(z) def1 formájában redirect-gateway hozzáadja a(z) 0.0.0.0/1 és a(z) 128.0.0.0/1 címet az alapértelmezett útvonal felülírása helyett. Ez a két fél lefedi a teljes címteret, miközben mindkettő hosszabb előtag marad, mint a(z) 0.0.0.0/0, így minden olyan cél, amelyhez nincs pontosabb egyezés, most az alagútba kerül. Ezt a mechanizmust érdemes megjegyezni, mert az alábbi javítások mindegyike pontosabb egyezés telepítésével működik.

Az adminisztrációs címed egyike ezeknek a céloknak.

A VPN-kiszolgáló továbbítja az ügyfelei forgalmát az internet felé. Nincs útvonala ahhoz a nyilvános címhez, ahonnan csatlakozol, és nincs oka arra, hogy ezeket a csomagokat másként kezelje, mint az ügyféltől érkező forgalmat, ezért eldobja őket. Közben az általad küldött kérés mégis elérte a hosztot, és ezért tűnik a munkamenet csak az egyik oldalon élőnek.

ip route show table main | head -n 20
ip route get 198.51.100.23

Keresd meg a forráscímedet és az alagút előtti útvonalat

A kiszolgálón listázd a létrejött SSH-kapcsolatot, és jegyezd fel a peer-címet, ahonnan jött. Ezt a címet kell a visszaútvonaladnak lefednie, és ez nem mindig az, amire gondolsz: egy ugróhoszt, egy NAT-átjáró vagy egy szolgáltatói fordító más forrást tehet be.

Ezután keresd meg a fizikai átjárót és az interfészt, amelyek az alagút indulása előtt a forgalmat vitték. A(z) def1 elrendezésben az alapértelmezett útvonal továbbra is ott van a fél-alapértelmezettek alatt, tehát az információ elérhető, bár egy hosszú útvonaltábla szemmel olvasása hibákra csábít.

Jegyezd fel a két értéket és az interfész nevét együtt, mert a hozzáadni kívánt útvonalnak mindháromra szüksége van. Ha a hoszt házirend-alapú útválasztási szabályt használt a felső kapcsolata kiválasztásához, előfordulhat, hogy egy egyszerű útvonalat egyáltalán nem vesznek figyelembe, és ez a lehetőség megváltoztatja a javítást.

Rögzíts egy hoszt-útvonalat, amely felülmúlja a fél-alapértelmezetteket

Egy /32 útvonal hosszabb mindkét fél-alapértelmezettnél, így a címedre érkező válaszok azt választják az alagút helyett. A következő ugrás az alagút előtti átjáró, az eszköz pedig a fizikai interfész, ami a csomagot azon az úton tartja, amelyet az alagút létezése előtt használt.

ip route add 198.51.100.23/32 via 203.0.113.1 dev eth0

Ellenőrizd egy lekérdezéssel, ne a tábla vizsgálatával: a válasznak a(z) eth0 és az átjáró nevét kell tartalmaznia, soha nem a(z) tun0.

Az OpenVPN már hozzáad egy hoszt-útvonalat magának a VPN-kiszolgálónak a címéhez ugyanezen okból, tehát a minta ismerős, és az adminisztrációs cím egyszerűen csak egy újabb kivétel. Ne nyúlj a(z) route-nopull eszközhöz ennek javításához, mert eldobja az alagútnak szükséges továbbított útvonalakat, beleértve a távoli hálózatot és a DNS-beállításokat.

Tedd túlélőképessé egy újracsatlakozásra

A kézzel hozzáadott útvonal eltűnik, amikor az ügyfél újracsatlakozik és telepíti a sajátját, ami a javítást visszatérő kieséssé teszi. Kapcsold a parancsot valamihez, ami az útvonalak telepítése után fut.

Mind a(z) route-up szkript, mind a hálózatkezelő pre-up kampója működik, és a megbízható ellenőrzés egy újracsatlakozás, amelyet ugyanaz a lekérdezés követ.

Windows alatt a megfelelő egy állandó útvonal, amelyet a(z) -p kapcsolóval adnak hozzá, amely túléli az újraindításokat, de hálózati változás után még mindig a helyes átjáróra kell mutatnia. Bármilyen platform is legyen, írd oda az okot az útvonal mellé: a következő adminisztrátornak tudnia kell, hogy azért létezik, hogy egy kezelési munkamenetet védjen, nem azért, mert a hálózati tervezés megkövetelte.

Amikor egy rögzített útvonal még mindig nem elég

A fordított útvonal szűrése eldobhat egy csomagot, amely az egyik interfészen érkezik és a másikon távozik, és pontosan ezt hozza létre egy rögzített útvonal. Ellenőrizd a(z) rp_filter effektív értékét, mielőtt bármit globálisan letiltanál, és inkább az aszimmetriát javítsd, mint hogy kikapcsold az ellenőrzést. Az interfészenkénti beállítás az, amely érvényes, és a loose mód gyakran csak naplózza az aszimmetriát ahelyett, hogy eldobná a csomagot. Olvasd el mindkettőt, mielőtt arra jutnál, hogy a szűrő a te hibád.

A házirend-alapú útválasztást használó hosztoknak szabályra is szükségük van az útvonal mellett, mert a szabálybázis kiválasztja a táblát, mielőtt a benne lévő útvonalat megvizsgálnák. A main táblában lévő útvonal láthatatlan egy olyan folyamat számára, amely egy másik táblára mutató szabálynak felel meg. Olvasd el a szabályokat, mielőtt bármit hozzáadnál a main-höz. Ha egy szabály már lefedi a kezelési forgalmat, a kivétel inkább annak a szabálynak a táblájába tartozik.

Tarts nyitva egy sávon kívüli konzolt a tesztelés alatt, és ellenőrizd újra egy második bejelentkezésből, mielőtt bontanád azt, amelyiket használod. Az az útvonal, amely a saját kezelési forgalmadat az alagútba küldi, elvágja azt a kapcsolatot, amelyen keresztül javítod. Akkor a visszajutás soros konzolt vagy mentőbetöltést jelent, ami rossz üzlet egyetlen ellenőrzési lépés kihagyásáért.