Ar tarpinė serveris vis dar senajame tunelio adrese po VPN prisijungimo iš naujo?

Prisijungimas iš naujo gali palikti jūsų persiuntėją pririštą prie adreso, kurio tunelis nebevaldo. Keturi eilės tvarka atliekami patikrinimai, sunumeruotas perdavimas ir tikras bandomasis užklausimas.

VPN kliento paleidimas iš naujo įrodo tik tai, kad tunelis grįžo. Jis nieko nesako apie tarpinį serverį, kuriam buvo liepta išeiti per jį. Squid, tinyproxy ir dauguma kitų persiuntėjų laiko vietinį šaltinio adresą, kurį nustatė paleidžiant, kol kažkas priverčia juos įkelti iš naujo. Kai prisijungimas iš naujo suteikia naują tunelio adresą, persiuntėjas arba nepavyksta kiekviename išeinančiame ryšyje, arba pradeda išeiti įprastu maršrutu.

Antroji klaida yra pavojingoji: tunelis veikia, puslapiai kraunasi, o neteisingas tik išėjimo adresas.

Pradėkite nuo klausytojo, o ne nuo tunelio

Žaidime yra trys adresai, o prisijungimas iš naujo perkelia tik kai kuriuos. Klausytojas yra vieta, į kurią nukreipta jūsų naršyklė, paprastai 127.0.0.1 arba LAN adresas, ir jam nerūpi, kad tunelis pasikeitė. Išeinantis vietinis šaltinis yra tai, ko persiuntėjas prašo branduolio naudoti rinkdamasis kitą šuolį, ir jis susietas su tunelio įrenginiu. Viešasis išėjimas yra tai, ką registruoja žiniatinklio serveris, ir tai gali būti išverstas adresas per kelis šuolius.

Viešojo IP paieška atsako tik į paskutinį klausimą. Ji negali pasakyti, prie kurio vietinio adreso persiuntėjas turėtų rištis, nes vienas viešasis išėjimas gali slėpti kelis vidinius šaltinius. Skaitykite adresą iš to, kas valdo ryšį: kliento būsenos išvesties, paties sąsajos arba vardų erdvės, kurioje gyvena tunelis. Paėmus pirmąją sąsają, kurios pavadinimas atrodo kaip tunelis, gaunamas neteisingas atsakymas, kai tik atsiranda antrasis profilis.

Konteinerių ir vardų erdvių išdėstymas tyliai sugriauna šią prielaidą. Persiuntėjas vienoje tinklo vardų erdvėje negali prisirišti prie tunelio, esančio kitoje, ir joks konfigūracijos redagavimas to nepataiso.

Keturi patikrinimai prieš ką nors redaguojant

Atlikite juos iš eilės. Pirmasis nepavykęs patikrinimas yra vieta, kur sustojate, nes vėlesni daro prielaidą, kad ankstesni galioja.

  1. Patvirtinkite, kad naudojamas tunelis yra profilis, aplink kurį buvo sukurtas tarpinis serveris, o ne antrasis profilis, prisijungęs savarankiškai.
  2. Atspausdinkite adresą, kuris šiuo metu yra tame įrenginyje, ir palyginkite jį su adresu veikiančioje konfigūracijoje.
  3. Paklauskite persiuntėjo, kokį šaltinį jis nustatė, o ne ką teigia diske esantis failas.
  4. Patvirtinkite, kad persiuntėjo srautas tikrai pavaldus maršrutizavimo ir ugniasienės politikai, kurios tikitės.

Įrenginio adresas paprastas: ip -4 addr show dev tun0 atspausdina dabartinį, o ip -4 route get 1.1.1.1 parodo, kurią sąsają branduolys pasirinktų tam tikslui. Persiuntėjas, prisirišantis prie tikslaus adreso, garsiai nepavyksta, kai adresas dingsta. Persiuntėjas, prisirišantis prie įrenginio arba grįžtantis prie numatytojo šaltinio, toliau dirba ir nuteka, ir tai yra tylioji baigtis.

