Atkļūdošanas starpniekserveris kļūst akls, kad pieslēdzas uzņēmuma VPN

Jūsu starpniekserverī nekas nav mainījies. Tunela ieraksts nes savus iestatījumus, pārvaldīts PAC var atgriezties, un daži klienti sistēmas starpniekserveri vispār nelasa.

Uzņemšanas rīks strādā visu rītu, tunelis pieslēdzas, un tas apklust. Atvienojiet, un tas atkal sāk darboties. Pirmā doma ir, ka VPN sabojāja starpniekserveri, bet starpniekservera konfigurācijā patiesībā nekas nav mainījies. Mainījies ir tas, kādu konfigurāciju tagad lasa lietojumprogrammas: tunela ieraksts var nest savus starpniekservera iestatījumus, pārvaldīts profils var atkal ieslēgt automātisko konfigurāciju, un dažas izpildlaika vides lasa tikai daļu no tā, ko piedāvā operētājsistēma. Izlasiet vērtību katram savienojumam, pirms aiztiekat globālo.

Windows glabā starpniekserveri katram savienojumam

Interneta opcijās ir divi slāņi, kas dialogā izskatās vienādi. Vietējā tīkla iestatījumi attiecas uz parasto vietējo savienojumu, bet zvanu vai VPN ieraksts glabā savu kopiju HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Connections ceļā kā bināru vērtību. Zināmo globālo reģistra vērtību rakstīšana šo kopiju neatjaunina.

Tieši tā rīks darbojas pareizi pirms pieslēgšanās un nepareizi pēc tam, bez nekādām redzamām izmaiņām tā iestatījumos. Dialogs, kurā jūs skatījāties, bija vietējā tīkla panelis. Tas bija pareizs, un tas bija nebūtisks. Ieraksts, ko Windows faktiski izmantoja, bija tas, kas izveidots tunelim.

Atbalstītais veids, kā mainīt vienu ierakstu, ir WinINET savienojuma opciju API: aizpildiet INTERNET_PER_CONN_OPTION_LIST ar savienojuma nosaukumu, karodziņiem, starpniekservera adresi un apiešanas sarakstu, piemērojiet to un pēc tam atsvaidziniet. Ātrai pārbaudei atveriet paša tunela ieraksta iestatījumu dialogu un salīdziniet tā starpniekservera paneli ar vietējā tīkla paneli; atšķirība parasti ir acīmredzama, tiklīdz zināt, kur skatīties.

Pārvaldīts PAC var pats atkal ieslēgties

Operētājsistēmā macOS automātiskās starpniekservera konfigurācijas skripts un automātiskā starpniekservera atklāšana ir tīkla pakalpojuma, nevis mašīnas īpašības. Konfigurācijas profils var tos pieprasīt, tāpēc tie atkal parādās pēc atzīmes noņemšanas, un pēc tam katrs pieprasījums tiek sūtīts uz to starpniekserveri, kuru izvēlas skripts.

Pārbaudiet un, ja esat pilnvarots, izslēdziet šos divus slēdžus pakalpojumam, kas pārvieto datplūsmu:

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

Izmantojiet īsto pakalpojuma nosaukumu, nevis minējumu. Klēpjdatoram ar gan bezvadu tīklu, gan USB Ethernet adapteri ir divi šādi pakalpojumi, un tikai viens pārvieto jūsu datplūsmu. scutil --proxy izdrukā pašreizējā primārā pakalpojuma vērtības. Salīdziniet šo izvadi ar to, ko rediģējāt, pirms secināt, ka profils ir uzvarējis.

Vērsiet rīku uz īsto augšupēju

Ja skripts satur uzņēmuma starpniekserveri, izlasiet to un ievadiet to pašu adresi kā ārējo starpniekserveri uzņemšanas rīka iekšienē. Tad rīks pārsūta uz īsto augšupēju, ko uzņēmuma starpniekserveris arī sagaida, un tas paliek pieprasījuma ceļā, nevis cīnās ar politiku.

Tas ir gājiens, kas jūs notur atkļūdošanā, nevis pārkonfigurēšanā.

Iebīdiet starpniekserveri tunelī

Klients, kura pamatā ir OpenVPN, var pieņemt starpniekservera opcijas, kas stājas spēkā pēc tuneļa pacelšanas, kas ir ērti, ja maršruti ir klienta pārziņā:

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

Tās izmantos tikai klienti, kas šo opciju ievēro, un tā cieti ieraksta jūsu klausīšanās portu profilā. Uzskatiet to par laboratorijas ērtību, nevis ieviešanas standartu, jo nākamā profila nosūtīšana to noņems.

Daži klienti nekad nelasa sistēmas starpniekserveri

Firefox glabā savus starpniekservera iestatījumus, tāpēc tas dažkārt turpina uzņemšanu, kad pārlūks ar sistēmas starpniekserveri to vairs nedara. Vecāks .NET klients, kas nesaprot automātisko konfigurāciju, pieslēdzas tieši, lai kur tas arī darbotos, tāpēc lapa, kas ielādēta caur tunela ierakstu, lietojumprogrammas iekšienē tomēr var neizdoties.

Tīkla rīkiem ir arī savi iemesli. FTP sesija, kas karājas pāri tunelim vai tālruņa tetheringam, bieži ir aktīvā pret pasīvo režīmu problēma, par ko vienojas klients, un neviens starpniekservera iestatījums to nemainīs.

Lasiet konfigurāciju, nevis slēdzi

Strādājiet šādā secībā: paša tunela ieraksta starpniekservera vērtība, PAC un automātiskās atklāšanas stāvoklis katram pakalpojumam, tad pašas lietojumprogrammas starpniekservera apstrāde. Apstājieties pie pirmā, kas atšķiras no jūsu pieņēmuma.

Katrs gadījums šeit ir konfigurācijas prioritātes problēma. Neviens nav tunelis, kas lauztu jūsu rīku.

Saistītie raksti