Nye samband på ein ny VPN-utgang, gamle flytar får vere i fred

Ein planlagd drenering flyttar berre uklassifiserte flytar. Samanlikn det med eit ruteskifte, og sjå merka, tabellane og conntrack-tilstanden som får det til å halde.

To sunne VPN-utgangar, éin lang opplasting som alt køyrer, og eit krav om at neste samband brukar den andre tunnelen. Det er to måtar å oppfylle det på, og berre éin av dei er trygg på ein levande gateway. Å skifte standardruta flyttar kvar pakke, også dei som høyrer til opplastinga. Ein planlagd drenering endrar valet for nye samband og lèt dei spora flytane bli på vegen dei starta på.

To måtar å skifte ein utgang

Ruteskiftet er éin kommando og kan rullast tilbake på sekund, og difor vert det brukt under hendingar. Det er også utan skilje: pakkar frå den eksisterande opplastinga forlèt plutseleg ein annan tunnel, med ei anna offentleg kjeldeadresse og separat omsetjingstilstand.

Viss den fjerne enden sporer flytar etter kjeldeadresse, kan opplastinga rett og slett slutte å bli kjend att. Dreneringa unngår det ved å ta avgjerda éin gong per samband og lagre henne, slik at den gamle opplastinga held utgangen sin til ho er ferdig. Det er heile verdien: den fjerne enden ser inga endring han må tolke. Han held fram med å ta imot pakkar som passar til sambandet han alt kjenner.

Prisen er kompleksitet: to rutetabellar, ein klassifiserar som køyrer på rett hook, og merke som må koordinerast med alt anna på maskina som brukar dei.

Gje kvar utgang sin eigen tabell

Reserver ein rutetabell per utgang og ulike merkeverdiar eller bitar for dei to vala. Kvar tabell treng rutene som passar til rolla, ikkje berre eit namn, og han treng eit medvite feilresultat for det manglande tilfellet. Ein tom tabell som stille fell gjennom til hovudtabellen — slik forlèt trafikk ein utgang 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

Legg til ei blackhole-rute på slutten av kvar tabell, slik at eit oppslag utan treff feilar høgt i staden for å rømme til ein standard du ikkje valde.

Vel éin gong, ved den fyrste pakken

Klassifiser etter at sambandssporing finst, og før det ruteoppslaget som betyr noko. For eit nytt, uklassifisert LAN-samband, vel utgangen og lagre han i sambandstilstanden. På seinare pakkar, gjenopprett den lagra verdien i pakkemerket som policy-ruting les.

Det subtile er kva ny tyder. Conntrack kan framleis rapportere NEW for tidlege pakkar og gjenutsendingar før eit svar er sett, så ein klassifiserar som berre ser på den tilstanden, kan skrive over eit val han alt har teke. Kontroller at ingen utgang er lagra for sambandet før du tildeler ein.

nftables held pakke- og sambandsmerke åtskilde, og rettleiinga om metainformasjon dokumenterer den eksplisitte kopien mellom dei. Eit sambandsmerke vert ikkje av seg sjølv det pakkemerket som regelen din matchar, og det er den vanlegaste grunnen til at ein nøye skriven klassifiserar ikkje har noka verknad.

Avgrens gjenopprettinga til retninga og trafikken du meiner. Bruk av eit internett-utgangsmerke på returpakkar kan sende svar mot utgangen i staden for LAN, og symptomet er eit einvegssamband som ser ut som eit brannmurproblem. Les svarvegen før du rører ein brannmurregel, fordi pakken vert ruta, berre ikkje tilbake til sendaren.

Fire fasar i ei drenering

  1. Førebu B utan å røre A: ruting, videresending, autorisasjon, NAT og returvegen. Installer tabellen og utvalspolicyen gjennom den eksisterande konfigurasjonseigaren til gatewayen.

  2. Byt klassifiseraren slik at nye, uklassifiserte samband vel B, medan lagra val vert tekne vare på. Ein atomisk nftables-transaksjon unngår eit vindauge der gammal tilstand må ryddast.

  3. Lat A vere oppe medan flytane vert ferdige. Grensesnittet, tabellen, den fjerne utgangen og NAT-mappingane er framleis del av desse flytane, og redigering av ein NAT-regel byggjer ikkje opp att bindingar som alt finst.

  4. Ta A ut når dreneringsvilkåret er oppfylt, vurdert ut frå sambandstilstand og applikasjonsåtferd snarare enn eitt roleg intervall.

Kva ei drenering ikkje kan love

Ein nettlesarførespurnad er ikkje eit nytt transportssamband; samanslåing held fram med å sende førespurnader over den gamle. Omvendt kan ein UDP-flyt eldast ut av conntrack, og ein seinare pakke vert klassifisert på nytt. Dreneringa følgjer spora flytar, ikkje idéen ein applikasjon har om ein sesjon.

Viss A sviktar før flytane er ferdige, bergar ikkje det lagra merket dei. Dei koplar til på nytt gjennom B, eller dei koplar ikkje til i det heile. Ei planlagd drenering kjøper kontinuitet medan den opphavlege vegen er sunn; det er ikkje tilstandsreplikering mellom sjølvstendige utgangar.

Stadfest begge halvdelar

Start eit langvarig tillate samband før endringa og eit verkeleg nytt etter. Stadfest kva tunnel kvar brukar og kva offentleg kjeldeadresse den fjerne enden ser, og kontroller deretter at returtrafikken kjem tilbake.

Ikkje tøm conntrack-tabellen for å få det nye valet til å vise seg. Det øydelegg nett den tilstanden dreneringa skal ta vare på, og det gjer ei kontrollert migrering om til eit avbrot med ein rein test.

Relaterte artiklar