Programmas pieprasījumi neizdodas aiz uzņēmuma VPN, bet pārlūks strādā

Atverat iekšējo portālu pārlūkā, un tas ielādējas. Palaidiet programmu, kas izsauc to pašu resursdatoru, un tā neizdodas, ar ziņojumu, kas nenosauc nevienu slāni. Tunelis pārvadā pārlūku, tāpēc tunelis nav pirmais aizdomās turamais. Starp jūsu pieprasījumu un pakalpojumu ir četras lietas, un katra atstāj citu nospiedumu. Šī ir secība, kuru ievēroju, sākot ar pieprasījumu, ko programma patiešām sūta, nevis ar VPN klienta iestatījumu lapu.

Apskatiet pieprasījumu, ko programma patiešām sūta

Pirms aiztiekat konfigurāciju, ļaujiet programmai pateikt, ko tā dara. Viena pieprasījuma tveršana ar skaidri izslēgtu starpniekserveri un vienkāršs ostas tests dod divas bāzes līnijas, ar kurām salīdzina turpmākos soļus. Ja pieprasījums izdodas ar izslēgtu starpniekserveri, trīs no četriem slāņiem jau ir galā.

env | grep -i proxy            # Linux/macOS
netsh winhttp show proxy       # Windows, machine-wide
curl -sv --noproxy '*' https://svc.internal/
nc -vz svc.internal 8080

Palaidiet pēdējos divus uz to pašu galamērķi un vērojiet, kur tie atšķiras. Strādājošs pārlūks plus strādājošs curl plus nestrādājoša programma sašaurina problēmu līdz tam, ko programma pievieno: starpniekserverim, transportam vai ziņojuma izmēram.

Programma mantoja starpniekserveri, ko neviens nekonfigurēja

Lielākā daļa HTTP steku pēc noklusējuma lasa starpniekservera konfigurāciju no operētājsistēmas. Uzņēmuma VPN klients bieži instalē vienu kā savas piekļuves profila daļu, tāpēc pieprasījumi iziet caur starpniekserveri, ko izstrādātājs kodā nekad nav pieminējis. .NET noklusējuma apdarinātājs ņem IE/WinHTTP iestatījumus; Java lasa -Dhttp.proxyHost; Node nav iebūvēta starpniekservera atbalsta, kamēr bibliotēka to nepievieno. Neveiksme reti ir tīra atteikšana, tāpēc cilvēki sāk skatīties uz serveri.

Tests maksā vienu pieprasījumu: skaidri izslēdziet starpniekserveri vienā apdarinātājā un salīdziniet.

var handler = new HttpClientHandler { UseProxy = false };
using var client = new HttpClient(handler);

Ja tas izdodas, labojums pieder programmas konfigurācijai, nevis tunelim. Atkārtojiet auditu katrai projekta izpildlaika videi, jo katra lasa citu avotu un tikai viena var būt salauzta.

Osta, kuru izvēlējāties, nav osta, ko atļauj politika

Maršrutēts resursdators nav atļauts pakalpojums. Uzņēmuma politika parasti atļauj izejošās tīmekļa ostas un pārējās izmet, tāpēc pakalpojums uz 8080 vai 1883 ir nesasniedzams, kamēr 443 strādā labi. Pārlūks šeit neko nepierāda: tas pēc definīcijas izmanto 443.

Publicējiet to pašu pakalpojumu aiz 443 un sasniedziet to pēc nosaukuma, pirms pieprasāt izņēmumu. Ja izņēmums patiešām ir vajadzīgs, ierobežojiet to ar vienu avota diapazonu un vienu galamērķi un uzskatiet to par pakalpojuma definīcijas daļu, nevis kāda personīgu apiešanu.

Neapstrādāts TCP, ko ceļš atiestata

Ilgstoši neapstrādāta TCP savienojumi ir slānis, kas neizdodas visapmulsinošāk. Ceļš, kas atļauj tīmekļa trafiku, joprojām var atiestatīt vai pārrakstīt neparastu izejošo TCP, un klients ziņo par ligzdas kļūdu, kas lasās kā pārtraukums. Ziņojumapmaiņas un notikumu pakalpojumi parasti piedāvā WebSocket transportu tieši šādam tīklam, un pārslēgšanās ir klienta izvēle, nevis tuneļa izmaiņa.

Nomainiet transportu, pārbaudiet vēlreiz un tajā pašā palaidē neko citu nemainiet. Šis viena mainīgā tests pasaka, vai atiestatīšana nāca no ceļa vai no pakalpojuma.

Savienojumi, kas aizveras tikai pie lielām kravām

Pieprasījums, kas izdodas un pēc tam nomirst apmēram sekundi vēlāk, bet tikai tad, kad pamatteksts ir liels, norāda uz izmēra ierobežojumu kaut kur pa vidu. Starpnieks, kas skaita ziņojumu baitus, var nomest savienojumu pārsūtīšanas vidū, un klients ziņo par neparastu aizvēršanu, nevis par taimautu.

Sadaliet kravu gabalos lietojumprogrammas līmenī. Turiet to atsevišķi no MTU darba: tuneļa paketes izmēra samazināšana palīdz, kad parastās TCP sesijas iestrēgst pie nemainīga baitu skaita, un tas neko nedara ziņojumam, ko starpnieks uzskata par pārāk lielu.

Kā atšķirt četrus vienā piegājienā

Trīs novērojumi izšķir lielāko daļu gadījumu. Vai neveiksme notiek uzreiz vai tikai ar lielu pamattekstu? Vai tas pats pieprasījums izdodas ar izslēgtu starpniekserveri? Vai rezultāts mainās, mainot ostu vai transportu? Pierakstiet atbildes pirms nākamās izmaiņas, jo uzņēmuma VPN plus mantots starpniekserveris plus programmas noklusējums dod trīs ticamus cēloņus uzreiz.

Turiet vienu mainīgo vienā testā un pierakstiet izmantoto galamērķa resursdatoru. Bez šīs bāzes līnijas nākamais cilvēks atkārto visus četrus soļus no sākuma.