Hvorfor den offentlige Linux-tjenesten din svarer gjennom VPN-et i stedet

Ingenting i socketen husker hvilket grensesnitt som bar forespørselen, så en standardrute for fulltunnel-VPN kan fange et svar som hører hjemme på WAN-et. Tjenesten ignorerer ikke det inngående grensesnittet; Linux ruter et lokalt generert svar etter destinasjon og kilde-policy. En kildebasert regel kan i stedet sende bare tjenestens svar gjennom en komplett WAN-tabell og la den vanlige utgangen bli på tunnelen. Porten forblir åpen mens svaret forlater gjennom feil vei, og derfor virker symptomet ensidig.

Misforståelsen: svar følger grensesnittet de kom inn på

Det virker logisk at en pakke som ankommer på eth0 skal forlate på eth0. Tilstandsløse pakkefiltre kan skrives slik, og tcpdump på inngangssiden viser forespørselen nøyaktig der den forventes. Ruting fungerer ikke slik for trafikk verten selv lager.

Når tjenesten godtar tilkoblingen, er svaret en ny lokalt generert pakke. Kjernen konsulterer rutingsreglene for svarets destinasjon og kilde, og VPN-ets standardrute er et fullstendig gyldig svar. Ingenting i socketen husker hvilket grensesnitt som bar forespørselen.

Derfor virker symptomet ensidig: forespørsler ankommer, svar forsvinner. Derfor endrer heller ikke en brannmurregel for inngangsporten noe. Pakken blir ikke blokkert på vei inn; den blir rutet et annet sted på vei ut. Følg svaret med et kildekvalifisert oppslag, og omveien blir synlig.

Hva kjernen faktisk ruter: kildeadressen

Håndtaket du trenger er den lokale adressen tjenesten bruker for svar. På en vert med den illustrative eth0-adressen 192.0.2.10/24 og gatewayen 192.0.2.1 finnes den adressen på grensesnittet. På en sky-VM kan den offentlige adressen være oversatt lenger oppe og mangle på gjesten, så bruk adressen verten faktisk har.

Undersøk nåværende tilstand før du reserverer et tabellnummer eller en regelprioritet. Eksisterende policyregler kan overskygge en ny, og en gammel tabell med samme nummer kan allerede bære urelaterte ruter:

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

Velg deretter en tabell etter kilde. Reglen matcher svar som allerede bærer 192.0.2.10, nettopp den lokalt avsluttede trafikken du vil unnta. Videresendt trafikk og pakker fra andre lokale adresser matcher ikke.

Bygg en komplett returtabell, ikke en halv standardrute

En tabell med bare en standardrute er ikke nok. Kjernen må fortsatt løse opp gatewayen, og den oppløsningen trenger det tilkoblede prefikset i samme tabell. En tabell som mangler det prefikset, feiler ved gateway-oppløsningen selv når standardruten ser riktig ut. Legg til begge, og pek deretter kildereglen 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

Bruk det virkelige prefikset og gatewayen i stedet for å kopiere eksempelet. Et skygrensesnitt konfigurert som /32 med en on-link-gateway trenger en annen tilkoblet rute, og en tabell bygget fra feil prefiks feiler ved første hopp. Attributtet src angir den foretrukne kilden for den ruten; det erstatter ikke kildereglen.

Rekkefølgen betyr også noe. En bred regel med lavere prioritetsnummer evalueres først, så kildereglen må nås før enhver regel som ville sendt denne trafikken tilbake til hovedtabellen. Kontroller prioritetene med ip rule show etter at du har lagt den til, ikke bare ved oppstart.

Bekreft med et kildekvalifisert oppslag

Be kjernen rute en testdestinasjon fra tjenesteadressen. Svaret bør navngi eth0 og WAN-gatewayen, ikke tunnelen:

ip -4 route get 198.51.100.25 from 192.0.2.10

Opprett deretter en ny autorisert tilkobling og observer begge retninger. Et oppslag som velger riktig tabell mens den levende tilkoblingen fortsatt feiler, peker på omvendt sti-filtrering eller en brannmurregel, ikke på tabellen. Kontroller disse styringene før du deaktiverer noe globalt.

Legg de endelige rutene og reglen under nettverksbehandleren som eier grensesnittet. Adresseendringer, DHCP-fornyelse og VPN-gjenoppkoblinger skriver alle om kjernetilstanden, og en regel lagt til for hånd forsvinner eller peker på en utdatert gateway etter neste hendelse.

Hvor dette unntaket stopper

Reglen unntar lokalt avsluttet trafikk fra én kildeadresse. Den dekker ikke Docker-publiserte porter, DNAT eller tjenester videresendt gjennom verten, fordi disse pakkene rutes som videresendt trafikk og aldri bærer vertens lokale kilde på samme måte. Slike design trenger vanligvis et merke satt ved inngangen og en regel som matcher merket.

Den får heller ikke vertens offentlige adresse til å vises på grensesnittet. Når en oppstrøms NAT eier den adressen, må svaret fortsatt forlate gjennom veien den NAT-en forventer, og derfor må WAN-tabellen speile den opprinnelige gatewayen og prefikset i stedet for et gjettet offentlig område.

Hold unntaket dokumentert med tabellnummeret, regelprioriteten og den nøyaktige kildeadressen. Den neste endringen i VPN-et eller grensesnittet kan stille ødelegge det, og et notat som navngir de tre verdiene er raskere å kontrollere enn å gjenoppdage symptomet fra en kunderapport.

Hvis tjenesten fortsatt svarer på feil vei etter at det kildekvalifiserte oppslaget lykkes, sammenlign kildeadressen til den levende socketen med den i reglen. En tjeneste bundet til en jokertegnadresse kan velge en annen kilde enn adressen du testet, og det avviket er det gjenværende gapet.