Står proxyn kvar på den gamla tunneladressen efter en VPN-återanslutning?

Att starta om VPN-klienten bevisar bara att tunneln är tillbaka. Det säger ingenting om proxyn som fick order att gå ut genom den. Squid, tinyproxy och de flesta andra vidarebefordrare behåller den lokala källadressen de hittade vid start tills något tvingar dem att ladda om. När en återanslutning delar ut en ny tunneladress misslyckas vidarebefordraren på varje utgående anslutning, eller så börjar den gå ut via din vanliga rutt.

Det andra felet är det farliga: tunneln är uppe, sidorna laddas, och bara uttagsadressen är fel.

Börja med lyssnaren, inte tunneln

Tre adresser är inblandade, och en återanslutning flyttar bara några av dem. Lyssnaren är där din webbläsare pekar, oftast 127.0.0.1 eller en LAN-adress, och den bryr sig inte om att tunneln har ändrats. Den utgående lokala källan är det vidarebefordraren ber kärnan använda när den slår nästa hopp, och den är bunden till tunnelenheten. Den publika uttagen är det en webbserver loggar, och den kan vara en översatt adress flera hopp bort.

En sökning på den publika IP-adressen svarar bara på den sista frågan. Den kan inte säga vilken lokal adress en vidarebefordrare ska binda till, eftersom en enda publik uttag kan dölja flera interna källor. Läs adressen hos den som äger anslutningen: klientens statusutdata, själva gränssnittet eller det namnutrymme där tunneln bor. Att ta det första gränssnittet vars namn ser ut som en tunnel ger fel svar så snart en andra profil finns.

Container- och namnutrymmeslayouter bryter den förutsättningen tyst. En vidarebefordrare i ett nätverksnamnutrymme kan inte binda en tunnel som finns i ett annat, och ingen mängd konfigurationsredigering reparerar det.

Fyra kontroller innan du redigerar något

Gå igenom dem i ordning. Den första kontrollen som misslyckas är där du stannar, eftersom de senare förutsätter att de tidigare gäller.

1. Bekräfta att tunneln som används är den profil som proxyn byggdes kring, inte en andra profil som anslöt av sig själv.
2. Skriv ut adressen som för närvarande finns på enheten och jämför den med adressen i den körande konfigurationen.
3. Fråga vidarebefordraren vilken källa den hittade, i stället för vad filen på disken påstår.
4. Bekräfta att trafiken från vidarebefordraren verkligen omfattas av den routing- och brandväggspolicy du förväntar dig.

Enhetens adress är enkel: ip -4 addr show dev tun0 skriver ut den aktuella, och ip -4 route get 1.1.1.1 visar vilket gränssnitt kärnan skulle välja för det målet. En vidarebefordrare som binder en exakt adress misslyckas högljutt när adressen försvinner. En vidarebefordrare som binder en enhet, eller faller tillbaka på standardkällan, fortsätter att fungera och läcka, och det är det tysta resultatet.

Anpassa dokumentationen till den version du kör, inte till det översta sökresultatet. Squids direktiv för utgående adress är dokumenterat för v7 och tidigare, och v8-dokumentationen säger rakt ut att direktivet inte är tillgängligt där, så ett skript byggt kring det överlever inte den gränsen (se Squid tcp_outgoing_address-referensen). Validera med produktens egen parser innan något laddas om: squid -k parse rapporterar fel och avslutar utan att röra den körande processen.

Numrera varje tunnel och släng föråldrade byten

En återanslutning är en överlämning, och överlämningar behöver en ordning. Märk varje observerad anslutning med en räknare eller tidsstämpel som ökar vid varje lyckad etablering, och bär sedan den markeringen i kandidatkonfigurationen. När markeringen på en kandidat är äldre än den nuvarande, släng kandidaten i stället för att tillämpa den, eftersom en långsam uppdatering skriven för den förra tunneln annars skriver över inställningarna för den nuvarande. Slå ihop skurar av händelser så att en fladdrande länk ger en övergång i stället för femton.

Sätt arbetet i fyra steg: ogiltigförklara det gamla utgångstillståndet, vänta på att anslutningens ägare rapporterar slutförande, bygg bara det hanterade fragmentet, och validera och aktivera sedan via tjänstehanteraren. Att återskapa hela filen från två adressvärden är hur lyssnarbegränsningar, autentisering och destinationspolicy tyst försvinner. Respektera också ett avsiktligt stopp. En hjälpare som fortsätter ringa en tunnel som användaren stängde av är en bugg, inte motståndskraft.

Öppna sockets följer inte den nya adressen

Att konfigurera om vidarebefordraren säger ingenting om anslutningar som redan är etablerade. Om de töms eller dör beror på produkten, så observera beteendet i stället för att anta det.

En begäran som betjänas över en socket som öppnades före bytet går fortfarande ut den gamla vägen, även när den nya konfigurationen är korrekt. Om det spelar roll, bestäm uttryckligen: tillåt ett kort tömningsfönster och sluta ta emot nytt arbete, eller avsluta de gamla socketarna och acceptera felen. Testa sedan med en ny anslutning och håll det resultatet skilt från tömningskontrollen. Källbindning är inte heller en säkerhetsgräns. När trafik aldrig får röra den vanliga rutten, framtvinga det med markeringar och brandväggsregler, DNS och IPv6 inkluderat, så att en misslyckad omladdning lämnar proxyn uttryckligen nere i stället för öppen.

Bevisa den nya uttagen med en ny begäran

Det som räknas är en begäran som öppnas efter aktivering, inte en ping och inte en sida som redan låg i cachen. Be proxyn om en riktig URL och läs uttagsadressen som fjärrsidan rapporterar, och jämför den sedan med klientens egen bild av tunneln när leverantören visar en.

Håll parsningen, omladdningen och begäran som separata kommandon så att ett fel pekar på ett enda steg. De två första ändrar ingenting när de misslyckas, och det är just därför de körs före 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

Om omladdningen misslyckas, stoppa tjänsten och reparera fragmentet; en proxy som betjänar med en föråldrad uttag är värre än ett kort avbrott. Om omladdningen lyckas men den nya begäran fortfarande går ut någonstans oväntat, gå tillbaka till routingkontrollen i stället för att redigera adresser igen. Anteckna tunnelgenerationen du validerade mot, så att nästa återanslutning har något konkret att jämföra med.