Proxy-ul este încă pe adresa veche a tunelului după reconectarea VPN?

Repornirea clientului VPN dovedește doar că tunelul a revenit. Nu spune nimic despre proxy-ul căruia i s-a spus să iasă prin el. Squid, tinyproxy și majoritatea celorlalte redirectoare păstrează adresa sursă locală pe care au rezolvat-o la pornire până când ceva le obligă să reîncarce. Când o reconectare oferă o adresă nouă de tunel, redirectorul fie eșuează la fiecare conexiune de ieșire, fie începe să iasă prin ruta ta obișnuită.

A doua defecțiune este cea periculoasă: tunelul funcționează, paginile se încarcă și doar adresa de ieșire este greșită.

Începe cu ascultătorul, nu cu tunelul

Sunt trei adrese în joc, iar o reconectare mută doar unele dintre ele. Ascultătorul este locul spre care indică browserul tău, de obicei 127.0.0.1 sau o adresă LAN, și nu-i pasă că tunelul s-a schimbat. Sursa locală de ieșire este ceea ce redirectorul cere nucleului să folosească atunci când formează următorul salt, iar ea este legată de dispozitivul tunelului. Ieșirea publică este ceea ce înregistrează un server web și poate fi o adresă tradusă la câteva salturi distanță.

O căutare a IP-ului public răspunde doar la ultima întrebare. Nu îți poate spune la ce adresă locală ar trebui să se lege un redirector, deoarece o singură ieșire publică poate ascunde mai multe surse interne. Citește adresa de la cel care deține conexiunea: ieșirea de stare a clientului, interfața însăși sau spațiul de nume în care trăiește tunelul. A lua prima interfață al cărei nume arată ca un tunel dă răspunsul greșit de îndată ce există un al doilea profil.

Aranjamentele de containere și spații de nume încalcă în tăcere această presupunere. Un redirector dintr-un spațiu de nume de rețea nu se poate lega de un tunel care există în altul, iar nicio cantitate de editare a configurației nu repară asta.

Patru verificări înainte de a edita ceva

Parcurge-le în ordine. Prima verificare care eșuează este locul unde te oprești, pentru că cele ulterioare presupun că cele anterioare sunt valabile.

1. Confirmă că tunelul folosit este profilul în jurul căruia a fost construit proxy-ul, nu un al doilea profil care s-a conectat singur.
2. Tipărește adresa care este acum pe dispozitivul respectiv și compară-o cu adresa din configurația care rulează.
3. Întreabă redirectorul ce sursă a rezolvat, în loc de ce susține fișierul de pe disc.
4. Confirmă că traficul de la redirector este într-adevăr supus politicii de rutare și de firewall pe care o aștepți.

Adresa dispozitivului este simplă: ip -4 addr show dev tun0 o tipărește pe cea curentă, iar ip -4 route get 1.1.1.1 arată ce interfață ar alege nucleul pentru destinația respectivă. Un redirector care leagă o adresă exactă eșuează zgomotos când adresa dispare. Un redirector care leagă un dispozitiv sau revine la sursa implicită continuă să funcționeze și să scurgă, iar acesta este rezultatul tăcut.

Potrivește documentația cu versiunea pe care o rulezi, nu cu primul rezultat al căutării. Directiva de adresă de ieșire a Squid este documentată pentru v7 și versiunile anterioare, iar documentația v8 spune clar că directiva nu este disponibilă acolo, așa că un script construit în jurul ei nu supraviețuiește acelei granițe (vezi referința Squid tcp_outgoing_address). Validează cu parserul produsului însuși înainte de a reîncărca ceva: squid -k parse raportează erori și iese fără să atingă procesul care rulează.

Numerotează fiecare tunel și aruncă schimburile învechite

O reconectare este o predare, iar predările au nevoie de o ordine. Marchează fiecare conexiune observată cu un contor sau o marcă de timp care crește la fiecare stabilire reușită, apoi du acea marcă în configurația candidat. Când marca de pe un candidat este mai veche decât cea curentă, aruncă candidatul în loc să îl aplici, pentru că o actualizare lentă scrisă pentru tunelul anterior ar suprascrie altfel setările celui curent. Unește rafalele de evenimente astfel încât o legătură care oscilează să producă o singură tranziție în loc de cincisprezece.

Ordonează munca în patru mișcări: invalidează starea veche de ieșire, așteaptă ca proprietarul conexiunii să raporteze finalizarea, construiește doar fragmentul administrat, apoi validează și activează prin managerul de servicii. Regenerarea întregului fișier din două valori de adresă este modul în care restricțiile ascultătorului, autentificarea și politica de destinație dispar în tăcere. Respectă și o oprire deliberată. Un ajutor care continuă să formeze un tunel pe care utilizatorul l-a oprit este un defect, nu o reziliență.

Socketele deschise nu vor urma noua adresă

Reconfigurarea redirectorului nu spune nimic despre conexiunile deja stabilite. Dacă se golesc sau mor depinde de produs, așa că observă comportamentul în loc să îl presupui.

O cerere servită printr-un socket deschis înainte de schimbare iese încă pe calea veche, chiar și când noua configurație este corectă. Dacă asta contează, decide explicit: permite o fereastră scurtă de golire și oprește acceptarea de lucru nou, sau închide socketele vechi și acceptă erorile. Apoi testează cu o conexiune nouă și ține rezultatul separat de verificarea golirii. Nici legarea de sursă nu este o graniță de securitate. Când traficul nu trebuie să atingă niciodată ruta obișnuită, impune asta cu marcaje și reguli de firewall, inclusiv DNS și IPv6, astfel încât o reîncărcare eșuată să lase proxy-ul explicit oprit, nu deschis.

Dovedește noua ieșire cu o cerere nouă

Ce contează este o cerere deschisă după activare, nu un ping și nu o pagină deja din cache. Cere proxy-ului un URL real și citește adresa de ieșire pe care o raportează capătul îndepărtat, apoi compară-o cu viziunea clientului asupra tunelului când furnizorul expune una.

Ține analiza, reîncărcarea și cererea ca comenzi separate, astfel încât o defecțiune să indice un singur pas. Primele două nu schimbă nimic când eșuează, și exact de aceea rulează înainte de repornire.

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

Dacă reîncărcarea eșuează, oprește serviciul și repară fragmentul; un proxy care servește cu o ieșire învechită este mai rău decât o întrerupere scurtă. Dacă reîncărcarea reușește dar cererea nouă iese în continuare undeva neașteptat, întoarce-te la verificarea rutării în loc să editezi din nou adrese. Notează generația tunelului față de care ai validat, ca următoarea reconectare să aibă ceva concret de comparat.