Rut mellom private LAN før du legger til nok en NAT

To interne brannmurer, ett privat transittsegment og en forespørsel om å la noen få verter i hvert LAN snakke med dem i det andre. Refleksen er å reise en VPN eller legge til et andre NAT-lag, og begge refleksene koster mer enn problemet fortjener. Vanlig ruting er nok når tre vilkår gjelder: adresseområdene overlapper ikke, begge sider kan sende trafikk tilbake til det andre LAN-et, og transittsegmentet er allerede betrodd nok for dataene. Kontroller de tre før du designer noe, fordi hvert av dem endrer svaret.

Tre vilkår som avgjør designet

Det første vilkåret er adresseplass. Hvis begge LAN bruker den samme RFC 1918-blokken, kan ruting ikke skille dem, og oversettelse blir uunngåelig i stedet for valgfritt. Det andre er en returvei: en rute fra A til B er ubrukelig med mindre B også vet hvordan man når A sitt LAN, og asymmetrisk kunnskap er den vanligste grunnen til at et rutet design stille slipper svar.

Det tredje er tillit. Ruting flytter pakker; det beskytter dem ikke. Et privat transittsegment inne i én bygning er noe annet enn en overlevering til en leverandør eller en lenke som krysser en delt campusryggrad. Hvis segmentet ikke er betrodd, er svaret en tunnel mellom de to brannmurene, og ruteplanen nedenfor gjelder fortsatt inne i den.

Bare når alle tre peker samme vei, vinner det enkle designet. Når ett av dem svikter, rett på det vilkåret eksplisitt i stedet for å dekke over det med oversettelse, fordi NAT skjuler feilen i stedet for å løse den.

Bygg ruteplanen på transittnettet

Gi hver brannmur en adresse på det delte segmentet, og legg til én bestemt rute per fjern LAN. Ingenting annet i den eksisterende konfigurasjonen trenger å flytte seg, og spesielt internett-standardruten må bli nøyaktig der den er. Å erstatte en standardrute med makkerbrannmuren ville sendt hver ubeslektet destinasjon over transitten, noe som er en mye større endring enn den som bes om. pfSense-dokumentasjonen om statisk ruting beskriver den samme rute-pluss-gateway-modellen for den plattformen, og den tilsvarende kontrollen finnes på hvilken som helst brannmur du faktisk kjører.

Brannmur A betjener 10.30.0.0/24 og brannmur B betjener 10.40.0.0/24, med de to transittadressene på 192.0.2.0/24. Hver LAN-vert beholder sin lokale brannmur som gateway, så den eneste nye tilstanden er én rute på hver side. På en Linux-basert brannmur ser den samme planen slik ut, og videresending må være slått på, ellers løses ruten opp mens pakken forkastes.

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

Hold filtrering atskilt fra oversettelse

Ruting og policy er forskjellige kontroller, og det er i den andre de fleste rutet design faktisk svikter. Tillat de bestemte kildene, destinasjonene og tjenestene ved inngangsgrensen som pakkene faktisk krysser, og husk at en grensesnittetikett som WAN er et navn, ikke en erklæring om tillit. En transittport som bærer privat trafikk kan fortsatt ha blokkering av private adresser slått på som standard.

Se deretter på utgående oversettelse før du konkluderer med at ingen NAT skjer. Automatiske utgående regler kan skrive om trafikk som aldri var ment å oversettes, og det ødelegger kildeadressene den andre siden trenger for sin egen policy og sine logger. Bekreft at de valgte flytene beholder sine opprinnelige adresser, og la internett-oversettelsesreglene være i fred for trafikken som fortsatt trenger dem.

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 ærlige svaret

Oversettelse fortjener plassen sin når adresseområdene virkelig overlapper og omnummerering ikke er tilgjengelig, eller når en policy krever at én side ser én adresse i stedet for et subnett. I de tilfellene er en bevisst en-til-en- eller portbegrenset mapping en designbeslutning med kjente konsekvenser, ikke en nødløsning.

Konsekvensen som må sies høyt, er at den andre siden ikke lenger kan se eller filtrere enkeltkilder. Loggene faller sammen til den oversettende adressen, policy per vert slutter å virke, og feilsøking blir en jakt på hvilken intern vert som eide en flyt på et gitt tidspunkt. Hvis ingenting av dette betyr noe for trafikken det gjelder, er NAT greit.

Når transitten selv er den gale antakelsen

Hvis det delte segmentet krysser en leverandør, et delt svitsjefabric eller en hvilken som helst vei der en annen part kunne lese trafikken, er ruting alene ikke et fullstendig svar. En tunnel mellom de to brannmurene gir konfidensialitet og makkerautentisering, og rutetabellen inni den er den samme tabellen du ville ha skrevet på transitten.

Avgjør det ut fra tillitsspørsmålet i første del, ikke ut fra en vane om at VPN-er er sikrere. En tunnel over et segment som allerede er privat legger til driftskostnader og nok en feilmodus uten gevinst, mens ruting over et utroverdig segment bytter konfidensialitet mot en enkelhet du ikke har råd til. Skriv ned hvilket av de tre vilkårene som drev valget, og den neste ingeniøren slipper å ta det opp igjen.