A qëndron proxy-ja ende në adresën e vjetër të tunelit pas rilidhjes së VPN-së?

Rinisja e klientit VPN dëshmon vetëm se tuneli u kthye. Nuk thotë asgjë për proxy-në të cilës iu tha të dilte përmes tij. Squid, tinyproxy dhe shumica e përcjellësve të tjerë mbajnë adresën burimore lokale që zbuluan në nisje, derisa diçka t'i detyrojë të rimbushen. Kur një rilidhje jep një adresë të re tuneli, përcjellësi ose dështon në çdo lidhje dalëse, ose fillon të dalë përmes rrugës suaj të zakonshme.

Dështimi i dytë është ai i rrezikshmi: tuneli është lart, faqet ngarkohen dhe vetëm adresa e daljes është e gabuar.

Filloni nga dëgjuesi, jo nga tuneli

Tre adresa janë në lojë, dhe një rilidhje lëviz vetëm disa prej tyre. Dëgjuesi është vendi ku tregon shfletuesi juaj, zakonisht 127.0.0.1 ose një adresë LAN, dhe nuk i intereson që tuneli ka ndryshuar. Burimi lokal dalës është ajo që përcjellësi i kërkon kernelit të përdorë kur zgjedh hopin tjetër, dhe është i lidhur me pajisjen e tunelit. Dalja publike është ajo që regjistron një server web, dhe mund të jetë një adresë e përkthyer disa hops larg.

Një kërkim i IP-së publike përgjigjet vetëm pyetjes së fundit. Nuk mund t'ju thotë se në cilën adresë lokale duhet të lidhet një përcjellës, sepse një dalje publike e vetme mund të fshehë disa burime të brendshme. Lexojeni adresën nga ai që zotëron lidhjen: dalja e statusit të klientit, vetë ndërfaqja ose hapësira e emrave ku jeton tuneli. Marrja e ndërfaqes së parë që duket si tunel jep përgjigjen e gabuar sapo ekziston një profil i dytë.

Planimetritë e kontejnerëve dhe hapësirave të emrave e thyejnë këtë supozim në heshtje. Një përcjellës në një hapësirë emrash rrjeti nuk mund të lidhet me një tunel që ekziston në një tjetër, dhe asnjë sasi e redaktimit të konfigurimit nuk e rregullon atë.

Katër kontrolle përpara se të redaktoni çdo gjë

Kryejini me radhë. Kontrolli i parë që dështon është vendi ku ndaleni, sepse të mëvonshmit supozojnë që të mëparshmit vlejnë.

1. Konfirmoni që tuneli në përdorim është profili rreth të cilit u ndërtua proxy-ja, jo një profil i dytë që u lidh vetë.
2. Printo adresën që ndodhet aktualisht në atë pajisje dhe krahasoje me adresën në konfigurimin që punon.
3. Pyetni përcjellësin se çfarë burimi zbuloi, jo çfarë pretendon skedari në disk.
4. Konfirmoni që trafiku nga përcjellësi i nënshtrohet vërtet politikës së rrugëtimit dhe të murit të zjarrit që prisni.

Adresa e pajisjes është e lehtë: ip -4 addr show dev tun0 printon atë aktuale, dhe ip -4 route get 1.1.1.1 tregon cilën ndërfaqe do të zgjidhte kernel-i për atë destinacion. Një përcjellës që lidh një adresë të saktë dështon me zë kur adresa zhduket. Një përcjellës që lidh një pajisje, ose kthehet te burimi i parazgjedhur, vazhdon të punojë dhe rrjedh, dhe ky është rezultati i heshtur.

Përputhni dokumentacionin me botimin që ekzekutoni, jo me rezultatin e parë të kërkimit. Direktiva e adresës dalëse e Squid është dokumentuar për v7 dhe më herët, dhe dokumentacioni i v8 thotë qartë se direktiva nuk është e disponueshme atje, ndaj një skript i ndërtuar rreth saj nuk e kalon atë kufi (shihni referencën Squid tcp_outgoing_address). Vërtetoni me analizuesin e vetë produktit përpara se të rimbushet ndonjë gjë: squid -k parse raporton gabime dhe del pa prekur procesin që punon.

