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, калі хоць адно з гэтага магчыма там, дзе вы працуеце.