Lipești adresa din e-mailul de introducere, clientul ajunge la gateway, iar formularul de autentificare care apare este portalul general, nu cel al partenerului descris de operator. Nimic nu semnalează o eroare, și exact asta încurcă: tunelul poate chiar să urce, doar în spatele unui punct de intrare greșit. Calea din acel URL făcea treabă, iar orice a înlocuit-o a pierdut acea treabă.

Separă două lucruri care ajung ca un singur șir într-un tichet: adresa care ajunge la serviciu și intrarea care decide unde începe autentificarea. Repararea primeia ignorând a doua este modul în care un nume de gazdă corect produce totuși o autentificare greșită.

Ce trimite clientul înainte să vezi un formular

Cu o adresă precum https://vpn.example.net/partners, primul act al clientului este o cerere HTTPS către acea cale, nu către gazda goală. Ce se întoarce este de obicei o redirecționare către punctul de autentificare sau formularul însuși. Un client care primește doar vpn.example.net pornește de la pagina de destinație implicită care există, iar aceasta poate fi alt portal, altă listă de grupuri sau o pagină care așteaptă un protocol complet diferit. Diferența se vede în anteturile răspunsului cu mult înainte de a fi tastată vreo acreditare.

De aceea un tab de browser care funcționează și un profil de client care eșuează pot numi același gateway și totuși să nu fie de acord. Browserul a urmat calea; profilul nu a avut-o niciodată.

Două intrări care par interschimbabile și nu sunt

OpenConnect expune calea HTTPS inițială ca --usergroup, iar pagina manualului tratează un URL complet care poartă acea cale ca aceeași cerere scrisă altfel. --authgroup este o opțiune separată: alege o intrare din lista pe care gateway-ul o prezintă în interiorul formularului de autentificare. Unele protocoale numesc acea intrare grup, altele domeniu sau gateway, și exact acolo se confundă cele două comutatoare.

Un serviciu poate avea în mod legitim nevoie de ambele. Calea te poate duce la portalul corect în timp ce formularul îți cere în continuare să alegi între grupuri din interiorul lui. Dacă dai numele portalului drept nume de grup, sau invers, obții o autentificare care pare acceptată și apoi nu autorizează, pentru că valoarea era sintactic validă și semantic greșită.

Cere operatorului fiecare valoare pe linia ei: calea de intrare, selecția din formular și dacă ambele sunt necesare. Nu deduce una din cealaltă doar pentru că etichetele sună asemănător.

De ce scurtarea căii schimbă rezultatul

Clienții care acceptă doar gazdă și port se conectează adesea totuși, așa că simptomul este rareori o eșuare dură. În schimb obții pagina de autentificare greșită, o listă de grupuri goală, un nume de certificat care nu mai corespunde cu ce a publicat operatorul, sau un tunel care urcă fără o rută către serviciul dorit. Fiecare dintre acestea stă într-un alt strat, și niciunul nu se repară lipind un șir mai lung într-un câmp documentat ca nume de gazdă. Două dintre ele sunt și indistinguibile din exterior, pentru că ambele ajung ca un formular de autentificare care pur și simplu nu continuă.

Înlocuirea numelui de gazdă cu o adresă IP este o eroare separată care călătorește adesea cu aceasta. Selecția serviciului după nume și validarea certificatului depind ambele de nume, așa că o adresă numerică poate transforma o problemă de format al căii într-o eroare TLS.

Adresele din browser poartă și mai mult decât căi. Identificatorii de sesiune, țintele de redirecționare, prefixele de limbă și parametrii temporari de autentificare apar toți în bara de adrese, și niciunul dintre ei nu aparține unui profil de client salvat.

Confirmă punctul de intrare înainte de a edita orice altceva

Citește anteturile pentru calea care ți-a fost dată. O cerere precum curl -sS -o /dev/null -D - https://vpn.example.net/partners tipărește linia de stare și orice antet Location fără a urma redirecționarea. Un 302 care indică un punct de autentificare numit confirmă că calea există și arată încotro duce; un 404 înseamnă că adresa operatorului este învechită.

Apoi reprodu aceeași cale de intrare în clientul aprobat, de exemplu openconnect --usergroup=partners vpn.example.net, și urmărește ce formular apare. Dacă formularul este corect și tunelul tot eșuează, calea nu a fost niciodată problema, iar următoarea oprire este politica sau rutarea.

Notează numele de gazdă, portul, protocolul, calea de intrare și selecția din formular ca cinci câmpuri separate în tichet. Acea listă este ce îi permite inginerului următor să distingă un server inaccesibil de un refuz TLS, de o selecție refuzată și de un tunel care a urcat fără rutele de care avea nevoie.

Articole similare