Varför din offentliga Linux-tjänst svarar via VPN:et i stället

Ingenting i socketen minns vilket gränssnitt som bar fram begäran, så en standardväg för en fulltunnel-VPN kan fånga ett svar som hör hemma på WAN:et. Tjänsten ignorerar inte det inkommande gränssnittet; Linux dirigerar ett lokalt genererat svar efter destination och källpolicy. En källbaserad regel kan i stället skicka bara tjänstens svar genom en komplett WAN-tabell och låta den vanliga utgången stanna på tunneln. Porten förblir öppen medan svaret lämnar via fel väg, och därför ser symtomet enkelriktat ut.

Missuppfattningen: svar följer gränssnittet de kom in på

Det verkar logiskt att ett paket som anländer på eth0 ska lämna på eth0. Tillståndslösa paketfilter kan skrivas så, och tcpdump på ingångssidan visar begäran exakt där den förväntas. Routning fungerar inte så för trafik som värden själv skapar.

När tjänsten tar emot anslutningen är svaret ett nytt lokalt genererat paket. Kärnan konsulterar routningsreglerna för svarets destination och källa, och VPN:ets standardväg är ett fullständigt giltigt svar. Ingenting i socketen minns vilket gränssnitt som bar fram begäran.

Därför ser symtomet enkelriktat ut: begäranden kommer in, svar försvinner. Därför ändrar inte heller en brandväggsregel för ingångsporten något. Paketet blockeras inte på vägen in; det routas någon annanstans på vägen ut. Följ svaret med en källkvalificerad sökning och omvägen blir synlig.

Vad kärnan faktiskt routar: källadressen

Handtaget du behöver är den lokala adress som tjänsten använder för svar. På en värd med den illustrativa eth0-adressen 192.0.2.10/24 och gatewayen 192.0.2.1 finns den adressen på gränssnittet. På en moln-VM kan den offentliga adressen vara översatt högre upp och saknas i gästen, så använd den adress som värden faktiskt har.

Inspektera nuvarande tillstånd innan du reserverar ett tabellnummer eller en regelprioritet. Befintliga policyregler kan skugga en ny, och en gammal tabell med samma nummer kan redan bära orelaterade rutter:

ip -4 addr show dev eth0
ip -4 rule show
ip -4 route show table all

Välj sedan en tabell efter källa. Regeln matchar svar som redan bär 192.0.2.10, just den lokalt avslutade trafik du vill undanta. Vidarebefordrad trafik och paket från andra lokala adresser matchar inte.

Bygg en komplett returtabell, inte en halv standardväg

En tabell med bara en standardväg räcker inte. Kärnan måste fortfarande lösa gatewayen, och den lösningen kräver det anslutna prefixet i samma tabell. En tabell som saknar det prefixet misslyckas vid gatewayupplösningen även när dess standardväg ser korrekt ut. Lägg till båda och peka sedan källregeln mot tabellen:

ip -4 route add table 100 192.0.2.0/24 dev eth0 src 192.0.2.10
ip -4 route add table 100 default via 192.0.2.1 dev eth0
ip -4 rule add priority 1000 from 192.0.2.10/32 lookup 100

Använd det riktiga prefixet och gatewayen i stället för att kopiera exemplet. Ett molngränssnitt konfigurerat som /32 med en on-link-gateway behöver en annan ansluten väg, och en tabell byggd från fel prefix misslyckas vid första hoppet. Attributet src anger den föredragna källan för den vägen; det ersätter inte källregeln.

Ordningen spelar också roll. En bred regel med lägre prioritetsnummer utvärderas först, så källregeln måste nås före varje regel som skulle skicka tillbaka trafiken till huvudtabellen. Kontrollera prioriteringarna med ip rule show efter att du lagt till den, inte bara vid start.

Verifiera med en källkvalificerad sökning

Be kärnan att routa en testdestination från tjänsteadressen. Svaret bör namnge eth0 och WAN-gatewayen, inte tunneln:

ip -4 route get 198.51.100.25 from 192.0.2.10

Upprätta sedan en ny auktoriserad anslutning och observera båda riktningarna. En sökning som väljer rätt tabell medan den levande anslutningen fortfarande misslyckas pekar på omvänd väg-filtrering eller en brandväggsregel, inte på tabellen. Kontrollera dessa styrningar innan du inaktiverar något globalt.

Placera de slutliga vägarna och regeln under nätverkshanteraren som äger gränssnittet. Adressändringar, DHCP-förnyelse och VPN-återanslutningar skriver om kärnans tillstånd, och en regel som lagts till för hand försvinner eller pekar på en föråldrad gateway efter nästa händelse.

Var detta undantag slutar

Regeln undantar lokalt avslutad trafik från en källadress. Den täcker inte Docker-publicerade portar, DNAT eller tjänster som vidarebefordras via värden, eftersom dessa paket routas som vidarebefordrad trafik och aldrig bär värdens lokala källa på samma sätt. Sådana konstruktioner kräver vanligtvis en markering som sätts vid ingången och en regel som matchar markeringen.

Den får inte heller värdens offentliga adress att synas på gränssnittet. När en uppströms NAT äger den adressen, måste svaret fortfarande lämna via den väg som NAT:en förväntar sig, och därför måste WAN-tabellen spegla den ursprungliga gatewayen och prefixet i stället för ett gissat offentligt intervall.

Håll undantaget dokumenterat med tabellnummer, regelprioritet och den exakta källadressen. Nästa ändring i VPN:et eller gränssnittet kan tysta förstöra det, och en anteckning som namnger de tre värdena går snabbare att kontrollera än att återupptäcka symtomet från en kundrapport.

Om tjänsten fortfarande svarar via fel väg efter att den källkvalificerade sökningen lyckas, jämför den levande socketens källadress med den i regeln. En tjänst bunden till en jokerteckenadress kan välja en annan källa än adressen du testade, och den avvikelsen är det kvarvarande gapet.