Az alkalmazás kérései elbuknak egy vállalati VPN mögött, a böngésző viszont működik

Egy alkalmazás elhasal, miközben a böngésző betölti az oldalt. Ebben a sorrendben járja végig az örökölt proxyt, a portszabályzatot, a nyers TCP visszaállításokat és a hasznos teher méretkorlátait.

Megnyitja a belső portált egy böngészőben, és az betöltődik. Elindítja az alkalmazást, amely ugyanazt a gazdagépet hívja, és az elbukik, olyan üzenettel, amely egyetlen réteget sem nevez meg. Az alagút szállítja a böngészőt, tehát az alagút nem az első gyanúsított. Négy dolog áll a kérése és a szolgáltatás között, és mindegyik más nyomot hagy. Ez az a sorrend, amelyet követek, a kéréstől kezdve, amelyet az alkalmazás valóban küld, és nem a VPN-kliens beállítási oldalától.

Nézze meg azt a kérést, amelyet az alkalmazás valóban küld

Mielőtt hozzányúlna a konfigurációhoz, hagyja, hogy az alkalmazás elmondja, mit tesz. Egyetlen kérés rögzítése kifejezetten kikapcsolt proxyval és egy egyszerű portteszt két alapvonalat ad, amelyekhez a következő lépések hasonlíthatók. Ha a kérés a proxy kikapcsolásával sikerül, már három réteggel végzett a négyből.

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

Futtassa az utolsó kettőt ugyanarra a célra, és figyelje, hol válnak el. Egy működő böngésző plusz egy működő curl plusz egy nem működő alkalmazás arra szűkíti a problémát, amit az alkalmazás hozzáad: egy proxy, egy átvitel vagy egy üzenetméret.

Az alkalmazás olyan proxyt örökölt, amelyet senki nem állított be

A legtöbb HTTP-verem alapértelmezés szerint az operációs rendszerből olvassa a proxy konfigurációját. Egy vállalati VPN-kliens gyakran telepít egyet a hozzáférési profiljának részeként, így a kérések olyan proxyn keresztül mennek ki, amelyet a fejlesztő soha nem említett a kódban. .NET-ben az alapértelmezett kezelő az IE/WinHTTP beállításaiból olvas; a Java a -Dhttp.proxyHost értéket olvassa; a Node-nak nincs beépített proxytámogatása, amíg egy könyvtár hozzá nem adja. A hiba ritkán tiszta elutasítás, ezért kezdenek az emberek a kiszolgálóra nézni.

A teszt egy kérést ér: kapcsolja ki a proxyt kifejezetten egy kezelőn, és hasonlítsa össze.

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

Ha ez sikerül, a javítás az alkalmazás konfigurációjába tartozik, nem az alagútba. Ismételje meg az auditot a projekt minden futtatókörnyezetére, mert mindegyik más forrást olvas, és csak az egyik lehet hibás.

A kiválasztott port nem az, amelyet a szabályzat engedélyez

Egy irányított gazdagép nem engedélyezett szolgáltatás. A vállalati szabályzat általában engedélyezi a kimenő webportokat és eldobja a többit, ezért a 8080 vagy 1883 porton futó szolgáltatás elérhetetlen, miközben a 443 jól működik. A böngésző itt semmit nem bizonyít: definíció szerint a 443-at használja.

Tegye közzé ugyanazt a szolgáltatást a 443 mögött, és név szerint érje el, mielőtt kivételt kér. Ha a kivétel valóban szükséges, korlátozza egy forrástartományra és egy célra, és a szolgáltatásdefiníció részének tekintse, ne valaki személyes kerülőútjának.

Nyers TCP, amelyet az útvonal visszaállít

A hosszú életű nyers TCP-kapcsolatok az a réteg, amely a legzavarba ejtőbben hibázik. Egy webes forgalmat engedélyező útvonal még mindig visszaállíthatja vagy átírhatja a szokatlan kimenő TCP-t, és a kliens olyan socket-hibát jelent, amely kiesésnek olvasható. Az üzenet- és eseményszolgáltatások általában WebSocket-átvitelt szállítanak éppen az ilyen hálózathoz, és a váltás kliensbeállítás, nem alagútmódosítás.

Váltson átvitelt, teszteljen újra, és ugyanabban a futásban ne változtasson semmi máson. Ez az egyváltozós teszt megmondja, hogy a visszaállítás az útvonalról vagy a szolgáltatásból jött.

Kapcsolatok, amelyek csak nagy terhelésnél záródnak

Egy kérés, amely sikerül, majd körülbelül egy másodperc múlva meghal, de csak akkor, ha a törzs nagy, egy méretkorlátra mutat valahol a közepén. Egy közvetítő, amely az üzenetek bájtjait számolja, az átvitel közepén eldobhatja a kapcsolatot, és a kliens időtúllépés helyett rendellenes lezárást jelent.

Darabolja a terhet az alkalmazásrétegen. Tartsa ezt külön az MTU-munkától: az alagút csomagméretének csökkentése akkor segít, amikor a közönséges TCP-munkamenetek állandó bájtszámnál elakadnak, és semmit nem tesz egy olyan üzenetért, amelyet egy közvetítő túl nagynak tart.

Hogyan különböztesse meg a négyet egy menetben

Három megfigyelés eldönti a legtöbb esetet. A hiba azonnal jelentkezik, vagy csak nagy törzzsel? Ugyanaz a kérés sikerül kikapcsolt proxyval? Változik az eredmény, ha portot vagy átvitelt vált? Írja le a válaszokat a következő változtatás előtt, mert egy vállalati VPN plusz egy örökölt proxy plusz egy alkalmazás-alapértelmezés egyszerre három valószínű okot ad.

Tartson egy változót tesztenként, és jegyezze fel a használt célgazdagépet. Ezen alapvonal nélkül a következő ember mind a négy lépést elölről ismétli.

Kapcsolódó cikkek