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. Тие вредности се избрани за воопшто да не личат на стандардната вредност на облачен VPC 10.0.0.0/16 или домашна мрежа 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

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

Држете го повратниот пат со состојба

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 го отстранува симптомот и го уништува доказот во истата команда, затоа тоа треба да биде последниот експеримент, а не првиот.