Каде му е местото на VPN NAT во before.rules на UFW и како да се тестира

NAT правилото што работи кога се внесува во shell не успева кога се вметнува во before.rules, затоа што таа датотека не е скрипта. Таа е документ во формат за враќање со делови од табели, декларации за синџири и COMMIT ознака за секоја табела. Линија на погрешно место или ја прекинува целата операција за враќање или тивко ги отфрла правилата за кои мислевте дека постојат. Постапката подолу го става фрагментот таму каде што рамката го очекува и го докажува резултатот пред следното вчитување.

Командата во shell не е датотека за враќање

Линијата што започнува со iptables -t nat е упатство за бинарниот фајл iptables, додека датотеката што ја чита UFW е опис на целосен сет правила. Разликата не е козметичка: форматот за враќање мора да знае во која табела се наоѓа, кои синџири постојат и каде завршува табелата. Командата вметната во тој документ е или синтаксна грешка или, уште полошо, правило прикачено на погрешната табела. Рамката ги вчитува овие датотеки преку алатки за враќање токму затоа што се декларативни, а не секвенцијални.

Документот се вчитува и како целина, па еден неисправен дел може да го запре применувањето на остатокот од датотеката. Затоа мала грешка во NAT фрагментот ги повлекува со себе и правилата за филтрирање, и така промена на огнениот ѕид станува прекин.

Ставете го фрагментот во постоечкиот дел од табелата

NAT фрагментот има форма, а формата е поважна од текстот на правилото во него. Заглавието на табелата го отвора делот, декларациите за синџири ги поставуваат бројачите, правилата следат, а COMMIT го затвора делот.

*nat
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -s 10.55.0.0/24 -o ens3 -j MASQUERADE
COMMIT

Базенот и интерфејсот погоре се места за вашите вредности; структурата е делот што вреди да се копира. Ако датотеката веќе содржи дел *nat, додајте го правилото во тој дел наместо да отворите втор, бидејќи форматот очекува еден COMMIT по табела, а два дела за истата табела се поправка што чека да се случи. Зачувајте ги дефинициите на синџирите на дистрибуцијата недопрени, вклучувајќи ги и оние што добавувачот ги додал за сопствена интеграција. Прирачникот за рамката UFW ги документира датотеките before, user и after заедно со барањето за соодветен COMMIT.

Ако датотеката излезе празна, не ја пополнувајте од учебник. Потврдете кој пакет ја поседува и каква е навистина активната политика, бидејќи празна постојана датотека не докажува дека јадрото нема правила, а вчитан сет правила не докажува дека следното вчитување ќе има целосна датотека за читање. Прво вратете ја поддржаната основна линија, потоа повторно применете ги промените на страницата врз неа.

Тестирајте го кандидатот без да го примените

Алатката за враќање може да анализира и изгради сет правила без да го примени, што е најевтиниот достапен тест. Извршете ја врз заштитено копие, а не врз активната датотека, и читајте го текстот на грешката, а не само статусот на излезот. Неуспехот при анализа именува линија и обично табела, што е повеќе отколку што ќе ви каже неуспешното вчитување.

sudo cp /etc/ufw/before.rules /root/before.rules.bak
sudo iptables-restore --test < /root/before.rules.bak
echo "exit: 0"

Поминувањето на таа проверка докажува дека документот се анализира и ништо друго. Таа не докажува дека кандидатот сѐ уште го содржи секој синџир од кој зависи UFW, дека дозволува само изворите што ги имавте на ум или дека далечинската администрација останува достапна. Тоа се одделни прегледи, а последниот заслужува втора сесија отворена пред да започнете.

Изберете ја алатката што одговара на инсталираниот backend и на семејството адреси. Домаќин што го извршува nft backend преку слојот за компатибилност бара соодветна команда, а правилата IPv6 живеат во сосема друга датотека.

Држете го пренесувањето, NAT и политиката за пристап одделно

Преводот на изворот решава проблем со адресирање и не дава ништо. Пренесувањето е одделна дозвола контролирана од sysctl и од табелата за филтрирање, и тоа е она што луѓето го забораваат кога тунелот маршрутизира, но не пропушта сообраќај. Политиката за пристап е трета одлука за тоа кои извори можат да достигнат кои услуги, и ниту едно NAT правило не ја изразува. Токму одвојувањето на овие три го прави дефектот дијагностички, наместо еден нејасен симптом.

sysctl net.ipv4.ip_forward
sudo iptables -t nat -S POSTROUTING
sudo iptables -S FORWARD

Читајте ги овие три излези заедно, а не еден по еден. Правилото masquerade со исклучено пренесување создава клиент што се поврзува и не стигнува никаде, што од страната на клиентот изгледа точно како дефект во насочувањето и ги испраќа луѓето на погрешната датотека. Табелата за филтрирање е и местото каде што се крие премногу широк accept, затоа проверете ја нејзината стандардна политика додека сте таму.

Проверете повторно вчитување, одбивање и губење на VPN

Три набљудувања сочинуваат целосен тест за прифаќање: повторното вчитување успева, дозволената операција на клиентот работи, и барањето што треба да биде одбиено навистина се одбива. Третото е она што се прескокнува, и тоа е единствениот доказ дека политиката воопшто прави нешто.

sudo ufw reload
sudo ufw status verbose
sudo iptables -t nat -L POSTROUTING -n -v

Потоа тестирајте го дефектот за кој проектиравте. Пуштете го тунелот и набљудувајте што прави домаќинот, бидејќи политика што работи само додека VPN е вклучен е политика со неизречена зависност. Потоа вчитајте уште еднаш за да докажете дека работниот резултат го дава датотеката, а не некаква преостаната работна состојба.

IPv4 NAT не кажува ништо за IPv6, затоа наведете го предвиденото покривање за двете семејства во истата белешка како правилото. Целта е кожерентна управувана политика, а фрагментот што случајно се анализирал не е доказ за неа.