Rut bare én lokal webtjeneste utenom VPN-et etter port

Én vertstjeneste må svare internett over den fysiske opplenken mens alt annet på maskinen fortsetter å bruke tunnelen. Tre betingelser avgjør om policybasert ruting kan bære den belastningen, og hver av dem er billig å kontrollere før du skriver en regel. Tjenesten må avsluttes på denne verten og ikke bak en DNAT eller en videresendt port, VPN-ets egne regler må tillate unntaket, og du må matche svaret i stedet for forespørselen. Feiler én av de tre, lastes kommandoene nedenfor rent inn, men gjør ingenting nyttig.

Kontroller de tre betingelsene før du skriver en regel

En container som publiserer en port via DNAT, eller en server bak en portvideresending, produserer pakker som ikke oppstår på denne verten. Disse pakkene videresendes, så en regel knyttet til vertslokale inndata ser dem aldri og trafikken fortsetter å ta standardruten. Bekreft hvor tjenesten faktisk kjører før du fortsetter, for dette er betingelsen folk oftest tar feil av.

Den andre betingelsen er politikk og ikke mekanikk. Enhver rute som omgår tunnelen er et unntak fra tunnelens formål, og på en administrert vert tilhører den beslutningen den som eier politikken, ikke personen som feilsøker en timeout.

Match svaret, ikke klientens destinasjonsport

Et svar fra en server som lytter på TCP 443 forlater verten med kildeport 443. En nettleser på samme vert som kobler til et eksternt HTTPS-nettsted sender en efemær kildeport og destinasjonsport 443. Begge er port-443-trafikk, og bare én av dem bør ta WAN-tabellen, og derfor ville en match på destinasjonsporten gripe feil halvdel.

Svarretningen er det du kan skille. Match kildeporten, begrens regelen til lokalt genererte pakker, og regelen dekker tjenestens egne svar uten å berøre nettleserens forespørsler.

Bygg en fullstendig returtabell før regelen peker på den

En tom tabell betyr ingen rute, noe som ser ut som en ødelagt tjeneste snarere enn en ødelagt politikk. Fyll den først, med et tabellnummer og en prioritet som ingenting annet på verten krever:

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 tallene fra den kjørende verten i stedet for å kopiere dem. ip -4 rule show forteller deg hvilke prioriteter som er tatt, og å legge til en regel på en prioritet som allerede finnes endrer lydløst rekkefølgen på to regler som hver for seg ser fine ut.

To selektorer gjør den egentlige jobben her. iif lo er måten kjernen rapporterer pakker som verten selv har generert, så regelen kan ikke ved et uhell fange videresendt trafikk som kommer utenfra. ipproto tcp sport 443 snevrer det inn til én transport og én port, noe som er så stramt som kravet tillater. Fjern protokollselektoren, og regelen fanger også UDP 443, som er en annen tjeneste med en annen oppførsel.

Hold private svar inne i tunnelen

Hvis den samme lytteren også svarer klienter på den private siden, vil en standard-WAN-rute som fanger alt i tabell 100 prøve å sende disse svarene tilbake over opplenken. Legg til de private prefiksene som ikke skal følge WAN-standarden, eller la dem falle videre til neste policyregel:

ip -4 route add table 100 throw 10.90.0.0/24

En throw-rute avslutter oppslaget i denne tabellen og gir pakken tilbake til regellisten, slik at VPN-policyen som følger får sin sjanse. Den ruter ikke selv noe inn i tunnelen, og hvis ingen senere regel har en samsvarende rute, feiler pakken likevel; verifiser den neste policyen i stedet for å anta at throw er en løsning.

Filtrering av omvendt sti og vertens brannmurregler gjelder fortsatt for forespørselen som kommer inn. Se på deres faktiske avgjørelser før du lemper på valideringen, for et ruteunntak får ikke rp_filter til å godta en retursti den anser som umulig.

Test TCP, deretter QUIC, deretter en omstart

Åpne én forbindelse fra en autorisert ekstern klient og én fra den private siden, og inspiser deretter svaroppslaget med de faktiske adressene og portene. Hvis det eksterne svaret tar tabell 100 og det private ikke, gjør policyen det du ba om.

HTTP/3 leveres over UDP og vil ikke bli matchet av en TCP-regel, så en QUIC-lytter trenger sin egen selektor, ellers fortsetter den å bruke tunnelen mens HTTPS virker. Lagre reglene du lander på hos komponenten som eier grensesnittet, og bekreft dem etter en gjentilkobling eller en DHCP-fornyelse. Når en konkurrerende behandler fjerner en kjøretidsrute etter en omstart, er det et eierskapsproblem som må løses ved kilden, ikke en grunn til å legge bredere NAT-regler oppå.