SNAT, DNAT и Masquerade: какво прави всяко правило за NAT във VPN

Поставете прихващане от двете страни на VPN шлюз и един поток може да покаже четири различни адреса. Изходният NAT пренаписва мястото, откъдето пакетът твърди, че идва; целевият NAT пренаписва мястото, накъдето отива. Masquerade не е трета посока, а правило за изходен NAT, което взема адреса от изходящия интерфейс вместо фиксирана стойност. Назовете кое от трите наистина ви трябва и повечето тикети „VPN е счупен“ се свеждат до въпрос за обратния път.

Какво пренаписва всяко правило

Изходният NAT, обикновено записван SNAT, променя изходния адрес на поток, когато той напуска рутер или шлюз. Получаващата услуга отговаря на преведения адрес, а кутията, която превежда, обръща промяната чрез състоянието, което е пазила за тази връзка. В Linux това състояние живее в conntrack, затова conntrack -L отпечатва оригиналните и ответните кортежи един до друг.

Целевият NAT, DNAT, променя вместо това местоназначението. Пакет, адресиран до публичен адрес на UDP 51820, може да бъде пренаписан към вътрешен WireGuard сървър на 10.8.0.2:51820. Така домашен рутер или облачен балансьор публикува VPN слушател и това не казва нищо за това какво може да носи тунелът след това.

Masquerade принадлежи към семейството на SNAT. Правилото не назовава адрес; то използва какъвто адрес има изходящият интерфейс, когато пакетът излезе. Linux му дава собствена цел и това е обичайният избор на WAN интерфейс, който получава адреса си от DHCP или PPPoE.

Къде живее съпоставянето определя отказа

Записвайте кортежа на всяка граница: преди тунела, вътре в него и на публичния интерфейс. Прихващането вътре в тунела законно се различава от това отвън и всеки, който сравнява двете без да знае къде става преводът, ще гони грешния хост.

Обратният трафик трябва да минава през устройството, което държи съпоставянето. Ако отговорът поеме друг маршрут, втори ъплинк, маршрут по политика или доставчик, който никога не е чувал за частния ви диапазон, обръщащият превод със състояние не се случва и клиентът вижда еднопосочен трафик. Добавянето на още изходен NAT рядко поправя липсващ обратен маршрут; може да скрие симптома при един поток, докато чупи адресно базираната политика навсякъде другаде.

Другата честа грешка е да се очаква, че тунелът създава маршрутизируемост. Частен клиент, чиито пакети излизат в интернет, се нуждае от валидна схема за изход: маршрут по подразбиране, препращащ шлюз и обикновено изходен превод към публичен адрес. Шифроването само по себе си не прави частния адрес достъпен.

Masquerade или явен SNAT

Сравнете двете по това какво обещават. Masquerade избира изходящия адрес, явният SNAT го заковава. На шлюз със стабилен публичен адрес заковаването дава на журналите и на партньорските списъци за разрешение една предвидима стойност. На динамична WAN връзка закован SNAT адрес става грешен в момента, в който наемът се смени, а точно за този случай е създаден Masquerade.

Обхватът е толкова важен, колкото и изборът. Правило Masquerade, което съвпада с всеки пакет, напускащ шлюза, без ограничение по източник или местоназначение, превежда и трафик, който сте искали да остане непокътнат, включително трафик към други частни мрежи. Ограничете правилото до клиентския диапазон, желаното местоназначение и интерфейса.

При IPsec, базиран на политики, това боли най-силно. Ръководството на strongSwan за препращане преминава през включването на IP препращане и добавянето на правило за изходен NAT за клиенти, а същата документация покрива изключването на трафик, който трябва да запази оригиналния си адрес. Преведете източник, преди политиката за сигурност да го съпостави, и тунелът може да се вдигне, докато трафикът все още се отхвърля, защото пакетът вече не изглежда като договорения селектор.

Решете и какво трябва да вижда далечният край. След превода услугата вижда шлюза, не отделния клиент. Това опростява обратното маршрутизиране и същевременно изравнява журналите и обезсмисля списъците за разрешение по клиент. Ако запазването на клиентските адреси е важно, планирайте маршрутизиран обратен път, вместо да ги криете, за да мине тест.

Четене на правилата на Linux шлюз

Шлюз за отдалечен достъп с клиенти на 10.8.0.0/24 и WAN интерфейс с име eth0 се нуждае от включено препращане и филтрираща политика, която разрешава потока, преди което и да е NAT правило да помогне. Версията с iptables държи двете посоки в таблицата nat:

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
iptables -t nat -A PREROUTING -i eth0 -p udp --dport 51820 \
  -j DNAT --to-destination 10.8.0.2:51820

Формата с nftables използва същите две куки с именуван интерфейс и явна верига:

nft add rule ip nat postrouting ip saddr 10.8.0.0/24 oifname "eth0" masquerade
nft add rule ip nat prerouting iifname "eth0" udp dport 51820 dnat to 10.8.0.2:51820

И двата фрагмента предполагат, че филтриращата верига вече приема препращания поток. NAT не е правило за разрешение и правилно преведен пакет може да бъде отхвърлен една таблица по-късно. Потвърдете живото съпоставяне с conntrack -L, потвърдете какво е заредено с nft list ruleset или iptables-save -t nat, после прихванете на двата интерфейса, за да видите, че адресът наистина се променя.

Режими на отказ, които изглеждат като лошо правило

Трафикът тип фиба е класиката. Вътрешен клиент, който достига до вътрешен сървър през публичния адрес на сървъра, се нуждае от DNAT по пътя навътре и от изходен превод по пътя навън, иначе сървърът отговаря направо на клиента и отговорът се отхвърля. Поправката е второ, по-тясно правило за този случай вътрешно към публично, а не по-широко правило Masquerade за всичко.

Двойният превод е тихият. Клиент, който вече е зад NAT на операторско ниво, пристига на шлюза ви с адрес, който не можете да маршрутизирате обратно, затова превеждате отново. Работи, но журналите вече носят два скока частна адресация и всяко разследване се нуждае от двете съпоставяния. IPsec, базиран на политики, добавя трети обрат: преведете преди съпоставянето на политиката и получавате SA, което е вдигнато без трафик да минава, което изглежда като бъг във файъруола, не в NAT.

После има тест, който минава, и внедряване, което се проваля. Ръчното пускане на NAT командата доказва механизма, не конфигурацията. Правило, добавено по време на работа, изчезва при рестарт или при следващото събитие на интерфейса, а правило Masquerade, вързано към интерфейс, който сменя номера, може тихо да смени адреса, който вижда далечният край. Сложете правилото в конфигурацията на собствения файъруол и тествайте отново след повторно свързване.

Контролен списък преди да запазите правилото

Първо назовете посоката: източник, местоназначение или и двете. После определете кой трябва да държи състоянието — шлюзът, рутерът отгоре или IPsec партньорът — и потвърдете, че обратният път се връща през него. Ограничете правилото до клиентския диапазон, местоназначението и интерфейса, които наистина имате предвид, и решете предварително дали далечният край трябва да вижда шлюза или оригиналния клиентски адрес.

Тествайте от клиент, не от шлюза. Браузър на самия шлюз може напълно да заобиколи правилото за клиентски превод, затова работеща страница там не доказва нищо за тунела. Изпратете една заявка, започната от клиента, следете броячите и таблицата conntrack и повторете след повторно свързване на тунела и смяна на WAN адреса, ако някое от двете е възможно там, където работите.