Rut berre éin lokal webtjeneste utanom VPN-et etter port

Éin vertsteneste må svara internett over den fysiske opplenka medan alt anna på maskina held fram med tunnelen. Tre vilkår avgjer om policybasert ruting kan bera den lasta, og kvart av dei er billeg å kontrollera før du skriv ein regel. Tenesta må enda på denne verten og ikkje bak ein DNAT eller ein vidaresend port, reglane til VPN-et sjølv må tillate unntaket, og du må matcha svaret i staden for førespurnaden. Feilar éin av dei tre, blir kommandoane nedanfor lasta reint inn, men gjer ingenting nyttig.

Kontroller dei tre vilkåra før du skriv ein regel

Ein container som publiserer ein port via DNAT, eller ein tenar bak ein portvidaresending, produserer pakkar som ikkje oppstår på denne verten. Desse pakkane blir vidaresende, så ein regel knytt til vertslokale inndata ser dei aldri og trafikken held fram med å ta standardruta. Stadfest kvar tenesta faktisk køyrer før du held fram, for dette er vilkåret folk oftast tek feil av.

Det andre vilkåret er politikk og ikkje mekanikk. Kvar rute som går utanom tunnelen er eit unntak frå føremålet med tunnelen, og på ein administrert vert høyrer den avgjerda til den som eig politikken, ikkje personen som feilsøkjer ein timeout.

Match svaret, ikkje destinasjonsporten til klienten

Eit svar frå ein tenar som lyttar på TCP 443 forlèt verten med kjeldeport 443. Ein nettlesar på same verten som koplar til eit eksternt HTTPS-nettstad sender ein efemær kjeldeport og destinasjonsport 443. Båe er port-443-trafikk, og berre éin av dei bør ta WAN-tabellen, og difor ville ein match på destinasjonsporten gripa feil halvdel.

Svarretninga er det du kan skilja. Match kjeldeporten, avgrens regelen til lokalt genererte pakkar, og regelen dekkjer dei eigne svara til tenesta utan å røra førespurnadene til nettlesaren.

Bygg ein fullstendig returtabell før regelen peikar på han

Ein tom tabell tyder inga rute, noko som ser ut som ei øydelagd teneste snarare enn ein øydelagd politikk. Fyll han først, med eit tabellnummer og ein prioritet som ingenting anna på verten krev:

ip -4 route add table 100 192.0.2.0/24 dev eth0
ip -4 route add table 100 default via 192.0.2.1 dev eth0
ip -4 rule add priority 1000 iif lo ipproto tcp sport 443 lookup 100

Les tala frå den køyrande verten i staden for å kopiera dei. ip -4 rule show fortel deg kva prioritetar som er tekne, og å leggja til ein regel på ein prioritet som alt finst endrar lydlaust rekkjefølgja på to reglar som kvar for seg ser fine ut.

To selektorar gjer den eigenlege jobben her. iif lo er måten kjernen rapporterer pakkar som verten sjølv har generert, så regelen kan ikkje ved eit uhell fanga vidaresend trafikk som kjem utanfrå. ipproto tcp sport 443 snevrar det inn til éin transport og éin port, noko som er så stramt som kravet tillèt. Fjern protokollselektoren, og regelen fangar òg UDP 443, som er ei anna teneste med ei anna åtferd.

Hald private svar inne i tunnelen

Viss den same lyttaren òg svarar klientar på den private sida, vil ei standard-WAN-rute som fangar alt i tabell 100 prøva å senda dei svara tilbake over opplenka. Legg til dei private prefiksa som ikkje skal fylgja WAN-standarden, eller lat dei falla vidare til neste policyregel:

ip -4 route add table 100 throw 10.90.0.0/24

Ei throw-rute avsluttar oppslaget i denne tabellen og gir pakken tilbake til regellista, slik at VPN-politikken som fylgjer får sjansen sin. Ho ruter ikkje sjølv noko inn i tunnelen, og viss ingen seinare regel har ei samsvarande rute, feilar pakken likevel; verifiser den neste politikken i staden for å anta at throw er ei løysing.

Filtrering av omvend sti og brannmurreglane til verten gjeld framleis for førespurnaden som kjem inn. Sjå på dei faktiske avgjerdene deira før du lempar på valideringa, for eit ruteunntak får ikkje rp_filter til å godta ein retursti som han reknar som umogleg.

Test TCP, deretter QUIC, deretter ein omstart

Opne éi tilknyting frå ein autorisert ekstern klient og éi frå den private sida, og inspiser deretter svaroppslaget med dei faktiske adressene og portane. Viss det eksterne svaret tar tabell 100 og det private ikkje, gjer politikken det du bad om.

HTTP/3 blir levert over UDP og blir ikkje matcha av ein TCP-regel, så ein QUIC-lyttar treng sin eigen selektor, elles held han fram med å bruka tunnelen medan HTTPS virkar. Lagre reglane du landar på hjå komponenten som eig grensesnittet, og stadfest dei etter ei ny tilkopling eller ei DHCP-fornying. Når ein konkurrerande handterar fjernar ei køyretidsrute etter ein omstart, er det eit eigarskapsproblem som må løysast ved kjelda, ikkje ein grunn til å leggja breiare NAT-reglar oppå.