Suderinkite dokumentaciją su leidiniu, kurį vykdote, o ne su pirmuoju paieškos rezultatu. Squid išeinančio adreso direktyva dokumentuota v7 ir ankstesnėms versijoms, o v8 dokumentacija aiškiai sako, kad direktyva ten nepasiekiama, todėl ja pagrįstas scenarijus neperžengia šios ribos (žiūrėkite Squid tcp_outgoing_address nuorodą). Patikrinkite paties produkto analizatoriumi prieš ką nors įkeliant iš naujo: squid -k parse praneša apie klaidas ir išeina neliesdamas veikiančio proceso.

Sunumeruokite kiekvieną tunelį ir atmeskite pasenusius keitimus

Prisijungimas iš naujo yra perdavimas, o perdavimui reikia tvarkos. Pažymėkite kiekvieną stebimą ryšį skaitikliu ar laiko žyma, kuri didėja su kiekvienu sėkmingu užmezgimu, tada perneškite tą žymą į kandidato konfigūraciją. Kai kandidato žyma senesnė už dabartinę, atmeskite kandidatą užuot jį pritaikę, nes lėtas atnaujinimas, parašytas ankstesniam tuneliui, kitaip perrašytų dabartinio nustatymus. Sujunkite įvykių pliūpsnius, kad mirksinti jungtis duotų vieną perėjimą, o ne penkiolika.

Sudėliokite darbą į keturis žingsnius: panaikinkite seną išėjimo būseną, palaukite, kol ryšio savininkas praneš apie užbaigimą, sukurkite tik valdomą fragmentą, tada patikrinkite ir aktyvuokite per paslaugų tvarkytuvę. Viso failo atkūrimas iš dviejų adreso reikšmių yra būdas, kuriuo tyliai dingsta klausytojo apribojimai, autentifikavimas ir paskirties politika. Gerbkite ir tyčinį sustabdymą. Pagalbinė programa, kuri toliau skambina į tunelį, kurį naudotojas išjungė, yra klaida, o ne atsparumas.

Atviri lizdai nesekės naujo adreso

Persiuntėjo perkonfigūravimas nieko nesako apie jau užmegztus ryšius. Ar jie išseks, ar žus, priklauso nuo produkto, todėl stebėkite elgseną, o ne darykite prielaidas.

Užklausa, aptarnaujama per lizdą, atidarytą prieš keitimą, vis tiek išeina senu keliu, net kai nauja konfigūracija teisinga. Jei tai svarbu, nuspręskite aiškiai: leiskite trumpą išsekimo langą ir nustokite priimti naują darbą arba uždarykite senus lizdus ir priimkite klaidas. Tada išbandykite su nauju ryšiu ir laikykite tą rezultatą atskirai nuo išsekimo patikrinimo. Šaltinio susiejimas taip pat nėra saugumo riba. Kai srautas niekada neturi liesti įprasto maršruto, priverskite tai žymėmis ir ugniasienės taisyklėmis, įskaitant DNS ir IPv6, kad nepavykęs įkėlimas paliktų tarpinį serverį aiškiai išjungtą, o ne atvirą.

Įrodykite naują išėjimą nauja užklausa

Svarbu tai, kad užklausa būtų atidaryta po aktyvavimo, o ne ping ir ne jau podėlyje esantis puslapis. Paprašykite tarpinio serverio tikro URL ir perskaitykite išėjimo adresą, kurį praneša tolimasis galas, tada palyginkite jį su kliento požiūriu į tunelį, kai tiekėjas jį rodo.

Laikykite analizę, įkėlimą iš naujo ir užklausą atskiromis komandomis, kad nesėkmė rodytų į vieną žingsnį. Pirmieji du nieko nekeičia, kai nepavyksta, ir būtent todėl jie vykdomi prieš paleidimą iš naujo.

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

Jei įkėlimas iš naujo nepavyksta, sustabdykite paslaugą ir pataisykite fragmentą; tarpinis serveris, veikiantis su pasenusiu išėjimu, yra blogiau nei trumpas pertrūkis. Jei įkėlimas pavyko, bet nauja užklausa vis tiek išeina kažkur netikėtai, grįžkite prie maršrutizavimo patikrinimo, o ne vėl redaguokite adresus. Užsirašykite tunelio kartą, pagal kurią tikrinote, kad kitas prisijungimas iš naujo turėtų ką konkretaus palyginti.

Susiję straipsniai