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

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

Држите повратни пут са стањем

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