Маршруты паміж прыватнымі LAN, перш чым дадаць яшчэ адзін NAT

Два ўнутраныя файрволы, адзін прыватны транзітны сегмент і просьба дазволіць некалькім хастам у кожнай LAN звяртацца да другой. Звычайная рэакцыя — падняць VPN або дадаць другі слой NAT, і абедзве рэакцыі каштуюць даражэй, чым заслугоўвае праблема. Звычайная маршрутызацыя дастатковая, калі выконваюцца тры ўмовы: дыяпазоны адрасоў не перакрываюцца, абодва бакі могуць вяртаць трафік у іншую LAN, а транзітны сегмент ужо дастаткова давераны для гэтых даных. Праверце гэтыя тры ўмовы, перш чым нешта праектаваць, бо кожная з іх змяняе адказ.

Тры ўмовы, якія вызначаюць праект

Першая ўмова — адрасная прастора. Калі абедзве LAN выкарыстоўваюць адзін і той жа блок RFC 1918, маршрутызацыя не можа іх адрозніць, і трансляцыя становіцца непазбежнай, а не апцыянальнай. Другая — зваротны шлях: маршрут з A у B бескарысны, калі B таксама не ведае, як дасягнуць LAN пункта A, і асіметрычныя веды — самая частая прычына, па якой маршрутызаваны праект моўчкі губляе адказы.

Трэцяя — давер. Маршрутызацыя перамяшчае пакеты; яна іх не абараняе. Прыватны транзітны сегмент унутры аднаго будынка — гэта іншая справа, чым стык з правайдэрам або лінія, якая перасякае агульны кампусны магістральны канал. Калі сегменту не давяраюць, адказ — тунель паміж двума файрволамі, і план маршрутызацыі ніжэй усё яшчэ дзейнічае ўнутры яго.

Просты праект перамагае толькі тады, калі ўсе тры ўмовы паказваюць у адзін бок. Калі адна з іх не выконваецца, выпраўце менавіта гэтую ўмову, а не маскіруйце яе трансляцыяй, бо NAT хавае збой, а не вырашае яго.

Пабудуйце план маршрутаў на транзітнай сетцы

Дайце кожнаму файрволу адрас на агульным сегменце і дадайце адзін канкрэтны маршрут для кожнай аддаленай LAN. Нічога іншага ў існуючай канфігурацыі зрушваць не трэба, і асабліва маршрут па змаўчанні ў інтэрнэт павінен застацца менавіта там, дзе ён ёсць. Замена маршруту па змаўчанні на суседні файрвол адправіла б кожны незвязаны пункт прызначэння праз транзіт, што было б значна большая змена, чым тая, якую просяць. Дакументацыя pfSense па статычнай маршрутызацыі апісвае тую ж мадэль маршруту плюс шлюза для гэтай платформы, і эквівалентная налада існуе на любым файрволе, які вы фактычна выкарыстоўваеце.

Файрвол A абслугоўвае 10.30.0.0/24, а файрвол B — 10.40.0.0/24, прычым два транзітныя адрасы знаходзяцца ў 192.0.2.0/24. Кожны хост LAN захоўвае свой лакальны файрвол як шлюз, таму адзіны новы стан — адзін маршрут на кожным баку. На файрволе на базе Linux той жа план выглядае так, і перасыланне павінна быць уключана, інакш маршрут вызначыцца, а пакет будзе адкінуты.

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

Трымайце фільтрацыю асобна ад трансляцыі

Маршрутызацыя і палітыка — розныя сродкі кіравання, і менавіта на другім большасць маршрутызаваных праектаў фактычна церпіць няўдачу. Дазвольце канкрэтныя крыніцы, пункты прызначэння і сэрвісы на мяжы ўваходу, якую пакеты сапраўды перасякаюць, і памятайце, што назва інтэрфейса, напрыклад WAN, — гэта імя, а не сцвярджэнне пра давер. Транзітны порт, які нясе прыватны трафік, можа мець блакаванне прыватных адрасоў, уключанае па змаўчанні.

Затым паглядзіце на зыходную трансляцыю, перш чым заключыць, што NAT не адбываецца. Аўтаматычныя правілы зыходнага трафіку могуць перапісаць трафік, які ніколі не прызначаўся для трансляцыі, і гэта знішчае адрасы крыніц, патрэбныя іншаму боку для ўласнай палітыкі і журналаў. Пацвердзіце, што выбраныя патоку захоўваюць зыходныя адрасы, і не чапайце правілы інтэрнэт-трансляцыі для трафіку, які ўсё яшчэ іх патрабуе.

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

Калі NAT — гэта сумленны адказ

Трансляцыя заслугоўвае свайго месца, калі дыяпазоны адрасоў сапраўды перакрываюцца і перанумарацыя недаступная, або калі палітыка патрабуе, каб адзін бок бачыў адзін адрас, а не падсетку. У такіх выпадках наўмыснае супастаўленне адзін-да-аднаго або з абмежаваннем портаў — гэта праектнае рашэнне з вядомымі наступствамі, а не абыходны шлях.

Наступства, якое трэба назваць уголас, — гэта тое, што іншы бок больш не можа бачыць або фільтраваць асобныя крыніцы. Журналы зліваюцца ў адзін адрас трансляцыі, палітыка па кожным хосце перастае працаваць, а пошук няспраўнасцей ператвараецца ў пошук таго, які ўнутраны хост валодаў патокам у пэўны момант. Калі нішто з гэтага не мае значэння для разгляданага трафіку, NAT — гэта нармальна.

Калі сам транзіт — гэта няправільная здагадка

Калі агульны сегмент перасякае правайдэра, агульную камутацыйную матрыцу або любы шлях, дзе іншы бок мог бы чытаць трафік, адной маршрутызацыі недастаткова для поўнага адказу. Тунель паміж двума файрволамі дае канфідэнцыйнасць і аўтэнтыфікацыю партнёра, а табліца маршрутаў унутры яго — тая ж табліца, якую вы напісалі б на транзіце.

Вырашайце гэта з пытання даверу ў першым раздзеле, а не з прывычкі, што VPN больш бяспечныя. Тунель праз сегмент, які ўжо прыватны, дадае эксплуатацыйныя выдаткі і яшчэ адзін рэжым адмовы без выгады, а маршрутызацыя праз недавераны сегмент абменьвае канфідэнцыйнасць на прастату, якую вы не можаце сабе дазволіць. Запішыце, якая з трох умоў вызначыла выбар, і наступнаму інжынеру не давядзецца абмяркоўваць гэта зноў.