Šaltinio maršrutizavimas dviem VPN telkiniams: ką praleidžia jūsų taisyklė
from formos taisyklė atitinka kliento adresą prieš SNAT jį perrašant, o testas iš gateway neatitinka nė vieno. Atlikite paiešką kiekvienam telkiniui ir skaitykite prioritetus.
Du klientų telkiniai, viena gateway ir planas atrodo trivialus: viena taisyklė išleidžia pirmą telkinį per greitą uplink, kita išleidžia antrą per partnerio tunelį. Tada taisyklės vietoje, o antras telkinys vis tiek išeina numatytuoju maršrutu. Taisyklė nesugedusi. Paketo šaltinis nėra tai, ko autorius tikėjosi paieškos metu, nes vertimas ir paieška vyksta skirtinguose to paties paketo kelionės taškuose, o tvarka priešinga tam proto diagramai, kurią dauguma piešia.
Paieška įvyksta anksčiau, nei šaltinis perrašomas
Paketui, perduodamam iš VPN kliento, branduolys atlieka fiksuotą seką. Jis patenka į tunelio sąsają, praeina prerouting, kur gyvena conntrack ir DNAT, tada priimamas maršrutizavimo sprendimas, tada perdavimas, tada postrouting, kur SNAT taikomas paskutinis. from formos taisyklė tikrinama to maršrutizavimo sprendimo metu, tai reiškia ji mato pradinį kliento adresą, o ne išverstą.
Taigi masquerade taisyklės pridėjimas nekeičia, kuri politika atitinka išeinantį srautą. Keičiasi tai, ką mato tolimasis galas, ir dėl to, koks grįžtamasis kelias egzistuoja. Tai dvi skirtingos pasekmės, ir pakeitimų apžvalgos nuolat jas painioja. Atskirkite jas ir dizainas paprastai paaiškėja per minutę.
Būtent atsakymo kryptimi išverstas adresas pasirodo taisyklėse. Paketas, grįžtantis į gateway, adresuotas išverstam adresui, ir jei turite politikos taisykles pagal paskirties vietą ar sąsają, per kurią jis atėjo, tai ta reikšmė ir bus lyginama. Ta pati jungtis, kiekviena kryptimi kitas tiesos šaltinis.
| Stage | Source the kernel sees | What it means for your rule |
|---|---|---|
| Prerouting | Client address, 172.31.7.42 | Where marks and DNAT are applied |
| Routing decision | Still 172.31.7.42 | This is where from rules match |
| Postrouting | Becomes 198.51.100.9 | What the far end and its return route see |
Taigi du telkiniai su skirtingais šaltiniais tikrai reikalauja skirtingų lentelių, ir dizainas teisingas. Tai, ką aukščiau pateikta lentelė atmeta, yra apėjimo būdas derinti žiūrint, ką gavo tolimoji svetainė, ir iš to numatyti taisyklę.
Testas iš gateway nėra telkinio testas
Srautas, kurį generuoja pats gateway, niekada nepraeina prerouting, nes jis neatvyko į sąsają. Jis maršrutizuojamas išėjimo kelyje, kaip šaltinį naudojant paties gateway adresą, o klientų diapazonui pritaikyta from taisyklė nesutaps. Kiekvienas šios srities bilietas, sakantis, kad iš dėžės veikia, o iš kliento ne, yra to paties fakto pakartojimas.
Imituokite klientą, o ne aproksimuokite jį. Maršrutizavimo paieškos galima klausti tiesiogiai, nurodžius šaltinį ir įėjimo sąsają:
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 201Paleiskite tai kartą kiekvienam telkiniui. Jei abi komandos grąžina tą pačią sąsają, taisyklės neskiria telkinių, o priežastis yra arba trūkstama taisyklė, arba abiem tinkanti aukštesnio prioriteto taisyklė. Jei jos grąžina skirtingas sąsajas, bet klientas vis tiek nepavyksta, klaida yra po paieškos ir galite nustoti žiūrėti taisykles.
Prioritetas, o ne vieta faile
Taisyklės vertinamos didėjančia prioriteto tvarka, ir svarbus yra skaičius, o ne eilė, kuria jas įvedėte. local lentelė yra 0 prioriteto, main lentelė – 32766, o numatytoji taisyklė – 32767, todėl su numatytuoju prioritetu pridėta taisyklė atsiduria prie sąrašo pabaigos ir pralaimi beveik viskam.
ip rule show
ip rule add from 172.31.8.0/24 lookup 201 priority 1000
ip -4 route show table 201Aiškus prioritetas padaro numatytą tvarką matomą faile ir peržiūroje. Jis taip pat neleidžia vėlesniam papildymui tyliai aplenkti esamos taisyklės, o tai yra dažniausia priežastis, kodėl veikianti politika nustoja veikti po nesusijusio pakeitimo.
Atitinkanti taisyklė, rodanti į nepilną lentelę, yra kiti spąstai. Jei 201 lentelėje yra numatytasis maršrutas, bet nėra maršruto į paskirties vietą, paketas išmetamas arba siunčiamas ne ten, o taisyklė atskirai atrodo visiškai teisinga. Skaitykite lentelę, ne tik taisyklę. Taisyklė yra rodyklė, o tuščia lentelė yra rodyklė į nieką.
Grįžtamasis kelias vis tiek turi egzistuoti
Šaltinio politika pasirenka išėjimą. Ji nesukuria grįžtamojo kelio. Jei antras telkinys išeina per partnerio tunelį, partneris turi žinoti, kaip pasiekti 172.31.8.0/24, arba grįžimo maršrutu į gateway, arba gaudamas išverstus adresus, kuriuos jau žino.
Pasirinkimas tarp jų yra dizaino sprendimas su matomomis pasekmėmis. Klientų diapazono maršrutizavimas atgal išsaugo kiekvieno kliento tapatybę pas partnerį ir reikalauja, kad jis priimtų jūsų prefiksą. Vertimas paslepia telkinį už vieno adreso ir reikalauja, kad partneris priimtų tik tą adresą, už tai, kad jūsų ir jų žurnalai nebesutaria, kas prisijungė.
Kad ir ką pasirinktumėte, užrašykite tai šalia telkinio apibrėžimo. Grįžimo maršrutas, egzistuojantis tik kieno nors atmintyje, yra būtent tai, kas išlieka tol, kol partneris pakeičia ugniasienę, o paskui užima dieną atkurti.
Nepagaukite paties gateway tunelio politikoje
Taisyklės, kurias rašote klientams, galioja ir srautui, kurį generuoja gateway, nebent jį išskirtumėte. Plati taisyklė pagal žymę arba išėjimo sąsają gali pagauti paties gateway ryšį su partneriu, ir tada tunelis, kuris neša politiką, yra maršrutizuojamas politikos. Tai sukuria kilpą arba triktį, kuri atrodo kaip tiekėjo gedimas.
Apribokite kiekvieną taisyklę kiek įmanoma siauriau: šaltinio prefiksas, įėjimo sąsaja ir, kur palaikoma, žymė, kurią neša tik klientų paketai. Tada po kiekvieno taisyklių pakeitimo patikrinkite paties gateway ryšį, nes gedimas yra savireferentinis ir nepasireiškia kliento teste.
ip-rule vadovo puslapis dokumentuoja selektoriaus ir prioriteto semantiką. Sujunkite jį su paieškos testu kiekvienam telkiniui ir dizainas tampa tikrinamas, o tai yra skirtumas tarp metus išliekančio politikos maršrutizavimo ir to, kurio visi bijo liesti.