Usmjeravajte promet između privatnih LAN-ova prije nego dodate još jedan NAT

Dva interna firewall-a, jedan privatni tranzitni segment i zahtjev da nekoliko hostova u svakom LAN-u može razgovarati s onim drugim. Refleks je podići VPN ili dodati drugi NAT sloj, a oba refleksa koštaju više nego što problem zaslužuje. Obično rutiranje je dovoljno kada vrijede tri uslova: adresni opsezi se ne preklapaju, obje strane mogu vraćati promet u drugi LAN i tranzitni segment je već dovoljno pouzdan za te podatke. Provjerite ta tri prije nego išta projektujete, jer svaki od njih mijenja odgovor.

Tri uslova koja odlučuju o dizajnu

Prvi uslov je adresni prostor. Ako oba LAN-a koriste isti RFC 1918 blok, rutiranje ih ne može razlikovati i prevođenje postaje neizbježno, a ne opcionalno. Drugi je povratna putanja: ruta od A do B je beskorisna ako B također ne zna kako doći do LAN-a od A, a asimetrično znanje je najčešći razlog da rutirani dizajn tiho odbacuje odgovore.

Treći je povjerenje. Rutiranje prenosi pakete; ono ih ne štiti. Privatni tranzitni segment unutar jedne zgrade je druga stvar od predaje provajderu ili linka koji prelazi preko zajedničke kampusske magistrale. Ako segment nije pouzdan, odgovor je tunel između dva firewall-a, a plan rutiranja ispod i dalje vrijedi unutar njega.

Samo kada sva tri pokazuju u istom smjeru, jednostavan dizajn pobjeđuje. Kada jedan od njih zakaže, popravite taj uslov izričito umjesto da ga prekrijete prevođenjem, jer NAT krije kvar umjesto da ga rješava.

Izgradite plan ruta na tranzitnoj mreži

Dajte svakom firewall-u adresu na zajedničkom segmentu i dodajte po jednu konkretnu rutu za svaki udaljeni LAN. Ništa drugo u postojećoj konfiguraciji ne treba pomjerati, a posebno internet default ruta mora ostati tačno gdje jeste. Zamjena default rute partnerskim firewall-om poslala bi svako nepovezano odredište preko tranzita, što je mnogo veća promjena od tražene. pfSense dokumentacija o statičkom rutiranju opisuje isti model rute plus gateway-a za tu platformu, a ekvivalentna kontrola postoji na kojem god firewall-u da radite.

Firewall A opslužuje 10.30.0.0/24, a firewall B opslužuje 10.40.0.0/24, dok su dvije tranzitne adrese na 192.0.2.0/24. Svaki host u LAN-u zadržava svoj lokalni firewall kao gateway, pa je jedino novo stanje po jedna ruta na svakoj strani. Na firewall-u zasnovanom na Linuxu isti plan izgleda ovako, a forwarding mora biti omogućen ili će se ruta razriješiti dok paket bude odbačen.

sysctl -w net.ipv4.ip_forward=1
ip route add 10.40.0.0/24 via 192.0.2.20 dev eth1
ip route get 10.40.0.15
traceroute -n 10.40.0.15

Držite filtriranje odvojeno od prevođenja

Rutiranje i politika su različite kontrole, a na drugoj većina rutiranih dizajna stvarno pada. Dozvolite konkretne izvore, odredišta i servise na ulaznoj granici koju paketi zaista prelaze i zapamtite da je oznaka interfejsa poput WAN ime, a ne izjava o povjerenju. Tranzitni port koji nosi privatni promet može i dalje imati blokiranje privatnih adresa uključeno po defaultu.

Zatim pogledajte odlazno prevođenje prije nego zaključite da se NAT ne događa. Automatska odlazna pravila mogu prepisati promet koji nikada nije bio namijenjen prevođenju, a to uništava izvorne adrese koje druga strana treba za vlastitu politiku i logove. Potvrdite da odabrani tokovi zadržavaju originalne adrese i ostavite internet pravila prevođenja na miru za promet kojem još trebaju.

iptables -t nat -S POSTROUTING
iptables -t nat -L POSTROUTING -n -v
tcpdump -ni eth1 -c 5 host 10.40.0.15

Kada je NAT iskren odgovor

Prevođenje zaslužuje svoje mjesto kada se adresni opsezi stvarno preklapaju i prenumeracija nije dostupna, ili kada politika zahtijeva da jedna strana vidi jednu adresu, a ne podmrežu. U tim slučajevima namjerno mapiranje jedan-na-jedan ili ograničeno portovima je dizajnerska odluka s poznatim posljedicama, a ne zaobilazno rješenje.

Posljedica koju treba reći naglas je da druga strana više ne može vidjeti ni filtrirati pojedinačne izvore. Logovi se slijevaju na adresu koja prevodi, politika po hostu prestaje raditi i rješavanje problema postaje lov na to koji je interni host posjedovao tok u datom trenutku. Ako ništa od toga nije važno za dotični promet, NAT je u redu.

Kada je sam tranzit pogrešna pretpostavka

Ako zajednički segment prelazi preko provajdera, zajedničke switch fabric ili bilo koje putanje gdje bi druga strana mogla čitati promet, samo rutiranje nije potpun odgovor. Tunel između dva firewall-a daje povjerljivost i autentifikaciju partnera, a tabela ruta unutar njega ista je tabela koju biste napisali na tranzitu.

Odlučite to iz pitanja povjerenja u prvom odjeljku, a ne iz navike da su VPN-ovi sigurniji. Tunel preko segmenta koji je već privatan dodaje operativni trošak i još jedan način otkaza bez dobiti, dok rutiranje preko nepouzdanog segmenta mijenja povjerljivost za jednostavnost koju ne možete priuštiti. Zapišite koji je od tri uslova vodio izbor i sljedeći inženjer neće morati to ponovo raspravljati.