Насочувајте меѓу приватни 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 се побезбедни. Тунел над веќе приватен сегмент додава оперативен трошок и уште еден режим на откажување без добивка, додека насочувањето над недоверлив сегмент ја заменува доверливоста за едноставност што не можете да си ја дозволите. Запишете кој од трите услови ја водеше одлуката, и следниот инженер нема да мора повторно да го преиспитува.