Rutiranje po izvoru za dva VPN pula: šta vaše pravilo propušta
Pravilo oblika from poklapa se s adresom klijenta prije nego što ga SNAT prepiše, a test s gatewaya ne poklapa se ni s jednim. Pokrenite pretraživanje po pulu i čitajte prioritete umjesto toga.
Dva klijentska pula, jedan gateway i plan izgleda trivijalno: jedno pravilo šalje prvi pul kroz brzi uplink, drugo šalje drugi pul kroz partnerski tunel. Zatim su pravila na mjestu, a drugi pul i dalje izlazi preko zadane rute. Pravilo nije pokvareno. Izvor paketa nije ono što je autor očekivao u trenutku pretraživanja, jer se prevođenje i pretraživanje odvijaju na različitim tačkama putovanja istog paketa, a redoslijed je suprotan mentalnoj shemi koju većina ljudi crta.
Pretraživanje se odvija prije nego što se izvor prepiše
Za paket koji se prosljeđuje od VPN klijenta, kernel izvodi fiksni slijed. Paket dolazi na tunelski interfejs, prolazi kroz prerouting gdje žive conntrack i DNAT, zatim se donosi odluka o rutiranju, zatim prosljeđivanje, zatim postrouting, gdje se SNAT primjenjuje posljednji. Pravilo oblika from konsultuje se tokom te odluke o rutiranju, što znači da vidi originalnu adresu klijenta, a ne prevedenu.
Dakle, dodavanje masquerade pravila ne mijenja koja politika odgovara odlaznom toku. Mijenja ono što vidi dalji kraj, a time i koja povratna putanja postoji. To su dvije različite posljedice i pregledi izmjena ih stalno miješaju. Razdvojite ih i dizajn obično postane očigledan u roku od minute.
Prevedena adresa pojavljuje se u pravilima u smjeru odgovora. Paket koji se vraća na gateway adresiran je na prevedenu adresu, i ako imate pravila politike vezana za odredište ili za interfejs s kojeg je došao, to je vrijednost koju ćete upoređivati. Ista veza, različit izvor istine u svakom smjeru.
| 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 pula s različitim izvorima dakle zaista trebaju različite tabele, i dizajn je ispravan. Ono što tabela iznad isključuje jeste prečica da se greška traži gledanjem onoga što je udaljeno odredište primilo i izvlačenjem pravila iz toga.
Test s gatewaya nije test pula
Saobraćaj koji gateway sam generiše nikada ne prolazi kroz prerouting, jer nije stigao na interfejs. Rutira se u izlaznoj putanji, s adresom samog gatewaya kao izvorom, a pravilo from vezano za raspon klijenata neće se poklopiti. Svaki tiket u ovoj oblasti koji kaže da radi s kutije ali ne s klijenta samo je prepričavanje te činjenice.
Simulirajte klijenta umjesto da ga aproksimirate. Odluka o rutiranju može se pitati direktno, uz dostavljen izvor i ulazni interfejs:
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 201Pokrenite to jednom po pulu. Ako dvije komande vrate isti interfejs, pravila ne razdvajaju pulove, a razlog je ili pravilo koje nedostaje ili pravilo višeg prioriteta koje odgovara objema. Ako vrate različite interfejse, a klijent i dalje ne radi, kvar je nizvodno od pretraživanja i možete prestati gledati pravila.
Prioritet, a ne pozicija u datoteci
Pravila se procjenjuju u rastućem redoslijedu prioriteta, a broj je ono što je važno, ne redoslijed kojim ste ih upisali. Tabela local stoji na prioritetu 0, tabela main na 32766, a zadano pravilo na 32767, zato pravilo dodano sa zadanim prioritetom pada blizu kraja liste i gubi od gotovo svega.
ip rule show
ip rule add from 172.31.8.0/24 lookup 201 priority 1000
ip -4 route show table 201Eksplicitni prioritet čini namjeravani redoslijed vidljivim u datoteci i pri pregledu. Također sprječava da kasniji dodatak tiho preskoči postojeće pravilo, što je najčešći uzrok politike koja radi pa prestane raditi nakon nepovezane izmjene.
Podudarno pravilo koje pokazuje na nepotpunu tabelu je druga zamka. Ako tabela 201 sadrži zadanu rutu ali ne i rutu do odredišta, paket se odbacuje ili šalje na pogrešno mjesto, a pravilo izgleda potpuno ispravno izolovano. Čitajte tabelu, ne samo pravilo. Pravilo je pokazivač, a prazna tabela je pokazivač u ništa.
Povratna putanja ipak mora postojati
Politika izvora bira izlaz. Ona ne stvara povratnu putanju. Ako drugi pul izlazi kroz partnerski tunel, partner mora znati kako doći do 172.31.8.0/24, bilo rutom natrag prema gatewayu, bilo primanjem prevedenih adresa koje već poznaje.
Izbor između toga je dizajnerska odluka s vidljivim posljedicama. Rutiranje raspona klijenata natrag čuva identitet svakog klijenta kod partnera i zahtijeva da prihvati vaš prefiks. Prevođenje skriva pul iza jedne adrese i zahtijeva da partner prihvati samo tu adresu, po cijeni da se vaši i njihovi zapisi više ne slažu o tome ko se povezao.
Šta god odaberete, zapišite to uz definiciju pula. Povratna ruta koja postoji samo u nečijem sjećanju upravo je ona vrsta stvari koja preživi dok partner ne promijeni firewall, a zatim oduzme dan za rekonstrukciju.
Ne hvatajte vlastiti tunel gatewaya u politici
Pravila koja pišete za klijente primjenjuju se i na saobraćaj koji gateway generiše, osim ako ga izuzmete. Široko pravilo vezano za oznaku ili za izlazni interfejs može uhvatiti vlastitu vezu gatewaya s partnerom, i tada tunel koji nosi politiku biva rutiran politikom. To stvara petlju ili prekid koji izgleda kao kvar provajdera.
Ograničite svako pravilo što je moguće usklađenije: prefiks izvora, ulazni interfejs i, gdje je podržano, oznaka koju nose samo klijentski paketi. Zatim testirajte vlastitu povezanost gatewaya nakon svake izmjene pravila, jer je kvar samo-referentan i ne pojavljuje se u testu s klijenta.
Stranica priručnika za ip-rule dokumentuje semantiku selektora i prioriteta. Kombinujte je s testom pretraživanja po pulu i dizajn postaje provjerljiv, što je razlika između političkog rutiranja koje preživi godinu i onog koje se svi boje dirati.