A partner címe menet közben megváltozott: mit tesz az OpenVPN float

A laptop átvált az irodai Wi-Fi-ről egy telefonos hotspotra, az alagút még néhány másodpercig fennmarad, aztán a forgalom megáll, miközben az interfész továbbra is azt állítja, hogy kapcsolódva van. A szerveren az állapotlista továbbra is a régi nyilvános címet mutatja. Erre a helyzetre való a float, és ez az a helyzet is, amikor az emberek sokkal többet várnak tőle, mint amit tesz. A határ pontos ismerete a zavaró akadást vagy egysoros konfigurációmódosítássá vagy egészen más vizsgálattá alakítja.

Mit lazít a float, és mit soha nem lazít

Általában a munkamenet tovább beszél azzal a külső címmel és porttal, amellyel indult, és a más helyről érkező csomagokat figyelmen kívül hagyja. A float beállítás megszünteti ezt a szigorú kötést, miután a partner már bizonyította magát, így a megváltozott forrásleképezés ugyanazt a munkamenetet folytathatja ahelyett, hogy eldobnák. A titkosítási ellenőrzésekben semmi sem változik: a kulcsok, a tanúsítványok és bármilyen HMAC-védelem pontosan úgy maradnak, ahogy be vannak állítva.

Ez csomagonkénti döntés, nem pedig arról szóló szabály, hogy ki kapcsolódhat. Egy ismeretlen gép, amely új címről küld csomagot, semmit sem bizonyított, és a csomagja ugyanúgy elvész, mint bármely más hitelesítetlen forgalom. Csak az a forgalom mozdíthatja el a rögzített partner-címet, amely átmegy a munkamenet saját hitelesítésén, és ezért biztonságos a floatot bekapcsolva hagyni olyan környezetekben, ahol a kliensek vándorolnak.

A belső alagútról sem mond semmit. Az elmozdított külső cím nem rendel hozzá új alagútcímet, nem változtatja meg a címkészletet, és nem ad a partnernek hozzáférést semmi újhoz. Az alagúton belül ugyanaz az identitás és ugyanazok a továbbított útvonalak érvényesek az elmozdulás előtt és után. A vándorlás az adatcsatornát sem tárgyalja újra, így a kialkudott titkosítás és kulcsok folytatódnak.

A munkamenetet elmozdító csomagnak hitelesítenie kell magát

Indítson munkamenetet a szokásos módon a beállított távoli végpont felé, és a float kezeli, mi történik a leképezés megváltozásakor. A folyamat közben átszámozó mobilszolgáltató, a portleképezését átíró NAT-átjáró vagy az uplinket váltó laptop mind ugyanazt a formát adja: hitelesített csomagok egy új tuple-ből, amelyek egy még a régihez ragaszkodó munkamenethez érkeznek.

Amikor azt kérdezik, működik-e a float, a hasznos bizonyíték egy befejezett kézfogás és az azt követő elfogadott forrásváltozás, nem pedig egy naplósor csupán a címről. Kapcsolja össze a régi és az új külső címet az életben maradt munkamenettel, majd erősítse meg, hogy a forgalom valóban folytatódott az alagúton át.

Ha a munkamenet elmozdulás helyett meghal, az új címről érkező csomag valószínűleg elbukott a hitelesítésen, vagy egyáltalán nem érkezett meg. Mindkét eset ugyanúgy néz ki a kliens felől. A szerveren a nyilvános interfészen készített elfogás megmondja, melyik áll fenn, mielőtt bármilyen konfigurációhoz hozzányúlna.

A felderítés teljesen külön mechanizmus

A float nem old fel neveket időzítő alapján, és nem követ dinamikus DNS-rekordot. Ha a szerver hosztneve elkezd új címre feloldódni, a tétlen kliensnek nincs oka ezt észrevenni, és nincs csomagja az új végponttól, amelyet hitelesíthetne. Ez a probléma az újracsatlakozási logikához, a kliens saját újrapróbálkozási viselkedéséhez és a DNS-hez tartozik, nem a floathoz.

A beállítás még egyszeri hozzáadása nem pótolja az új cím felé vezető útvonal hiányát. Akkor sem segít, ha a partner hallgat, mert a hallgató partner soha nem küldi el azt a hitelesített csomagot, amely bármit elmozdítana.

Az alatta lévő tűzfalnak is van szava. Az a szabály, amely csak a régi külső végpontot engedi, blokkolja a megváltozott címet, mielőtt az OpenVPN egyáltalán látná, és semmilyen kliensoldali konfiguráció nem javítja ezt. Tekintse külön feladatnak az engedélyezett címek életciklusát; a szabály bármely forrásra való kiterjesztése egy kis problémát cserél egy nagyra.

Amikor a NetworkManager birtokolja a profilt

A parancssori profil és az importált kapcsolat külön konfigurációk, és az egyik szerkesztése nem érinti a másikat. Mielőtt feltételezné, hogy a beállítás nem támogatott, állapítsa meg, milyen bővítménytípust használ valójában a mentett profil, és hol élnek az értékei. A profil UUID-je az az azonosító, amely számít, amikor bármit megvizsgál vagy módosít.

A mentett kapcsolatot vizsgálja meg, ne az eredeti importfájlt. Egy sor, amely túlél egy .ovpn fájlban, semmit sem bizonyít, ha az aktív kezelő soha nem alkalmazta, és egy adott beállításhoz jelölőnégyzet nélküli szerkesztő sem bizonyít semmit a protokoll képességeiről.

Ne foltozzon meg egy csomagolt bővítményt a viselkedés hozzáadásához, főleg ne egy független komponens történelmi verziójához írt diffel. Ha a telepített integráció valóban nem tudja kifejezni a beállítást, a helyes lépés egy támogatott profil vagy egy másik kliensútvonal, amelyet az üzembe helyezés tulajdonosa jóváhagy.

Bizonyítsa az átmenetet, ne feltételezze

Futtassa a tesztet úgy, ahogy a hiba bekövetkezik. Kapcsolódjon, ellenőrizze a forgalmat az alagúton, kényszerítse a külső cím megváltozását, majd ellenőrizze három dolgot: a munkamenet még létezik, a rögzített partner-cím elmozdult, és egy valódi kérés még eléri a célját. Mindháromnál kevesebb részleges válasz.

Tartsa elérhetően a helyreállítási hozzáférést tesztelés közben, mert a vándorlási kísérletek hajlamosak ott hagyni a gépet, amelyről dolgozik. Egy soros konzol vagy egy sávon kívüli útvonal ötperces helyreállítássá teszi a sikertelen tesztet a helyszíni látogatás helyett.

Végül csak azt az esetet írja le, amelyet ténylegesen gyakorolt. Egy sikeres címváltozás egy munkamenet alatt nem bizonyítja, hogy a DNS-migrációk, egy másik kliensmegvalósítás vagy egy újraépített profil ugyanígy viselkedik. A link-options dokumentáció pontosan megadja a beállítás hatókörét; a tesztnaplójának meg kell mondania, hogy ennek a hatókörnek melyik részét fedte le valójában.