Bronroetering vir twee VPN-poele: wat jou reël miskyk

Twee kliëntpoele, een gateway en 'n plan wat eenvoudig lyk: een reël stuur die eerste poel deur die vinnige oplyn, 'n ander stuur die tweede poel deur 'n vennoottonnel. Dan staan die reëls in plek en die tweede poel vertrek steeds via die verstekroete. Die reël is nie stukkend nie. Die pakket se bron is nie wat die skrywer op die oomblik van die opsoek verwag het nie, want vertaling en opsoek vind op verskillende punte in dieselfde pakket se reis plaas, en die volgorde is die teenoorgestelde van die verstandelike diagram wat die meeste mense teken.

Die opsoek gebeur voordat die bron herskryf word

Vir 'n pakket wat vanaf 'n VPN-kliënt aanstuur word, loop die kern 'n vaste volgorde. Dit kom op die tonnelkoppelvlak aan, gaan deur prerouting waar conntrack en DNAT sit, dan word die roetebesluit geneem, dan aanstuur, dan postrouting, waar SNAT laaste toegepas word. 'n Reël van die vorm from word tydens daardie roetebesluit geraadpleeg, wat beteken dit sien die kliënt se oorspronklike adres, nie die vertaalde een nie.

Om 'n masquerade-reël by te voeg, verander dus nie watter beleid by die uitgaande vloei pas nie. Wat dit verander, is wat die ander kant sien, en daarom watter terugpad bestaan. Dit is twee verskillende gevolge, en veranderingsresensies verwar hulle heeltyd. Skei hulle en die ontwerp word gewoonlik binne 'n minuut duidelik.

Die antwoordrigting is waar die vertaalde adres in die reëls opduik. 'n Pakket wat na die gateway terugkom, is aan die vertaalde adres geadresseer, en as jy beleidsreëls het wat op bestemming of op die inkomende koppelvlak gebaseer is, is dit die waarde wat jy sal pas. Dieselfde verbinding, 'n ander bron van waarheid in elke rigting.

Twee poele met verskillende bronne het dus wel verskillende tabelle nodig, en die ontwerp is gesond. Wat die tabel hierbo uitsluit, is die kortpad om te ontfout deur te kyk wat die afgeleë kant ontvang het en daaruit die reël af te lei.

Toets vanaf die gateway is nie 'n toets van die poel nie

Verkeer wat die gateway self genereer, gaan nooit deur prerouting nie, want dit het nie op 'n koppelvlak aangekom nie. Dit word in die uitvoerpad gerouteer, met die gateway se eie adres as bron, en 'n from-reël wat op 'n kliëntreeks gemik is, sal nie pas nie. Elke kaartjie in hierdie area wat sê dat dit van die boks af werk maar nie van die kliënt nie, is daardie feit in ander woorde.

Simuleer die kliënt in plaas daarvan om hom te benader. Die roetebesluit kan direk gevra word, met 'n bron en 'n inkomende koppelvlak bygevoeg:

ip route get 198.51.100.9 from 172.31.7.42 iif tun0
ip route get 198.51.100.9 from 172.31.8.42 iif tun0
ip route show table 201

Voer dit een keer per poel uit. As die twee opdragte dieselfde koppelvlak teruggee, skei die reëls nie die poele nie, en die rede is óf 'n ontbrekende reël óf 'n reël met hoër prioriteit wat albei pas. As hulle verskillende koppelvlakke teruggee maar die kliënt steeds faal, lê die fout stroomaf van die opsoek en kan jy ophou om na reëls te kyk.

Prioriteit, nie posisie in die lêer nie

Reëls word in stygende prioriteitsorde geëvalueer, en die nommer is wat saak maak, nie die volgorde waarin jy hulle getik het nie. Die local-tabel sit op prioriteit 0, die main-tabel op 32766 en die verstekreël op 32767, daarom beland 'n reël wat met die verstekprioriteit bygevoeg is naby die einde van die lys en verloor teen byna alles.

ip rule show
ip rule add from 172.31.8.0/24 lookup 201 priority 1000
ip -4 route show table 201

'n Eksplisiete prioriteit maak die bedoelde volgorde sigbaar in die lêer en in resensie. Dit verhoed ook dat 'n latere byvoeging stilweg voor 'n bestaande reël inspring, wat die algemeenste oorsaak is van 'n werkende beleid wat ná 'n onverwante verandering ophou werk.

'n Passende reël wat na 'n onvolledige tabel wys, is die ander lokval. As tabel 201 'n verstekroete bevat maar geen roete na die bestemming nie, word die pakket laat val of na die verkeerde plek gestuur, en die reël lyk heeltemal korrek in isolasie. Lees die tabel, nie net die reël nie. 'n Reël is 'n wyser, en 'n leë tabel is 'n wyser in niks in.

Die terugpad moet steeds bestaan

Bronbeleid kies 'n uitweg. Dit skep nie 'n terugpad nie. As die tweede poel deur 'n vennoottonnel vertrek, moet die vennoot weet hoe om 172.31.8.0/24 te bereik, hetsy deur 'n roete terug na die gateway of deur vertaalde adresse te ontvang wat hy reeds ken.

Om tussen dié twee te kies is 'n ontwerpbesluit met sigbare gevolge. Om die kliëntreeks terug te routeer behou per-kliënt-identiteit by die vennoot en vereis dat hulle jou prefiks aanvaar. Vertaling versteek die poel agter een adres en vereis dat die vennoot net daardie adres aanvaar, ten koste daarvan dat jou logboeke en hulle s'n nie meer saamstem oor wie gekonnekteer het nie.

Wat jy ook al kies, skryf dit neer langs die poeldefinisie. 'n Terugroete wat net in iemand se geheue bestaan, is presies die soort ding wat oorleef tot die vennoot 'n firewall verander, en dan 'n dag neem om te rekonstrueer.

Moenie die gateway se eie tonnel in die beleid vang nie

Die reëls wat jy vir kliënte skryf, geld ook vir verkeer wat die gateway genereer, tensy jy dit uitsluit. 'n Breë reël wat op 'n merk of op die uitvoerkoppelvlak gemik is, kan die gateway se eie verbinding na die vennoot vang, en dan word die tonnel wat die beleid dra, deur die beleid gerouteer. Dit veroorsaak 'n lus of 'n onderbreking wat soos 'n verskafferfout lyk.

Beperk elke reël so nou as wat die ontwerp toelaat: bronprefiks, inkomende koppelvlak, en waar dit ondersteun word 'n merk wat net kliëntpakkette dra. Toets dan die gateway se eie konnektiwiteit ná elke reëlverandering, want die fout is selfverwysend en wys nie in 'n kliënttoets nie.

Die ip-rule-handleiding dokumenteer die keuse- en prioriteitsemantiek. Kombineer dit met 'n opsoektoets per poel en die ontwerp word natrekbaar, wat die verskil is tussen beleidsroetering wat 'n jaar oorleef en beleidsroetering wat almal bang is om aan te raak.