VPN strādā, bet vienai lietotnei nav interneta? Pārbaudiet tās starpniekserveri

Jūsu tunelis ir pacelts, statusa lapa rāda veselīgu handshake, bet viena lietotne joprojām neko neielādē. Šī lietotne, visticamāk, joprojām sūta savus pieprasījumus vecākam starpniekam: sistēmas starpniekserverim, paplašinājumam, ierīču pārvaldības piegrūstam konfigurācijas failam vai starpniekservera mainīgajam, ko lasa tikai tās pašas process. VPN servera maiņa šo iestatījumu neaiztiktu, un tas izskaidro modeli, kurā citas lietotnes darbojas no tās pašas mašīnas. Strādājiet no neveiksmīgās lietotnes uz āru un atstājiet tuneli mierā, līdz starpniekservera jautājums ir atrisināts.

Kurš slānis pārvalda starpniekservera iestatījumu

Četras vietas var pretendēt uz varu pār lietotnes pieprasījumiem, un parasti uzvar šaurākā. Operētājsistēma tur globālu starpniekserveri un neobligātu automātiskās konfigurācijas URL; pārlūkprogramma var tam sekot, to pārrakstīt vai nodot kontroli paplašinājumam; komandrindas rīks lasa savu vidi; un pārvaldīta politika var pēc izmaiņām atkal piespraust jebkuru no iepriekšminētajiem. Izlemiet, kurš slānis ir atbildīgs, pirms kaut ko rediģējat, jo nepareizā slāņa notīrīšana izskatās kā veiksmīgs labojums, kas atgriežas nākamajā pieteikšanās reizē.

Salīdziniet divas lietotnes tajā pašā parastajā tīmekļa vietnē, nevis testa lapā, kas paredzēta tikai VPN. Ja pārlūkprogramma neizdodas, bet lejupielāde terminālī izdodas, operētājsistēma nav problēma, un atšķirība ir pārlūkprogrammas profilā vai tās paplašinājumos. Ja abas neizdodas, bet otrs lietotāja konts tajā pašā mašīnā izdodas, iestatījums ir katram lietotājam. Šis salīdzinājums maksā minūti un novērš lielāko daļu minējumu.

Izlasiet vērtību, ko katrs rīks patiešām izmanto

Izdrukājiet konfigurāciju pirms tās maiņas un nokopējiet precīzo starpniekservera virkni vietā, no kuras varat to atjaunot. Shell mainīgie ir ātrākā komandrindas rīku pārbaude, jo VPN klients tos parasti atstāj neskartus.

env | grep -i -E 'http_proxy|https_proxy|all_proxy|no_proxy'
scutil --proxy
gsettings get org.gnome.system.proxy mode
netsh winhttp show proxy

Palaidiet tikai to rindu, kas atbilst platformai jums priekšā, pēc tam lasiet izvadi par resursdatoru, portu un akreditācijas datiem. Šāda vērtība kā http://proxy.corp.example:8080 nozīmē, ka rīks katram pieprasījumam jautā šim resursdatoram, savukārt tukšs rezultāts nozīmē, ka tas iet tieši un īstā kļūda ir citur. Pirms izvades ielīmēšanas biļetē aizklājiet lietotāja un paroles daļu, jo šīs virknes daudz biežāk ir dzīvi akreditācijas dati, nekā cilvēki pieņem.

Rīkiem ar savu starpniekservera dzinēju vajag savus pierādījumus. Curl paziņo lēmumu, ko pieņēma, kad palielināt detalizāciju, un tas ir labāk nekā minēt no vides, un tas pats karodziņš parāda, vai vārdu izšķiršana notika lokāli vai starpniekserverī.

Notīriet pārrakstīšanu un vēlreiz pārbaudiet to pašu pieprasījumu

Mainiet vienu slāni, pēc tam atkārtojiet tieši to pieprasījumu, kas neizdevās, jo cits URL neko nepierāda. Vispirms notīriet vides mainīgos pašreizējā shell, jo šī izmaiņa ir atgriežama un nevar salauzt tuneli:

unset http_proxy https_proxy all_proxy
curl -v --max-time 10 https://example.com 2>&1 | grep -i -E 'uses proxy|connected to|http/'

Ja detalizētā izvade joprojām apgalvo, ka ir starpniekserveris, vide nebija vara. Pacelieties vienu līmeni augstāk, nevis kraujiet vairāk pārrakstīšanu.

macOS pārbaudiet, vai automātiskais konfigurācijas fails nepiegādā vērtību, pēc tam izslēdziet pakalpojuma starpniekserveri un apstipriniet izmaiņu. Windows atcerieties, ka WinHTTP iestatījums un katram lietotājam paredzētais pārlūkprogrammas iestatījums ir dažādi objekti, tāpēc tīrs komandrindas rīks var pastāvēt līdzās pārlūkprogrammai, kas joprojām norāda uz vecu serveri. Paplašinājumi ir pelnījuši tādas pašas aizdomas: starpniekservera paplašinājums var pārrakstīt pieprasījumus tikai vienam profilam, un tā ir tieši tāda kļūdas forma, kas skar vienu pārlūkprogrammu un neko citu.

Pārbaudiet, vai labojums pārdzīvo pārstartēšanu

Iestatījums, kas darbojas tikai terminālī, kuru rediģējāt, nav labots. Atveriet lietotni no jauna no darbvirsmas palaidēja, izlogojieties un ielogojieties vēlreiz, un vērojiet, vai vecais starpniekserveris atgriežas.

Divi pārbaudes nošķir īstu labojumu no pagaidu, un abām jāziņo par tiešu savienojumu vai paredzēto vērtību. Palaišana tīrā vidē parāda, vai attīrīts process joprojām pārņem sistēmas iestatījumu.

env -i /usr/bin/curl -sS -o /dev/null -w '%{http_code} %{remote_ip}
' https://example.com
networksetup -getwebproxy "Wi-Fi"

Ja vecā vērtība atgriežas pēc pārstartēšanas, avots ir pārvaldīta politika vai profils, kas to atkal piemēro, un šīs politikas īpašniekam ir jānoņem izņēmums. Atstājiet sertifikātu pārbaudi ieslēgtu visu laiku, jo starpniekserveris, kas pārtver satiksmi, citādi izskatīsies atrisināts, tiklīdz izslēgsiet pārbaudes. Nobeigumā pierakstiet noņemto vērtību un datumu savos pierakstos, lai nākamais cilvēks varētu atšķirt apzinātu starpniekserveri no aizmirsta.