Маршрутизиране между частни 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 е по-сигурен. Тунел върху сегмент, който вече е частен, добавя оперативни разходи и още един режим на отказ без полза, докато маршрутизирането върху недоверен сегмент разменя поверителност срещу простота, която не можете да си позволите. Запишете кое от трите условия е продиктувало избора и следващият инженер няма да трябва да го преразглежда.