Az ufw allow 443 semmit sem tett a VPN mögötti szolgáltatásért

A ping sikerül egy VPN-kliensről, a TCP-szolgáltatás időtúllépésbe fut, és a ufw allow 443/tcp semmit sem változtat. Amikor az alkalmazás az átjáró mögötti hoszton fut, és nem magán az átjárón, ez az engedély a rossz forgalmi útvonalra íródott. A csomag nincs a tűzfalra címezve, és nem kerül helyi folyamathoz, ezért a bemeneti szabályok soha nem látják. A javítás a továbbított folyamatra irányuló útvonal-szabály, és a bizonyíték már ott van a naplóban.

Döntsd el, hogy a cél helyi vagy továbbított

Olvasd a csomagot úgy, ahogy a kernel látja. Az átjárón lévő szolgáltatásnak átadott forgalom helyi bemenet. A forgalom, amelyet az átjáró továbbít egy másik hoszt felé, továbbított, és az UFW külön szabálykészletet tart a két útvonalhoz. A különbséget a célcím és az útvonalkeresés dönti el, nem az a hálózati csatoló, amelyen a csomag érkezett.

Egy naplósor, amely ugyanazt a csatolót mutatja az IN és az OUT mezőben, még mindig leírhat egy átirányított csomagot, mert egy alagút, amely egyetlen eszközön belül és kívül szállít ügyfeleket, pontosan így néz ki. A célcím gyorsabban eldönti a kérdést, mint a csatolók nevei. Ugyanazt a nevet kétszer látni nem bizonyítja a helyi kézbesítést, és egy olyan alagút-csatoló kitalálása sem segít, amelyet a telepítés soha nem hozott létre.

Olvasd el a blokkot, mielőtt bármilyen szabályt hozzáadnál

Játssz újra egy engedélyezett kapcsolódási kísérletet, és rögzítsd a forrását, célját, protokollját és célportját úgy, ahogy az átjáró rögzítette őket. Hasonlítsd össze ezt a négy értéket a naplóbejegyzéssel és a szolgáltatás tényleges helyével. Egy korábbi sikeres ping csak azt bizonyítja, hogy a saját cseréje engedélyezett volt, és egy tűzfal egészen másképp kezelhet egy alkalmazás felé menő TCP SYN-t.

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

Az első parancs visszaadja az ítéletet a mezőivel együtt, a második pedig megmutatja, mi van már betöltve és milyen sorrendben. Olvasd el mindkettőt, mielőtt bármit szerkesztenél, mert a szabályod feletti korábbi tiltás ugyanazt a tünetet magyarázza hiányzó szabály nélkül is.

Írd meg a legszűkebb megfelelő útvonal-szabályt

Ebben a példában az ügyfelek a tun0 csatolón érkeznek a 172.20.8.0/24 címről, a szolgáltatás a 10.30.0.15 címen a 8443 porton figyel, és az átjáró a ens5 csatolón lép ki. Ezeket az értékeket azért választottuk, hogy egyáltalán ne hasonlítsanak egy felhős VPC 10.0.0.0/16-os alapértékére vagy egy otthoni 192.168.0.0/16-os hálózatra, és a 8443 távol tartja a példát az átjáró saját 443-as figyelőjétől.

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

A próbafuttatás kiírja a létrejövő szabálykészletet, és ez a legolcsóbb módja annak megállapítására, hogy a szabályod egy meglévő tiltás elé vagy mögé kerül-e. Ellenőrizd a csatolók neveit és a belső címeket a telepítéshez képest, ne a példához, és ne feledd, hogy amikor a cél NAT fut először, a szűrő a lefordított célt látja.

Tartsd az állapotkövető visszaútvonalat

Az UFW követi az engedélyezett kapcsolatokat, ezért az engedélyezett továbbított folyam válaszai kifejezett fordított szabály nélkül is beengedődnek. Egy korlátlan szabály hozzáadása az ellenkező irányba, hogy a dolgok működjenek, messze az egyetlen szolgáltatáson túl szélesíti a házirendet, és egy normál kérés-válasz cseréhez nem szükséges. Tartsd a visszaútvonalat implicitnek és a szabálykészletet olvashatónak.

Csak akkor alkalmazd a szabályt, ha a próbafuttatás megfelel a szándékodnak, majd igazold, hogy a rendezett lista a várt helyen mutatja. Tartsd a VPN-figyelőt és a kezelési szabályokat külön ügyként, mert ezek módosítása más döntés, mint egy alkalmazás beengedése. Jegyezd fel a változtatást ott, ahol a topológia le van írva, hogy a következő mérnöknek ne kelljen újra felfedeznie egy csomagrögzítésből.

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

Ellenőrizd, mit nem tud helyetted érvényesíteni az UFW

Egy helyes szabályhoz továbbra is kell kernel-továbbítás és egy útvonal, amely eléri a szolgáltatást. Igazold mindkettőt, mielőtt másodszor is a tűzfalat hibáztatnád.

sysctl net.ipv4.ip_forward
ip route get 10.30.0.15

Aztán nézz a hoszton kívülre. Felhős példányon a vendég UFW-házirendje nem helyettesíti a biztonsági csoportokat, az alhálózati ACL-eket vagy a szolgáltató saját továbbítási konfigurációját, ezért egy helyi tiltás egy rétegről szóló bizonyíték, nem pedig annak bizonyítéka, hogy minden más réteg engedi a szolgáltatást.

Fejezd be egy friss kapcsolat tesztelésével bekapcsolt tűzfal mellett, egy engedélyezett forrásból és egy nem kapcsolódó forrásból. Az UFW kikapcsolása ugyanabban a parancsban megszünteti a tünetet és megsemmisíti a bizonyítékot, ezért az utolsó kísérletnek kell lennie, nem az elsőnek.