Kvifor den offentlege Linux-tenesta di svarar gjennom VPN-et i staden

Ingenting i socketen hugsar kva grensesnitt som bar førespurnaden, så ei standardrute for fulltunnel-VPN kan fange eit svar som høyrer heime på WAN-et. Tenesta ignorerer ikkje det inngåande grensesnittet; Linux rutar eit lokalt generert svar etter mål og kjeldepolitikk. Ein kjelderegel kan i staden senda berre svara til tenesta gjennom ein komplett WAN-tabell og la den vanlege utgangen bli på tunnelen. Porten held seg open medan svaret går ut gjennom feil veg, og difor verkar symptomet einsidig.

Misforståinga: svar følgjer grensesnittet dei kom inn på

Det verkar logisk at ein pakke som kjem inn på eth0 skal gå ut på eth0. Tilstandslause pakkefilter kan skrivast slik, og tcpdump på inngangssida viser førespurnaden nøyaktig der han er venta. Ruting fungerer ikkje slik for trafikk verten sjølv lagar.

Når tenesta tek imot tilkoplinga, er svaret ein ny lokalt generert pakke. Kjernen konsulterer rutingsreglane for målet og kjelda til svaret, og standardruta til VPN-et er eit fullstendig gyldig svar. Ingenting i socketen hugsar kva grensesnitt som bar førespurnaden.

Difor verkar symptomet einsidig: førespurnader kjem inn, svar forsvinn. Difor endrar heller ikkje ein brannmurregel for inngangsporten noko. Pakken blir ikkje blokkert på vegen inn; han blir ruta ein annan stad på vegen ut. Følg svaret med eit kjeldekvalifisert oppslag, og omvegen blir synleg.

Kva kjernen faktisk rutar: kjeldeadressa

Handtaket du treng er den lokale adressa tenesta brukar for svar. På ein vert med den illustrative eth0-adressa 192.0.2.10/24 og gatewayen 192.0.2.1 finst den adressa på grensesnittet. På ein sky-VM kan den offentlege adressa vere omsett lenger oppe og mangla på gjesten, så bruk adressa verten faktisk har.

Undersøk noverande tilstand før du reserverer eit tabellnummer eller ein regelprioritet. Eksisterande policyreglar kan overskugge ein ny, og ein gammal tabell med same nummer kan alt bere urelaterte ruter:

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

Vel deretter ein tabell etter kjelde. Regelen passar med svar som alt ber 192.0.2.10, nettopp den lokalt avslutta trafikken du vil unnta. Videresend trafikk og pakkar frå andre lokale adresser passar ikkje.

Bygg ein komplett returtabell, ikkje ei halv standardrute

Ein tabell med berre ei standardrute er ikkje nok. Kjernen må framleis løyse opp gatewayen, og den oppløysinga treng det tilkopla prefikset i same tabellen. Ein tabell som manglar det prefikset, feilar ved gateway-oppløysinga sjølv når standardruta ser rett ut. Legg til båe, og peik deretter kjelderegelen 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 verkelege prefikset og gatewayen i staden for å kopiere dømet. Eit skygrensesnitt konfigurert som /32 med ein on-link-gateway treng ei anna tilkopla rute, og ein tabell bygd frå feil prefiks feilar ved første hopp. Attributtet src angir den føretrekte kjelda for den ruta; det erstattar ikkje kjelderegelen.

Rekkjefølgja har også noko å seie. Ein brei regel med lågare prioritetsnummer blir vurdert først, så kjelderegelen må nåast før kvar regel som ville sendt denne trafikken tilbake til hovudtabellen. Kontroller prioritetane med ip rule show etter at du har lagt han til, ikkje berre ved oppstart.

Stadfest med eit kjeldekvalifisert oppslag

Be kjernen rute ein testdestinasjon frå tenesteadressa. Svaret bør nemne eth0 og WAN-gatewayen, ikkje tunnelen:

ip -4 route get 198.51.100.25 from 192.0.2.10

Opprett deretter ei ny autorisert tilkopling og observer båe retningar. Eit oppslag som vel rett tabell medan den levande tilkoplinga framleis feilar, peikar på omvendt veg-filtrering eller ein brannmurregel, ikkje på tabellen. Kontroller desse styringane før du deaktiverer noko globalt.

Legg dei endelege rutene og regelen under nettverkshandsamaren som eig grensesnittet. Adresseendringar, DHCP-fornying og VPN-gjenoppkoplingar skriv alle om kjernetilstanden, og ein regel lagt til for hand forsvinn eller peikar på ein utdatert gateway etter neste hending.

Kvar dette unntaket stoppar

Regelen unntar lokalt avslutta trafikk frå éi kjeldeadresse. Han dekkjer ikkje Docker-publiserte portar, DNAT eller tenester videresende gjennom verten, fordi desse pakkane blir ruta som videresend trafikk og aldri ber den lokale kjelda til verten på same måte. Slike design treng vanlegvis eit merke sett ved inngangen og ein regel som passar med merket.

Han får heller ikkje den offentlege adressa til verten til å visast på grensesnittet. Når ein oppstraums NAT eig den adressa, må svaret framleis gå ut gjennom vegen den NAT-en ventar, og difor må WAN-tabellen spegle den opphavlege gatewayen og prefikset i staden for eit gissa offentleg område.

Hald unntaket dokumentert med tabellnummeret, regelprioriteten og den nøyaktige kjeldeadressa. Den neste endringa i VPN-et eller grensesnittet kan stille øydeleggje det, og eit notat som nemner dei tre verdiane er raskare å kontrollere enn å gjenoppdage symptomet frå ein kunderapport.

Viss tenesta framleis svarar på feil veg etter at det kjeldekvalifiserte oppslaget lukkast, samanlikn kjeldeadressa til den levande socketen med den i regelen. Ei teneste bunden til ei jokerteiknadresse kan velje ei anna kjelde enn adressa du testa, og det avviket er det gjenverande gapet.