Routa bara en lokal webbtjänst utanför VPN:et efter port

En värdtjänst måste svara internet över den fysiska upplänken medan allt annat på maskinen fortsätter använda tunneln. Tre villkor avgör om policybaserad routning kan bära den belastningen, och vart och ett är billigt att kontrollera innan du skriver en regel. Tjänsten måste avslutas på den här värden och inte bakom en DNAT eller en vidarebefordrad port, VPN:ets egna regler måste tillåta undantaget, och du måste matcha svaret i stället för begäran. Fallerar något av de tre laddas kommandona nedan rent men gör ingenting användbart.

Kontrollera de tre villkoren innan du skriver en regel

En container som publicerar en port via DNAT, eller en server bakom en portvidarebefordran, producerar paket som inte uppstår på den här värden. Dessa paket vidarebefordras, så en regel knuten till värdlokala indata ser dem aldrig och trafiken fortsätter ta standardrutten. Bekräfta var tjänsten faktiskt körs innan du fortsätter, för det är villkoret folk oftast tar fel på.

Det andra villkoret är politik och inte mekanik. Varje rutt som kringgår tunneln är ett undantag från tunnelns syfte, och på en hanterad värd tillhör det beslutet den som äger politiken, inte personen som felsöker en timeout.

Matcha svaret, inte klientens destinationsport

Ett svar från en server som lyssnar på TCP 443 lämnar värden med källport 443. En webbläsare på samma värd som ansluter till en extern HTTPS-webbplats skickar en efemär källport och destinationsport 443. Båda är port 443-trafik och bara en av dem bör ta WAN-tabellen, vilket är varför en matchning på destinationsporten skulle fånga fel halva.

Svarriktningen är det du kan skilja på. Matcha källporten, begränsa regeln till lokalt genererade paket, och regeln täcker tjänstens egna svar utan att röra webbläsarens begäranden.

Bygg en fullständig returtabell innan regeln pekar på den

En tom tabell betyder ingen rutt, vilket ser ut som en trasig tjänst snarare än en trasig politik. Fyll den först, med ett tabellnummer och en prioritet som ingenting annat på värden gör anspråk på:

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

Läs siffrorna från den körande värden i stället för att kopiera dem. ip -4 rule show berättar vilka prioriteter som är tagna, och att lägga till en regel på en prioritet som redan finns ändrar tyst ordningen på två regler som var för sig ser bra ut.

Två selektorer gör det egentliga arbetet här. iif lo är sättet kärnan rapporterar paket som värden själv har genererat, så regeln kan inte av misstag fånga vidarebefordrad trafik som kommer utifrån. ipproto tcp sport 443 snävar in det till en transport och en port, vilket är så stramt som kravet tillåter. Ta bort protokollselektorn och regeln fångar även UDP 443, en annan tjänst med ett annat beteende.

Håll privata svar inne i tunneln

Om samma lyssnare också svarar klienter på den privata sidan kommer en standard-WAN-rutt som fångar allt i tabell 100 att försöka skicka tillbaka dessa svar över upplänken. Lägg till de privata prefixen som inte får följa WAN-standarden, eller låt dem falla vidare till nästa policyregel:

ip -4 route add table 100 throw 10.90.0.0/24

En throw-rutt avslutar sökningen i den här tabellen och lämnar tillbaka paketet till regellistan, så VPN-policyn som följer får sin chans. Den routar inte själv något in i tunneln, och om ingen senare regel har en matchande rutt misslyckas paketet ändå; verifiera nästa policy i stället för att anta att throw är en lösning.

Filtrering av omvänd väg och värdens brandväggsregler gäller fortfarande för begäran som kommer in. Titta på deras verkliga avgöranden innan du lättar på valideringen, för ett ruttundantag gör inte att rp_filter accepterar en returväg som den anser omöjlig.

Testa TCP, sedan QUIC, sedan en omstart

Öppna en anslutning från en auktoriserad extern klient och en från den privata sidan, och granska sedan svarsökningen med de faktiska adresserna och portarna. Om det externa svaret tar tabell 100 och det privata inte gör det, gör policyn det du bad om.

HTTP/3 levereras över UDP och kommer inte att matchas av en TCP-regel, så en QUIC-lyssnare behöver sin egen selektor, annars fortsätter den använda tunneln medan HTTPS fungerar. Spara reglerna du landar i hos komponenten som äger gränssnittet, och bekräfta dem efter en återanslutning eller en DHCP-förnyelse. När en konkurrerande hanterare tar bort en körtidsrutt efter en omstart är det ett ägarproblem som ska lösas vid källan, inte en anledning att lägga bredare NAT-regler ovanpå.