Serverim piesaistītais profils neizdodas aiz TLS starpniekservera: kura paaudze?

Viens lietotājs var pieslēgties, bet otrs ne, caur to pašu portālu, tajā pašā dienā. Abiem ir serverim piesaistīti profili, abi ir uz tā paša Access Server būvējuma, un vienīgā atšķirība ir tas, kad viņu profils tika ģenerēts. Tas ir modelis, ko ir vērts atpazīt, jo "serverim piesaistīts" nosauc politiku, nevis savienojuma secību. Access Server ir izlaidis divas šī artefakta paaudzes, un TLS apgrieztais starpniekserveris stāv priekšā tikai vienam no viņu ceļiem. Trīs nosacījumi nosaka, kurā zarā jūs esat.

Divas paaudzes, divas savienojuma secības

Vecākajā dizainā, kas spēkā līdz 2.8, importētā faila ir pseidoprofils. OpenVPN Connect to izmanto autentifikācijai pret Access Server tīmekļa API caur HTTPS, saņem pagaidu lietotājam piesaistītu profilu un sesijas pilnvaru, un tikai pēc tam izveido VPN. Divi transporti darbojas pēc kārtas, un pirmais ir parasts tīmekļa pieprasījums.

Formāts, kas ieviests ar 2.9, neveic šo sagatavošanu katram savienojumam. Tas ir vietējs profils, ko var izmantot saderīgi OpenVPN klienti, ne tikai OpenVPN Connect. Tā lejupielāde vai importēšana ar URL joprojām var ietvert HTTPS — tas ir publicēšanas solis, nevis pagaidu profila iegūšana katram savienojumam.

Atjauninājums ne vienmēr pārraksta jau izdotos profilus, tāpēc pašreizējā servera versija joprojām var izplatīt veco artefaktu. Servera būvējums pasaka, kas ir iespējams, nevis ko šis lietotājs importēja.

Trīs nosacījumi, kas izvēlas jūsu zaru

Pirmais nosacījums ir artefakta paaudze. Pieprasiet failu, apskatiet, kā tas tika ražots, un pierakstiet klienta versiju, kas to importēja. Ja nevarat noteikt paaudzi no faila, testa kontam izdots jauns profils jums pateiks, ko serveris ražo šodien, un tā ir cita informācija nekā tā, kas ir neizdevušajam lietotājam.

Otrais ir tas, ko jūsu priekšpuse faktiski pabeidz. Septītā slāņa HTTP apgrieztais starpniekserveris, kas noņem TLS, nav tas pats objekts kā ceturtā slāņa TCP pārsūtītājs, un UDP pārsūtītājs arī nav. Ierastais Access Server izkārtojums portā 443 liek OpenVPN TCP dēmonam atpazīt pārlūka trafiku un nodot to tīmekļa pakalpojumiem, tāpēc nesaistīta HTTPS pabeidzēja ievietošana priekšā nesaglabā šī dēmona protokola apstrādi. Kopīgais numurs 443 nepadara divus dizainus līdzvērtīgus.

Trešais ir tas, kur nonāk kļūme. Kļūme pirms VPN un vadības kanāla kļūme izskatās līdzīgas klientā, kas saka tikai "savienojas", taču tās atstāj pierādījumus dažādās vietās. Ja spēlē ir vecais formāts, sagatavošana ir kandidāts. Ja spēlē ir jaunais formāts, tukšs tīmekļa piekļuves žurnāls ir gaidāms un neko nepierāda nevienā virzienā.

Kad artefakts ir vecs: sagatavošana neizdodas pirmā

Lasiet klienta faktisko kļūdu, nevis tā galīgo stāvokli. Interesantie lauki ir HTTPS kļūda, servera identitāte, ko klients gaidīja, galamērķis, uz kuru devās pieprasījums, un vai sertifikāta validācija tika pabeigta. Pēc tam salīdziniet tos ar servera puses tīmekļa pakalpojuma un starpniekservera žurnāliem.

