ufw allow 443 hjalp intet for en tjeneste bag VPN'en

Ping lykkes fra en VPN-klient, TCP-tjenesten timer ud, og ufw allow 443/tcp ændrer slet ingenting. Når applikationen kører på en vært bag gatewayen i stedet for på gatewayen selv, blev den tilladelse skrevet til den forkerte trafikvej. Pakken er ikke adresseret til firewallen og bliver ikke leveret til en lokal proces, så inputreglerne ser den aldrig. Rettelsen er en ruterregel rettet mod den videresendte strøm, og beviset for den findes allerede i loggen.

Afgør, om destinationen er lokal eller videresendt

Læs pakken, som kernen ser den. Trafik leveret til en tjeneste på gatewayen er lokalt input. Trafik, som gatewayen ruter videre til en anden vært, er videresendt, og UFW holder separate regelsæt for de to veje. Forskellen afgøres af destinationsadressen og ruteopslaget, ikke af hvilket interface pakken ankom på.

En loglinje med det samme interface i både IN- og OUT-feltet kan stadig beskrive en rutet pakke, fordi en tunnel, der bærer klienter ind og ud af én enhed, ser præcis sådan ud. Destinationsadressen afgør spørgsmålet hurtigere, end interfacenavnene gør. At se det samme navn to gange beviser ikke lokal levering, og at opfinde et tunnelinterface, som udrulningen aldrig har oprettet, hjælper heller ikke.

Læs blokeringen, før du tilføjer nogen regel

Gengiv ét autoriseret forbindelsesforsøg, og registrer dets kilde, destination, protokol og destinationsport, som gatewayen registrerede dem. Sammenlign de fire værdier med logposten og med tjenestens faktiske placering. En tidligere vellykket ping beviser kun, at dens egen udveksling var tilladt, og en firewall kan behandle et TCP SYN mod en applikation helt anderledes.

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

Den første kommando returnerer afgørelsen med dens felter, og den anden viser, hvad der allerede er indlæst, og i hvilken rækkefølge. Læs begge, før du redigerer noget, fordi en tidligere afvisning over din regel forklarer det samme symptom uden nogen manglende regel.

Skriv den snævreste ruterregel, der passer

I denne gennemgang ankommer klienter på tun0 fra 172.20.8.0/24, tjenesten lytter på 10.30.0.15 på port 8443, og gatewayen går ud gennem ens5. De værdier er valgt for slet ikke at ligne en cloud-VPC-standard på 10.0.0.0/16 eller et hjemmenetværk på 192.168.0.0/16, og 8443 holder eksemplet væk fra gatewayens egen 443-lytter.

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

Prøvekørslen udskriver det regelsæt, der ville blive resultatet, og det er den billigste måde at se, om din regel lander før eller efter en eksisterende afvisning. Bekræft interfacenavne og indre adresser mod udrulningen i stedet for mod eksemplet, og husk, at når destinations-NAT kører først, ser filteret den oversatte destination.

Hold returvejen stateful

UFW sporer tilladte forbindelser, så svarene på en tilladt videresendt strøm lukkes ind uden en eksplicit omvendt regel. At tilføje en ubegrænset regel i den modsatte retning for at få tingene til at virke udvider politikken langt ud over den enkelte tjeneste og er ikke nødvendigt for en normal anmodning-svar-udveksling. Hold returvejen implicit og regelsættet læsbart.

Anvend kun reglen, når prøvekørslen matcher din hensigt, og bekræft derefter, at den ordnede liste viser den på den forventede plads. Bevar VPN-lytteren og administrationsreglerne som særskilte anliggender, fordi en ændring af dem er en anden beslutning end at lukke én applikation ind. Notér ændringen samme sted, hvor topologien er skrevet ned, så den næste ingeniør ikke skal genopdage den ud fra en pakkefangst.

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

Tjek, hvad UFW ikke kan håndhæve for dig

En korrekt regel kræver stadig videresendelse i kernen og en rute, der når tjenesten. Bekræft begge, før du bebrejder firewallen en anden gang.

sysctl net.ipv4.ip_forward
ip route get 10.30.0.15

Se derefter uden for værten. På en cloud-instans erstatter gæstens UFW-politik ikke sikkerhedsgrupper, subnet-ACL'er eller udbyderens egen videresendelseskonfiguration, så en lokal blokering er bevis om ét lag, ikke bevis for at alle andre lag tillader tjenesten.

Slut af med at teste en ny forbindelse med firewallen aktiveret, fra en tilladt kilde og fra en uvedkommende. Deaktivering af UFW fjerner symptomet og ødelægger beviset i samme kommando, og derfor bør det være det sidste eksperiment i stedet for det første.