Smerovanie podľa zdroja pre dva pool-y VPN: čo vaše pravidlo prehliada
Pravidlo tvaru from zodpovedá adrese klienta skôr, než ju SNAT prepíše, a test z brány nezodpovedá ani jednému. Vykonajte vyhľadanie pre každý pool a čítajte priority.
Dve klientske pool-y, jedna brána a plán vyzerá triviálne: jedno pravidlo pošle prvý pool cez rýchly uplink, druhé pošle druhý pool cez partnerský tunel. Potom sú pravidlá na mieste a druhý pool stále odchádza cez predvolenú trasu. Pravidlo nie je pokazené. Zdroj paketu nie je to, čo autor očakával v okamihu vyhľadania, pretože preklad a vyhľadanie prebiehajú v rôznych bodoch cesty toho istého paketu a poradie je opačné než mentálna schéma, ktorú si väčšina kreslí.
Vyhľadanie prebieha skôr, než sa zdroj prepíše
Pre paket preposielaný od klienta VPN jadro vykonáva pevnú postupnosť. Dorazí na rozhranie tunela, prejde cez prerouting, kde žijú conntrack a DNAT, potom sa urobí rozhodnutie o smerovaní, potom preposielanie, potom postrouting, kde sa SNAT aplikuje ako posledný. Pravidlo tvaru from sa konzultuje počas tohto rozhodnutia o smerovaní, takže vidí pôvodnú adresu klienta, nie preloženú.
Pridanie pravidla masquerade teda nemení, ktorá politika zodpovedá odchádzajúcemu toku. Mení to, čo vidí vzdialený koniec, a teda aká spätná cesta existuje. Sú to dva rôzne dôsledky a revízie zmien ich neustále zamieňajú. Oddeľte ich a návrh býva jasný do minúty.
Práve v smere odpovede sa preložená adresa objavuje v pravidlách. Paket vracajúci sa na bránu je adresovaný preloženej adrese, a ak máte pravidlá politiky založené na cieli alebo na rozhraní, ktorým prišiel, je to hodnota, ktorú budete porovnávať. To isté spojenie, v každom smere iný zdroj pravdy.
| 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 |
Dva pool-y s rôznymi zdrojmi teda naozaj potrebujú rôzne tabuľky a návrh je správny. Čo tabuľka vyššie vylučuje, je skratka ladenia pozeraním sa na to, čo vzdialené miesto dostalo, a odvodzovaním pravidla z toho.
Test z brány nie je test pool-u
Prevádzka, ktorú generuje samotná brána, nikdy neprechádza cez prerouting, pretože neprišla na žiadne rozhranie. Smeruje sa vo výstupnej ceste, so zdrojom v podobe vlastnej adresy brány, a pravidlo from založené na rozsahu klientov sa nezhodí. Každý tiket v tejto oblasti, ktorý hovorí, že to z krabice funguje, ale z klienta nie, je len prerozprávaním tohto faktu.
Simulujte klienta namiesto toho, aby ste ho aproximovali. Na vyhľadanie smerovania sa dá opýtať priamo, so zadaným zdrojom a vstupným rozhraním:
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 201Spustite to raz na pool. Ak oba príkazy vrátia rovnaké rozhranie, pravidlá pool-y neoddeľujú a príčinou je buď chýbajúce pravidlo, alebo pravidlo s vyššou prioritou, ktoré vyhovuje obom. Ak vrátia rôzne rozhrania, ale klient stále zlyháva, porucha je až za vyhľadaním a môžete prestať skúmať pravidlá.
Priorita, nie pozícia v súbore
Pravidlá sa vyhodnocujú vo vzostupnom poradí priority a rozhoduje číslo, nie poradie, v akom ste ich napísali. Tabuľka local je na priorite 0, tabuľka main na 32766 a predvolené pravidlo na 32767, preto pravidlo pridané s predvolenou prioritou skončí blízko konca zoznamu a prehrá takmer so všetkým.
ip rule show
ip rule add from 172.31.8.0/24 lookup 201 priority 1000
ip -4 route show table 201Explicitná priorita zviditeľní zamýšľané poradie v súbore aj pri revízii. Tiež bráni tomu, aby neskorší prírastok potichu preskočil existujúce pravidlo, čo je najčastejšia príčina toho, že funkčná politika prestane fungovať po nesúvisiacej zmene.
Zodpovedajúce pravidlo ukazujúce na neúplnú tabuľku je druhá pasca. Ak tabuľka 201 obsahuje predvolenú trasu, ale žiadnu trasu k cieľu, paket sa zahodí alebo odošle na nesprávne miesto, a pravidlo samo osebe vyzerá úplne správne. Čítajte tabuľku, nie len pravidlo. Pravidlo je ukazovateľ a prázdna tabuľka je ukazovateľ do ničoho.
Spätná cesta stále musí existovať
Politika zdroja vyberá výstup. Nevytvára spätnú cestu. Ak druhý pool odchádza cez partnerský tunel, partner musí vedieť, ako sa dostane na 172.31.8.0/24, buď trasou späť na bránu, alebo prijímaním preložených adries, ktoré už pozná.
Voľba medzi tým je návrhové rozhodnutie s viditeľnými dôsledkami. Smerovanie rozsahu klientov späť zachováva identitu každého klienta u partnera a vyžaduje, aby prijal váš prefix. Preklad skryje pool za jednou adresou a vyžaduje, aby partner akceptoval iba túto adresu, za cenu toho, že vaše a jeho záznamy sa už nezhodujú v tom, kto sa pripojil.
Čokoľvek si vyberiete, zapíšte to vedľa definície pool-u. Spätná trasa, ktorá existuje iba v niekoho pamäti, je presne ten typ veci, ktorá prežije, kým partner nezmení firewall, a potom zaberie deň na rekonštrukciu.
Nechytajte vlastný tunel brány do politiky
Pravidlá, ktoré píšete pre klientov, platia aj na prevádzku, ktorú generuje brána, ak ju nevylúčite. Široké pravidlo založené na značke alebo na výstupnom rozhraní môže zachytiť vlastné spojenie brány s partnerom, a potom tunel, ktorý nesie politiku, je smerovaný politikou. To vytvorí slučku alebo výpadok, ktorý vyzerá ako porucha poskytovateľa.
Ohraničte každé pravidlo tak úzko, ako návrh dovolí: prefix zdroja, vstupné rozhranie a tam, kde je to podporované, značka, ktorú nesú iba klientske pakety. Potom po každej zmene pravidiel otestujte vlastnú konektivitu brány, pretože porucha je samoreferenčná a v teste z klienta sa neprejaví.
Manuálová stránka ip-rule dokumentuje sémantiku selektora a priority. Skombinujte ju s testom vyhľadania pre každý pool a návrh sa stane overiteľným, čo je rozdiel medzi politickým smerovaním, ktoré vydrží rok, a tým, na ktoré sa všetci boja siahnuť.