Står proxyen fortsatt på den gamle tunneladressen etter en VPN-gjenoppkobling?

Å starte VPN-klienten på nytt beviser bare at tunnelen er tilbake. Det sier ingenting om proxyen som fikk beskjed om å gå ut gjennom den. Squid, tinyproxy og de fleste andre videresendere holder på den lokale kildeadressen de fant ved oppstart, helt til noe tvinger dem til å laste på nytt. Når en gjenoppkobling deler ut en ny tunneladresse, feiler videresenderen på hver utgående tilkobling, eller den begynner å gå ut gjennom den vanlige ruten din.

Den andre feilen er den farlige: tunnelen er oppe, sider lastes, og bare utgangsadressen er feil.

Start med lytteren, ikke tunnelen

Tre adresser er i spill, og en gjenoppkobling flytter bare noen av dem. Lytteren er der nettleseren din peker, vanligvis 127.0.0.1 eller en LAN-adresse, og den bryr seg ikke om at tunnelen er endret. Den utgående lokale kilden er det videresenderen ber kjernen bruke når den ringer neste hopp, og den er bundet til tunneleenheten. Den offentlige utgangen er det en webserver logger, og den kan være en oversatt adresse flere hopp unna.

Et oppslag på offentlig IP svarer bare på det siste spørsmålet. Det kan ikke fortelle deg hvilken lokal adresse en videresender skal binde til, fordi én offentlig utgang kan skjule flere interne kilder. Les adressen hos den som eier tilkoblingen: klientens statusutdata, selve grensesnittet eller navnerommet der tunnelen bor. Å gripe det første grensesnittet som ser ut som en tunnel, gir feil svar så snart en annen profil finnes.

Container- og navneromsoppsett bryter denne antakelsen stille. En videresender i ett nettverksnavnerom kan ikke binde en tunnel som finnes i et annet, og ingen mengde konfigurasjonsredigering reparerer det.

Fire kontroller før du redigerer noe

Gå gjennom dem i rekkefølge. Den første kontrollen som feiler, er der du stopper, fordi de senere forutsetter at de tidligere holder.

1. Bekreft at tunnelen som brukes, er profilen proxyen ble bygget rundt, ikke en annen profil som koblet til av seg selv.
2. Skriv ut adressen som for øyeblikket står på den enheten, og sammenlign den med adressen i konfigurasjonen som kjører.
3. Spør videresenderen hvilken kilde den fant, i stedet for hva filen på disken påstår.
4. Bekreft at trafikken fra videresenderen faktisk er underlagt den ruting- og brannmurpolitikken du forventer.

Enhetsadressen er enkel: ip -4 addr show dev tun0 skriver ut den gjeldende, og ip -4 route get 1.1.1.1 viser hvilket grensesnitt kjernen ville velge for destinasjonen. En videresender som binder en nøyaktig adresse, feiler høylytt når adressen forsvinner. En videresender som binder en enhet, eller faller tilbake til standardkilden, fortsetter å virke og lekker, og det er det stille resultatet.

Tilpass dokumentasjonen til utgivelsen du kjører, ikke til det øverste søkeresultatet. Squids direktiv for utgående adresse er dokumentert for v7 og tidligere, og v8-dokumentasjonen sier rett ut at direktivet ikke er tilgjengelig der, så et skript bygget rundt det overlever ikke den grensen (se Squid tcp_outgoing_address-referansen). Valider med produktets egen parser før noe lastes på nytt: squid -k parse rapporterer feil og avslutter uten å røre den kjørende prosessen.

Nummerer hver tunnel og forkast utdaterte bytter

En gjenoppkobling er en overlevering, og overleveringer trenger en rekkefølge. Merk hver observerte tilkobling med en teller eller tidsstempel som øker ved hver vellykket etablering, og bær deretter merket med inn i kandidatkonfigurasjonen. Når merket på en kandidat er eldre enn det gjeldende, forkast kandidaten i stedet for å bruke den, fordi en sen oppdatering skrevet for den forrige tunnelen ellers vil overskrive innstillingene for den gjeldende. Slå sammen byger av hendelser slik at en flagrende lenke gir én overgang i stedet for femten.

Sett arbeidet i fire trekk: ugyldiggjør den gamle utgangstilstanden, vent på at eieren av tilkoblingen rapporterer fullføring, bygg bare fragmentet som styres, og valider og aktiver deretter gjennom tjenestebehandleren. Å regenerere hele filen fra to adresseverdier er måten lytterbegrensninger, autentisering og destinasjonspolitikk stille forsvinner på. Respekter også en bevisst stopp. En hjelper som fortsetter å ringe en tunnel brukeren har slått av, er en feil, ikke robusthet.

Åpne sockets følger ikke den nye adressen

Å konfigurere videresenderen på nytt sier ingenting om tilkoblinger som allerede er etablert. Om de tømmes eller dør, avhenger av produktet, så observer atferden i stedet for å anta den.

En forespørsel som betjenes over en socket som ble åpnet før byttet, går fortsatt ut den gamle veien, selv når den nye konfigurasjonen er riktig. Hvis det betyr noe, må du bestemme eksplisitt: tillat et kort tømmevindu og slutt å ta imot nytt arbeid, eller avslutt de gamle socketene og godta feilene. Test deretter med en frisk tilkobling og hold resultatet atskilt fra tømmekontrollen. Kildebinding er heller ikke en sikkerhetsgrense. Når trafikk aldri skal berøre den vanlige ruten, håndhev det med merker og brannmurregler, DNS og IPv6 inkludert, slik at en mislykket omlasting etterlater proxyen uttrykkelig nede i stedet for åpen.

Bevis den nye utgangen med en frisk forespørsel

Det som betyr noe, er en forespørsel som åpnes etter aktivering, ikke en ping og ikke en side som allerede var bufret. Be proxyen om en ekte URL og les utgangsadressen den andre enden rapporterer, og sammenlign den deretter med klientens eget syn på tunnelen når leverandøren viser en.

Hold parsingen, omlastingen og forespørselen som separate kommandoer, slik at en feil peker på ett trinn. De to første endrer ingenting når de feiler, og det er nettopp derfor de kjøres før omstarten.

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 omlastingen feiler, stopp tjenesten og reparer fragmentet; en proxy som betjener med utdatert utgang, er verre enn et kort avbrudd. Hvis omlastingen lykkes, men den friske forespørselen fortsatt går ut et uventet sted, gå tilbake til rutingkontrollen i stedet for å redigere adresser igjen. Noter tunnelgenerasjonen du validerte mot, slik at den neste gjenoppkoblingen har noe konkret å sammenligne med.