Numëroni çdo tunel dhe hidhni ndërrimet e vjetruara

Një rilidhje është një dorëzim, dhe dorëzimet kanë nevojë për rend. Shënoni çdo lidhje të vëzhguar me një numërues ose vulë kohe që rritet në çdo vendosje të suksesshme, pastaj mbani atë shenjë brenda konfigurimit kandidat. Kur shenja e një kandidati është më e vjetër se ajo aktuale, hidheni kandidatin në vend që ta aplikoni, sepse një përditësim i ngadaltë i shkruar për tunelin e mëparshëm do të mbishkruante ndryshe cilësimet e atij aktual. Bashkoni shpërthimet e ngjarjeve në mënyrë që një lidhje që dridhet të prodhojë një kalim në vend të pesëmbëdhjetë.

Renditni punën në katër lëvizje: anuloni gjendjen e vjetër të daljes, prisni që pronari i lidhjes të raportojë përfundimin, ndërtoni vetëm fragmentin e menaxhuar, pastaj vërtetoni dhe aktivizoni përmes menaxherit të shërbimeve. Rigjenerimi i të gjithë skedarit nga dy vlera adrese është mënyra se si kufizimet e dëgjuesit, vërtetimi dhe politika e destinacionit zhduken në heshtje. Respektoni edhe një ndalesë të qëllimshme. Një ndihmës që vazhdon të thërrasë një tunel që përdoruesi e fiku është një defekt, jo rezistencë.

Soketat e hapura nuk do të ndjekin adresën e re

Rikonfigurimi i përcjellësit nuk thotë asgjë për lidhjet e vendosura tashmë. Nëse zbrazen ose vdesin varet nga produkti, ndaj vëzhgoni sjelljen në vend që ta supozoni.

Një kërkesë e shërbyer përmes një sockete të hapur para ndërrimit del ende nga rruga e vjetër, edhe kur konfigurimi i ri është i saktë. Nëse kjo ka rëndësi, vendosni në mënyrë eksplicite: lejoni një dritare të shkurtër zbrazjeje dhe ndaloni pranimin e punës së re, ose mbyllni soketat e vjetra dhe pranoni gabimet. Pastaj provoni me një lidhje të re dhe mbajeni atë rezultat të ndarë nga kontrolli i zbrazjes. Lidhja me burimin gjithashtu nuk është kufi sigurie. Kur trafiku nuk duhet të prekë kurrë rrugën e zakonshme, imponojeni me shenja dhe rregulla muri të zjarrit, duke përfshirë DNS dhe IPv6, që një rimbushje e dështuar ta lërë proxy-në në mënyrë eksplicite poshtë në vend të hapur.

Provoni daljen e re me një kërkesë të re

Ajo që ka rëndësi është një kërkesë e hapur pas aktivizimit, jo një ping dhe jo një faqe që ishte tashmë në cache. Kërkoni nga proxy-ja një URL të vërtetë dhe lexoni adresën e daljes që raporton skaji i largët, pastaj krahasojeni me pamjen e klientit për tunelin kur ofruesi shfaq një të tillë.

Mbajini analizën, rimbushjen dhe kërkesën si komanda të ndara, që një dështim të tregojë një hap të vetëm. Dy të parat nuk ndryshojnë asgjë kur dështojnë, dhe pikërisht për këtë ekzekutohen para rinisjes.

squid -k parse
sudo squid -k reconfigure
curl -x http://127.0.0.1:3128 -sS -o /dev/null -w '%{http_code} %{remote_ip}\n' https://example.com

Nëse rimbushja dështon, ndaloni shërbimin dhe rregulloni fragmentin; një proxy që shërben me një dalje të vjetruar është më keq se një ndërprerje e shkurtër. Nëse rimbushja ka sukses, por kërkesa e re del ende diku e papritur, kthehuni te kontrolli i rrugëtimit në vend që të redaktoni përsëri adresat. Shënoni gjeneratën e tunelit ndaj të cilit vërtetuat, që rilidhja tjetër të ketë diçka konkrete për të krahasuar.