Rutați între LAN-uri private înainte de a adăuga încă un NAT

Două firewall-uri interne, un segment de tranzit privat și o cerere ca câteva gazde din fiecare LAN să poată vorbi cu cele din cealaltă. Reflexul este să ridici un VPN sau să adaugi un al doilea strat NAT, iar ambele reflexe costă mai mult decât merită problema. Rutarea obișnuită este suficientă când sunt îndeplinite trei condiții: intervalele de adrese nu se suprapun, ambele părți pot trimite traficul înapoi în cealaltă LAN și segmentul de tranzit este deja suficient de sigur pentru date. Verificați aceste trei înainte de a proiecta ceva, pentru că fiecare dintre ele schimbă răspunsul.

Trei condiții care decid proiectul

Prima condiție este spațiul de adrese. Dacă ambele LAN-uri folosesc același bloc RFC 1918, rutarea nu le poate distinge și traducerea devine inevitabilă, nu opțională. A doua este o cale de retur: o rută de la A la B este inutilă dacă B nu știe și cum să ajungă în LAN-ul lui A, iar cunoașterea asimetrică este cel mai frecvent motiv pentru care un proiect rutat aruncă răspunsurile în tăcere.

A treia este încrederea. Rutarea mută pachete; nu le protejează. Un segment de tranzit privat într-o singură clădire este altceva decât o predare către un furnizor sau o legătură care traversează un backbone de campus partajat. Dacă segmentul nu este de încredere, răspunsul este un tunel între cele două firewall-uri, iar planul de rutare de mai jos se aplică în continuare în interiorul lui.

Proiectul simplu câștigă doar când toate trei arată în aceeași direcție. Când una dintre ele eșuează, corectați acea condiție explicit în loc să o acoperiți cu traducere, pentru că NAT ascunde defectul în loc să îl rezolve.

Construiți planul de rute pe rețeaua de tranzit

Dați fiecărui firewall o adresă pe segmentul comun și adăugați o rută specifică pentru fiecare LAN îndepărtat. Nimic altceva din configurația existentă nu trebuie să se miște, iar în special ruta implicită către internet trebuie să rămână exact unde este. Înlocuirea unei rute implicite cu firewall-ul partener ar trimite fiecare destinație fără legătură prin tranzit, ceea ce este o schimbare mult mai mare decât cea cerută. Documentația pfSense despre rutarea statică descrie același model rută-plus-gateway pentru acea platformă, iar controlul echivalent există pe orice firewall pe care îl rulați efectiv.

Firewall-ul A deservește 10.30.0.0/24, iar firewall-ul B deservește 10.40.0.0/24, cu cele două adrese de tranzit în 192.0.2.0/24. Fiecare gazdă din LAN își păstrează firewall-ul local ca gateway, așa că singura stare nouă este o rută pe fiecare parte. Pe un firewall bazat pe Linux același plan arată astfel, iar forwarding-ul trebuie activat, altfel ruta se rezolvă în timp ce pachetul este eliminat.

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

Țineți filtrarea separată de traducere

Rutarea și politica sunt controale diferite, iar la a doua eșuează de fapt majoritatea proiectelor rutate. Permiteți sursele, destinațiile și serviciile concrete la granița de intrare pe care pachetele o traversează realmente, și rețineți că o etichetă de interfață precum WAN este un nume, nu o afirmație despre încredere. Un port de tranzit care transportă trafic privat poate avea în continuare blocarea adreselor private activată implicit.

Apoi priviți traducerea de ieșire înainte de a concluziona că nu există NAT. Regulile de ieșire automate pot rescrie trafic care nu a fost niciodată destinat traducerii, iar asta distruge adresele sursă de care cealaltă parte are nevoie pentru propria politică și propriile jurnale. Confirmați că fluxurile selectate își păstrează adresele originale și lăsați regulile de traducere pentru internet în pace pentru traficul care încă le are nevoie.

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

Când NAT este răspunsul onest

Traducerea își câștigă locul când intervalele de adrese se suprapun cu adevărat și renumerotarea nu este disponibilă, sau când o politică cere ca o parte să vadă o singură adresă în loc de o subrețea. În acele cazuri, o mapare deliberată unu-la-unu sau restricționată pe porturi este o decizie de proiectare cu consecințe cunoscute, nu o soluție de moment.

Consecința care trebuie spusă cu voce tare este că cealaltă parte nu mai poate vedea sau filtra surse individuale. Jurnalele se prăbușesc la adresa care traduce, politica pe gazdă nu mai funcționează, iar depanarea devine o vânătoare a gazdei interne care deținea un flux la un moment dat. Dacă nimic din toate acestea nu contează pentru traficul în cauză, NAT este în regulă.

Când tranzitul însuși este presupunerea greșită

Dacă segmentul comun traversează un furnizor, o structură de comutare partajată sau orice cale pe care o altă parte ar putea citi traficul, rutarea singură nu este un răspuns complet. Un tunel între cele două firewall-uri vă dă confidențialitate și autentificarea partenerului, iar tabela de rutare din interior este aceeași tabelă pe care ați fi scris-o pe tranzit.

Decideți asta din întrebarea despre încredere din prima secțiune, nu dintr-un obicei că VPN-urile sunt mai sigure. Un tunel peste un segment deja privat adaugă cost operațional și încă un mod de eșec fără câștig, în timp ce rutarea peste un segment neîncrezut schimbă confidențialitatea pe o simplitate pe care nu v-o puteți permite. Notați care dintre cele trei condiții a condus alegerea, iar următorul inginer nu va trebui să o reia.