Hvorfor din offentlige Linux-tjeneste svarer gennem VPN’et i stedet

Intet i socket’en husker, hvilken grænseflade der bar anmodningen, så en standardrute til en fuldtunnel-VPN kan opsnappe et svar, der hører hjemme på WAN’en. Tjenesten ignorerer ikke den indgående grænseflade; Linux ruter et lokalt genereret svar efter destination og kildepolitik. En kilderegel kan i stedet sende kun tjenestens svar gennem en komplet WAN-tabel og lade den almindelige udgang blive på tunnelen. Porten forbliver åben, mens svaret forlader gennem den forkerte vej, og derfor virker symptomet ensidigt.

Misforståelsen: svar følger den grænseflade, de ankom på

Det virker logisk, at en pakke, der ankommer på eth0, skal forlade på eth0. Tilstandsløse pakkefiltre kan skrives sådan, og tcpdump på den indgående side viser anmodningen præcis, hvor den forventes. Rutning fungerer ikke sådan for trafik, som værten selv opretter.

Når tjenesten accepterer forbindelsen, er dens svar en ny lokalt genereret pakke. Kernen konsulterer rutningsreglerne for svarets destination og kilde, og VPN’ets standardrute er et fuldstændigt gyldigt svar. Intet i socket’en husker, hvilken grænseflade der bar anmodningen.

Derfor virker symptomet ensidigt: anmodninger ankommer, svar forsvinder. Derfor ændrer en firewallregel for den indgående port heller intet. Pakken bliver ikke blokeret på vej ind; den bliver rutet et andet sted hen på vej ud. Følg svaret med et kildekvalificeret opslag, og omvejen bliver synlig.

Hvad kernen faktisk ruter: kildeadressen

Det håndtag, du har brug for, er den lokale adresse, som tjenesten bruger til svar. På en vært med den illustrative eth0-adresse 192.0.2.10/24 og gatewayen 192.0.2.1 findes den adresse på grænsefladen. På en cloud-VM kan den offentlige adresse være oversat længere oppe og mangle på gæsten, så brug den adresse, som værten faktisk har.

Undersøg den aktuelle tilstand, før du reserverer et tabelnummer eller en regelprioritet. Eksisterende politikregler kan overskygge en ny, og en gammel tabel med samme nummer kan allerede bære urelaterede ruter:

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

Vælg derefter en tabel efter kilde. Reglen matcher svar, der allerede bærer 192.0.2.10, netop den lokalt afsluttede trafik, som du vil undtage. Videresendt trafik og pakker fra andre lokale adresser matcher ikke.

Byg en komplet returtabel, ikke en halv standardrute

En tabel med kun en standardrute er ikke nok. Kernen skal stadig opløse gatewayen, og den opløsning kræver det forbundne præfiks i samme tabel. En tabel, der mangler det præfiks, fejler ved gateway-opløsningen, selv når dens standardrute ser korrekt ud. Tilføj begge, og peg derefter kildereglen mod 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

Brug det rigtige præfiks og den rigtige gateway i stedet for at kopiere eksemplet. En cloud-grænseflade konfigureret som /32 med en on-link-gateway kræver en anden forbundet rute, og en tabel bygget ud fra det forkerte præfiks fejler ved første hop. Attributten src angiver den foretrukne kilde for den rute; den erstatter ikke kildereglen.

Rækkefølgen betyder også noget. En bred regel med et lavere prioritetsnummer evalueres først, så kildereglen skal nås før enhver regel, der ville sende denne trafik tilbage til hovedtabellen. Kontroller prioriteterne med ip rule show efter tilføjelsen, ikke kun ved opstart.

Bekræft med et kildekvalificeret opslag

Bed kernen om at rute en testdestination fra tjenesteadressen. Svaret bør nævne eth0 og WAN-gatewayen, ikke tunnelen:

ip -4 route get 198.51.100.25 from 192.0.2.10

Opret derefter en ny autoriseret forbindelse, og se begge retninger. Et opslag, der vælger den rigtige tabel, mens den levende forbindelse stadig fejler, peger på omvendt sti-filtrering eller en firewallregel, ikke på tabellen. Kontroller disse styringer, før du deaktiverer noget globalt.

Læg de endelige ruter og reglen under den netværksadministrator, der ejer grænsefladen. Adresseændringer, DHCP-fornyelse og VPN-genforbindelser omskriver alle kernetilstanden, og en regel tilføjet i hånden forsvinder eller peger på en forældet gateway efter den næste hændelse.

Hvor denne undtagelse stopper

Reglen undtager lokalt afsluttet trafik fra én kildeadresse. Den dækker ikke Docker-publicerede porte, DNAT eller tjenester videresendt gennem værten, fordi disse pakker rutes som videresendt trafik og aldrig bærer værtens lokale kilde på samme måde. Sådanne design kræver normalt et mærke sat ved indgangen og en regel, der matcher mærket.

Den får heller ikke værtens offentlige adresse til at optræde på grænsefladen. Når en upstream-NAT ejer den adresse, skal svaret stadig forlade gennem den vej, som NAT’en forventer, og derfor skal WAN-tabellen afspejle den oprindelige gateway og det oprindelige præfiks i stedet for et gættet offentligt område.

Hold undtagelsen dokumenteret med sit tabelnummer, regelprioritet og den præcise kildeadresse. Den næste ændring af VPN’et eller grænsefladen kan stille ødelægge den, og en note, der nævner de tre værdier, er hurtigere at kontrollere end at genopdage symptomet fra en kunderapport.

Hvis tjenesten stadig svarer på den forkerte vej, efter at det kildekvalificerede opslag lykkes, så sammenlign den levende socket’s kildeadresse med den i reglen. En tjeneste bundet til en jokertegnadresse kan vælge en anden kilde end den adresse, du testede, og den uoverensstemmelse er det resterende hul.