Roeteer tussen privaat LAN's voordat jy nóg 'n NAT byvoeg
Oorvleuelende adresruimte, 'n ontbrekende terugroete of 'n onbetroubare deurgang bepaal die keuse tussen roetering, NAT en 'n tonnel. Kontroleer daardie drie voordat jy die vuurmuur wysig.
Twee interne vuurmure, een privaat deurgangsegment en 'n versoek om 'n paar gashere in elke LAN met die ander te laat praat. Die refleks is om 'n VPN op te rig of 'n tweede NAT-laag by te voeg, en beide reflekse kos meer as wat die probleem verdien. Gewone roetering is genoeg wanneer drie voorwaardes geld: die adresreekse oorvleuel nie, beide kante kan verkeer na die ander LAN terugstuur, en die deurgangsegment word reeds vertrou vir die data. Kontroleer daardie drie voordat jy iets ontwerp, want elkeen verander die antwoord.
Drie voorwaardes wat die ontwerp bepaal
Die eerste voorwaarde is adresruimte. As beide LAN's dieselfde RFC 1918-blok gebruik, kan roetering hulle nie onderskei nie en word adresvertaling onvermydelik eerder as opsioneel. Die tweede is 'n terugpad: 'n roete van A na B is nutteloos tensy B ook weet hoe om A se LAN te bereik, en asimmetriese kennis is die algemeenste rede waarom 'n geroeteerde ontwerp stilweg antwoorde laat val.
Die derde is vertroue. Roetering beweeg pakkette; dit beskerm hulle nie. 'n Privaat deurgangsegment binne een gebou is 'n ander saak as 'n diensverskaffer-oorgang of 'n skakel wat deur 'n gedeelde kampusruggraat loop. As die segment nie vertrou word nie, is die antwoord 'n tonnel tussen die twee vuurmure, en die roeteringsplan hieronder geld steeds daarbinne.
Slegs wanneer al drie dieselfde kant toe wys, wen die eenvoudige ontwerp. Wanneer een van hulle faal, herstel daardie voorwaarde eksplisiet eerder as om dit met adresvertaling toe te smeer, want NAT verberg die fout eerder as om dit op te los.
Bou die roeteringsplan op die deurgangsnetwerk
Gee elke vuurmuur 'n adres op die gedeelde segment en voeg een spesifieke roete per afgeleë LAN by. Niks anders aan die bestaande opset hoef te skuif nie, en veral die internet-verstekroete moet presies bly waar dit is. Om 'n verstekroete deur die eweknie-vuurmuur te vervang, sou elke onverwante bestemming oor die deurgang stuur, wat 'n veel groter verandering is as die een wat gevra word. Die pfSense-dokumentasie oor statiese roetering beskryf dieselfde roete-plus-gateway-model vir daardie platform, en die ekwivalente beheer bestaan op watter vuurmuur jy ook al gebruik.
| 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 |
Vuurmuur A bedien 10.30.0.0/24 en vuurmuur B bedien 10.40.0.0/24, met die twee deurgangsadresse op 192.0.2.0/24. Elke LAN-gasheer hou sy plaaslike vuurmuur as sy poort, so die enigste nuwe toestand is een roete aan elke kant. Op 'n Linux-gebaseerde vuurmuur lyk dieselfde plan so, en doorstuur moet geaktiveer word, anders word die roete opgelos terwyl die pakket val.
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
Hou filtering apart van adresvertaling
Roetering en beleid is verskillende kontroles, en die tweede is waar die meeste geroeteerde ontwerpe werklik faal. Laat die spesifieke bronne, bestemmings en dienste toe by die inkomende grens wat die pakkette werklik oorsteek, en onthou dat 'n koppelvlaknaam soos WAN 'n naam is, nie 'n verklaring oor vertroue nie. 'n Deurgangspoort wat privaatverkeer dra, kan steeds privaatadresblokkering by verstek geaktiveer hê.
Kyk dan na uitgaande adresvertaling voordat jy aflei dat geen NAT plaasvind nie. Outomatiese uitgaande reëls kan verkeer herskryf wat nooit bedoel was om vertaal te word nie, wat die bronadresse vernietig wat die ander kant vir sy eie beleid en logs nodig het. Bevestig dat die gekose strome hul oorspronklike adresse behou, en laat die internet-vertaalreëls alleen vir die verkeer wat dit steeds nodig het.
iptables -t nat -S POSTROUTING iptables -t nat -L POSTROUTING -n -v tcpdump -ni eth1 -c 5 host 10.40.0.15
Wanneer NAT die eerlike antwoord is
Adresvertaling verdien sy plek wanneer die adresreekse werklik oorvleuel en hernommering nie beskikbaar is nie, of wanneer 'n beleid vereis dat een kant 'n enkele adres sien eerder as 'n subnet. In daardie gevalle is 'n doelbewuste een-tot-een- of poortbeperkte kartering 'n ontwerpbesluit met bekende gevolge, nie 'n noodoplossing nie.
Die gevolg om hardop te sê is dat die ander kant nie meer individuele bronne kan sien of filter nie. Logs verval na die vertalende adres, per-gasheer-beleid hou op werk, en foutsoeking word 'n jag na watter interne gasheer 'n stroom op 'n gegewe oomblik besit het. As niks daarvan saak maak vir die betrokke verkeer nie, is NAT heeltemal reg.
Wanneer die deurgang self die verkeerde aanname is
As die gedeelde segment deur 'n diensverskaffer loop, deur 'n gedeelde skakelweefsel, of deur enige pad waar 'n ander party die verkeer kon lees, is roetering alleen nie 'n volledige antwoord nie. 'n Tonnel tussen die twee vuurmure gee jou vertroulikheid en eweknie-verifikasie, en die roetetabel daarbinne is dieselfde tabel wat jy op die deurgang sou geskryf het.
Besluit dit uit die vertrouensvraag in die eerste afdeling, nie uit 'n gewoonte dat VPN's veiliger is nie. 'n Tonnel oor 'n segment wat reeds privaat is, voeg bedryfskoste en nog 'n foutmodus by sonder wins, terwyl roetering oor 'n onbetroubare segment vertroulikheid verruil vir eenvoud wat jy nie kan bekostig nie. Skryf neer watter van die drie voorwaardes die keuse gedryf het, en die volgende ingenieur hoef dit nie weer te betwis nie.