Rut mellom private LAN før du legg til endå ein NAT

To interne brannmurar, eitt privat transittsegment og ei førespurnad om å la nokre få vertar i kvart LAN snakke med dei i det andre. Refleksen er å reise ein VPN eller leggje til eit andre NAT-lag, og begge refleksane kostar meir enn problemet fortener. Vanleg ruting er nok når tre vilkår gjeld: adresseområda overlappar ikkje, begge sider kan sende trafikk tilbake til det andre LAN-et, og transittsegmentet er allereie godkjent nok for dataa. Kontroller dei tre før du designar noko, fordi kvart av dei endrar svaret.

Tre vilkår som avgjer designet

Det første vilkåret er adresseplass. Viss begge LAN brukar den same RFC 1918-blokka, kan ruting ikkje skilje dei, og omsetjing blir uunngåeleg i staden for valfri. Det andre er ein returveg: ei rute frå A til B er ubrukeleg med mindre B også veit korleis ein når LAN-et til A, og asymmetrisk kunnskap er den vanlegaste grunnen til at eit ruta design stille slepp svar.

Det tredje er tillit. Ruting flyttar pakkar; det beskyttar dei ikkje. Eit privat transittsegment inne i éin bygning er noko anna enn ei overlevering til ein leverandør eller ei lenke som kryssar ein delt campusryggrad. Viss segmentet ikkje er godkjent, er svaret ein tunnel mellom dei to brannmurane, og ruteplanen nedanfor gjeld framleis inne i han.

Berre når alle tre peikar same veg, vinn det enkle designet. Når eitt av dei sviktar, rett på det vilkåret eksplisitt i staden for å dekkje over det med omsetjing, fordi NAT løyner feilen i staden for å løyse han.

Bygg ruteplanen på transittnettet

Gje kvar brannmur ei adresse på det delte segmentet, og legg til éi bestemt rute per fjern LAN. Ingenting anna i den eksisterande konfigurasjonen treng å flytte seg, og særleg internett-standardruta må bli nøyaktig der ho er. Å byta ut ei standardrute med partnarbrannmuren ville sendt kvar urelatert destinasjon over transitten, noko som er ei mykje større endring enn den som er beden om. pfSense-dokumentasjonen om statisk ruting skildrar den same rute-pluss-gateway-modellen for den plattforma, og den tilsvarande kontrollen finst på kva brannmur du faktisk køyrer.

Brannmur A betener 10.30.0.0/24 og brannmur B betener 10.40.0.0/24, med dei to transittadressene på 192.0.2.0/24. Kvar LAN-vert held på sin lokale brannmur som gateway, så den einaste nye tilstanden er éi rute på kvar side. På ein Linux-basert brannmur ser den same planen slik ut, og vidaresending må vere slått på, elles blir ruta løyst opp medan pakken blir kasta.

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

Hald filtrering skild frå omsetjing

Ruting og politikk er ulike kontrollar, og det er i den andre dei fleste ruta design faktisk sviktar. Tillat dei bestemte kjeldene, destinasjonane og tenestene ved inngangsgrensa som pakkane faktisk kryssar, og hugs at ei grensesnittetikett som WAN er eit namn, ikkje ei fråsegn om tillit. Ein transittport som ber privat trafikk kan framleis ha blokkering av private adresser slått på som standard.

Sjå deretter på utgåande omsetjing før du konkluderer med at ingen NAT skjer. Automatiske utgåande reglar kan skrive om trafikk som aldri var meint å bli omsett, og det øydelegg kjeldeadressene den andre sida treng for sin eigen politikk og sine loggar. Stadfest at dei valde flyta held på dei opphavlege adressene sine, og lat internett-omsetjingsreglane vere i fred for trafikken som framleis treng dei.

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

Når NAT er det ærlege svaret

Omsetjing fortener plassen sin når adresseområda verkeleg overlappar og omnummerering ikkje er tilgjengeleg, eller når ein politikk krev at éi side ser éi adresse i staden for eit subnett. I dei tilfella er ein medviten ein-til-ein- eller portavgrensa mapping eit designval med kjende konsekvensar, ikkje ei naudløysing.

Konsekvensen som må seiast høgt, er at den andre sida ikkje lenger kan sjå eller filtrere enkeltkjelder. Loggane fell saman til den omsetjande adressa, politikk per vert sluttar å verke, og feilsøking blir ei jakt på kva intern vert som åtte ein flyt på eit gitt tidspunkt. Viss ingenting av dette betyr noko for trafikken det gjeld, er NAT greitt.

Når transitten sjølv er den gale føresetnaden

Viss det delte segmentet kryssar ein leverandør, eit delt svitsjefabric eller ein kva som helst veg der ein annan part kunne lese trafikken, er ruting åleine ikkje eit fullstendig svar. Ein tunnel mellom dei to brannmurane gjev konfidensialitet og partnarautentisering, og rutetabellen inni han er den same tabellen du ville ha skrive på transitten.

Avgjer det ut frå tillitsspørsmålet i første del, ikkje ut frå ein vane om at VPN-ar er tryggare. Ein tunnel over eit segment som allereie er privat legg til driftskostnader og nok ein feilmodus utan vinning, medan ruting over eit utruverdig segment byter konfidensialitet mot ein enkelheit du ikkje har råd til. Skriv ned kva av dei tre vilkåra som styrte valet, og den neste ingeniøren slepp å ta det opp att.