Sovelluksen pyynnöt epäonnistuvat yrityksen VPN:n takana, mutta selain toimii

Avaat sisäisen portaalin selaimessa ja se latautuu. Käynnistät sovelluksen, joka kutsuu samaa isäntää, ja se epäonnistuu viestillä, joka ei nimeä yhtään kerrosta. Tunneli kuljettaa selainta, joten tunneli ei ole ensimmäinen epäilty. Pyyntösi ja palvelun välissä on neljä asiaa, ja jokainen jättää erilaisen jäljen. Tämä on järjestys, jota seuraan, alkaen pyynnöstä, jonka sovellus todella lähettää, enkä VPN-asiakkaan asetussivusta.

Katso pyyntöä, jonka sovellus todella lähettää

Ennen kuin kosket asetuksiin, anna sovelluksen kertoa, mitä se tekee. Yhden pyynnön tallennus proxyn ollessa nimenomaisesti pois päältä ja yksinkertainen porttitesti antavat kaksi perusviivaa, joihin seuraavia vaiheita verrataan. Jos pyyntö onnistuu proxyn ollessa pois päältä, olet jo hoitanut kolme neljästä kerroksesta.

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

Aja kaksi viimeistä samaan kohteeseen ja katso, missä ne erkanevat. Toimiva selain plus toimiva curl plus sovellus, joka ei toimi, rajaavat ongelman johonkin, mitä sovellus lisää: proxy, kuljetus tai viestin koko.

Sovellus peri proxyn, jota kukaan ei määrittänyt

Useimmat HTTP-pinot lukevat proxyasetukset käyttöjärjestelmästä oletuksena. Yrityksen VPN-asiakas asentaa usein sellaisen osana käyttöprofiiliaan, joten pyynnöt lähtevät proxyn kautta, jota kehittäjä ei koskaan maininnut koodissa. .NET:ssä oletuskäsittelijä lukee IE/WinHTTP-asetuksista; Java lukee -Dhttp.proxyHost; Nodella ei ole sisäänrakennettua proxytukea ennen kuin kirjasto lisää sen. Epäonnistuminen on harvoin puhdas kieltäytyminen, siksi ihmiset alkavat katsoa palvelinta.

Testi maksaa yhden pyynnön: kytke proxy nimenomaisesti pois yhdestä käsittelijästä ja vertaa.

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

Jos se onnistuu, korjaus kuuluu sovelluksen asetuksiin, ei tunneliin. Toista tarkastus jokaiselle projektin ajonaikaiselle ympäristölle, koska jokainen lukee eri lähdettä ja vain yksi niistä voi olla rikki.

Valitsemasi portti ei ole portti, jonka käytäntö sallii

Reititetty isäntä ei ole sallittu palvelu. Yrityskäytäntö sallii yleensä lähtevät verkkoportit ja pudottaa muut, joten palvelu portissa 8080 tai 1883 on saavuttamaton, kun taas 443 toimii hyvin. Selain ei todista tässä mitään: se käyttää porttia 443 määritelmän mukaan.

Julkaise sama palvelu portin 443 takana ja tavoita se nimellä ennen kuin pyydät poikkeusta. Jos poikkeus on todella tarpeen, rajaa se yhteen lähdealueeseen ja yhteen kohteeseen ja käsittele sitä osana palvelun määritelmää, ei kenenkään henkilökohtaisena kiertotienä.

Raaka TCP, jonka polku nollaa

Pitkäikäiset raa’an TCP:n yhteydet ovat kerros, joka epäonnistuu hämmentävimmin. Polku, joka sallii verkkoliikenteen, voi silti nollata tai kirjoittaa uudelleen epätavallista lähtevää TCP:tä, ja asiakas raportoi pistokkeen virheen, joka luetaan katkokseksi. Viestintä- ja tapahtumapalvelut toimittavat yleensä WebSocket-kuljetuksen juuri tällaista verkkoa varten, ja vaihtaminen on asiakkaan valinta, ei tunnelin muutos.

Vaihda kuljetus, testaa uudelleen äläkä muuta samassa ajossa mitään muuta. Tämä yhden muuttujan testi kertoo, tuliko nollaus polulta vai palvelusta.

Yhteydet, jotka sulkeutuvat vain suurilla hyötykuormilla

Pyyntö, joka onnistuu ja kuolee noin sekuntia myöhemmin, mutta vain kun runko on suuri, viittaa kokorajaan jossain keskellä. Välittäjä, joka laskee viestin tavuja, voi pudottaa yhteyden kesken siirron, ja asiakas raportoi epänormaalista sulkeutumisesta aikakatkaisun sijaan.

Pilko hyötykuorma sovelluskerroksessa. Pidä se erillään MTU-työstä: tunnelin pakettikoon laskeminen auttaa, kun tavalliset TCP-istunnot juuttuvat tasaiseen tavumäärään, eikä se tee mitään viestille, jonka välittäjä katsoo liian suureksi.

Miten neljä erottaa yhdellä kierroksella

Kolme havaintoa ratkaisee useimmat tapaukset. Tapahtuuko epäonnistuminen heti vai vain suurella rungolla? Onnistuuko sama pyyntö proxyn ollessa pois päältä? Muuttuuko tulos, kun vaihdat porttia tai kuljetusta? Kirjoita vastaukset ennen seuraavaa muutosta, koska yrityksen VPN plus peritty proxy plus sovelluksen oletus antavat sinulle kolme uskottavaa syytä kerralla.

Pidä yksi muuttuja testiä kohden ja kirjaa käyttämäsi kohdeisäntä. Ilman tätä perusviivaa seuraava henkilö toistaa kaikki neljä vaihetta alusta.