Allikapõhine marsruutimine kahele VPN-poolile: mida sinu reegel kahe silma vahele jätab
Reegel kujul from sobib kliendi aadressiga enne, kui SNAT selle ümber kirjutab, ja lüüsilt tehtud test ei sobi kummagagi. Tee otsing iga pooli kohta ja loe selle asemel prioriteete.
Kaks kliendipooli, üks lüüs ja plaan tundub tühine: üks reegel saadab esimese pooli kiirele üleslingile, teine saadab teise pooli partneri tunnelisse. Siis on reeglid paigas ja teine pool väljub ikka vaikimisi marsruudi kaudu. Reegel ei ole katki. Paketi allikas ei ole see, mida autor otsingu hetkel eeldas, sest tõlkimine ja otsing toimuvad sama paketi teekonna eri punktides ning järjekord on vastupidine enamiku joonistatavale mõtteskeemile.
Otsing toimub enne, kui allikas ümber kirjutatakse
VPN-kliendilt edastatava paketi puhul jooksutab kernel fikseeritud järjestust. Pakk saabub tunneliliidesele, läbib preroutingi, kus elavad conntrack ja DNAT, seejärel tehakse marsruudiotus, seejärel edastamine, seejärel postrouting, kus SNAT rakendatakse viimasena. Reeglit kujul from vaadatakse selle marsruudiotuse ajal, mis tähendab, et see näeb kliendi algset aadressi, mitte tõlgitud aadressi.
Nii et masquerade-reegli lisamine ei muuda seda, milline poliitika väljuvale voolule vastab. Muutub see, mida näeb kaugem pool, ja seega see, milline tagasitee olemas on. Need on kaks eri tagajärge ja muudatuste ülevaatused ajavad need pidevalt segi. Eraldage need ja disain muutub tavaliselt minuti jooksul ilmseks.
Tõlgitud aadress ilmub reeglites vastuse suunas. Lüüsile tagasi tulev pakk on adresseeritud tõlgitud aadressile, ja kui teil on poliitikareeglid, mis põhinevad sihtkohal või liidesel, millelt see saabus, siis just seda väärtust te sobitate. Sama ühendus, igas suunas erinev tõeallikas.
| 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 |
Seega vajavad kaks erineva allikaga pooli tõesti eri tabeleid ja disain on terve. Tabel ülal välistab otsetee, kus silumiseks vaadatakse, mida kaugem pool vastu võttis, ja tuletatakse sellest reegel.
Test lüüsilt ei ole pooli test
Lüüsi enda genereeritud liiklus ei läbi kunagi preroutingi, sest see ei saabunud liidesele. See marsruuditakse väljundteel, allikaks lüüsi enda aadress, ja kliendivahemikule seatud from reegel ei sobi. Iga selle valdkonna pilet, mis ütleb, et kastist töötab, aga kliendist mitte, on selle sama fakti kordus.
Simuleerige klienti, selle asemel et seda lähendada. Marsruudiotust saab otse küsida, andes allika ja sisenemisliidese:
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 201Käivitage seda üks kord pooli kohta. Kui kaks käsku tagastavad sama liidese, ei eralda reeglid poole ja põhjus on kas puuduv reegel või mõlemale sobiv kõrgema prioriteediga reegel. Kui need tagastavad erinevad liidesed, aga klient ikka ei tööta, on viga otsingust edasi ja võite reeglite vaatamise lõpetada.
Prioriteet, mitte asukoht failis
Reegleid hinnatakse kasvavas prioriteedijärjekorras ja oluline on number, mitte järjekord, milles te need trükkisite. Tabel local asub prioriteedil 0, tabel main 32766 ja vaikimisi reegel 32767, seepärast satub vaikimisi prioriteediga lisatud reegel nimekirja lõpu lähedale ja kaotab peaaegu kõigele.
ip rule show
ip rule add from 172.31.8.0/24 lookup 201 priority 1000
ip -4 route show table 201Selgesõnaline prioriteet teeb soovitud järjekorra failis ja ülevaatuses nähtavaks. See takistab ka hilisemal lisandusel vaikselt olemasolevast reeglist ette hüpata, mis on kõige tavalisem põhjus, miks töötav poliitika lakkab pärast mitteseotud muudatust töötamast.
Sobiv reegel, mis osutab puudulikule tabelile, on teine lõks. Kui tabel 201 sisaldab vaikimisi marsruuti, aga mitte marsruuti sihtkohta, siis pakk lastakse maha või saadetakse valesse kohta ning reegel näeb isoleeritult täiesti korrektsena välja. Lugege tabelit, mitte ainult reeglit. Reegel on osuti ja tühi tabel on osuti eimiski.
Tagasitee peab ikkagi olemas olema
Allika poliitika valib väljapääsu. See ei loo tagasiteed. Kui teine pool väljub partneri tunnelist, peab partner teadma, kuidas jõuda aadressile 172.31.8.0/24, kas tagasimasruudiga lüüsile või võttes vastu tõlgitud aadresse, mida ta juba teab.
Nende vahel valimine on disainiotsus, millel on nähtavad tagajärjed. Kliendivahemiku tagasi marsruutimine säilitab partneri juures iga kliendi identiteedi ja nõuab, et ta aktsepteeriks teie prefiksit. Tõlkimine peidab pooli ühe aadressi taha ja nõuab, et partner aktsepteeriks ainult seda aadressi, mille hinnaks on see, et teie ja tema logid ei ole enam ühel meelel, kes ühendus.
Mida iganes valite, kirjutage see pooli definitsiooni kõrvale. Tagasitee, mis eksisteerib ainult kellegi mälus, on täpselt see asi, mis püsib, kuni partner muudab tulemüüri, ja võtab siis rekonstrueerimiseks päeva.
Ärge püüdke poliitikasse lüüsi enda tunnelit
Reeglid, mille kirjutate klientidele, kehtivad ka liiklusele, mida lüüs genereerib, kui te seda ei välista. Lai reegel, mis põhineb märgisel või väljundliidesel, võib tabada lüüsi enda ühendust partneriga ja siis marsruuditakse poliitikat kandev tunnel poliitika järgi. See tekitab silmuse või katkestuse, mis näeb välja nagu teenusepakkuja rike.
Piiritlege iga reegel nii kitsalt, kui disain lubab: allika prefiks, sisenemisliides ja kus toetatud, märgis, mida kannavad ainult kliendipaketid. Seejärel testige lüüsi enda ühendust pärast iga reeglimuudatust, sest rike on iseviitav ega ilmne klienditestis.
ip-rule'i manuaalilehekülg dokumenteerib valija ja prioriteedi semantika. Ühendage see iga pooli otsingutestiga ja disain muutub kontrollitavaks, mis on vahe aasta vastu pidava poliitikamarsruutimise ja selle vahel, mida kõik kardavad puutuda.