Rut mellem private LAN'er, før du tilføjer endnu en NAT

To interne firewalls, ét privat transitsegment og en anmodning om at lade nogle få værter i hvert LAN tale med dem i det andet. Refleksen er at rejse en VPN eller tilføje et andet NAT-lag, og begge reflekser koster mere, end problemet fortjener. Almindelig routing er nok, når tre betingelser gælder: adresseområderne overlapper ikke, begge sider kan sende trafik tilbage til det andet LAN, og transitsegmentet er allerede betroet nok til dataene. Kontrollér de tre, før du designer noget, fordi hver af dem ændrer svaret.

Tre betingelser, der afgør designet

Den første betingelse er adresseplads. Hvis begge LAN bruger den samme RFC 1918-blok, kan routing ikke skelne dem, og oversættelse bliver uundgåelig i stedet for valgfri. Den anden er en returvej: en rute fra A til B er ubrugelig, medmindre B også ved, hvordan man når A's LAN, og asymmetrisk viden er den mest almindelige grund til, at et rutet design lydløst dropper svar.

Den tredje er tillid. Routing flytter pakker; det beskytter dem ikke. Et privat transitsegment inde i én bygning er noget andet end en overdragelse til en udbyder eller et link, der krydser en delt campus-backbone. Hvis segmentet ikke er betroet, er svaret en tunnel mellem de to firewalls, og ruteplanen nedenfor gælder stadig inde i den.

Kun når alle tre peger samme vej, vinder det enkle design. Når en af dem fejler, ret den betingelse eksplicit i stedet for at dække over den med oversættelse, fordi NAT skjuler fejlen i stedet for at løse den.

Byg ruteplanen på transitnettet

Giv hver firewall en adresse på det delte segment, og tilføj én specifik rute pr. fjernnet-LAN. Intet andet i den eksisterende konfiguration behøver at flytte sig, og især internet-standardruten skal blive præcis, hvor den er. At erstatte en standardrute med peer-firewallen ville sende enhver uvedkommende destination over transitnettet, hvilket er en meget større ændring end den, der bedes om. pfSense-dokumentationen om statisk routing beskriver den samme rute-plus-gateway-model for den platform, og den tilsvarende kontrol findes på den firewall, du faktisk kører.

Firewall A betjener 10.30.0.0/24, og firewall B betjener 10.40.0.0/24, med de to transitadresser på 192.0.2.0/24. Hver LAN-vært beholder sin lokale firewall som gateway, så den eneste nye tilstand er én rute på hver side. På en Linux-baseret firewall ser den samme plan sådan ud, og videresendelse skal være aktiveret, ellers opløses ruten, mens pakken droppes.

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 adskilt fra oversættelse

Routing og politik er forskellige kontroller, og det er i den anden, de fleste rutede designs reelt fejler. Tillad de specifikke kilder, destinationer og tjenester ved den indgående grænse, som pakkerne faktisk krydser, og husk, at en interfacebetegnelse som WAN er et navn, ikke en erklæring om tillid. En transitport, der bærer privat trafik, kan stadig have blokering af private adresser aktiveret som standard.

Se derefter på udgående oversættelse, før du konkluderer, at der ikke sker NAT. Automatiske udgående regler kan omskrive trafik, der aldrig var ment som oversat, og det ødelægger kildeadresserne, som den anden side har brug for til sin egen politik og sine logs. Bekræft, at de valgte flows beholder deres oprindelige adresser, og lad internetoversættelsesreglerne være i fred for den trafik, der stadig har brug for 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 svar

Oversættelse fortjener sin plads, når adresseområderne reelt overlapper, og omnummerering ikke er en mulighed, eller når en politik kræver, at den ene side ser én adresse i stedet for et subnet. I de tilfælde er en bevidst en-til-en- eller portbegrænset mapping en designbeslutning med kendte konsekvenser, ikke en nødløsning.

Konsekvensen, der skal siges højt, er, at den anden side ikke længere kan se eller filtrere individuelle kilder. Logs falder sammen til den oversættende adresse, politik pr. vært holder op med at virke, og fejlfinding bliver en jagt på, hvilken intern vært der ejede et flow på et givet tidspunkt. Hvis intet af det betyder noget for den pågældende trafik, er NAT fint.

Når selve transitnettet er den forkerte antagelse

Hvis det delte segment krydser en udbyder, et delt switch-fabric eller enhver vej, hvor en anden part kunne læse trafikken, er routing alene ikke et fuldstændigt svar. En tunnel mellem de to firewalls giver fortrolighed og peer-autentifikation, og rutetabellen indeni er den samme tabel, du ville have skrevet på transitnettet.

Afgør det ud fra tillidsspørgsmålet i første afsnit, ikke ud fra en vane om, at VPN'er er mere sikre. En tunnel over et segment, der allerede er privat, tilføjer driftsomkostninger og endnu en fejltilstand uden gevinst, mens routing over et utroværdigt segment bytter fortrolighed for enkelhed, du ikke har råd til. Skriv ned, hvilken af de tre betingelser der drev valget, og den næste ingeniør skal ikke genforhandle det.