Zakaj ponovna povezava VPN znova zahteva poverilnice
Shranjeno geslo in znova uporabljiv žeton potečeta po različnih urnikih. Preden karkoli spremenite na odjemalcu, preberite, kateri material je zahtevala ponovna povezava.
Predor, ki je deloval ure in ure, zahteva geslo v trenutku, ko se prenosnik prebudi, in v konfiguraciji se ni nič spremenilo. Spremenilo se je stanje poverilnice, ki jo je ponovna povezava poskusila znova uporabiti. To urejajo tri vrste materiala in le ena od njih preživi poljubno vrzel.
Preberite, katero je zahteval odjemalec, ker vse tri potečejo po različnih urah in odpovejo z različnimi sporočili.
Tri vrste znova uporabljivega materiala
Geslo v predpomnilniku je skrivnost, ki jo hrani odjemalec, in velja, dokler ga račun ne spremeni. Žeton seje izda strežnik po uspešni prijavi, nosi lastno življenjsko dobo in ga je mogoče kadar koli preklicati. Vstopnica seje TLS ali varnostna povezava IKE je protokolno stanje, poceni za nadaljevanje in popolnoma neodvisno od vašega gesla. Vsako izda druga komponenta in vsaka poteče pod svojimi pogoji.
Prva preživi ponovni zagon, druga običajno preživi mirovanje, tretja pa morda sploh ne preživi spremembe omrežja. Njihovo mešanje da napačno rešitev, na primer ponastavitev gesla, ki ni bilo nikoli zavrnjeno.
Sama zahteva je diagnoza. Okno brskalnika ali koda drugega dejavnika pomeni, da je strežnik zahteval interaktivno preverjanje, medtem ko tiha napaka brez zahteve pomeni, da odjemalec ni prišel dovolj daleč, da bi ga vprašali.
| Material | Typical lifetime | What invalidates it |
|---|---|---|
| Cached password | Until changed | Account or password policy change |
| Session token | Minutes to hours | Expiry, revocation, reauthentication policy |
| Tunnel SA or TLS ticket | Configured rekey interval | Rekey, network change, peer restart |
Obnavljanje ključev ni ponovno preverjanje
Obnavljanje ključev zamenja ključe, pri čemer ohrani preverjeno identiteto, zato se na zdravem predoru občasno zgodi tiho. Ponovno preverjanje ponovi samo preverjanje identitete in to je dogodek, ki potrebuje vas. IKEv2 oba izrecno ločuje, enakovredni partner pa lahko v nastavljenem intervalu zahteva popolno ponovno preverjanje ne glede na to, koliko obnovitev ključev je bilo vmes. Oba dogodka sta od zunaj videti enaka, dokler ne preberete, katerega imenuje dnevnik.
OpenVPN se obnaša enako v svojem besedišču: interval ponovnega pogajanja osveži podatkovni kanal, žeton za preverjanje pa je mogoče vrniti odjemalcu, da se izogne popolni prijavi ob naslednji povezavi. Ta žeton ima življenjsko dobo in strežnik odloči, ali ga bo znova sprejel.
Tako lahko ponovna povezava po osmih urah spodleti tam, kjer je ponovna povezava po osmih minutah uspela, brez kakršne koli spremembe konfiguracije na obeh straneh. To je celotna razlaga za zahtevo, ki se pojavi šele po kosilu.
Ko odjemalec ne more dokončati novega izziva
Pravilo, ki zahteva korak v brskalniku, bo spodletelo na odjemalcu, ki ga nima kako prikazati. Strežniki brez vmesnika, zagonske skripte in stari profili, zgrajeni za preverjanje samo z geslom, vsi udarijo v to steno, in napaka se pogosto pokaže kot splošen časovni limit, ne kot napaka preverjanja.
Prehodi naprave in omrežja lahko tudi padejo v okno ocenjevanja pravila, zato prehod z Wi-Fi na dostopno točko sovpada s preverjanjem, ki bi se zgodilo tako ali tako. To naključje naredi omrežje krivo, ko je vzrok časovnik.
openvpn --config client.ovpn --verb 3 2>&1 | grep -i -E "reneg|auth" ipsec statusall | grep -i -E "rekey|reauth"
Prva vrstica prikazuje dogodke ponovnega pogajanja in preverjanja v odjemalčevem lastnem dnevniku, druga pa varnostne povezave, ki jih partner strongSwan trenutno drži. Primerjajte časovne žige s trenutkom, ko se je zahteva pojavila; ujemanje potrdi časovnik in ne omrežje.
Kaj poročati in česa ne izklopiti
Če ročna prijava uspe, samodejna ponovna uporaba pa dosledno spodleti, to natančno povejte upravljavcu. To imenuje komponento: pot ponovne uporabe, ne poverilnice. Navedite čas napake, uporabljeni račun in vrsto zahteve, ki ste jo videli.
Ne izklopite drugega dejavnika, ne preskočite preverjanja potrdila in ne lepite poverilnic v skript, da bi bila povezava tiha. Vsako od tega odstrani preverjanje, zaradi katerega pravilo obstaja, in vsako spremeni zahtevo za prijavo v incident.
Namesto tega zaprosite za podprt potek: odjemalca, ki lahko dokonča izziv, življenjsko dobo žetona, ki ustreza delovnemu dnevu, ali odobren neinteraktivni profil za stroj, ki ne more vprašati. Vse to so konfiguracijske odločitve, ki jih lahko nekdo odobri, kar obhod ni.