Dosegnuti udaljenu /24 kroz tunel: NETMAP, DNAT ili ruta?
Mapirajte ceo prefiks pomoću NETMAP, dodajte DNAT pravila po hostu ili rutirajte stvarni opseg, i odlučite prema tome šta udaljena strana mora da vidi i ko sme da započne saobraćaj.
Do podmreže iza tunelske završne tačke možete doći na tri načina, a minut prikupljanja činjenica obično diskvalifikuje dva. Činjenice su da li serveri tamo moraju da razlikuju korisnike, da li će se neko odatle ikada javiti ka vašem opsegu, i ko sme da menja ruter na udaljenoj strani. Odgovorite na ta tri pitanja i dizajn se sam bira. Ostatak pretpostavlja da vi upravljate završnom tačkom i možete da menjate njen firewall.
Tri opcije i šta svaka zapravo menja
Mapiranje prefiksa, DNAT po hostu i rutirani prefiks svi premeštaju pakete između ista dva opsega, ali menjaju različite stvari. Mapiranje izmišlja alias opseg i aritmetički prepisuje adrese u letu. Pravila po hostu takođe prepisuju, samo se svaka destinacija imenuje ručno. Rutirani prefiks ne prepisuje ništa: paketi zadržavaju stvarne adrese i oba kraja se slažu gde 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 udaljene strane, gde je ograničenja najteže promeniti. Ako server tamo upisuje adrese klijenata u logove, proverava ih prema listi dozvoljenih ili ih predaje drugom sistemu, prevođenje izvora uništava njegov jedini identifikator. Ako udaljena strana takođe mora da se javlja ka unutra, prevođenje je potpuno isključeno, jer tamo niko ne zna da alias postoji. Samo kada udaljena strana samo odgovara na zahteve, jeftinije opcije postaju bezbedne.
Parovi prefiksa i zašto veličine moraju da se poklope
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 ponovo ih pričvršćuje na novi prefiks, zato se /24 mapira na /24 i nikada na /25. Položaj određuje smer: podudaranje destinacije u PREROUTING prepisuje gde paket ide, a podudaranje izvora u POSTROUTING prepisuje odakle je došao.
Host na 192.168.2.17 se vašim klijentima prikazuje kao 10.50.1.17, a poslednji oktet nije ukras — to je isti broj na obe strane. Dodajte sutra host na 192.168.2.40 i njegov alias je 10.50.1.40, bez pravila koje treba menjati.
Klijentima i dalje treba ruta za alias opseg koja pokazuje na vašu kutiju, osim ako alias pada u podmrežu koju već dostižu. Gateway ne treba rutu za alias, jer se prevođenje destinacije izvršava u PREROUTING, pre traženja rute. Prosleđivanje takođe mora biti uključeno, inače kernel odbacuje paket posle prepisivanja. Tri komande ispod su cela konfiguracija na gateway-u u Debian stilu 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 da nađe put nazad
Prepisivanje destinacije samo odlučuje gde će paket biti dostavljen. Udaljeni server i dalje mora da odgovori na adresu do koje dolazi, a to se može urediti na dva načina. Prevedite izvor da bi se odgovori vraćali na vašu kutiju, ili ostavite izvor i dajte udaljenoj strani rutu za opseg klijenata.
Masquerade na izlazu je kraći put: jedno pravilo u POSTROUTING i udaljena strana vidi adresu vašeg tunela, pa joj ne treba sopstvena ruta. Cena je da se svaki korisnik sažima u jednu adresu, a logovi po korisniku prestaju da znače bilo šta. Ostavljanje izvora netaknutim čuva tu informaciju, ali tada udaljeni sajt mora da vrati odgovore za opseg klijenata kroz tunel.OpenVPN serveru to je push-ovano push "route 10.50.9.0 255.255.255.0", plus route 192.168.2.0 255.255.255.0 linija.
Skupa greška je raditi po pola svakoga. Ako maskirate deo saobraćaja dok udaljena strana nosi i povratnu rutu za drugi saobraćaj, odgovori dolaze na interfejs gde zapis praćenja veze nikada nije viđen. Klijent prijavljuje istek vremena za zahtev koji je server zabeležio kao uslužen. Oba smera toka moraju da prođu 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 -nČitajte zapis u oba smera: 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 nikada nisu pomerili, paket nikada nije stigao do tog hook-a.
Sudari i pretraga koja se izvršava prva
Dva različita opsega mogu da se sudare, a oba kvara izgledaju kao pokvaren tunel, a ne kao loše pravilo. Alias koji izmislite mora biti neiskorišćen duž celog puta, a stvarni udaljeni opseg ne sme već da postoji na vašoj mreži. Duplikat stvara povremeni saobraćaj ka pogrešnom hostu, što je teže dijagnostikovati od odbijene veze. Pitajte tabelu rutiranja pre nego što dodate pravilo.
Na gateway-u, ip route get 192.168.2.17 treba da imenuje tunelski uređaj; lokalni bridge znači da je udaljeni opseg zasenčen i nijedno nat pravilo ga ne popravlja. Ako vaša mreža već koristi 192.168.2.0/24, prenumerišite udaljeni sajt umesto da slažete mapiranje na sudar.
Testiranje sa stvarnog klijenta, pa čuvanje
Testirajte sa mašine koja će zaista koristiti alias, ne sa gateway-a, jer lokalno generisan saobraćaj nikada ne prolazi PREROUTING na isti način. Otvorite vezu ka jednom hostu sa aliasom i gledajte kako se brojači i conntrack zapis pojavljuju zajedno, zatim je zatvorite i potvrdite da zapis odlazi. Zastareo zapis ukazuje na poluotvorenu vezu, što obično znači da se odgovor nikada nije vratio.
curl -sv http://10.50.1.17/ -o /dev/null
ss -tn dst 10.50.1.17
conntrack -L -d 10.50.1.17Dve ili tri uspešne veze dokazuju aritmetiku, ali ne govore ništa o trajnosti ili o sledećem inženjeru. Sačuvajte pravila tamo gde ih čita proces podizanja, što na Debian-u i Ubuntu-u znači iptables-save > /etc/iptables/rules.v4 sa uključenim netfilter-persistent. Mapiranje koje nestane pri restartu gore je od nikakvog, jer prekid dolazi bez skorašnje izmene koja bi se krivila.
Ostavite belešku pored pravila: alias opseg, stvarni opseg, razlog para i koja strana sme da inicira. Ta beleška razdvaja dizajn od gomile pravila koja se niko ne usuđuje da obriše. Ona rešava i kasnije pitanje, kada udaljeni sajt doda host i adresa koju niko nije konfigurisao već odgovara. Ako beleška kaže da udaljenoj strani treba povratna ruta, sledeća osoba zna da uklanjanje masquerade pravila prekida povezanost. Dokumentacija je ovde jeftina; ponovno otkrivanje NAT zavisnosti u tri sata ujutru nije.