OpenConnect pieteikšanās nonāk nepareizajā lapā? Vispirms pārbaudiet ceļu

Jūs ielīmējat adresi no ievadpasta, klients sasniedz vārteju, un parādītā pieteikšanās veidlapa ir vispārējais portāls, nevis partneru portāls, ko aprakstījis operators. Nekas neuzrāda kļūdu, un tieši tas mulsina: tunelis var pat pacelties, tikai aiz nepareizā ieejas punkta. Ceļš šajā URL veica darbu, un, kas to aizstāja, to darbu nometa.

Atdaliet divas lietas, kas biļetenā nāk kā viena virkne: adresi, kas sasniedz pakalpojumu, un ievadi, kas nosaka, kur sākas autentifikācija. Salabot pirmo, ignorējot otro, ir veids, kā pareizs resursdatora nosaukums joprojām dod nepareizu pieteikšanos.

Ko klients nosūta pirms veidlapas redzēšanas

Ar adresi, piemēram, https://vpn.example.net/partners, klienta pirmā darbība ir HTTPS pieprasījums uz šo ceļu, nevis uz kailo resursdatoru. Atpakaļ parasti nāk pāradresācija uz pieteikšanās galapunktu vai pati veidlapa. Klients, kas saņem tikai vpn.example.net, sāk no tās noklusējuma galalapas, kāda vien ir, un tā var būt cits portāls, cits grupu saraksts vai lapa, kas gaida pavisam citu protokolu. Atšķirība ir redzama atbildes galvenēs daudz agrāk, nekā tiek ievadīts jebkurš pieteikšanās datus.

Tāpēc strādājoša pārlūka cilne un neveiksmīgs klienta profils var nosaukt vienu un to pašu vārteju un tomēr nepiekrist. Pārlūks sekoja ceļam; profilam tā nekad nebija.

Divas ievades, kas izskatās aizstājamas un nav

OpenConnect atklāj sākotnējo HTTPS ceļu kā --usergroup, un rokasgrāmatas lapa pilnu URL ar šo ceļu uzskata par to pašu pieprasījumu, kas uzrakstīts citādi. --authgroup ir atsevišķa opcija: tā izvēlas ierakstu no saraksta, ko vārteja uzrāda pieteikšanās veidlapas iekšpusē. Daži protokoli šo ierakstu sauc par grupu, citi par domēnu vai vārteju, un tieši tur abi karodziņi tiek sajaukti.

Pakalpojumam likumīgi var būt vajadzīgi abi. Ceļš var aizvest uz pareizo portālu, kamēr veidlapa joprojām prasa izvēlēties grupu tā iekšpusē. Ja portāla nosaukumu dod kā grupas nosaukumu vai otrādi, tiek iegūta pieteikšanās, kas izskatās pieņemta un pēc tam neautorizē, jo vērtība bija sintaktiski derīga un semantiski nepareiza.

Palūdziet operatoram katru vērtību atsevišķā rindā: ieejas ceļu, veidlapas izvēli un vai abi ir vajadzīgi. Neatvasiniet vienu no otra tikai tāpēc, ka birkas izklausās līdzīgi.

Kāpēc ceļa saīsināšana maina rezultātu

Klienti, kas pieņem tikai resursdatoru un portu, bieži tomēr pievienojas, tāpēc simptoms reti ir skarba kļūda. Tā vietā jūs iegūstat nepareizu pieteikšanās lapu, tukšu grupu sarakstu, sertifikāta nosaukumu, kas vairs neatbilst operatora publicētajam, vai tuneli, kas paceļas bez maršruta uz vēlamo pakalpojumu. Katrs no tiem atrodas citā slānī, un nevienu no tiem neizlabo garākas virknes ielīmēšana laukā, kas dokumentēts kā resursdatora nosaukums. Divi no tiem arī nav atšķirami no ārpuses, jo abi nāk kā pieteikšanās veidlapa, kas vienkārši neturpinās.

Resursdatora nosaukuma aizstāšana ar IP adresi ir atsevišķa kļūda, kas bieži ceļo kopā ar šo. Pakalpojuma izvēle pēc nosaukuma un sertifikāta validācija abas ir atkarīgas no nosaukuma, tāpēc skaitliska adrese var pārvērst ceļa formāta problēmu TLS kļūdā.

Pārlūka adreses satur arī vairāk nekā ceļus. Sesijas identifikatori, pāradresācijas mērķi, valodas prefiksi un pagaidu pieteikšanās parametri visi parādās adreses joslā, un neviens no tiem nepieder saglabātam klienta profilam.

Apstipriniet ieejas punktu pirms kaut kā cita rediģēšanas

Izlasiet tā ceļa galvenes, kuru saņēmāt. Pieprasījums, piemēram, curl -sS -o /dev/null -D - https://vpn.example.net/partners, izdrukā statusa rindu un jebkuru Location galveni, nesekojot pāradresācijai. 302, kas norāda uz nosauktu pieteikšanās galapunktu, apstiprina, ka ceļš pastāv, un parāda, uz kurieni tas ved; 404 nozīmē, ka operatora adrese ir novecojusi.

Pēc tam atkārtojiet to pašu ieejas punktu apstiprinātajā klientā, piemēram, openconnect --usergroup=partners vpn.example.net, un vērojiet, kura veidlapa parādās. Ja veidlapa ir pareiza un tunelis joprojām neizdodas, ceļš nekad nav bijis problēma, un nākamā pietura ir politika vai maršrutēšana.

Biļetenā ierakstiet resursdatora nosaukumu, portu, protokolu, ieejas ceļu un veidlapas izvēli kā piecus atsevišķus laukus. Tieši šis saraksts ļauj nākamajam inženierim atšķirt nesasniedzamu serveri no TLS noraidījuma, noraidītas izvēles un tuneļa, kas pacēlās bez nepieciešamajiem maršrutiem.