ufw allow 443 не направи нищо за услуга зад VPN

Ping минава от VPN клиент, TCP услугата не отговаря, а ufw allow 443/tcp не променя нищо. Когато приложението работи на хост зад шлюза, а не на самия шлюз, това разрешение е написано за грешен път на трафика. Пакетът не е адресиран до защитната стена и не се доставя до локален процес, затова правилата за входящ трафик никога не го виждат. Поправката е правило за маршрут, насочено към препращания поток, и доказателството за него вече е в журнала.

Определете дали дестинацията е локална или препращана

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

Ред в журнала с един и същ интерфейс в полетата IN и OUT може да описва препращан пакет, защото тунел, който пренася клиенти в и извън едно устройство, изглежда точно така. Адресът на дестинацията решава въпроса по-бързо от имената на интерфейсите. Виждането на едно и също име два пъти не доказва локална доставка, а измислянето на тунелен интерфейс, който внедряването никога не е създавало, също не помага.

Прочетете блокировката, преди да добавите каквото и да е правило

Възпроизведете един разрешен опит за свързване и запишете източника, дестинацията, протокола и порта на дестинацията така, както шлюзът ги е записал. Сравнете тези четири стойности със записа в журнала и с действителното местоположение на услугата. Успешен ping по-рано доказва само, че собственият му обмен е бил разрешен, а защитната стена може да третира TCP SYN към приложение съвсем различно.

sudo dmesg | grep "UFW BLOCK" | tail -n 5
sudo ufw status numbered

Първата команда връща присъдата заедно с полетата ѝ, а втората показва какво вече е заредено и в какъв ред. Прочетете и двете, преди да редактирате нещо, защото по-ранна забрана над вашето правило обяснява същия симптом без никакво липсващо правило.

Напишете най-тясното правило за маршрут, което пасва

В това ръководство клиентите идват по tun0 от 172.20.8.0/24, услугата слуша на 10.30.0.15 на порт 8443, а шлюзът излиза през ens5. Тези стойности са избрани да не приличат на подразбираща се стойност 10.0.0.0/16 в облачен VPC или на домашна мрежа 192.168.0.0/16, а 8443 държи примера далеч от собствения слушател на порт 443 на шлюза.

sudo ufw --dry-run route allow in on tun0 out on ens5 proto tcp from 172.20.8.0/24 to 10.30.0.15 port 8443

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

Пазете обратния път със запазване на състояние

UFW следи разрешените връзки, затова отговорите на разрешен препращан поток се допускат без изрично обратно правило. Добавянето на неограничено правило в обратна посока, за да проработи всичко, разширява политиката далеч отвъд едната услуга и не е необходимо за нормален обмен заявка-отговор. Пазете обратния път неявен, а набора от правила — четим.

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

sudo ufw route allow in on tun0 out on ens5 proto tcp from 172.20.8.0/24 to 10.30.0.15 port 8443
sudo ufw status numbered

Проверете какво UFW не може да наложи вместо вас

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

sysctl net.ipv4.ip_forward
ip route get 10.30.0.15

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

Завършете с тест на нова връзка при включена защитна стена, от разрешен източник и от несвързан такъв. Изключването на UFW премахва симптома и унищожава доказателството с една и съща команда, затова трябва да е последният експеримент, а не първият.