ufw allow 443 hjelpte ikkje for ei teneste bak VPN-en

Ping lukkast frå ein VPN-klient, TCP-tenesta går i tidsavbrot, og ufw allow 443/tcp endrar absolutt ingenting. Når programmet køyrer på ein vert bak gatewayen i staden for på gatewayen sjølv, vart tilgangen skriven for feil trafikkveg. Pakken er ikkje adressert til brannmuren og vert ikkje levert til ein lokal prosess, så inndatareglane ser han aldri. Rettinga er ei ruterregel retta mot den vidaresende straumen, og prova for ho ligg alt i loggen.

Avgjer om destinasjonen er lokal eller vidaresend

Les pakken slik kjernen ser han. Trafikk som vert levert til ei teneste på gatewayen, er lokale inndata. Trafikk som gatewayen rutar vidare til ein annan vert, er vidaresend, og UFW held separate regelsett for dei to vegane. Skilnaden vert avgjord av destinasjonsadressa og ruteoppslaget, ikkje av grensesnittet pakken kom inn på.

Ei logglinje som viser same grensesnitt i både IN- og OUT-feltet kan framleis skildre ein ruta pakke, fordi ein tunnel som ber klientar inn og ut av éi eining ser nøyaktig slik ut. Destinasjonsadressa avgjer spørsmålet raskare enn grensesnittnamna. Å sjå same namn to gonger provar ikkje lokal levering, og å finne opp eit tunnelgrensesnitt som utrullinga aldri oppretta hjelper heller ikkje.

Les blokkeringa før du legg til noka regel

Gjenskap eitt autorisert tilkoplingsforsøk og registrer kjelde, destinasjon, protokoll og destinasjonsport slik gatewayen registrerte dei. Samanlikn dei fire verdiane med loggoppføringa og med den faktiske plasseringa til tenesta. Ein tidlegare vellukka ping provar berre at den eiga utvekslinga var tillaten, og ein brannmur kan handsame ein TCP SYN mot eit program heilt annleis.

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

Den første kommandoen returnerer avgjerda med felta sine, og den andre viser kva som alt er lasta og i kva rekkjefølgje. Les båe før du redigerer noko, fordi ei tidlegare avvising over regelen din forklarer same symptomet utan noka manglande regel.

Skriv den smalaste ruterregelen som passar

I dette dømet kjem klientane inn på tun0 frå 172.20.8.0/24, tenesta lyttar på 10.30.0.15 på port 8443, og gatewayen går ut gjennom ens5. Desse verdiane vart valde for å ikkje likne i det heile på ein sky-VPC-standard på 10.0.0.0/16 eller eit heimenett på 192.168.0.0/16, og 8443 held dømet unna gatewayen sin eigen 443-lyttar.

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øyringa skriv ut regelsettet som ville bli resultatet, og det er den billegaste måten å sjå om regelen din landar før eller etter ei eksisterande avvising. Stadfest grensesnittnamna og dei indre adressene mot utrullinga i staden for mot dømet, og hugs at når destinasjons-NAT køyrer først, ser filteret den omsette destinasjonen.

Hald returvegen tilstandsfull

UFW sporar tillatne tilkoplingar, så svara på ein tillaten vidaresend straum vert sleppte inn utan ein uttrykkeleg motsett regel. Å leggje til ein ubegrensa regel i motsett retning for å få ting til å verke utvidar politikken langt utover den eine tenesta og er ikkje naudsynt for ei normal førespurnad-svar-utveksling. Hald returvegen implisitt og regelsettet lesbart.

Bruk regelen først når prøvekøyringa samsvarar med intensjonen din, og stadfest deretter at den ordna lista viser han på venta plass. Hald VPN-lyttaren og administrasjonsreglane som separate saker, fordi å endre dei er eit anna vedtak enn å sleppe inn eitt program. Noter endringa same stad som topologien er skriven ned, slik at neste ingeniør ikkje må oppdage ho på nytt frå ein 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 kva UFW ikkje kan handheve for deg

Ein korrekt regel treng framleis vidaresending i kjernen og ei rute som når tenesta. Stadfest båe før du gir brannmuren skulda ein gong til.

sysctl net.ipv4.ip_forward
ip route get 10.30.0.15

Sjå deretter utanfor verten. På ein skyinstans erstattar ikkje UFW-politikken til gjesten sikkerhetsgrupper, subnett-ACL-ar eller leverandøren si eiga vidaresendingskonfigurasjon, så ei lokal blokkering er prov om eitt lag og ikkje prov for at alle andre lag tillèt tenesta.

Avslutt med å teste ei ny tilkopling med brannmuren slått på, frå ei tillaten kjelde og frå ei uvedkomande. Å slå av UFW fjernar symptomet og øydelegg prova i same kommando, difor bør det vere det siste eksperimentet og ikkje det første.