Nye forbindelser på en ny VPN-utgang, gamle flyter får være i fred

En planlagt drenering flytter bare uklassifiserte flyter. Sammenlign det med et rutebytte, og se merkene, tabellene og conntrack-tilstanden som får det til å holde.

To sunne VPN-utganger, én lang opplasting som allerede kjører, og et krav om at neste forbindelse bruker den andre tunnelen. Det er to måter å oppfylle det på, og bare én av dem er trygg på en levende gateway. Å bytte standardruten flytter hver pakke, også de som hører til opplastingen. En planlagt drenering endrer valget for nye forbindelser og lar de sporede flytene bli på veien de startet på.

To måter å bytte en utgang

Rutebyttet er én kommando og kan rulles tilbake på sekunder, og derfor brukes det under hendelser. Det er også uten skille: pakker fra den eksisterende opplastingen forlater plutselig en annen tunnel, med en annen offentlig kildeadresse og separat oversettelsestilstand.

Hvis den fjerne enden sporer flyter etter kildeadresse, kan opplastingen rett og slett slutte å bli gjenkjent. Dreneringen unngår det ved å ta beslutningen én gang per forbindelse og lagre den, slik at den gamle opplastingen beholder utgangen sin til den er ferdig. Det er hele verdien: den fjerne enden ser ingen endring den må tolke. Den fortsetter å motta pakker som passer til forbindelsen den allerede kjenner.

Prisen er kompleksitet: to rutetabeller, en klassifiserer som kjører på riktig hook, og merker som må koordineres med alt annet på maskinen som bruker dem.

Gi hver utgang sin egen tabell

Reserver en rutetabell per utgang og ulike merkeverdier eller biter for de to valgene. Hver tabell trenger rutene som passer til rollen, ikke bare et navn, og den trenger et bevisst feilresultat for det manglende tilfellet. En tom tabell som stille faller gjennom til hovedtabellen — slik forlater trafikk en utgang 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

Legg til en blackhole-rute på slutten av hver tabell, slik at et oppslag uten treff feiler høylytt i stedet for å unnslippe til en standard du ikke valgte.

Velg én gang, ved den første pakken

Klassifiser etter at forbindelsessporing finnes, og før det ruteoppslaget som betyr noe. For en ny, uklassifisert LAN-forbindelse, velg utgangen og lagre den i forbindelsestilstanden. På senere pakker, gjenopprett den lagrede verdien i pakkemerked som policy-ruting leser.

Det subtile er hva ny betyr. Conntrack kan fortsatt rapportere NEW for tidlige pakker og gjenutsendelser før et svar er sett, så en klassifiserer som bare ser på den tilstanden, kan overskrive et valg den allerede har tatt. Kontroller at ingen utgang er lagret for forbindelsen før du tildeler en.

nftables holder pakke- og forbindelsesmerker atskilt, og veiledningen om metainformasjon dokumenterer den eksplisitte kopien mellom dem. Et forbindelsesmerke blir ikke av seg selv det pakkemerked som regelen din matcher, og det er den vanligste grunnen til at en nøye skrevet klassifiserer ikke har noen virkning.

Begrens gjenopprettingen til retningen og trafikken du mener. Bruk av et internett-utgangsmerke på returpakker kan sende svar mot utgangen i stedet for LAN, og symptomet er en enveisforbindelse som ser ut som et brannmurproblem. Les svarveien før du rører en brannmurregel, fordi pakken blir rutet, bare ikke tilbake til avsenderen.

Fire faser i en drenering

  1. Forbered B uten å røre A: ruting, videresending, autorisasjon, NAT og returveien. Installer tabellen og utvalgspolicyen gjennom gatewayens eksisterende konfigurasjonseier.

  2. Bytt klassifisereren slik at nye, uklassifiserte forbindelser velger B, mens lagrede valg bevares. En atomisk nftables-transaksjon unngår et vindu der gammel tilstand må ryddes.

  3. La A være oppe mens flytene fullføres. Grensesnittet, tabellen, den fjerne utgangen og NAT-mappingene er fortsatt en del av disse flytene, og redigering av en NAT-regel bygger ikke opp igjen bindinger som allerede finnes.

  4. Ta A ut når dreneringsbetingelsen er oppfylt, vurdert ut fra forbindelsestilstand og applikasjonsatferd snarere enn ett rolig intervall.

Hva en drenering ikke kan love

En nettleserforespørsel er ikke en ny transportforbindelse; sammenslåing fortsetter å sende forespørsler over den gamle. Omvendt kan en UDP-flyt eldes ut av conntrack, og en senere pakke klassifiseres på nytt. Dreneringen følger sporede flyter, ikke en applikasjons idé om en sesjon.

Hvis A svikter før flytene er ferdige, redder ikke det lagrede merket dem. De kobler til på nytt gjennom B, eller de kobler ikke til i det hele tatt. En planlagt drenering kjøper kontinuitet mens den opprinnelige veien er sunn; det er ikke tilstandsreplikering mellom uavhengige utganger.

Verifiser begge halvdeler

Start en langvarig tillatt forbindelse før endringen og en virkelig ny etter. Bekreft hvilken tunnel hver bruker og hvilken offentlig kildeadresse den fjerne enden ser, og kontroller deretter at returtrafikken kommer tilbake.

Ikke tøm conntrack-tabellen for å få det nye valget til å vises. Det ødelegger nettopp den tilstanden dreneringen skal bevare, og det gjør en kontrollert migrering om til et avbrudd med en ren test.

Relaterte artikler