Zahtjevi aplikacije ne prolaze kroz korporativni VPN, ali preglednik radi

Otvorite interni portal u pregledniku i on se učita. Pokrenete aplikaciju koja poziva isti host i ona padne, s porukom koja ne imenuje nijedan sloj. Tunel nosi preglednik, pa tunel nije prvi osumnjičeni. Četiri stvari stoje između vašeg zahtjeva i servisa i svaka ostavlja drugačiji trag. Ovo je redoslijed kojim idem, počevši od zahtjeva koji aplikacija stvarno šalje, a ne od stranice s postavkama VPN klijenta.

Pogledajte zahtjev koji aplikacija zaista šalje

Prije nego dirnete konfiguraciju, natjerajte aplikaciju da vam kaže što radi. Snimanje jednog zahtjeva s izričito isključenim proxyjem i običan test porta daju vam dvije osnovne linije s kojima se uspoređuju kasniji koraci. Ako zahtjev prođe s isključenim proxyjem, već ste završili tri od četiri sloja.

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

Pokrenite posljednja dva prema istoj destinaciji i gledajte gdje se razilaze. Preglednik koji radi plus curl koji radi plus aplikacija koja ne radi sužavaju problem na nešto što aplikacija dodaje: proxy, transport ili veličinu poruke.

Aplikacija je naslijedila proxy koji nitko nije podesio

Većina HTTP stogova čita proxy konfiguraciju iz operacijskog sustava po defaultu. Korporativni VPN klijent često ga instalira kao dio svog profila pristupa, pa zahtjevi izlaze kroz proxy koji programer nikada nije spomenuo u kodu. U .NET-u podrazumijevani handler vuče iz IE/WinHTTP postavki; Java čita -Dhttp.proxyHost; Node nema ugrađenu podršku za proxy dok je biblioteka ne doda. Neuspjeh rijetko je čisto odbijanje, zato ljudi počinju gledati poslužitelj.

Test košta jedan zahtjev: isključite proxy izričito na jednom handleru i usporedite.

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

Ako to prođe, popravak pripada konfiguraciji aplikacije, a ne tunelu. Ponovite reviziju za svako okruženje izvršavanja u projektu, jer svako čita drugačiji izvor i samo jedno može biti pokvareno.

Port koji ste odabrali nije port koji politika dopušta

Rutirani host nije dopušteni servis. Korporativna politika obično dopušta odlazne web portove i odbacuje ostale, pa je servis na 8080 ili 1883 nedostupan dok 443 radi dobro. Preglednik ovdje ništa ne dokazuje: on po definiciji koristi 443.

Objavite isti servis iza 443 i dohvatite ga po imenu prije nego što zatražite iznimku. Ako je iznimka zaista potrebna, ograničite je na jedan raspon izvora i jednu destinaciju i tretirajte je kao dio definicije servisa, a ne kao nečiji osobni zaobilazni put.

Sirovi TCP koji put resetira

Dugotrajne veze sirovog TCP-a su sloj koji pada najzbunjujuće. Put koji dopušta web promet ipak može resetirati ili prepisati neuobičajen odlazni TCP, a klijent prijavi pogrešku socketa koja se čita kao prekid. Servisi za poruke i događaje obično isporučuju WebSocket transport upravo za takvu mrežu, a prebacivanje je opcija klijenta, a ne promjena tunela.

Promijenite transport, ponovno testirajte i ne mijenjajte ništa drugo u istom prolazu. Taj test s jednom varijablom kaže vam dolazi li reset s puta ili iz servisa.

Veze koje se zatvaraju samo na velikim teretima

Zahtjev koji prođe i onda umre oko sekundu kasnije, ali samo kada je tijelo veliko, upućuje na ograničenje veličine negdje u sredini. Posrednik koji broji bajtove poruka može ispustiti vezu usred prijenosa, a klijent prijavi abnormalno zatvaranje umjesto isteka vremena.

Razdijelite teret na dijelove na razini aplikacije. Držite to odvojeno od rada na MTU: smanjenje veličine paketa tunela pomaže kada obične TCP sesije zastanu na stalnom broju bajtova, a ne čini ništa za poruku koju posrednik smatra prevelikom.

Kako razlikovati četiri u jednom prolazu

Tri zapažanja rješavaju većinu slučajeva. Događa li se neuspjeh odmah ili samo s velikim tijelom? Prolazi li isti zahtjev s isključenim proxyjem? Mijenja li se ishod kada promijenite port ili transport? Zapišite odgovore prije sljedeće promjene, jer korporativni VPN plus naslijeđeni proxy plus zadana postavka aplikacije daju vam tri vjerojatna uzroka odjednom.

Držite jednu varijablu po testu i zabilježite host destinacije koji ste koristili. Bez te osnovne linije sljedeća osoba ponavlja sva četiri koraka od početka.