IKEv1 z XAuth in OTP: kaj zahteva vsak poziv
PSK skupine, uporabniška izmenjava XAuth in izziv OTP so trije različni vhodi. Vsak poziv povežite z njegovim lastnikom, preden namestite še enega odjemalca.
IKEv1 s PSK, XAuth in OTP ne zahteva enega zapletenega gesla. Sloji deljeni ključ med peerji, uporabniško izmenjavo in drugi dejavnik, katerega način zahteve določi backend. Vsak sloj ima svojega lastnika in svoje sporočilo o napaki. Če jih zamenjate, ljudje znova vtipkajo enkratno kodo v polje, ki shranjuje skupinsko skrivnost.
Vsak poziv povežite s slojem, ki ga zahteva, preden namestite drugega odjemalca ali ponastavite poverilnico.
Tri skrivnosti, trije lastniki
Deljeni ključ pripada odnosu med peerji in ga enkrat nastavi tisti, ki upravlja oba konca. Uporabniška poverilnica pripada avtentikacijskemu backendu in se preveri ob vsaki prijavi. Drugi dejavnik pripada sistemu žetonov, katerega odgovor se spremeni ob vsakem poskusu. Noben ne nadomesti drugega, in postavitev, ki jih obravnava kot eno geslo, odpove na sloju, ki ga nihče ni dokumentiral.
Zapišite tri stolpce: lastnik, življenjska doba in sporočilo o napaki, ki ga vsak ustvari. Diagnostično orodje je ta tabela, ne imena polj v odjemalcu.
| Layer | Owner | Lifetime |
|---|---|---|
| Pre-shared key | Peer configuration | Until operators change it |
| XAuth credential | Authentication backend | Per session, per policy |
| One-time code | Token system | Single use |
PSK: peerja, ne osebe
V tej stari ureditvi deljeni ključ avtentificira par prehodov, zato ga prijava uporabnika nikoli ne nadomesti. Je tudi vrednost, ki se najpogosteje zmoti tako, da nastane splošna napaka pogajanja namesto poziva. Ko tunel odpove, preden se pojavi kateri koli uporabniški poziv, sta sumljiva ključ ali predlogi.
Uporabniška poverilnica ne more popraviti napake prve faze. Njena rotacija zapravi edino poverilnico, ki jo lahko varno rotirate, in utrdi napačno teorijo.
XAuth: stara uporabniška izmenjava
XAuth doda izmenjavo avtentikacije uporabnika na vrh avtentikacije peerja v IKEv1, in prehod odloči, kateri backend jo preveri. Glede na ta backend lahko izmenjava sprejme geslo imenika, poverilnico RADIUS ali odgovor žetona. Beseda XAuth poimenuje prenos izmenjave, ne vrste poverilnice.
Preverite, na kateri backend kaže profil prehoda. To pove, kaj bo uporabnik vprašan in kaj ponastavitev gesla dejansko spremeni, in nobeno od tega ni vidno v profilu odjemalca.
OTP: karkoli zahteva backend
Nekatere postavitve po geslu zahtevajo ločeno enkratno kodo, druge določijo združeno vhodno obliko z dokumentiranim ločilom. Obe obstajata, in profil pred vami odloči, katera. Izmišljanje združevanja, ker je delovalo drugje, je najpogostejši način, da zapravite registracijski žeton. O tem odloča samo dokumentacija prehoda.
Uporabite dokumentirano obliko z odjemalcem, ki lahko dokonča izmenjavo, ki jo ponuja prehod.
Kje ugrizne meja odjemalca
Fortinet navaja, da FortiClient 7.4.4 in novejši ne podpirajo več IKEv1 za VPN IPsec, kar je meja izdelka in različice, ne splošna odstranitev, kot beleži opomba o združljivosti FortiClient. Tudi drugi odjemalci niso zamenljivi: OpenConnect in openfortivpn govorita določene protokole prehoda, ne poljubnih profilov IKEv1. Posamezno preverite različico IKE, način PSK, podporo XAuth in model interakcije nameščenega odjemalca. Odjemalec, ki se poveže z drugo metodo, ni dokazal prvotne zahteve.
IKEv1 je opuščen, zato je nova uvedba na nepodprtem starem odjemalcu kratkotrajna rešitev. Lastnika prehoda prosite za podprto pot selitve, vključno s tem, kako bo tam obravnavan drugi dejavnik.
Diagnosticiranje brez izklopa dejavnika
V dnevniku ločite stopnje: pogajanje peerjev, uporabniška izmenjava, izid drugega dejavnika, nato dodelitev naslova in poti. Zapišite komponento in stopnjo, namesto da preizkušate kodo v vsakem polju. Izklop dejavnika, da test uspe, ustvari tunel, ki o postavitvi ničesar ne dokaže.
Registracijske skrivnosti in deljeni ključ hranite v zaščiteni shrambi po procesu organizacije. Enkratna koda v trajni datoteki je dejavnik, ki je prenehal biti dejavnik.