Tas, ka pārlūks sasniedz pieteikšanās lapu, nav pierādījums, ka šī klienta API autentifikācija izdevās. Tie ir dažādi pieprasījumi, ar dažādām sertifikāta gaidām un bieži dažādiem resursdatora nosaukumiem. Ja portāls tiek apkalpots pareizi un klients joprojām neizdodas, nesaskaņa ir sagatavošanas ceļā, nevis lietotāja parolē.

Nelieciet salīdzinājumam izdoties, izslēdzot TLS validāciju vai mīkstinot autentifikācijas politiku. Tas diagnosticējamu konfigurācijas neatbilstību pārvērš strādājošā, bet nepārbaudītā ceļā, un tieši šīs izmaiņas pagaidu testu pārvērš pastāvīgā caurumā. Access Server savienojuma profilu dokumentācija apraksta abas paaudzes un pagaidu profila plūsmu, un tas ir atsauce, kas jāpārbauda, pirms pieņemt, ka vainīgs ir starpniekserveris.

Kad artefakts ir jauns: lasiet vadības kanālu

Ar 2.9 stila profilu klients dodas tieši uz vietējo VPN galapunktu. Izpētiet profila galapunktus, izmantoto transportu un vadības kanāla kļūdu. Ja klients nekad neizsūta HTTP pieprasījumu, tas atbilst dizainam un nav simptoms.

Šeit arī starpniekservera jautājums maina formu. HTTPS noņemšana nevar salauzt tikai TCP plūsmu, ko tā nekad neredz, bet tā joprojām var salauzt lejupielādi, kas publicē profilu, un tikai TCP pārsūtītājs vispār nepārvadās UDP. Pārbaudiet, kādu transportu profils pieprasa, pirms secināt, ka priekšpuse ir nebūtiska.

TLS caureja vienai plūsmai ir šaurs izkārtojums. Tā nenodrošina UDP pārsūtīšanu un neatveido paša dēmona pakalpojumu pārsūtīšanas uzvedību portā 443. Ja jūsu priekšpuse dara kādu no šiem, pasakiet kuru, jo risinājums atšķiras.

Risinājumi, kas paliek šauri

Vismazāk invazīvā pārbaude ir ģenerēt jaunu atbalstītu profilu testa kontam un savienoties caur paredzēto vietējo galapunktu ar tām pašām autentifikācijas prasībām. Ja tas strādā un saglabātais vecais profils ne, jūs vienā solī esat atdalījis artefaktu no servera un no starpniekservera.

Lietotājam piesaistīta profila izplatīšana pilnībā novērš mantoto sagatavošanas atkarību, jo nav pagaidu profila apmaiņas, kas varētu neizdoties. Tas jāizdod paredzētajam lietotājam, nekad jākopē no administratora, un tas maina to, ko klients drīkst darīt, tāpēc uzskatiet to par politikas lēmumu, nevis apietošanas ceļu.

Pēc tam izlabojiet publicēšanas izkārtojumu, lai pastāvētu katrs nepieciešamais ceļš: tīmekļa ceļš lejupielādēm un portāla lietošanai, un vietējais VPN ceļš transportā, ko profili gaida. Turiet starpniekservera darbu vienā slānī. Strādājošs lietotājam piesaistīts tunelis pierāda, ka šis ceļš strādā; tas nepierāda, ka katrs starpniekservera izkārtojums atbalsta katru paaudzi, un veca sagatavošanas kļūme nenosoda jaunāko formātu.

• Nosakiet artefakta paaudzi, pirms aiztikt starpniekserveri.
• Nosakiet, vai kļūme notiek pirms tuneļa vai tajā.
• Apstipriniet, ko pabeidz priekšpuse: HTTP, TCP plūsmu vai UDP.
• Pārbaudiet tikko izdotu profilu pret vietējo galapunktu ar nemainītu politiku.