ufw allow 443 nije učinio ništa za uslugu iza VPN-a

Ping prolazi sa VPN klijenta, TCP usluga ne odgovara, a ufw allow 443/tcp ne mijenja ništa. Kada aplikacija radi na domaćinu iza mrežnog prolaza, a ne na samom prolazu, ta dozvola je napisana za pogrešan put saobraćaja. Paket nije adresiran na firewall i ne dostavlja se lokalnom procesu, pa ga ulazna pravila nikada ne vide. Popravka je pravilo rute usmjereno na proslijeđeni tok, a dokaz za to već je u zapisniku.

Utvrdite je li odredište lokalno ili proslijeđeno

Čitajte paket onako kako ga vidi kernel. Saobraćaj koji se dostavlja usluzi na prolazu je lokalni ulaz. Saobraćaj koji prolaz prosljeđuje drugom domaćinu je proslijeđen, a UFW drži odvojene skupove pravila za ta dva puta. Razlika se određuje pomoću odredišne adrese i pretrage rute, a ne pomoću interfejsa na koji je paket stigao.

Zapis u dnevniku koji pokazuje isti interfejs u poljima IN i OUT ipak može opisivati rutirani paket, jer tunel koji nosi klijente unutar jedne naprave i izvan nje izgleda upravo tako. Odredišna adresa rješava pitanje brže nego nazivi interfejsa. Dvaput viđeno isto ime ne dokazuje lokalnu dostavu, a izmišljanje tunelskog interfejsa koji implementacija nikada nije stvorila također ne pomaže.

Pročitajte blok prije nego dodate bilo koje pravilo

Reproducirajte jedan ovlašteni pokušaj povezivanja i zabilježite njegov izvor, odredište, protokol i odredišni port onako kako ih je prolaz zabilježio. Uporedite te četiri vrijednosti sa zapisom u dnevniku i sa stvarnim položajem usluge. Raniji uspješni ping dokazuje samo da je njegova vlastita razmjena bila dozvoljena, a firewall može tretirati TCP SYN prema aplikaciji sasvim drugačije.

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

Prva naredba vraća presudu zajedno sa njenim poljima, a druga pokazuje šta je već učitano i kojim redom. Pročitajte oboje prije nego bilo šta uredite, jer ranija zabrana iznad vašeg pravila objašnjava isti simptom bez ikakvog pravila koje nedostaje.

Napišite najužu rutu koja odgovara

U ovom primjeru klijenti dolaze preko tun0 sa 172.20.8.0/24, usluga sluša na 10.30.0.15 na portu 8443, a prolaz izlazi kroz ens5. Te vrijednosti su odabrane da ne liče na zadanu vrijednost oblaka VPC 10.0.0.0/16 ili kućnu mrežu 192.168.0.0/16, a 8443 drži primjer podalje od vlastitog slušača na portu 443 samog prolaza.

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

Probno pokretanje ispisuje skup pravila koji bi nastao, a to je najjeftiniji način da vidite da li vaše pravilo pada prije ili poslije postojeće zabrane. Provjerite nazive interfejsa i unutrašnje adrese prema implementaciji, a ne prema primjeru, i zapamtite da kada se prevođenje odredišta izvrši prvo, filter vidi prevedeno odredište.

Održite povratni put sa stanjem

UFW prati dozvoljene veze, pa se odgovori na dozvoljeni proslijeđeni tok primaju bez izričitog obrnutog pravila. Dodavanje neograničenog pravila u suprotnom smjeru da bi sve radilo širi politiku daleko izvan jedne usluge i nije potrebno za normalnu razmjenu zahtjeva i odgovora. Povratni put držite implicitnim, a skup pravila čitljivim.

Primijenite pravilo tek kada probno pokretanje odgovara vašoj namjeri, pa potvrdite da ga uređena lista prikazuje na očekivanom mjestu. Čuvajte VPN slušač i pravila upravljanja kao odvojene stvari; promjena njih je drugačija odluka od puštanja jedne aplikacije. Zabilježite promjenu tamo gdje je topologija zapisana, da je sljedeći inženjer ne otkriva ponovo iz snimke paketa.

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

Provjerite što UFW ne može provesti umjesto vas

Ispravno pravilo i dalje traži prosljeđivanje u kernelu i rutu koja stiže do usluge. Potvrdite oboje prije nego drugi put krivite firewall.

sysctl net.ipv4.ip_forward
ip route get 10.30.0.15

Zatim pogledajte izvan domaćina. Na instanci u oblaku UFW politika gosta ne zamjenjuje sigurnosne grupe, ACL-ove podmreže ni vlastitu konfiguraciju prosljeđivanja provajdera, pa je lokalni blok dokaz o jednom sloju, a ne dokaz da svi ostali slojevi propuštaju uslugu.

Završite testiranjem nove veze sa uključenim firewallom, sa dozvoljenog izvora i sa nepovezanog. Isključivanje UFW-a uklanja simptom i uništava dokaz istom naredbom, zato to treba biti posljednji eksperiment, a ne prvi.