ufw allow 443 ni pomagal storitvi za VPN

Ping uspe iz odjemalca VPN, storitev TCP poteče, in ufw allow 443/tcp ne spremeni čisto ničesar. Ko aplikacija teče na gostitelju za prehodom in ne na samem prehodu, je bilo to dovoljenje napisano za napačno pot prometa. Paket ni naslovljen na požarni zid in ni dostavljen nobenemu lokalnemu procesu, zato ga vhodna pravila nikoli ne vidijo. Popravek je pravilo poti, usmerjeno na posredovani tok, in dokaz zanj je že v dnevniku.

Odločite, ali je cilj lokalen ali posredovan

Berite paket tako, kot ga vidi jedro. Promet, dostavljen storitvi na prehodu, je lokalni vhod. Promet, ki ga prehod usmeri naprej na drugega gostitelja, je posredovan, in UFW vodi ločene nize pravil za obe poti. Razliko določata ciljni naslov in iskanje poti, ne vmesnik, po katerem je paket prispel.

Vrstica dnevnika z istim vmesnikom v obeh poljih IN in OUT lahko še vedno opisuje usmerjen paket, ker je tunel, ki prenaša odjemalce v eno napravo in iz nje, videti natanko tako. Ciljni naslov to vprašanje razreši hitreje kot imena vmesnikov. Dvakrat videno isto ime ne dokazuje lokalne dostave, izmišljanje tunelskega vmesnika, ki ga namestitev ni nikoli ustvarila, pa tudi ne pomaga.

Preberite blok, preden dodate kakršno koli pravilo

Ponovite en pooblaščen poskus povezave in zabeležite njegov vir, cilj, protokol in ciljna vrata tako, kot jih je zabeležil prehod. Primerjajte te štiri vrednosti z vnosom v dnevniku in z dejansko lokacijo storitve. Prejšnji uspešni ping dokazuje le, da je bila dovoljena njegova lastna izmenjava, požarni zid pa lahko TCP SYN do aplikacije obravnava povsem drugače.

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

Prvi ukaz vrne razsodbo skupaj z njenimi polji, drugi pa pokaže, kaj je že naloženo in v kakšnem vrstnem redu. Preberite oba, preden karkoli uredite, ker prejšnja zavrnitev nad vašim pravilom pojasni isto simptomatiko brez kakršnega koli manjkajočega pravila.

Napišite najožje pravilo poti, ki ustreza

V tem primeru odjemalci prihajajo na tun0 iz 172.20.8.0/24, storitev posluša na 10.30.0.15 na vratih 8443, prehod pa izstopa skozi ens5. Te vrednosti so bile izbrane, da niso prav nič podobne privzeti vrednosti oblaka VPC 10.0.0.0/16 ali domačemu omrežju 192.168.0.0/16, in 8443 drži primer stran od lastnega poslušalca 443 na prehodu.

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

Preizkusni tek izpiše niz pravil, ki bi nastal, in to je najcenejši način, da vidite, ali vaše pravilo pade pred obstoječo zavrnitvijo ali za njo. Preverite imena vmesnikov in notranje naslove glede na namestitev in ne glede na primer, ter ne pozabite, da ob prvem izvajanju NAT cilja filter vidi že prevedeni cilj.

Ohranite povratno pot s stanjem

UFW sledi dovoljenim povezavam, zato so odgovori na dovoljen posredovani tok sprejeti brez izrecnega obratnega pravila. Dodajanje neomejenega pravila v nasprotni smeri, da bi stvari delovale, razširi politiko daleč preko ene storitve in ni potrebno za običajno izmenjavo zahteve in odgovora. Ohranite povratno pot implicitno in niz pravil berljiv.

Pravilo uporabite šele, ko se preizkusni tek ujema z vašim namenom, nato potrdite, da ga urejeni seznam prikazuje na pričakovanem mestu. Ohranite poslušalec VPN in pravila upravljanja kot ločeni zadevi, ker je njihova sprememba druga odločitev kot spustiti eno aplikacijo. Zabeležite spremembo tam, kjer je zapisana topologija, da je naslednji inženir ne bo moral znova odkrivati iz zajema paketov.

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

Preverite, česa UFW ne more uveljaviti namesto vas

Pravilno pravilo še vedno potrebuje posredovanje v jedru in pot, ki doseže storitev. Potrdite oboje, preden požarni zid obtožite drugič.

sysctl net.ipv4.ip_forward
ip route get 10.30.0.15

Nato poglejte izven gostitelja. V primerku v oblaku politika UFW gosta ne nadomesti varnostnih skupin, ACL podomrežja ali lastne konfiguracije posredovanja ponudnika, zato je lokalna blokada dokaz o enem sloju in ne dokaz, da vsi drugi sloji prepuščajo storitev.

Končajte s preizkusom nove povezave z vklopljenim požarnim zidom, iz dovoljenega vira in iz nepovezanega. Izklop UFW odpravi simptom in uniči dokaz v istem ukazu, zato bi moral biti zadnji poskus in ne prvi.