Aplikazioaren eskaerek huts egiten dute enpresako VPN baten atzean, baina nabigatzaileak bai funtzionatzen du
Aplikazio bat apurtzen da nabigatzaileak gunea kargatzen duen bitartean. Haren ordenean aztertu heredatu zuen proxy-a, ataka-politika, TCP gordinaren berrezarpenak eta karga-tamainaren mugak.
Barneko ataria nabigatzailean irekitzen duzu eta kargatu egiten da. Host bera deitzen duen aplikazioa exekutatzen duzu eta huts egiten du, inolako geruza izendatzen ez duen mezu batekin. Tunelak nabigatzailea darama, beraz tunela ez da lehen susmagarria. Lau gauza daude zure eskaeraren eta zerbitzuaren artean, eta bakoitzak arrasto desberdina uzten du. Hau da jarraitzen dudan ordena: aplikazioak benetan bidaltzen duen eskaeratik hasita, ez VPN bezeroaren ezarpenen orritik.
Begiratu aplikazioak benetan bidaltzen duen eskaera
Konfigurazioa ukitu aurretik, egin aplikazioari zer egiten duen esateko. Proxy-a espresuki desgaituta duen eskaera bakarreko kaptura batek eta ataka-proba soil batek bi oinarri-lerro ematen dizkizu, hurrengo pausoak haiekin alderatzeko. Eskaerak proxy-rik gabe funtzionatzen badu, lau geruzetatik hiru amaitu dituzu.
env | grep -i proxy # Linux/macOS
netsh winhttp show proxy # Windows, machine-wide
curl -sv --noproxy '*' https://svc.internal/
nc -vz svc.internal 8080Exekutatu azken biak helmuga berarekin eta begiratu non dibergitzen duten. Funtzionatzen duen nabigatzaileak gehi funtzionatzen duen curl-ek gehi funtzionatzen ez duen aplikazioak arazoa aplikazioak gehitzen duen zerbaitetara murrizten dute: proxy bat, garraio bat edo mezu-tamaina bat.
Aplikazioak inork konfiguratu ez zuen proxy bat heredatu zuen
HTTP pila gehienek proxy konfigurazioa sistema eragiletik irakurtzen dute lehenespenez. Enpresako VPN bezeroak sarritan bat instalatzen du bere sarbide-profilaren parte gisa, beraz eskaerak garatzaileak kodean inoiz aipatu ez zuen proxy batetik irteten dira. .NET-en lehenetsitako handler-ak IE/WinHTTP ezarpenetatik irakurtzen du; Java-k -Dhttp.proxyHost irakurtzen du; Node-k ez du proxy onarpenik barne, liburutegi batek gehitzen duen arte. Hutsegitea oso gutxitan da ukapen garbia, horregatik jendea zerbitzaria begiratzen hasten da.
Probak eskaera bat balio du: desgaitu proxy-a espresuki handler bakarrean eta alderatu.
var handler = new HttpClientHandler { UseProxy = false };
using var client = new HttpClient(handler);Hori funtzionatzen badu, konponketa aplikazioaren konfigurazioan dago, ez tunelean. Errepikatu auditoria proiektuko exekuzio-ingurune bakoitzeko, bakoitzak iturri desberdina irakurtzen baitu eta agian bakarra dago hautsita.
Aukeratu duzun ataka ez da politikak uzten duen ataka
Bideratutako host bat ez da baimendutako zerbitzu bat. Enpresako politikak normalean irteerako web atakak uzten ditu eta gainerakoak baztertzen, beraz 8080 edo 1883 atakan dagoen zerbitzua iristezina da, 443 ondo funtzionatzen duen bitartean. Nabigatzaileak ez du ezer frogatzen hemen: 443 erabiltzen du definizioz.
Argitaratu zerbitzu bera 443-ren atzean eta iritsi hara izenez salbuespen bat eskatu aurretik. Salbuespena benetan beharrezkoa bada, mugatu iturri-barruti bakar batera eta helmuga bakarrera, eta hartu zerbitzuaren definizioaren parte gisa, ez norbaiten irtenbide pertsonal gisa.
Bideak berrezartzen duen TCP gordina
Iraupen luzeko TCP gordin konexioak dira modurik nahasgarrienean huts egiten duen geruza. Web trafikoa uzten duen bide batek oraindik ere irteerako TCP ezohikoa berrezarri edo berridatzi dezake, eta bezeroak etenaldi gisa irakurtzen den socket errore bat jakinarazten du. Mezu eta gertaera zerbitzuek normalean WebSocket garraioa eskaintzen dute hain zuzen sare mota horretarako, eta aldatzea bezeroaren aukera da, ez tunelaren aldaketa.
Aldatu garraioa, probatu berriro eta ez aldatu beste ezer exekuzio berean. Aldagai bakarreko proba horrek esaten dizu berrezarpena bidetik edo zerbitzutik etorri den.
Karga handiekin soilik ixten diren konexioak
Arrakasta izan eta gero segundo bat inguru geroago hiltzen den eskaerak, baina gorputza handia denean soilik, erdian nonbait dagoen tamaina-muga bat adierazten du. Mezuen byteak zenbatzen dituen bitartekari batek konexioa transferentziaren erdian bota dezake, eta bezeroak itxiera anormala jakinarazten du denbora-muga baten ordez.
Zatikatu karga aplikazio-geruzan. Eduki hori MTU lanetik bereizita: tunelaren pakete-tamaina jaisteak laguntzen du TCP saio arruntak byte-kopuru konstantean blokeatzen direnean, eta ez du ezer egiten bitartekari batek handiegitzat jotzen duen mezu baterako.
Nola bereizi laurak pasaaldi bakarrean
Hiru behaketak askatzen dituzte kasu gehienak. Hutsegitea berehala gertatzen da edo gorputz handiarekin soilik? Eskaera berak funtzionatzen du proxy-a desgaituta? Emaitza aldatzen da ataka edo garraioa aldatzen duzunean? Idatzi erantzunak hurrengo aldaketaren aurretik, enpresako VPN batek gehi heredatutako proxy batek gehi aplikazioaren balio lehenetsiak hiru arrazoi sinesgarri ematen baitizkizute batera.
Eduki aldagai bat proba bakoitzeko eta idatzi erabili duzun helmuga-host-a. Oinarri-lerro hori gabe, hurrengo pertsonak lau pausoak berriro errepikatzen ditu hasieratik.