Een fout, drie geheime: watter VPN-aanmeldbewys het gefaal?
Die kliënt wys een fout vir elke stap. Lees die assosiasie, die gebruikersuitruiling en die metode voordat jy ’n wagwoord herstel wat niemand nagegaan het nie.
“Verifikasie het misluk” kan na ’n bediener-sertifikaat, ’n masjien-voorgedeelde sleutel of ’n gebruikerswagwoord wys. Watter een bedoel word, hang van die protokol af, want elke protokol definieer ’n ander stel geheime. Herstel die verkeerde een en die fout bly onveranderd. Die uitweg is om vas te stel hoeveel bewyse die protokol vereis voordat jy enigiets wysig.
Twee bewyse wat in teenoorgestelde rigtings wys
’n Tonnel moet antwoord of dit die regte poort bereik het, en apart wie die gebruiker is. Die poortbewys is op masjienvlak: ’n bediener-sertifikaat, ’n voorgedeelde sleutel of ’n statiese publieke sleutel. Die gebruikersbewys is op persoonsvlak: ’n wagwoord, ’n token, ’n kliëntsertifikaat of glad niks. Dit is teenoorgestelde rigtings van vertroue en hulle verbruik verskillende materiaal.
IKEv2 doen die poortbewys binne IKE_AUTH en, wanneer EAP gebruik word, voer dit die gebruikersbewys daarna in ’n aparte uitruiling uit. Die IKEv2-spesifikasie hou dit as afsonderlike afdelings, wat ’n sterk wenk is oor waar om te kyk wanneer een boodskap albei rondtes dek.
Lees die stadium, nie die boodskap nie
Die kliënt wys een foutstring, ongeag watter stadium gefaal het, so die string self dra byna geen inligting nie. Wat inligting dra, is die toestand wat jy by elke stadium kan inspekteer: of daar ’n assosiasie bestaan, of ’n gebruikersuitruiling begin het, en of die kliënt die metode aangebied het wat die poort wou hê. Die tabel sorteer die stadiums op daardie manier eerder as volgens protokolnaam.
| Stage that failed | Evidence you can inspect | What a password change cannot fix |
|---|---|---|
| The machine proof | no security association in the state list | a mismatched pre-shared key or an untrusted chain |
| The user proof | an association is up while PPP or EAP reports failure | an expired token, a locked account, a missing client key |
| The client's method support | the client offers no method the gateway accepts | a client without the required EAP or key material |
| The server's policy | the gateway rejects before any user exchange starts | a policy that requires a certificate the profile lacks |
Net die tweede ry gaan oor ’n aanmeldbewys wat ’n gebruiker kan oortik. Die ander drie is konfigurasiefeite, en daardie wanverhouding is waarom so baie van hierdie verslae eindig met ’n wagwoordherstel wat niks verander nie. Lees die ry wat by jou bewyse pas voordat jy aan ’n veld raak.
’n Protokol met twee geheime wys sy hand
L2TP oor IPsec maak die telling sigbaar, want die twee kontroles gebeur in verskillende prosesse. Die IPsec-laag moet eerste opkom met ’n voorgedeelde sleutel of ’n sertifikaat, en eers dan probeer PPP daarbinne ’n gebruiker aanmeld.
Wanneer die masjiengeheim verkeerd is, vorm daar geen assosiasie nie en word die gebruikersaanmelding nooit probeer nie. Wanneer die masjiengeheim reg is en die gebruikergeheim verkeerd is, bestaan die assosiasie en verwerp PPP die aanmelding nadat die tonnel al op is. Albei lewer dieselfde boodskap op die skerm uit twee verskillende gebeurtenisse.
sudo swanctl --list-sas
sudo ip xfrm state list
sudo journalctl -u xl2tpd -n 50 --no-pager’n Leë assosiasielys skakel die gebruikerslaag dadelik uit, so kyk daarna voor die wagwoord. ’n Bestaande assosiasie met herhaalde PPP-foute wys die ander kant toe, na die gebruikerslaag of na die verifikasieprotokol daarbinne. Nie een van die twee gevolgtrekkings is uit die kliënt se foutteks beskikbaar nie.
Waarvan slegs-wagwoord eintlik afhang
Slegs-wagwoord-toegang is gewoon vir L2TP, PPTP, SSTP en IKEv2 met EAP. WireGuard het glad nie so ’n opsie nie, want sy eweknieë is sleutels eerder as gebruikers. Vir OpenVPN kom die antwoord van die bediener se kliëntsertifikaat-vereiste: ’n poort wat beide sertifikaat en wagwoord eis, sal ’n slegs-wagwoord-kliënt bly verwerp, wat ook al in die veld getik word.
Watter komponent jy nodig het, volg uit dieselfde antwoord. ’n Wagwoordaanmelding onder IKEv2 vereis ’n kliënt wat EAP praat, terwyl ’n sertifikaataanmelding die kliënt se private sleutel en die bediener se ketting nodig het. Installeer die verkeerde een en die mislukking lees soos ’n aanmeldbewysfout, selfs al is dit die verifikasiemetode self wat ontbreek.
Verander een ding, en toets weer
Stel eers drie feite vas: watter protokol loop, hoeveel geheime dit definieer, en watter van hulle aan die masjien eerder as die gebruiker behoort. Masjiene faal by die eerste stadium en mense faal by die tweede, en om die twee te verwar is die hele probleem.
Verander dan presies een ding en toets weer vanaf dieselfde kliënt. Daardie dissipline maak ’n verwarrende mislukking ’n regstelling wat jy aan die volgende persoon kan verduidelik, wat nuttiger is as ’n werkende verbinding wat niemand kan verduidelik nie.