Rutare pe sursă pentru două pool-uri VPN: ce lasă să scape regula dumneavoastră

Două pool-uri de clienți, un gateway și planul pare trivial: o regulă trimite primul pool pe uplink-ul rapid, alta trimite al doilea pool printr-un tunel de partener. Apoi regulile sunt la loc, iar al doilea pool iese în continuare pe ruta implicită. Regula nu este stricată. Sursa pachetului nu este ce aștepta autorul în momentul căutării, pentru că traducerea și căutarea au loc în puncte diferite ale călătoriei aceluiași pachet, iar ordinea este inversul diagramei mentale pe care o desenează majoritatea.

Căutarea are loc înainte ca sursa să fie rescrisă

Pentru un pachet redirecționat de la un client VPN, kernelul execută o secvență fixă. Ajunge pe interfața tunelului, trece prin prerouting unde locuiesc conntrack și DNAT, apoi se ia decizia de rutare, apoi redirecționarea, apoi postrouting unde SNAT se aplică ultimul. O regulă de forma from este consultată în timpul acelei decizii de rutare, adică vede adresa originală a clientului, nu pe cea tradusă.

Așadar adăugarea unei reguli masquerade nu schimbă ce politică se potrivește fluxului de ieșire. Se schimbă ce vede capătul îndepărtat și, prin urmare, ce cale de întoarcere există. Sunt două consecințe diferite, iar recenziile modificărilor le confundă constant. Separați-le și proiectul devine de obicei clar într-un minut.

În direcția răspunsului apare adresa tradusă în reguli. Un pachet care se întoarce la gateway este adresat adresei traduse, iar dacă aveți reguli de politică bazate pe destinație sau pe interfața prin care a intrat, aceea este valoarea pe care o veți potrivi. Aceeași conexiune, o sursă de adevăr diferită în fiecare direcție.

Două pool-uri cu surse diferite au într-adevăr nevoie de tabele diferite, iar proiectul este solid. Ce exclude tabelul de mai sus este scurtătura de a depana uitându-vă la ce a primit site-ul îndepărtat și deducând regula de acolo.

Un test de pe gateway nu este un test al pool-ului

Traficul generat de gateway însuși nu trece niciodată prin prerouting, pentru că nu a ajuns pe o interfață. Este rutat pe calea de ieșire, cu adresa gateway-ului ca sursă, iar o regulă from bazată pe un interval de clienți nu se va potrivi. Fiecare tichet din acest domeniu care spune că merge de pe cutie dar nu de pe client este același fapt repetat.

Simulați clientul în loc să îl aproximați. Căutarea de rutare poate fi întrebată direct, cu o sursă și o interfață de intrare date:

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

Rulați-o o dată pentru fiecare pool. Dacă cele două comenzi returnează aceeași interfață, regulile nu separă pool-urile, iar motivul este fie o regulă lipsă, fie o regulă cu prioritate mai mare care se potrivește ambelor. Dacă returnează interfețe diferite dar clientul tot eșuează, defectul este după căutare și puteți înceta să vă uitați la reguli.

Prioritate, nu poziție în fișier

Regulile sunt evaluate în ordine crescătoare a priorității, iar numărul contează, nu ordinea în care le-ați scris. Tabelul local stă la prioritatea 0, tabelul main la 32766, iar regula implicită la 32767, de aceea o regulă adăugată cu prioritatea implicită ajunge aproape de sfârșitul listei și pierde în fața aproape a tot.

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

O prioritate explicită face ordinea dorită vizibilă în fișier și în recenzie. Împiedică și ca o adăugare ulterioară să sară în liniște în fața unei reguli existente, care este cea mai frecventă cauză pentru care o politică funcțională încetează să funcționeze după o modificare fără legătură.

O regulă potrivită care arată spre un tabel incomplet este cealaltă capcană. Dacă tabelul 201 conține o rută implicită dar nicio rută către destinație, pachetul este aruncat sau trimis în locul greșit, iar regula pare perfect corectă izolat. Citiți tabelul, nu doar regula. O regulă este un indicator, iar un tabel gol este un indicator în nimic.

Calea de întoarcere trebuie să existe totuși

Politica de sursă alege o ieșire. Nu creează o cale de întoarcere. Dacă al doilea pool iese printr-un tunel de partener, partenerul trebuie să știe cum să ajungă la 172.31.8.0/24, fie printr-o rută înapoi la gateway, fie primind adrese traduse pe care le știe deja.

Alegerea între ele este o decizie de proiectare cu consecințe vizibile. Rutarea intervalului de clienți înapoi păstrează identitatea fiecărui client la partener și cere ca acesta să accepte prefixul dumneavoastră. Traducerea ascunde pool-ul în spatele unei singure adrese și cere partenerului să accepte doar acea adresă, cu prețul ca jurnalele dumneavoastră și ale lui să nu mai fie de acord cu privire la cine s-a conectat.

Orice ați alege, scrieți-l lângă definiția pool-ului. O rută de întoarcere care există doar în memoria cuiva este exact genul de lucru care supraviețuiește până când partenerul schimbă un firewall, iar apoi ia o zi să fie reconstruită.

Nu prindeți tunelul propriu al gateway-ului în politică

Regulile pe care le scrieți pentru clienți se aplică și traficului generat de gateway, dacă nu îl excludeți. O regulă largă bazată pe un marcaj sau pe interfața de ieșire poate prinde propria conexiune a gateway-ului la partener, iar atunci tunelul care transportă politica este rutat de politică. Asta produce o buclă sau o întrerupere care arată ca o defecțiune a furnizorului.

Limitați fiecare regulă cât de îngust permite proiectul: prefix de sursă, interfață de intrare și, unde este acceptat, un marcaj pe care îl poartă doar pachetele clienților. Apoi testați conectivitatea gateway-ului însuși după fiecare modificare de reguli, pentru că defecțiunea este autoreferențială și nu apare într-un test de pe client.

Pagina de manual ip-rule documentează semantica selectorului și a priorității. Combinați-o cu un test de căutare pentru fiecare pool și proiectul devine verificabil, ceea ce este diferența dintre rutarea pe politică care rezistă un an și cea pe care toți se tem să o atingă.