ufw allow 443 hjalp ingenting for en tjeneste bak VPN-en

Ping lykkes fra en VPN-klient, TCP-tjenesten timer ut, og ufw allow 443/tcp endrer absolutt ingenting. Når applikasjonen kjører på en vert bak gatewayen i stedet for på gatewayen selv, ble tillatelsen skrevet for feil trafikkvei. Pakken er ikke adressert til brannmuren og blir ikke levert til en lokal prosess, så inndata-reglene ser den aldri. Rettingen er en ruterregel rettet mot den videresendte strømmen, og beviset for den ligger allerede i loggen.

Avgjør om destinasjonen er lokal eller videresendt

Les pakken slik kjernen ser den. Trafikk som leveres til en tjeneste på gatewayen, er lokale inndata. Trafikk som gatewayen ruter videre til en annen vert, er videresendt, og UFW holder separate regelsett for de to veiene. Forskjellen avgjøres av destinasjonsadressen og ruteoppslaget, ikke av grensesnittet pakken kom inn på.

En logglinje som viser samme grensesnitt i både IN- og OUT-feltet kan fortsatt beskrive en rutet pakke, fordi en tunnel som bærer klienter inn og ut av én enhet ser nøyaktig slik ut. Destinasjonsadressen avgjør spørsmålet raskere enn grensesnittnavnene. Å se samme navn to ganger beviser ikke lokal levering, og å finne opp et tunnelgrensesnitt som utrullingen aldri opprettet hjelper heller ikke.

Les blokkeringen før du legger til noen regel

Gjenskap ett autorisert tilkoblingsforsøk og registrer kilde, destinasjon, protokoll og destinasjonsport slik gatewayen registrerte dem. Sammenlign de fire verdiene med loggoppføringen og med tjenestens faktiske plassering. En tidligere vellykket ping beviser bare at dens egen utveksling var tillatt, og en brannmur kan behandle en TCP SYN mot en applikasjon helt annerledes.

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

Den første kommandoen returnerer avgjørelsen med feltene sine, og den andre viser hva som allerede er lastet og i hvilken rekkefølge. Les begge før du redigerer noe, fordi en tidligere avvisning over regelen din forklarer det samme symptomet uten noen manglende regel.

Skriv den smaleste ruterregelen som passer

I dette eksempelet kommer klientene inn på tun0 fra 172.20.8.0/24, tjenesten lytter på 10.30.0.15 på port 8443, og gatewayen går ut gjennom ens5. Disse verdiene ble valgt for å ikke ligne i det hele tatt på en sky-VPC-standard på 10.0.0.0/16 eller et hjemmenett på 192.168.0.0/16, og 8443 holder eksempelet unna 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øvekjøringen skriver ut regelsettet som ville bli resultatet, og det er den billigste måten å se om regelen din lander før eller etter en eksisterende avvisning. Bekreft grensesnittnavnene og de indre adressene mot utrullingen i stedet for mot eksempelet, og husk at når destinasjons-NAT kjører først, ser filteret den oversatte destinasjonen.

Hold returveien tilstandsfull

UFW sporer tillatte forbindelser, så svarene på en tillatt videresendt strøm slippes inn uten en eksplisitt motsatt regel. Å legge til en ubegrenset regel i motsatt retning for å få ting til å virke utvider policyen langt utover den ene tjenesten og er ikke nødvendig for en normal forespørsel-svar-utveksling. Hold returveien implisitt og regelsettet lesbart.

Bruk regelen først når prøvekjøringen samsvarer med intensjonen din, og bekreft deretter at den ordnede listen viser den på forventet plass. Hold VPN-lytteren og administrasjonsreglene som separate anliggender, fordi å endre dem er en annen beslutning enn å slippe inn én applikasjon. Noter endringen samme sted som topologien er skrevet ned, slik at neste ingeniør ikke må gjenoppdage den 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

Sjekk hva UFW ikke kan håndheve for deg

En korrekt regel trenger fortsatt videresending i kjernen og en rute som når tjenesten. Bekreft begge før du gir brannmuren skylden en gang til.

sysctl net.ipv4.ip_forward
ip route get 10.30.0.15

Se deretter utenfor verten. På en skyinstans erstatter ikke gjestens UFW-policy sikkerhetsgrupper, subnett-ACL-er eller leverandørens egen videresendingskonfigurasjon, så en lokal blokkering er bevis om ett lag og ikke bevis for at alle andre lag tillater tjenesten.

Avslutt med å teste en ny tilkobling med brannmuren aktivert, fra en tillatt kilde og fra en uvedkommende. Å deaktivere UFW fjerner symptomet og ødelegger beviset i samme kommando, derfor bør det være det siste eksperimentet og ikke det første.