Dostizanje udaljene /24 mreže kroz tunel: NETMAP, DNAT ili ruta?
Mapirajte cijeli prefiks NETMAP-om, dodajte DNAT pravila po hostu ili rutirajte stvarni raspon, pa odlučite prema tome šta druga strana mora vidjeti i ko smije započeti saobraćaj.
Do podmreže iza krajnje tačke tunela možete doći na tri načina, a minuta prikupljanja činjenica obično eliminiše dva. Činjenice su: da li serveri tamo moraju razlikovati korisnike, hoće li se ikad neko odatle javiti prema vašem rasponu i ko smije uređivati ruter na drugoj strani. Odgovorite na ta tri i dizajn se sam bira. Ostalo pretpostavlja da vi upravljate krajnjom tačkom i smijete uređivati njen firewall.
Tri opcije i šta svaka od njih zapravo mijenja
Mapiranje prefiksa, DNAT po hostu i rutirani prefiks svi prenose pakete između ista dva raspona, ali mijenjaju različite stvari. Mapiranje izmišlja alias raspon i aritmetički prepisuje adrese u letu. Pravila po hostu takođe prepisuju, samo što se svaka destinacija imenuje ručno. Rutirani prefiks ne prepisuje ništa: paketi zadržavaju stvarne adrese i obje strane se slažu gdje te adrese žive.
| What the far side needs | Prefix mapping | Per-host DNAT | Routed prefix |
|---|---|---|---|
| Users visible to its logs | Only without source NAT | Same condition | Yes, unchanged |
| To start a connection toward you | No, alias is local | No, same reason | Yes, both ends route |
| To absorb a new host | Yes, arithmetic only | No, one rule per address | Yes, it simply routes |
| To require no config change | Yes, with source NAT | Yes, same condition | No, it needs a route back |
Počnite eliminaciju sa druge strane, gdje je ograničenja najteže mijenjati. Ako server tamo upisuje adrese klijenata u logove, provjerava ih prema listi dozvoljenih ili ih predaje drugom sistemu, prevođenje izvora uništava njegov jedini identifikator. Ako se druga strana takođe mora javljati, prevođenje potpuno otpada, jer tamo niko ne zna da alias postoji. Tek kada druga strana samo odgovara na zahtjeve, jeftinije opcije postaju sigurne.
Parovi prefiksa i zašto veličine moraju odgovarati
NETMAP je meta nat tabele koja radi na paru prefiksa iste dužine. Unutra nema tabele po adresi: skida prefiks, zadržava bitove hosta i pripaja ih novom prefiksu, zato se /24 mapira na /24 i nikada na /25. Položaj određuje smjer: podudaranje destinacije u PREROUTING-u prepisuje kuda paket ide, a podudaranje izvora u POSTROUTING-u prepisuje odakle je došao.
Host na 192.168.2.17 se vašim klijentima prikazuje kao 10.50.1.17, a posljednji oktet nije ukras — to je isti broj na obje strane. Dodajte sutra host na 192.168.2.40 i njegov alias je 10.50.1.40, bez pravila za uređivanje.
Klijentima i dalje treba ruta za alias raspon koja pokazuje na vašu kutiju, osim ako alias pada u podmrežu koju već dosežu. Gateway ne treba rutu za alias, jer se prevođenje destinacije izvodi u PREROUTING-u, prije pretrage rute. Prosljeđivanje takođe mora biti uključeno, inače kernel odbacuje paket nakon prepisivanja. Tri komande ispod su cijela postavka na gatewayu u stilu Debiana sa klijentima na br0, aliasom na 10.50.1.0/24 i tunelom na tun0.
sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A PREROUTING -i br0 -d 10.50.1.0/24 -j NETMAP --to 192.168.2.0/24
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADEOdgovor mora sam pronaći put nazad
Prepisivanje destinacije samo određuje gdje će paket biti dostavljen. Server na drugoj strani i dalje mora odgovoriti na adresu koju može dosegnuti, a postoje dva načina da se to uredi. Prevedite izvor da se odgovori vraćaju na vašu kutiju ili ostavite izvor na miru i dajte drugoj strani rutu za raspon klijenata.
Maskiranje na izlazu je kraći put: jedno pravilo u POSTROUTING-u i druga strana vidi adresu vašeg tunela, pa joj ne treba vlastita ruta. Cijena je da se svi korisnici stapaju u jednu adresu i logovi po korisniku prestaju nešto značiti. Ostavljanje izvora netaknutim čuva tu informaciju, ali onda udaljeno mjesto mora slati odgovore za raspon klijenata natrag kroz tunel. Na OpenVPN serveru to je poslano push "route 10.50.9.0 255.255.255.0", plus red route 192.168.2.0 255.255.255.0.
Skupa greška je uraditi pola svakog. Ako maskirate dio saobraćaja dok druga strana takođe nosi povratnu rutu za drugi saobraćaj, odgovori stižu na interfejs gdje zapis praćenja konekcija nikada nije viđen. Klijent prijavljuje istek vremena za zahtjev koji je server zabilježio kao uslužen. Oba smjera toka moraju proći kroz istu netfilter instancu: jedan gateway prevodi, a ne dva firewall-a u seriji.
conntrack -L -d 10.50.1.17
iptables -t nat -L PREROUTING -v -nPročitajte zapis u oba smjera: originalni tuple zadržava vaš alias na destinaciji, dok tuple odgovora nosi stvarnu adresu. Ako tuple odgovora nedostaje, problem je povratni put, a ne pravilo. Ako se brojači PREROUTING-a nikada nisu pomjerili, paket nikada nije stigao do te kuke.
Sudari i pretraga koja se izvodi prva
Dva različita raspona mogu se sudariti i oba kvara izgledaju kao pokvaren tunel, a ne kao loše pravilo. Alias koji izmislite mora biti nekorišten duž cijelog puta, a stvarni raspon druge strane ne smije već postojati na vašoj mreži. Duplikat proizvodi povremeni saobraćaj prema pogrešnom hostu, što je teže dijagnostikovati od odbijene konekcije. Pitajte tabelu rutiranja prije nego dodate pravilo.
Na gatewayu ip route get 192.168.2.17 treba navesti uređaj tunela; lokalni bridge znači da je udaljeni raspon zasjenjen i nijedno nat pravilo ga neće popraviti. Ako vaša mreža već koristi 192.168.2.0/24, prenumerišite udaljeno mjesto umjesto da slažete mapiranje na sudar.
Testiranje sa stvarnog klijenta, pa zadržavanje
Testirajte sa mašine koja će alias zaista koristiti, ne sa gatewaya, jer lokalno generisan saobraćaj nikada ne prolazi PREROUTING na isti način. Otvorite konekciju prema jednom aliasiranom hostu i gledajte kako se brojači i conntrack zapis pojavljuju zajedno, zatim je zatvorite i potvrdite da zapis odlazi. Zaostali zapis ukazuje na poluotvorenu konekciju, što obično znači da odgovor nikada nije stigao.
curl -sv http://10.50.1.17/ -o /dev/null
ss -tn dst 10.50.1.17
conntrack -L -d 10.50.1.17Dvije ili tri uspješne konekcije dokazuju aritmetiku, ali ne govore ništa o trajnosti ni o sljedećem inženjeru. Sačuvajte pravila tamo gdje ih proces podizanja čita, što na Debianu i Ubuntuu znači iptables-save > /etc/iptables/rules.v4 uz omogućen netfilter-persistent. Mapiranje koje nestane pri restartu gore je od nikakvog, jer prekid dolazi bez nedavne promjene da se okrivi.
Ostavite bilješku uz pravila: alias raspon, stvarni raspon, razlog para i koja strana smije započeti. Ta bilješka razdvaja dizajn od gomile pravila koja se niko ne usuđuje izbrisati. Ona rješava i kasnije pitanje, kada udaljeno mjesto doda host i adresa koju niko nije konfigurisao već odgovara. Ako bilješka kaže da drugoj strani treba povratna ruta, sljedeća osoba zna da uklanjanje pravila maskiranja prekida povezanost. Dokumentacija je ovdje jeftina; ponovno otkrivanje zavisnosti od NAT-a u tri ujutro nije.