Egy órákig működő alagút abban a pillanatban kér jelszót, amikor a laptop felébred, és a konfigurációban semmi sem változott. Ami változott, az annak a hitelesítő adatnak az állapota, amelyet az újracsatlakozás újra fel akart használni. Háromféle anyag szabályozza ezt, és közülük csak egy él túl egy tetszőleges szünetet.

Olvassa el, melyiket kérte az ügyfél, mert mindhárom más óra szerint jár le, és más üzenetekkel hibázik.

Háromféle újrafelhasználható anyag

A gyorsítótárazott jelszó az ügyfélnél lévő titok, és addig érvényes, amíg a fiók meg nem változtatja. A munkamenet-tokent a szerver állítja ki sikeres bejelentkezés után, saját élettartama van, és bármikor visszavonható. A TLS munkamenet-jegy vagy az IKE biztonsági társítás protokollállapot, olcsón folytatható, és teljesen független a jelszavától. Mindegyiket más komponens állítja ki, és mindegyik a saját feltételei szerint jár le.

Az első túléli az újraindítást, a második általában túléli az alvást, a harmadik pedig lehet, hogy egyáltalán nem éli túl a hálózatváltást. Összekeverésük rossz javítást eredményez, például olyan jelszó visszaállítását, amelyet soha nem utasítottak el.

Maga a felszólítás a diagnózis. A böngészőablak vagy a második faktor kódja azt jelenti, hogy a szerver interaktív hitelesítést követelt, míg a felszólítás nélküli csendes hiba azt, hogy az ügyfél soha nem jutott el odáig, hogy kérdezzék.

MaterialTypical lifetimeWhat invalidates it
Cached passwordUntil changedAccount or password policy change
Session tokenMinutes to hoursExpiry, revocation, reauthentication policy
Tunnel SA or TLS ticketConfigured rekey intervalRekey, network change, peer restart

A kulcsfrissítés nem újrahitelesítés

A kulcsfrissítés lecseréli a kulcsokat, miközben megtartja a hitelesített identitást, ezért történik csendesen időnként egy egészséges alagúton. Az újrahitelesítés magát az identitásellenőrzést ismétli meg, és ez az az esemény, amelynek szüksége van önre. Az IKEv2 egyértelműen elválasztja a kettőt, és a partner beállított időközönként teljes újrahitelesítést követelhet, függetlenül attól, hány kulcsfrissítés történt közben. Kívülről a két esemény azonosnak látszik, amíg el nem olvassa, melyiket nevezi meg a napló.

OpenVPN ugyanígy viselkedik a saját szókincsében: az újratárgyalási időköz frissíti az adatcsatornát, és a hitelesítési token visszaadható az ügyfélnek, hogy a következő kapcsolatnál elkerülje a teljes bejelentkezést. Annak a tokennek élettartama van, és a szerver dönti el, hogy újra elfogadja-e.

Így egy nyolc óra utáni újracsatlakozás ott is meghiúsulhat, ahol egy nyolc perc utáni sikerült, anélkül hogy bármelyik oldalon konfiguráció változna. Ez a teljes magyarázata egy olyan felszólításnak, amely csak ebéd után jelenik meg.

Amikor az ügyfél nem tudja teljesíteni az új kihívást

A böngészőlépést előíró szabályzat meghiúsul egy olyan ügyfélen, amelynek nincs módja megjeleníteni ilyet. A fej nélküli szerverek, az indítószkriptek és a csak jelszavas hitelesítésre épített régi profilok mind ebbe a falba ütköznek, és a hiba gyakran általános időtúllépésként jelenik meg, nem hitelesítési hibaként.

Az eszköz- és hálózatváltások is a szabályzat értékelési ablakába eshetnek, így a Wi-Fi-ről hotspotra való átállás egybeesik egy olyan ellenőrzéssel, amely amúgy is megtörtént volna. Az egybeesés miatt a hálózat tűnik bűnösnek, amikor az ok az időzítő.

openvpn --config client.ovpn --verb 3 2>&1 | grep -i -E "reneg|auth"
ipsec statusall | grep -i -E "rekey|reauth"

Az első sor az újratárgyalási és hitelesítési eseményeket mutatja az ügyfél saját naplójában, a második pedig azokat a biztonsági társításokat, amelyeket egy strongSwan partner jelenleg tart. Hasonlítsa össze az időbélyegeket azzal a pillanattal, amikor a felszólítás megjelent; az egyezés az időzítőt igazolja, nem a hálózatot.

Mit kell jelenteni, és mit nem kell kikapcsolni

Ha a kézi bejelentkezés sikerül, az automatikus újrafelhasználás pedig következetesen meghiúsul, mondja ezt pontosan az üzemeltetőnek. Ez megnevezi a komponenst: az újrafelhasználási utat, nem a hitelesítő adatot. Adja meg a hiba idejét, a használt fiókot és a látott felszólítás típusát.

Ne kapcsolja ki a második faktort, ne hagyja ki a tanúsítvány-ellenőrzést, és ne illesszen hitelesítő adatokat szkriptbe, hogy csendes legyen az újracsatlakozás. Mindegyik eltávolítja azt az ellenőrzést, amelynek kikényszerítésére a szabályzat létezik, és mindegyik bejelentkezési felszólítást tesz incidenssé.

Kérje helyette a támogatott folyamatot: olyan ügyfelet, amely végre tudja hajtani a kihívást, a munkanaphoz illő token-élettartamot, vagy jóváhagyott, nem interaktív profilt annak a gépnek, amely nem tud kérdezni. Ezek mind olyan konfigurációs döntések, amelyeket valaki jóváhagyhat, amit egy kerülő megoldás nem.

Kapcsolódó cikkek