Nya anslutningar på en ny VPN-utgång, gamla flöden lämnas i fred

En planerad dränering flyttar bara oklassificerade flöden. Jämför det med ett routebyte och se markeringarna, tabellerna och conntrack-tillståndet som får det att hålla.

Två friska VPN-utgångar, en lång uppladdning som redan körs och kravet att nästa anslutning använder den andra tunneln. Det finns två sätt att uppfylla det, och bara ett av dem är säkert på en levande gateway. Att byta standardrutt flyttar varje paket, även de som hör till uppladdningen. En planerad dränering ändrar valet för nya anslutningar och låter de spårade flödena stanna på den väg de började på.

Två sätt att byta en utgång

Routebytet är ett enda kommando och kan rullas tillbaka på sekunder, därför används det vid incidenter. Det är också urskillningslöst: paket från den befintliga uppladdningen lämnar plötsligt en annan tunnel, med en annan offentlig källadress och separat översättningstillstånd.

Om den bortre änden spårar flöden efter källadress kan uppladdningen helt enkelt sluta kännas igen. Dräneringen undviker det genom att fatta beslutet en gång per anslutning och spara det, så den gamla uppladdningen behåller sin utgång tills den är klar. Det är hela värdet: den bortre änden ser ingen förändring som den måste tolka. Den fortsätter att ta emot paket som matchar anslutningen den redan känner till.

Priset är komplexitet: två routingtabeller, en klassificerare som körs på rätt hook och markeringar som måste samordnas med allt annat på maskinen som använder dem.

Ge varje utgång sin egen tabell

Reservera en routingtabell per utgång och olika markeringsvärden eller bitar för de två valen. Varje tabell behöver de rutter som passar dess roll, inte bara ett namn, och den behöver ett medvetet felutfall för det saknade fallet. En tom tabell som tyst faller igenom till huvudtabellen — så lämnar trafiken en utgång som ingen valde.

ip rule add fwmark 0x10/0x10 table 101
ip rule add fwmark 0x20/0x20 table 102
ip route add default via 192.0.2.1 dev wg-a table 101
ip route add default via 198.51.100.1 dev wg-b table 102

Lägg till en blackhole-rutt i slutet av varje tabell så att en sökning utan träff misslyckas högljutt i stället för att fly till en standard du inte valde.

Välj en gång, vid det första paketet

Klassificera efter att anslutningsspårning finns och före den rutsökning som spelar roll. För en ny, oklassificerad LAN-anslutning, välj utgången och spara den i anslutningstillståndet. På senare paket, återställ det sparade värdet i den paketmarkering som policy-routing läser.

Det subtila är vad ny betyder. Conntrack kan fortfarande rapportera NEW för tidiga paket och omsändningar innan ett svar syns, så en klassificerare som bara tittar på det tillståndet kan skriva över ett val den redan gjort. Kontrollera att ingen utgång är sparad för anslutningen innan du tilldelar en.

nftables håller paket- och anslutningsmarkeringar åtskilda, och guiden om metainformation dokumenterar den uttryckliga kopian mellan dem. En anslutningsmarkering blir inte av sig själv den paketmarkering som din regel matchar, och det är den vanligaste orsaken till att en noggrant skriven klassificerare inte har någon verkan.

Begränsa återställningen till den riktning och trafik du menar. Att tillämpa en internet-utgångsmarkering på returpaket kan skicka svar mot utgången i stället för mot LAN, och symptomet är en enkelriktad anslutning som ser ut som ett brandväggsproblem. Läs svarsvägen innan du rör en brandväggsregel, eftersom paketet routas, bara inte tillbaka till avsändaren.

Fyra faser i en dränering

  1. Förbered B utan att röra A: routing, vidarebefordran, auktorisering, NAT och returvägen. Installera dess tabell och urvalspolicy genom gatewayens befintliga konfigurationägare.

  2. Byt klassificeraren så att nya, oklassificerade anslutningar väljer B, medan sparade val bevaras. En atomär nftables-transaktion undviker ett fönster där gammalt tillstånd måste rensas.

  3. Låt A vara uppe medan dess flöden slutförs. Dess gränssnitt, tabell, bortre utgång och NAT-mappningar är fortfarande en del av de flödena, och att redigera en NAT-regel bygger inte om bindningar som redan finns.

  4. Ta ur A när dräneringsvillkoret är uppfyllt, bedömt utifrån anslutningstillstånd och applikationsbeteende snarare än ett enda lugnt intervall.

Vad en dränering inte kan lova

En webbläsarförfrågan är inte en ny transportanslutning; poolning fortsätter skicka förfrågningar över den gamla. Omvänt kan ett UDP-flöde åldras ur conntrack och ett senare paket klassificeras på nytt. Dräneringen följer spårade flöden, inte en applikations idé om en session.

Om A fallerar innan dess flöden är klara räddar den sparade markeringen dem inte. De återansluter via B, eller de återansluter inte alls. En planerad dränering köper kontinuitet medan den ursprungliga vägen är frisk; det är inte tillståndsreplikering mellan oberoende utgångar.

Verifiera båda halvorna

Starta en långvarig tillåten anslutning före ändringen och en verkligt ny efter. Bekräfta vilken tunnel var och en använder och vilken offentlig källadress den bortre änden ser, kontrollera sedan att returtrafiken kommer tillbaka.

Töm inte conntrack-tabellen för att få det nya valet att synas. Det förstör precis det tillstånd som dräneringen ska bevara, och det gör en kontrollerad migrering till ett avbrott med ett rent utseende test.

Relaterade artiklar