Az ifconfig-noexec nem menti meg az SSH-munkamenetet: mit tesz valójában

Egy fórumtémában ifconfig-noexec-et kínálják megoldásként arra, hogy egy SSH-munkamenet életben maradjon, amikor feljön egy alagút. Az indoklás hihetőnek hangzik, amíg meg nem nézed, mihez nyúl valójában a kapcsoló. Megakadályozza, hogy OpenVPN beállítsa az alagút interfészének címét, és ezeket az értékeket inkább szkripteknek adja át; arról viszont semmit sem mond, hogy a kezelési kapcsolatodra érkező válaszok hová mennek. Ha az ellenkezőjét hiszed, olyan alagutat kapsz, amelynek nincs használható címe, és egy SSH-munkamenetet, amely továbbra is meghal.

Mit delegál valójában a kapcsoló

Alapértelmezés szerint az ügyfél felhozza az alagút eszközét, és beállítja a helyi és távoli címeket, amelyeket a szerver adott neki. Ha a ifconfig-noexec be van állítva, ez a lépés kimarad, és az egyeztetett értékek a szkript környezetébe exportálódnak, hogy valami más alkalmazhassa őket.

A tulajdonjog átkerül. A helyére semmi sem kerül kitalálásra.

Tehát a kérdés, amelyre a kapcsoló válaszol, az, hogy ki állítja be az interfészt, és a kérdés, amelyre nem válaszol, az, hogy a csomagok hogyan találnak vissza hozzád. Tartsd külön a kettőt, különben egy egész estét útvonalak szerkesztésével töltesz, hogy kompenzálj egy cím nélküli interfészt.

Három hasonló kapcsoló, különböző feladatokkal

A családot könnyű összetéveszteni, mert a nevek egyetlen szóban térnek el, a tünetek pedig átfednek. Olvasd el, mit nyom el mindegyik, mielőtt bármelyiket kiválasztod.

Ezek egyenként értelmezendő alternatívák, nem együtt beillesztendő készlet. A címbeállítás elnyomása nem nyomja el az útvonalváltozásokat, a tűzfal-szabályokat vagy a DNS-t szállító tolt beállításokat. Egy delegált szkript szabadon módosíthat útvonalakat is, ami olyan döntés, amelyet átadsz ahelyett, hogy elkerülnél.

Ha egy szállítói ügyfél becsomagolja a motort, használd a támogatott integrációját ahelyett, hogy egy alacsony szintű direktívát dobva a profilba abban bízol, hogy a burkoló tiszteletben tartja. A burkolók gyakran újragenerálják a profilt csatlakozáskor, így a kézi szerkesztés hibaüzenet nélkül eltűnik. Nézd meg, hol tartja a beállításait az ügyfél, mielőtt egy egész estét a fájlra szánsz. Ez a táblázat minden sorára vonatkozik, nem csak arra, amelyikért jöttél.

Az SSH-munkamenet, amelyet meg akartál védeni

Egy SSH-kapcsolatnak van forráscíme, célcíme és válaszútvonala. Egy olyan szerveren, amely épp most telepített teljes alagútú alapértelmezést, a nyilvános címedre érkező válasz az alagúthoz illeszkedik, és a VPN-átjáró eldobja.

Az alagút interfészének címbeállításában semmi sem változtat ezen.

Amit megold, az egy konkrétabb útvonal a kezelési címedhez az alagút előtti átjárón keresztül, vagy egy házirend-szabály, amely eltereli azt a forgalmat, plusz azok a szűrőbeállítások, amelyeket a gazdagéped alkalmaz. A két probléma néha együtt jelenik meg, és így lesz az egyik a másik gyógymódjának tartva. Külön teszteld őket: hozd fel az alagutat a kapcsoló nélkül, nézd meg az interfész címét és a válaszútvonalat, majd döntsd el, melyik kettő valóban hibás.

Mit kell egy delegált szkriptnek átvennie

Ha tényleg azt akarod, hogy egy másik tulajdonos állítsa be az interfészt, sorold fel a munkát: alkalmazd a helyi és távoli címet, hozd fel az eszközt, állítsd vissza vagy távolítsd el a címzést leállításkor, és tedd ugyanezt újra egy újracsatlakozás után. Egy sikeres munkamenet értékeit nem szabad beégetni, mert a szerver legközelebb másik párt adhat.

Az ügyfél által exportált környezeti változók az egyetlen támogatott bemenet ehhez a munkához.

env | grep -E '^ifconfig_|^route_'

Egy route-up szkripten belül ezek a változók elérhetők; egy cron-feladatból vagy kézi héjból nem. Erősítsd meg, melyik életciklus-horgot használja a verziód, és azt is, hogy a horog elegendő jogosultsággal fut az interfész módosításához, mert az ügyfél már leléphetett egy jogosulatlan felhasználóra.

Az egész életciklust teszteld, ne egyetlen munkamenetet

Hozd fel az alagutat, ellenőrizd a címet az eszközön, majd csatlakozz újra, és ellenőrizd megint. Egy konfiguráció, amely egyszer működik és a második próbálkozásnál elbukik, általában azt jelenti, hogy a delegált lépés csak az első csatlakozáskor fut le.

Aztán teszteld együtt a két elfogadási feltételt: egy friss SSH-kapcsolat a szándékolt kezelési útvonalon keresztül működik, és egy engedélyezett alkalmazás helyesen használja az alagutat.

Egy régi SSH-munkamenet, amely véletlenül életben marad, miközben az alagútnak nincs címe, nem siker, és pontosan ezt az állapotot állítja elő ez a kapcsoló, amikor senki sem veszi át a munkát. Először az interfész címét ellenőrizd, aztán a kezelési válaszútvonalat, aztán az alkalmazást. Ha a háromból kettő rossz, a kapcsoló áthelyezte a munkát, de nem adott neki tulajdonost.