Novaj konektoj sur nova VPN-elirejo, malnovaj fluoj restas netuŝitaj

Planita drenado movas nur neklasigitajn fluojn. Komparu tion kun itinrera anstataŭigo, kaj vidu la markojn, tabelojn kaj conntrack-staton, kiuj tenas ĝin.

Du sanaj VPN-elirejoj, unu longa alŝuto jam kuranta, kaj postulo, ke la sekva konekto uzu la alian tunelon. Estas du manieroj plenumi tion, kaj nur unu el ili estas sekura sur viva enirejo. Anstataŭigi la defaŭltan itineron movas ĉiun paketon, inkluzive de tiuj, kiuj apartenas al la alŝuto. Planita drenado ŝanĝas la elekton por novaj konektoj, lasante la spuritajn fluojn sur la vojo, kie ili komenciĝis.

Du manieroj ŝanĝi elirejon

La itinrera anstataŭigo estas unu komando kaj reigebla en sekundoj, tial ĝi uziĝas dum incidentoj. Ĝi ankaŭ estas sendistinga: pakaĵoj de la ekzistanta alŝuto subite eliras tra alia tunelo, kun alia publika fontadreso kaj aparta traduka stato.

Se la malproksima fino spuras fluojn laŭ fontadreso, la alŝuto eble simple ĉesos esti rekonebla. La drenado evitas tion farante la decidon unufoje por konekto kaj konservante ĝin, do la malnova alŝuto tenas sian elirejon ĝis ĝi finiĝas. Tio estas la tuta valoro de la ekzerco: la malproksima fino vidas neniun ŝanĝon, kiun ĝi devus interpreti. Ĝi daŭre ricevas pakaĵojn, kiuj kongruas kun la konekto, kiun ĝi jam konas.

La kosto estas komplekseco: du enkursigaj tabeloj, klasifikilo, kiu ruliĝas ĉe la ĝusta hoko, kaj markoj, kiuj devas esti kunordigitaj kun ĉio alia en la maŝino, kiu uzas ilin.

Donu al ĉiu elirejo sian propran tabelon

Rezervu enkursigan tabelon por elirejo kaj distingajn markvalorojn aŭ bitojn por la du elektoj. Ĉiu tabelo bezonas la itinerojn taŭgajn al sia rolo, ne nur nomon, kaj ĝi bezonas intencan malsukcesan rezulton por la mankanta kazo. Malplena tabelo, kiu silente falas en la ĉefan tabelon — tiel trafiko eliras tra elirejo, kiun neniu elektis.

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

Aldonu blackhole-itineron ĉe la fino de ĉiu tabelo, por ke serĉo sen kongruo malsukcesu laŭte anstataŭ eskapi al defaŭlto, kiun vi ne elektis.

Elektu unufoje, ĉe la unua pakaĵo

Klasifiku post kiam ekzistas konekta spurado kaj antaŭ la itinrera serĉo, kiu gravas. Por nova, neklasigita LAN-konekto, elektu la elirejon kaj konservu ĝin en la konekta stato. Sur postaj pakaĵoj, restarigu la konservitan valoron en la pakaĵan markon, kiun legas politika enkursigado.

La subtila parto estas, kion signifas nova. Conntrack ankoraŭ povas raporti NEW por fruaj pakaĵoj kaj resendoj antaŭ ol vidiĝas respondo, do klasifikilo, kiu baziĝas nur sur tiu stato, povas superskribi elekton, kiun ĝi jam faris. Kontrolu, ke neniu elirejo estas konservita por la konekto antaŭ ol atribui unu.

nftables tenas pakaĵajn kaj konektajn markojn aparte, kaj la gvidilo pri metainformoj dokumentas la eksplicitan kopion inter ili. Konekta marko mem ne fariĝas la pakaĵa marko, kun kiu kongruas via regulo, kaj tio estas la plej ofta kialo, ke zorgeme skribita klasifikilo havas neniun efikon.

Limigu restarigon al la direkto kaj trafiko, kiujn vi celas. Apliki interretan elirejmarkon al returniĝantaj pakaĵoj povas sendi respondojn al la elirejo anstataŭ al la LAN, kaj la simptomo estas unudirekta konekto, kiu aspektas kiel fajroŝirma problemo. Legu la respondan vojon antaŭ ol tuŝi fajroŝirman regulon, ĉar la pakaĵo estas enkursigata, nur ne reen al la sendinto.

Kvar fazoj de drenado

  1. Preparu B sen tuŝi A: enkursigado, plusendado, rajtigo, NAT kaj la revena vojo. Instalu ĝian tabelon kaj selektan politikon per la ekzistanta konfigura posedanto de la enirejo.

  2. Ŝanĝu la klasifikilon, por ke novaj, neklasigitaj konektoj elektu B, konservante la konservitajn elektojn. Atoma nftables-transakcio evitas fenestron, en kiu la malnova stato devas esti purigita.

  3. Lasu A funkcii, dum ĝiaj fluoj finiĝas. Ĝia interfaco, tabelo, malproksima elirejo kaj NAT-mapoj ankoraŭ estas parto de tiuj fluoj, kaj redakti NAT-regulon ne rekonstruas ligojn, kiuj jam ekzistas.

  4. Retiru A, kiam la drenada kondiĉo plenumiĝas, juĝita laŭ konekta stato kaj aplikaĵa konduto, ne laŭ unu kvieta intervalo.

Kion drenado ne povas promesi

Retumila peto ne estas nova transporta konekto; kunfandado daŭre sendas petojn tra la malnova. Inverse, UDP-fluo povas maljuniĝi el conntrack kaj posta pakaĵo klasifikiĝas denove. La drenado sekvas spuritajn fluojn, ne la ideon de aplikaĵo pri seanco.

Se A fiaskas antaŭ ol ĝiaj fluoj finiĝas, la konservita marko ne savas ilin. Ili rekonektiĝas tra B, aŭ ili tute ne rekonektiĝas. Planita drenado aĉetas kontinuecon dum la origina vojo estas sana; ĝi ne estas stata reproduktado inter sendependaj elirejoj.

Kontrolu ambaŭ duonojn

Startigu longdaŭran permesitan konekton antaŭ la ŝanĝo kaj vere novan post ĝi. Konfirmu, kiun tunelon ĝi uzas kaj kiun publikan fontadreson la malproksima fino vidas, poste kontrolu, ke la revena trafiko revenas.

Ne malplenigu la conntrack-tabelon por igi la novan elekton aperi. Tio detruas ĝuste tiun staton, kiun la drenado devas konservi, kaj ĝi transformas kontrolitan migradon en interrompon kun puraspekta testo.

Rilataj artikoloj