Усмеравајте саобраћај између приватних 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-ови безбеднији. Тунел преко сегмента који је већ приватан додаје оперативни трошак и још један режим отказа без добити, док усмеравање преко непоузданог сегмента мења поверљивост за једноставност коју не можете да приуштите. Запишите који је од три услова водио избор, и следећи инжењер неће морати поново да га преиспитује.