Proxy-ul de depanare orbește când se conectează VPN-ul corporativ

Instrumentul de captură funcționează toată dimineața, tunelul se conectează și devine silențios. Deconectezi și pornește din nou. Primul instinct este că VPN-ul a stricat proxy-ul, dar în configurația proxy-ului nu s-a schimbat nimic. Ce s-a schimbat este ce configurație citesc acum aplicațiile: o intrare de tunel poate purta propriile setări de proxy, un profil administrat poate reactiva configurația automată, iar unele medii de execuție citesc doar o parte din ce oferă sistemul de operare. Citește valoarea pentru fiecare conexiune înainte de a atinge valoarea globală.

Windows ține un proxy pentru fiecare conexiune

În opțiunile Internet există două straturi care arată identic în dialog. Setările rețelei locale se aplică conexiunii locale obișnuite, în timp ce o intrare de conectare telefonică sau VPN păstrează propria copie sub HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Connections, stocată ca valoare binară. Scrierea valorilor globale cunoscute din registru nu actualizează acea copie.

Exact așa se comportă un instrument corect înainte de conectare și incorect după, fără nicio schimbare vizibilă în setările sale. Dialogul la care te uitai era panoul rețelei locale. Era corect și era irelevant. Intrarea pe care Windows o folosea de fapt era cea creată pentru tunel.

Modul acceptat de a schimba o singură intrare este API-ul de opțiuni de conexiune WinINET: completează un INTERNET_PER_CONN_OPTION_LIST cu numele conexiunii, indicatorii, serverul proxy și o listă de excepții, aplică-l și apoi reîmprospătează. Pentru o verificare rapidă, deschide dialogul de setări al intrării tunelului și compară panoul de proxy cu cel al rețelei locale; diferența este de obicei evidentă după ce știi unde să te uiți.

Un PAC administrat se poate reactiva singur

În macOS, scriptul de configurare automată a proxy-ului și descoperirea automată a proxy-ului sunt proprietăți ale unui serviciu de rețea, nu ale mașinii. Un profil de configurare le poate impune, așa că reapar după ce le debifezi, iar fiecare cerere merge atunci la proxy-ul pe care îl alege scriptul.

Inspectează și, dacă ai autorizare, oprește acele două comutatoare pentru serviciul care transportă traficul:

networksetup -setautoproxystate "Wi-Fi" off
networksetup -setproxyautodiscovery "Wi-Fi" off
scutil --proxy

Folosește numele real al serviciului, nu o presupunere. Un laptop cu Wi-Fi și adaptor Ethernet USB are două astfel de servicii, iar traficul tău trece printr-unul singur. scutil --proxy afișează valorile pentru serviciul principal curent. Compară acea ieșire cu ce ai editat înainte de a concluziona că profilul a câștigat.

Îndreaptă instrumentul spre sursa reală

Dacă scriptul conține proxy-ul corporativ, citește-l și introdu aceeași adresă ca proxy extern în interiorul instrumentului de captură. Atunci instrumentul trimite mai departe către sursa reală, ceea ce așteaptă proxy-ul corporativ, și rămâne în calea cererii în loc să se lupte cu politica.

Aceasta este mișcarea care te ține în depanare în loc de reconfigurare.

Împinge proxy-ul în tunel

Un client bazat pe OpenVPN poate accepta opțiuni de proxy care se aplică după ce tunelul este ridicat, ceea ce este comod când clientul deține rutele:

dhcp-option HTTPPROXY 127.0.0.1:8888
dhcp-option HTTPSPROXY 127.0.0.1:8888

Doar clienții care respectă opțiunea o vor folosi, iar aceasta fixează portul tău de ascultare într-un profil. Trateaz-o ca pe o comozitate de laborator, nu ca standard de implementare, pentru că următorul push de profil o va elimina.

Unii clienți nu citesc niciodată proxy-ul de sistem

Firefox păstrează propriile setări de proxy, motiv pentru care uneori continuă să captureze când un browser cu proxy de sistem nu o mai face. Un client .NET mai vechi care nu înțelege configurația automată se conectează direct oriunde rulează, așa că o pagină încărcată prin intrarea tunelului poate eșua în continuare în interiorul aplicației.

Instrumentele de rețea au și ele propriile cauze. O sesiune FTP care se blochează printr-un tunel sau un tethering de telefon este adesea o problemă de mod activ versus pasiv negociată de client, iar nicio setare de proxy nu o va schimba.

Citește configurația, nu comutatorul

Lucrează în această ordine: valoarea de proxy a intrării tunelului, starea PAC și de descoperire automată pe serviciu, apoi tratarea proxy-ului de către aplicație. Oprește-te la prima care diferă de ce ai presupus.

Fiecare caz de aici este o problemă de precedență a configurației. Niciunul nu este tunelul care îți strică instrumentul.