Rrugëtoni mes LAN-esh private përpara se të shtoni një NAT tjetër

Dy firewall të brendshëm, një segment tranziti privat dhe një kërkesë që disa hoste në secilën LAN të flasin me ata të tjetrës. Refleksi është të ngrihet një VPN ose të shtohet një shtresë e dytë NAT, dhe të dy reflekset kushtojnë më shumë se sa e meriton problemi. Rrugëtimi i zakonshëm mjafton kur plotësohen tre kushte: intervalet e adresave nuk mbivendosen, të dyja palët mund të kthejnë trafikun në LAN-in tjetër dhe segmenti i tranzitit është tashmë mjaftueshëm i besuar për të dhënat. Kontrolloni këto tre para se të projektoni çdo gjë, sepse secili prej tyre ndryshon përgjigjen.

Tre kushte që vendosin projektin

Kushti i parë është hapësira e adresave. Nëse të dyja LAN-et përdorin të njëjtin bllok RFC 1918, rrugëtimi nuk mund t'i dallojë dhe përkthimi bëhet i pashmangshëm, jo opsional. I dyti është një rrugë kthimi: një rrugë nga A në B është e padobishme nëse B nuk e di gjithashtu se si të arrijë LAN-in e A, dhe njohuria asimetrike është arsyeja më e zakonshme që një projekt i rrugëtuar hedh përgjigjet në heshtje.

I treti është besimi. Rrugëtimi lëviz paketat; nuk i mbron ato. Një segment tranziti privat brenda një ndërtese është diçka tjetër nga një dorëzim te një ofrues ose një lidhje që kalon një shtyllë kurrizore kampusi të përbashkët. Nëse segmenti nuk është i besuar, përgjigjja është një tunel mes dy firewall-ave, dhe plani i rrugëtimit më poshtë vlen ende brenda tij.

Projekti i thjeshtë fiton vetëm kur të tre tregojnë në të njëjtin drejtim. Kur njëri prej tyre dështon, rregulloni pikërisht atë kusht në mënyrë eksplicite në vend që ta mbuloni me përkthim, sepse NAT-i e fsheh dështimin në vend që ta zgjidhë.

Ndërtoni planin e rrugëve mbi rrjetin e tranzitit

Jepini secilit firewall një adresë në segmentin e përbashkët dhe shtoni një rrugë specifike për çdo LAN të largët. Asgjë tjetër në konfigurimin ekzistues nuk duhet të lëvizë, dhe veçanërisht rruga e parazgjedhur drejt internetit duhet të mbetet saktësisht aty ku është. Zëvendësimi i një rruge të parazgjedhur me firewall-in homolog do të dërgonte çdo destinacion të palidhur përmes tranzitit, që është një ndryshim shumë më i madh se ai i kërkuar. Dokumentacioni i pfSense për rrugëtimin statik përshkruan të njëjtin model rrugë-plus-portë për atë platformë, dhe kontrolli ekuivalent ekziston në çdo firewall që ju ekzekutoni në të vërtetë.

Firewall-i A shërben 10.30.0.0/24 dhe firewall-i B shërben 10.40.0.0/24, ndërsa dy adresat e tranzitit janë në 192.0.2.0/24. Çdo host i LAN-it mban firewall-in lokal si portë e tij, kështu që i vetmi gjendje i re është një rrugë në secilën anë. Në një firewall të bazuar në Linux i njëjti plan duket kështu, dhe përcjellja duhet të jetë e aktivizuar, përndryshe rruga zgjidhet ndërsa paketa hidhet.

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

Mbani filtrimin të ndarë nga përkthimi

Rrugëtimi dhe politika janë kontrolle të ndryshme, dhe është në të dytën që shumica e projekteve të rrugëtuara dështojnë në të vërtetë. Lejoni burimet, destinacionet dhe shërbimet konkrete në kufirin e hyrjes që paketat vërtet kalojnë, dhe mbani mend se një etiketë ndërfaqeje si WAN është emër, jo deklaratë për besimin. Një portë tranziti që mban trafik privat mund të ketë ende bllokimin e adresave private të aktivizuar si parazgjedhje.

Pastaj shikoni përkthimin e daljes para se të konkludoni se nuk ndodh asnjë NAT. Rregullat automatike të daljes mund të rishkruajnë trafik që nuk ishte menduar kurrë për përkthim, dhe kjo shkatërron adresat e burimit që pala tjetër i nevojit për politikën dhe regjistrat e saj. Konfirmoni se flukset e zgjedhura ruajnë adresat origjinale, dhe lërini rregullat e përkthimit të internetit në paqe për trafikun që ende i nevojiten.

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

Kur NAT-i është përgjigjja e ndershme

Përkthimi e fiton vendin e tij kur intervalet e adresave vërtet mbivendosen dhe rinumërimi nuk është i disponueshëm, ose kur një politikë kërkon që njëra palë të shohë një adresë të vetme në vend të një nënrrjeti. Në ato raste, një hartëzim i qëllimshëm një-me-një ose i kufizuar në porta është një vendim projektimi me pasoja të njohura, jo një zgjidhje e shpejtë.

Pasoja që duhet thënë me zë të lartë është se pala tjetër nuk mund të shohë më ose të filtrojë burime individuale. Regjistrat shemben në adresën që përkthen, politika për host ndalon së funksionuari, dhe zgjidhja e problemeve bëhet një gjueti për atë se cili host i brendshëm zotëronte një rrjedhë në një moment të caktuar. Nëse asnjë prej këtyre nuk ka rëndësi për trafikun në fjalë, NAT-i është në rregull.

Kur vetë tranziti është supozimi i gabuar

Nëse segmenti i përbashkët kalon një ofrues, një strukturë komutimi të përbashkët ose çdo shteg ku një palë tjetër mund të lexonte trafikun, rrugëtimi i vetëm nuk është përgjigje e plotë. Një tunel mes dy firewall-ave ju jep konfidencialitet dhe vërtetim të homologut, dhe tabela e rrugëve brenda tij është e njëjta tabelë që do të kishit shkruar në tranzit.

Vendoseni këtë nga pyetja e besimit në seksionin e parë, jo nga një zakon se VPN-të janë më të sigurta. Një tunel mbi një segment që tashmë është privat shton kosto operative dhe një mënyrë tjetër dështimi pa përfitim, ndërsa rrugëtimi mbi një segment të pabesuar shkëmben konfidencialitetin me një thjeshtësi që nuk mund ta përballoni. Shkruani cili nga tre kushtet drejtoi zgjedhjen, dhe inxhinieri tjetër nuk do të ketë nevojë ta rishqyrtojë.