Rout tusken partikuliere LAN's foardat jo noch in NAT tafoegje
Oerlappende adresromte, in ûntbrekkende weromrûte of in ûnbetrouber transit beslisse tusken routing, NAT en tunnel. Kontrolearje dy trije foardat jo de firewall bewurkje.
Twa ynterne firewalls, ien partikulier transitssegment en in fersyk om in pear hosts yn elk LAN mei dy yn it oare prate te litten. De refleks is in VPN op te setten of in twadde NAT-laach ta te foegjen, en beide refleksen kostje mear as't it probleem fertsjinnet. Gewoane routing is genôch as trije betingsten jilde: de adresberikken oerlappe net, beide kanten kinne ferkear weromstjoere nei it oare LAN en it transitssegment is foar de gegevens al betrouber genôch. Kontrolearje dy trije foardat jo wat ûntwerpe, want elk fan harren feroaret it antwurd.
Trije betingsten dy't it ûntwerp beslisse
De earste betingst is adresromte. As beide LAN's itselde RFC 1918-blok brûke, kin routing se net ûnderskiede en wurdt oersetting ûnfermidlik ynstee fan opsjoneel. De twadde is in weromwei: in rûte fan A nei B is nutteleas as B ek net wit hoe't er by it LAN fan A komme moat, en asymmetryske kennis is de meast foarkommende reden dat in routed ûntwerp antwurden stil falle lit.
De tredde is fertrouwen. Routing ferpleatst pakketten; it beskermet se net. In partikulier transitssegment yn ien gebou is wat oars as in oerdracht oan in provider of in ferbining dy't in dielde kampusrigge krúst. As it segment net betrouber is, is it antwurd in tunnel tusken de twa firewalls, en it rûteplan hjirûnder jildt dêr noch altyd yn.
Allinnich as alle trije deselde kant út wize, wint it ienfâldige ûntwerp. As ien fan harren mist, reparearje dy betingst eksplisyt ynstee fan har mei oersetting te bedekken, want NAT ferberget it falen ynstee fan it op te lossen.
Bou it rûteplan op it transitsnetwurk
Jou elke firewall in adres op it dielde segment en foegje ien spesifike rûte ta foar elk lan dat fierôf leit. Neat oars yn 'e besteande konfiguraasje hoecht te bewegen, en benammen de ynternet-standertrûte moat krekt bliuwe wêr't er is. It ferfangen fan in standertrûte troch de pearel-firewall soe elke net-relatearre bestimming oer it transit stjoere, wat in folle gruttere feroaring is as de frege. De pfSense-dokumintaasje oer statyske routing beskriuwt itselde rûte-plus-gateway-model foar dat platfoarm, en de ekwivalinte kontrôle bestiet op hokfoar firewall jo ek rinne litte.
| Firewall | Remote LAN | Next hop on the transit |
|---|---|---|
| A | 10.40.0.0/24 | 192.0.2.20 |
| B | 10.30.0.0/24 | 192.0.2.10 |
Firewall A tsjinnet 10.30.0.0/24 en firewall B tsjinnet 10.40.0.0/24, mei de twa transitsadressen op 192.0.2.0/24. Elke LAN-host hâldt syn pleatslike firewall as gateway, sadat de iennige nije tastân ien rûte oan elke kant is. Op in firewall basearre op Linux sjocht itselde plan der sa út, en trochstjoere moat ynskeakele wêze, oars wurdt de rûte oplost wylst it pakket wurdt wegere.
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
Hâld filterjen apart fan oersetting
Routing en belied binne ferskillende kontrôles, en it is by de twadde dat de measte routed ûntwerpen echt misse. Stean de spesifike boarnen, bestimmingen en tsjinsten ta by de yngongsgrins dy't de pakketten echt oerstekke, en betink dat in ynterface-label as WAN in namme is, net in útspraak oer fertrouwen. In transitspoarte dy't partikulier ferkear draacht, kin noch altyd blokkearring fan partikuliere adressen standert oan hawwe.
Sjoch dan nei útgeande oersetting foardat jo konkludearje dat der gjin NAT bart. Automatyske útgeande regels kinne ferkear werom skriuwe dat nea foar oersetting bedoeld wie, en dat ferneatiget de boarneadressen dy't de oare kant foar syn eigen belied en logs nedich hat. Befêstigje dat de keazen streams har oarspronklike adressen hâlde, en lit de ynternet-oersettingsregels gewurde foar it ferkear dat se noch nedich hat.
iptables -t nat -S POSTROUTING iptables -t nat -L POSTROUTING -n -v tcpdump -ni eth1 -c 5 host 10.40.0.15
As NAT it earlike antwurd is
Oersetting fertsjinnet har plak as de adresberikken echt oerlappe en fernûmering net beskikber is, of as in belied easket dat ien kant ien adres sjocht ynstee fan in subnet. Yn dy gefallen is in bewuste ien-op-ien- of poartebeperkte mapping in ûntwerpbeslissing mei bekende gefolgen, net in needoplossing.
It gefolch dat lûd sein wurde moat, is dat de oare kant gjin yndividuele boarnen mear sjen of filterje kin. Logs stoarte yninoar ta it oersettende adres, belied per host wurket net mear, en it oplossen fan problemen wurdt in jacht op hokker ynterne host op in stuit in stream hie. As neat dêrfan foar it oangeande ferkear útmakket, is NAT prima.
As it transit sels de ferkearde oanname is
As it dielde segment in provider, in dield switch-fabryk of hokfoar paad dan ek krúst wêr't in oare partij it ferkear lêze koe, is routing allinnich gjin folslein antwurd. In tunnel tusken de twa firewalls jout jo fertroulikheid en peer-autentikaasje, en de rûtetabel deryn is deselde tabel dy't jo op it transit skreaun hiene.
Beslis dat út 'e fertrouwensfraach yn 'e earste seksje, net út in gewoante dat VPN's feiliger binne. In tunnel oer in segment dat al partikulier is, foeget operasjonele kosten en noch in flatermodus ta sûnder winst, wylst routing oer in ûnbetrouber segment fertroulikheid ruilet foar ienfâld dy't jo net bekostje kinne. Skriuw op hokker fan 'e trije betingsten de kar dreaun hat, en de folgjende yngenieur hoecht it net wer te bepraten.