Irányítson forgalmat privát LAN-ok között, mielőtt újabb NAT-ot ad hozzá

Két belső tűzfal, egy privát átviteli szakasz és egy kérés, hogy néhány hoszt az egyik LAN-ban beszélhessen a másikéval. A reflex az, hogy VPN-t állítunk fel vagy egy második NAT-réteget adunk hozzá, és mindkét reflex többe kerül, mint amit a probléma megérdemel. A hétköznapi útválasztás elég, ha három feltétel teljesül: a címterületek nem fednek át, mindkét oldal vissza tudja küldeni a forgalmat a másik LAN-ba, és az átviteli szakasz már elég megbízható az adatokhoz. Ellenőrizze ezt a hármat, mielőtt bármit tervezne, mert mindegyik megváltoztatja a választ.

Három feltétel, amely a tervezést eldönti

Az első feltétel a címterület. Ha mindkét LAN ugyanazt az RFC 1918 blokkot használja, az útválasztás nem tudja megkülönböztetni őket, és a fordítás elkerülhetetlenné válik a választható helyett. A második a visszaút: az A-ból B-be vezető útvonal haszontalan, ha B sem tudja, hogyan érje el A LAN-ját, és az aszimmetrikus tudás a leggyakoribb oka annak, hogy egy útválasztott tervezés csendesen eldobja a válaszokat.

A harmadik a bizalom. Az útválasztás továbbítja a csomagokat; nem védi meg őket. Egy privát átviteli szakasz egyetlen épületen belül más, mint egy szolgáltatónak történő átadás vagy egy közös campus gerincet keresztező kapcsolat. Ha a szakasz nem megbízható, a válasz alagút a két tűzfal között, és az alábbi útválasztási terv belül továbbra is érvényes.

Csak akkor nyer az egyszerű tervezés, ha mindhárom ugyanabba az irányba mutat. Ha valamelyik meghiúsul, javítsa ki azt a feltételt kifejezetten, ahelyett hogy fordítással takarná el, mert a NAT elrejti a hibát ahelyett hogy megoldaná.

Építse az útvonaltervet az átviteli hálózatra

Adjon minden tűzfalnak egy címet a közös szakaszon, és adjon hozzá egy konkrét útvonalat minden távoli LAN-hoz. A meglévő konfigurációban semmi másnak nem kell mozdulnia, és különösen az internetes alapértelmezett útvonalnak pontosan ott kell maradnia, ahol van. Az alapértelmezett útvonal lecserélése a partner tűzfalra minden független célállomást az átviteli szakaszon keresztül küldene, ami sokkal nagyobb változás a kértnél. A pfSense statikus útválasztási dokumentációja ugyanezt az útvonal-plusz-átjáró modellt írja le arra a platformra, és az egyenértékű beállítás minden olyan tűzfalon létezik, amelyet ténylegesen futtat.

Az A tűzfal a 10.30.0.0/24 hálózatot, a B tűzfal a 10.40.0.0/24 hálózatot szolgálja ki, a két átviteli cím pedig a 192.0.2.0/24-en van. Minden LAN-hoszt a helyi tűzfalát használja átjáróként, így az egyetlen új állapot oldalanként egy útvonal. Linux-alapú tűzfalon ugyanez a terv így néz ki, és a továbbítást engedélyezni kell, különben az útvonal feloldódik, miközben a csomag eldobásra kerül.

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

Tartsa a szűrést külön a fordítástól

Az útválasztás és a szabályzat különböző vezérlők, és a másodikban vallanak kudarcot valójában a legtöbb útválasztott tervezések. Engedélyezze a konkrét forrásokat, célokat és szolgáltatásokat azon a belépési határon, amelyen a csomagok ténylegesen átlépnek, és ne feledje, hogy az olyan interfész-címke, mint a WAN, név, nem pedig a bizalomról szóló nyilatkozat. A privát forgalmat vivő átviteli porton továbbra is be lehet kapcsolva a privát címek blokkolása alapértelmezés szerint.

Ezután nézze meg a kimenő fordítást, mielőtt arra jutna, hogy nem történik NAT. Az automatikus kimenő szabályok átírhatnak olyan forgalmat, amelyet soha nem szántak fordításra, és ez tönkreteszi a forráscímeket, amelyekre a másik oldalnak a saját szabályzatához és naplóihoz szüksége van. Erősítse meg, hogy a kiválasztott folyamok megtartják eredeti címeiket, és hagyja békén az internetes fordítási szabályokat azon forgalom számára, amelynek még szüksége van rájuk.

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

Amikor a NAT az őszinte válasz

A fordítás akkor érdemli ki a helyét, amikor a címterületek valóban átfednek, és az újraszámozás nem elérhető, vagy amikor egy szabályzat megköveteli, hogy az egyik oldal egyetlen címet lásson alhálózat helyett. Ezekben az esetekben a szándékos egy-az-egyhez vagy portkorlátozott leképezés ismert következményekkel járó tervezési döntés, nem kerülőút.

A következmény, amelyet hangosan ki kell mondani, hogy a másik oldal már nem látja és nem szűri az egyedi forrásokat. A naplók a fordító címre omlanak össze, a hosztonkénti szabályzat megszűnik működni, és a hibaelhárítás annak hajszolásává válik, melyik belső hoszt birtokolt egy folyamot egy adott pillanatban. Ha ezek egyike sem számít az adott forgalom szempontjából, a NAT rendben van.

Amikor maga az átviteli szakasz a téves feltevés

Ha a közös szakasz szolgáltatón, közös kapcsolófabricon vagy olyan útvonalon halad át, ahol egy másik fél olvashatná a forgalmat, az útválasztás önmagában nem teljes válasz. A két tűzfal közötti alagút bizalmasságot és partnerhitelesítést ad, és a benne lévő útvonaltábla ugyanaz a tábla, amelyet az átviteli szakaszon írt volna.

Ezt az első szakasz bizalmi kérdéséből döntse el, nem abból a szokásból, hogy a VPN-ek biztonságosabbak. Egy már privát szakasz feletti alagút üzemeltetési költséget és még egy hiba módot ad hozzá haszon nélkül, míg a nem megbízható szakaszon való útválasztás a bizalmasságot olyan egyszerűségre cseréli, amelyet nem engedhet meg magának. Írja le, melyik a három feltétel közül vezérelte a választást, és a következő mérnöknek nem kell újra megvitatnia.