Nye forbindelser på en ny VPN-udgang, gamle flows får lov at være

En planlagt dræning flytter kun uklassificerede flows. Sammenlign det med et ruteskift, og se de mærker, tabeller og conntrack-tilstande, der får det til at holde.

To sunde VPN-udgange, én lang upload der allerede kører, og et krav om, at den næste forbindelse bruger den anden tunnel. Der er to måder at opfylde det på, og kun én af dem er sikker på en levende gateway. At skifte standardruten flytter hver pakke, også dem der hører til uploadet. En planlagt dræning ændrer valget for nye forbindelser og lader de sporede flows blive på den vej, de startede på.

To måder at skifte en udgang

Ruteskiftet er én kommando, og det kan rulles tilbage på sekunder, og derfor bruges det under hændelser. Det er også uden skelen: pakker fra det eksisterende upload forlader pludselig en anden tunnel, med en anden offentlig kildeadresse og separat oversættelsestilstand.

Hvis den fjerne ende sporer flows efter kildeadresse, kan uploadet simpelthen holde op med at blive genkendt. Dræningen undgår det ved at træffe beslutningen én gang pr. forbindelse og gemme den, så det gamle upload beholder sin udgang, indtil det er færdigt. Det er hele værdien: den fjerne ende ser ingen ændring, den skal fortolke. Den bliver ved med at modtage pakker, der passer til den forbindelse, den allerede kender.

Prisen er kompleksitet: to routingtabeller, en klassificerer der kører på den rigtige hook, og mærker der skal koordineres med alt andet på maskinen, der bruger dem.

Giv hver udgang sin egen tabel

Reservér en routingtabel pr. udgang og forskellige mærkeværdier eller bits til de to valg. Hver tabel har brug for de ruter, der passer til dens rolle, ikke bare et navn, og den har brug for et bevidst fejlresultat for det manglende tilfælde. En tom tabel, der stille falder igennem til hovedtabellen er måden, trafik forlader gennem en udgang, ingen valgte.

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

Tilføj en blackhole-rute i slutningen af hver tabel, så et opslag uden match fejler højlydt i stedet for at undslippe til en standard, du ikke valgte.

Vælg én gang, ved den første pakke

Klassificér efter at forbindelsessporing findes, og før det ruteopslag, der betyder noget. For en ny, uklassificeret LAN-forbindelse, vælg udgangen og gem den i forbindelsestilstanden. På senere pakker, gendan den gemte værdi i det pakkemærke, som policy routing læser.

Det subtile er, hvad ny betyder. Conntrack kan stadig rapportere NEW for tidlige pakker og genudsendelser, før et svar er set, så en klassificerer, der kun ser på den tilstand, kan overskrive et valg, den allerede har truffet. Kontrollér, at der ikke er gemt nogen udgang for forbindelsen, før du tildeler en.

nftables holder pakke- og forbindelsesmærker adskilt, og vejledningen om metainformation dokumenterer den eksplicitte kopi mellem dem. Et forbindelsesmærke bliver ikke af sig selv det pakkemærke, din regel matcher, og det er den mest almindelige grund til, at en omhyggeligt skrevet klassificerer ingen virkning har.

Begræns genopretningen til den retning og trafik, du mener. Anvendes et internet-udgangsmærke på returpakker, kan svar blive sendt mod udgangen i stedet for LAN, og symptomet er en envejsforbindelse, der ligner et firewallproblem. Læs svarvejen, før du rører en firewallregel, fordi pakken bliver routet, bare ikke tilbage til afsenderen.

Fire faser i en dræning

  1. Forbered B uden at røre A: routing, videresendelse, autorisation, NAT og returvejen. Installér dens tabel og udvælgelsespolitik gennem gatewayens eksisterende konfigurationsejer.

  2. Skift klassificereren, så nye, uklassificerede forbindelser vælger B, mens gemte valg bevares. En atomisk nftables-transaktion undgår et vindue, hvor gammel tilstand skal ryddes.

  3. Lad A være oppe, mens dets flows færdiggøres. Dets interface, tabel, fjerne udgang og NAT-mappinger er stadig en del af de flows, og redigering af en NAT-regel genopbygger ikke bindinger, der allerede findes.

  4. Udtag A, når dræningsbetingelsen er opfyldt, vurderet ud fra forbindelsestilstand og applikationsadfærd snarere end ét roligt interval.

Hvad en dræning ikke kan love

En browseranmodning er ikke en ny transportforbindelse; pooling bliver ved med at sende anmodninger over den gamle. Omvendt kan et UDP-flow ældes ud af conntrack, og en senere pakke klassificeres forfra. Dræningen følger sporede flows, ikke en applikations idé om en session.

Hvis A fejler, før dets flows er færdige, redder det gemte mærke dem ikke. De genopretter forbindelse gennem B, eller de genopretter slet ikke. En planlagt dræning køber kontinuitet, mens den oprindelige vej er sund; det er ikke tilstandsreplikering mellem uafhængige udgange.

Verificér begge halvdele

Start en langvarig tilladt forbindelse før ændringen og en virkelig ny efter. Bekræft, hvilken tunnel hver bruger, og hvilken offentlig kildeadresse den fjerne ende ser, og kontrollér derefter, at returtrafikken kommer tilbage.

Tøm ikke conntrack-tabellen for at få det nye valg til at fremstå. Det ødelægger netop den tilstand, dræningen skal bevare, og det gør en kontrolleret migrering til en afbrydelse med en renset test.

Relaterede artikler