Maršrutizuokite tarp privačių LAN, prieš pridėdami dar vieną NAT

Dvi vidinės užkardos, vienas privatus tranzito segmentas ir prašymas leisti keliems hostams kiekviename LAN kalbėtis su kito LAN hostais. Įprasta reakcija – pastatyti VPN arba pridėti antrą NAT sluoksnį, ir abi reakcijos kainuoja daugiau, nei problema verta. Įprastas maršrutizavimas pakanka, kai galioja trys sąlygos: adresų diapazonai nesipersidengia, abi pusės gali grąžinti srautą į kitą LAN, o tranzito segmentas duomenims jau pakankamai patikimas. Patikrinkite šiuos tris, prieš ką nors projektuodami, nes kiekviena jų keičia atsakymą.

Trys sąlygos, lemiančios projektą

Pirmoji sąlyga – adresų erdvė. Jei abu LAN naudoja tą patį RFC 1918 bloką, maršrutizavimas negali jų atskirti, ir vertimas tampa neišvengiamas, o ne pasirenkamas. Antroji – grįžtamasis kelias: maršrutas iš A į B nenaudingas, jei B taip pat nežino, kaip pasiekti A LAN, o asimetrinės žinios yra dažniausia priežastis, kodėl maršrutizuotas projektas tyliai numeta atsakymus.

Trečioji – pasitikėjimas. Maršrutizavimas perduoda paketus; jis jų neapsaugo. Privatus tranzito segmentas viename pastate yra kas kita nei perdavimas paslaugų teikėjui arba jungtis, kertanti bendrą miestelio magistralę. Jei segmentu nepasitikima, atsakymas yra tunelis tarp dviejų užkardų, o žemiau pateiktas maršrutizavimo planas vis dar galioja jo viduje.

Tik kai visos trys rodo ta pačia kryptimi, paprastas projektas laimi. Kai viena jų sugenda, ištaisykite tą sąlygą aiškiai, o ne užmaskuokite vertimu, nes NAT slepia gedimą, o ne išsprendžia jį.

Sukurkite maršrutų planą tranzito tinkle

Suteikite kiekvienai užkardai adresą bendrame segmente ir pridėkite po vieną konkretų maršrutą kiekvienam nutolusiam LAN. Niekas kitas esamoje konfigūracijoje neturi judėti, o ypač interneto numatytasis maršrutas turi likti tiksliai ten, kur yra. Numatytąjį maršrutą pakeitus partnerio užkarda, kiekvienas nesusijęs tikslas būtų siunčiamas per tranzitą, o tai daug didesnis pakeitimas nei prašomasis. pfSense statinio maršrutizavimo dokumentacija aprašo tą patį maršruto ir šliuzo modelį tai platformai, o lygiavertis valdiklis egzistuoja bet kurioje užkardoje, kurią iš tikrųjų naudojate.

Užkarda A aptarnauja 10.30.0.0/24, o užkarda B – 10.40.0.0/24, o du tranzito adresai yra 192.0.2.0/24. Kiekvienas LAN hostas išlaiko savo vietinę užkardą kaip šliuzą, todėl vienintelė nauja būsena yra po vieną maršrutą kiekvienoje pusėje. Linux pagrindu veikiančioje užkardoje tas pats planas atrodo taip, ir persiuntimas turi būti įjungtas, kitaip maršrutas bus išspręstas, o paketas numestas.

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

Laikykite filtravimą atskirai nuo vertimo

Maršrutizavimas ir politika yra skirtingi valdikliai, ir būtent antrajame dauguma maršrutizuotų projektų iš tikrųjų žlunga. Leiskite konkrečius šaltinius, tikslus ir paslaugas įėjimo riboje, kurią paketai iš tikrųjų kerta, ir atminkite, kad sąsajos žymė, pavyzdžiui, WAN, yra pavadinimas, o ne pareiškimas apie pasitikėjimą. Tranzito prievadas, kuriuo eina privatus srautas, vis tiek gali turėti įjungtą privatų adresų blokavimą pagal numatytuosius nustatymus.

Tada pažiūrėkite į išeinantį vertimą, prieš darydami išvadą, kad NAT nevyksta. Automatinės išeinančios taisyklės gali perrašyti srautą, kuris niekada nebuvo skirtas vertimui, ir tai sunaikina šaltinio adresus, kurių kitai pusei reikia savo politikai ir žurnalams. Patvirtinkite, kad pasirinkti srautai išlaiko pradinius adresus, ir palikite interneto vertimo taisykles ramybėje tam srautui, kuriam jų dar reikia.

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

Kai NAT yra sąžiningas atsakymas

Vertimas užsitarnauja savo vietą, kai adresų diapazonai tikrai persidengia ir pernumeravimas neprieinamas, arba kai politika reikalauja, kad viena pusė matytų vieną adresą, o ne potinklį. Tokiais atvejais sąmoningas vienas-su-vienu arba prievadais apribotas susiejimas yra projektinis sprendimas su žinomomis pasekmėmis, o ne apeinamasis sprendimas.

Pasekmė, kurią reikia pasakyti garsiai, yra ta, kad kita pusė nebegali matyti ar filtruoti atskirų šaltinių. Žurnalai suplokštėja iki verčiančio adreso, politika kiekvienam hostui nustoja veikti, o trikčių šalinimas tampa medžiokle, kuris vidinis hostas tam tikru momentu turėjo srautą. Jei niekas iš to nagrinėjamam srautui nesvarbu, NAT tinka.

Kai pats tranzitas yra klaidinga prielaida

Jei bendras segmentas kerta paslaugų teikėją, bendrą perjungimo audinį ar bet kurį kelią, kuriame kita šalis galėtų skaityti srautą, vien maršrutizavimas nėra išsamus atsakymas. Tunelis tarp dviejų užkardų suteikia konfidencialumą ir partnerio autentifikavimą, o maršrutų lentelė jo viduje yra ta pati lentelė, kurią būtumėte rašę tranzite.

Nuspręskite tai pagal pasitikėjimo klausimą pirmame skyriuje, o ne pagal įprotį, kad VPN saugesni. Tunelis virš jau privataus segmento prideda eksploatacines išlaidas ir dar vieną gedimo režimą be naudos, o maršrutizavimas virš nepatikimo segmento iškeičia konfidencialumą į paprastumą, kurio negalite sau leisti. Užsirašykite, kuri iš trijų sąlygų lėmė pasirinkimą, ir kitam inžinieriui nereikės to vėl svarstyti.