ufw allow 443 nepomohol službe za VPN

Ping prejde z klienta VPN, služba TCP vyprší a ufw allow 443/tcp nezmení vôbec nič. Keď aplikácia beží na hostiteľovi za bránou a nie na samotnej bráne, toto povolenie bolo napísané pre nesprávnu cestu prevádzky. Paket nie je adresovaný firewallu a nie je doručený miestnemu procesu, takže vstupné pravidlá ho nikdy nevidia. Oprava je pravidlo trasy zamerané na preposielaný tok a dôkaz o ňom už je v logu.

Rozhodnite, či je cieľ miestny alebo preposielaný

Čítajte paket tak, ako ho vidí jadro. Prevádzka doručená službe na bráne je miestny vstup. Prevádzka, ktorú brána smeruje ďalej na iného hostiteľa, je preposielaná, a UFW drží pre obe cesty oddelené sady pravidiel. Rozdiel určuje cieľová adresa a vyhľadanie trasy, nie rozhranie, na ktorom paket dorazil.

Riadok logu s rovnakým rozhraním v poliach IN aj OUT môže stále opisovať smerovaný paket, pretože tunel, ktorý prenáša klientov dovnútra a von z jedného zariadenia, vyzerá presne tak. Cieľová adresa túto otázku vyrieši rýchlejšie ako názvy rozhraní. Dvakrát videné rovnaké meno miestne doručenie nedokazuje a vymýšľanie tunelového rozhrania, ktoré nasadenie nikdy nevytvorilo, tiež nepomôže.

Prečítajte si blok, skôr než pridáte akékoľvek pravidlo

Zopakujte jeden autorizovaný pokus o pripojenie a zaznamenajte jeho zdroj, cieľ, protokol a cieľový port tak, ako ich zaznamenala brána. Porovnajte tieto štyri hodnoty so záznamom v logu a so skutočným umiestnením služby. Skorší úspešný ping dokazuje len to, že jeho vlastná výmena bola povolená, a firewall môže TCP SYN k aplikácii ošetriť úplne inak.

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

Prvý príkaz vráti verdikt spolu s jeho poľami a druhý ukáže, čo je už načítané a v akom poradí. Prečítajte si oba, skôr než čokoľvek upravíte, pretože skoršie odmietnutie nad vaším pravidlom vysvetľuje rovnaký symptóm aj bez akéhokoľvek chýbajúceho pravidla.

Napíšte najužšie pravidlo trasy, ktoré sedí

V tomto príklade klienti prichádzajú cez tun0 z 172.20.8.0/24, služba počúva na 10.30.0.15 na porte 8443 a brána vychádza cez ens5. Tieto hodnoty boli zvolené tak, aby vôbec nevyzerali ako predvolená hodnota cloudového VPC 10.0.0.0/16 ani domáca sieť 192.168.0.0/16, a 8443 drží príklad ďalej od vlastného poslucháča 443 na bráne.

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

Skúšobný beh vypíše sadu pravidiel, ktorá by vznikla, a to je najlacnejší spôsob, ako zistiť, či vaše pravidlo dopadne pred existujúcim zákazom alebo po ňom. Overte názvy rozhraní a vnútorné adresy proti nasadeniu, nie proti príkladu, a pamätajte, že keď sa preklad cieľovej adresy vykoná prvý, filter vidí už preložený cieľ.

Udržte spiatočnú cestu stavovú

UFW sleduje povolené spojenia, takže odpovede na povolený preposielaný tok sa prepustia bez výslovného opačného pravidla. Pridanie neobmedzeného pravidla opačným smerom, aby to fungovalo, rozširuje politiku ďaleko za jedinú službu a pre bežnú výmenu požiadavky a odpovede nie je potrebné. Udržte spiatočnú cestu implicitnú a sadu pravidiel čitateľnú.

Pravidlo použite až vtedy, keď skúšobný beh zodpovedá vášmu zámeru, a potom potvrďte, že ho zoradený zoznam ukazuje na očakávanom mieste. Uchovajte poslucháč VPN a pravidlá správy ako oddelené záležitosti, pretože ich zmena je iné rozhodnutie než povolenie jednej aplikácie. Poznamenajte zmenu tam, kde je zapísaná topológia, aby ju budúci inžinier nemusel znovu objavovať zo zachytených 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

Skontrolujte, čo za vás UFW nemôže vynútiť

Správne pravidlo stále potrebuje preposielanie v jadre a trasu, ktorá sa dostane k službe. Potvrďte oboje, skôr než firewall obviníte druhýkrát.

sysctl net.ipv4.ip_forward
ip route get 10.30.0.15

Potom sa pozrite mimo hostiteľa. V cloudovej inštancii politika UFW hosťa nenahrádza bezpečnostné skupiny, ACL podsiete ani vlastnú konfiguráciu preposielania poskytovateľa, takže miestna blokáda je dôkaz o jednej vrstve a nie dôkaz, že všetky ostatné vrstvy službu prepúšťajú.

Skončite testom nového spojenia so zapnutým firewallom, z povoleného zdroja a z nesúvisiaceho. Vypnutie UFW odstráni symptóm a zničí dôkaz v jedinom príkaze, a preto by to mal byť posledný experiment, nie prvý.