Proxy stadig på den gamle tunneladresse efter en VPN-genopkobling?

Genstart af VPN-klienten beviser kun, at tunnelen er tilbage. Det siger intet om den proxy, der fik besked om at gå ud gennem den. Squid, tinyproxy og de fleste andre forwardere holder den lokale kildeadresse, som de slog op ved opstart, indtil noget tvinger dem til at genindlæse. Når en genopkobling uddeler en ny tunneladresse, fejler forwarderen på hver udgående forbindelse, eller den begynder at gå ud gennem din almindelige rute.

Den anden fejl er den farlige: tunnelen er oppe, siderne indlæses, og kun udgangsadressen er forkert.

Start med lytteren, ikke tunnelen

Tre adresser er i spil, og en genopkobling flytter kun nogle af dem. Lytteren er der, hvor din browser peger, normalt 127.0.0.1 eller en LAN-adresse, og den er ligeglad med, at tunnelen er skiftet. Den udgående lokale kilde er det, forwarderen beder kernen om at bruge, når den ringer til næste hop, og den er bundet til tunneleenheden. Den offentlige udgang er det, en webserver logger, og den kan være en oversat adresse flere hop væk.

Et opslag af offentlig IP besvarer kun det sidste spørgsmål. Det kan ikke fortælle dig, hvilken lokal adresse en forwarder skal binde, fordi én offentlig udgang kan skjule flere interne kilder. Læs adressen hos den, der ejer forbindelsen: klientens statusoutput, selve interfacet eller det namespace, hvor tunnelen bor. At gribe det første interface, hvis navn ligner en tunnel, giver det forkerte svar, så snart der findes en anden profil.

Container- og namespace-opsætninger bryder antagelsen i stilhed. En forwarder i ét netværksnamespace kan ikke binde en tunnel, der findes i et andet, og ingen mængde konfigurationsredigering reparerer det.

Fire kontroller, før du redigerer noget

Gå gennem dem i rækkefølge. Den første kontrol, der fejler, er der, hvor du stopper, fordi de senere forudsætter, at de tidligere holder.

1. Bekræft, at den tunnel, der bruges, er den profil, som proxyen blev bygget omkring, ikke en anden profil, der selv koblede op.
2. Udskriv den adresse, der aktuelt står på den enhed, og sammenlign den med adressen i den kørende konfiguration.
3. Spørg forwarderen, hvilken kilde den slog op, i stedet for hvad filen på disken påstår.
4. Bekræft, at trafik fra forwarderen faktisk er underlagt den rute- og firewallpolitik, du forventer.

Enhedsadressen er nem: ip -4 addr show dev tun0 udskriver den aktuelle, og ip -4 route get 1.1.1.1 viser, hvilket interface kernen ville vælge til den destination. En forwarder, der binder en præcis adresse, fejler højlydt, når adressen forsvinder. En forwarder, der binder en enhed eller falder tilbage til standardkilden, bliver ved med at virke og lække, og det er det stille udfald.

Afstem dokumentationen med den udgave, du kører, ikke med det øverste søgeresultat. Squids direktiv for udgående adresse er dokumenteret for v7 og tidligere, og v8-dokumentationen siger rent ud, at direktivet ikke findes der, så et script bygget omkring det overlever ikke den grænse (se Squid tcp_outgoing_address-referencen). Validér med produktets egen parser, før noget genindlæses: squid -k parse rapporterer fejl og afslutter uden at røre den kørende proces.

Nummerér hver tunnel, og kassér forældede ombytninger

En genopkobling er en overdragelse, og overdragelser kræver en orden. Mærk hver observeret forbindelse med en tæller eller et tidsstempel, der øges ved hver vellykket etablering, og bær derefter mærket med ind i kandidatkonfigurationen. Når mærket på en kandidat er ældre end det aktuelle, skal du kassere kandidaten i stedet for at anvende den, fordi en langsom opdatering skrevet til den forrige tunnel ellers overskriver indstillingerne for den aktuelle. Slå byger af hændelser sammen, så et flagrende link giver én overgang i stedet for femten.

Sæt arbejdet i fire træk: ugyldiggør den gamle udgangstilstand, vent på, at forbindelsens ejer rapporterer fuldførelse, byg kun det administrerede fragment, og validér og aktivér derefter gennem servicemanageren. At genskabe hele filen ud fra to adresseværdier er måden, hvorpå lytterbegrænsninger, godkendelse og destinationspolitik stille forsvinder. Respektér også et bevidst stop. En hjælper, der bliver ved med at ringe til en tunnel, som brugeren har slået fra, er en fejl, ikke robusthed.

Åbne sockets følger ikke den nye adresse

At omkonfigurere forwarderen siger intet om forbindelser, der allerede er etableret. Om de drænes eller dør, afhænger af produktet, så observer adfærden i stedet for at antage den.

En anmodning, der betjenes over en socket åbnet før ombytningen, går stadig ud ad den gamle vej, selv når den nye konfiguration er korrekt. Hvis det betyder noget, skal du beslutte det eksplicit: tillad et kort dræningsvindue og stop med at optage nyt arbejde, eller afslut de gamle sockets og accepter fejlene. Test derefter med en frisk forbindelse, og hold det resultat adskilt fra dræningskontrollen. Kildebinding er heller ikke en sikkerhedsgrænse. Når trafik aldrig må røre den almindelige rute, skal du håndhæve det med mærker og firewallregler, DNS og IPv6 inklusive, så en mislykket genindlæsning efterlader proxyen udtrykkeligt nede i stedet for åben.

Bevis den nye udgang med en frisk anmodning

Det afgørende er en anmodning åbnet efter aktivering, ikke en ping og ikke en side, der allerede var cachet. Bed proxyen om en rigtig URL, og læs den udgangsadresse, den anden ende rapporterer, og sammenlign den med klientens eget syn på tunnelen, når udbyderen viser et.

Hold parsingen, genindlæsningen og anmodningen som separate kommandoer, så en fejl peger på et enkelt trin. De to første ændrer intet, når de fejler, og det er netop derfor, de kører før genstarten.

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

Hvis genindlæsningen fejler, stop tjenesten, og reparér fragmentet; en proxy, der kører med forældet udgang, er værre end et kort afbrud. Hvis genindlæsningen lykkes, men den friske anmodning stadig går ud et uventet sted, skal du vende tilbage til rutekontrollen i stedet for at redigere adresser igen. Notér den tunnelgeneration, du validerede imod, så den næste genopkobling har noget konkret at sammenligne med.