Svaret forlater LAN-et, ikke tunnelen: hvorfor og hvordan

En tjeneste som publiseres gjennom en gateway, virker fra det meste av internett og feiler fra ett kontor. Noen undersøker tunnelen, ser forespørselen komme inn og konkluderer med at svaret må følge samme vei tilbake. Linux virker ikke slik, og ingen undersøkelse av tunnelen endrer svaret. Svaret rutes etter destinasjon, og den ene feilende kallereren ligger på et subnett som verten allerede når direkte.

Hva som faktisk avgjør en utgående pakke

Kjernen slår opp en rute for pakkens destinasjon, konsulterer policyregler i prioritetsrekkefølge og deretter tabellen en samsvarende regel velger. Grensesnittet en pakke kom inn på spiller ingen rolle, med mindre en regel eller et merke er skrevet for å gjøre det viktig. Det er et rutingfaktum om denne verten, ikke en feil i tunnelen.

En forespørsel som mottas på tunnelen kan derfor gi et svar som forlater gjennom det fysiske grensesnittet, og strømmen blir enveis uten at noen enhet rapporterer en feil. Kontroller begge retninger før du trekker en konklusjon om tunnelen. Et svar som går ut feil vei, forsvinner fra tunnelens tellere, og derfor er de to endene uenige om hvorvidt noe ble sendt. Legg merke til hvilken teller som flyttet seg før du rører en regel.

Hvorfor det lokale subnettet vinner

En vert med en adresse på et lokalt nettverk har en tilkoblet rute for det prefikset i hovedtabellen, og en tilkoblet rute er et direkte treff. Når kallereren kommer fra samme subnett, finner oppslaget den lokale lenken før tunnelen i det hele tatt vurderes.

Det er asymmetrien som gjør det forvirrende å diagnostisere. Kallere fra det bredere internett virker fordi de ikke samsvarer med noen lokal rute, mens den ene kallereren som deler kontorets prefiks feiler, og det er nettopp den kallereren noen tester med.

Peer-dekning er ikke det samme som installerte ruter

På tunnelsiden beskriver en peers tillatte områder hva som kan sendes inn i tunnelen og hvilke kilder som godtas fra den. De sier ingenting om hvor den lokale rutingtabellen vil sende en pakke.

Hvis tunnelverktøyet installerer en standardrute på verten, kan det dra ubeslektet trafikk inn i tunnelen som følgeskade. Der en policyregel i stedet bør eie beslutningen, finnes verktøyets valg for ruteinstallasjon nettopp for å hindre det, og adressene, nøklene og endepunktinnstillingene forblir nøyaktig som de var. En standardrute lagt til for enkelhets skyld er en vanlig måte en vert mister sitt eget lokale nettverk på.

Velg tabellen etter kildeadressen

En kildebasert regel sender svar fra tjenesteadressen inn i en privat tabell hvis standard er tunnelen, mens alt annet fortsetter å bruke hovedtabellen. Velg tabell- og prioritetsnumre som ikke brukes lokalt, og les de eksisterende reglene før du setter inn noe. Les de levende reglene i stedet for en lagret fil, for de to kan avvike etter en omstart.

ip -6 route add default dev wg0 table 200
ip -6 rule add priority 32000 from 2001:db8:aa::20/128 lookup 200
ip -6 rule add priority 32001 from 2001:db8:aa::20/128 unreachable

Den siste linjen får en manglende rute til å feile synlig i stedet for å falle tilbake til den lokale lenken. Kilden må faktisk være tildelt verten, og de vanlige lokale og primære oppslagene må bli på sine tidligere plasseringer. Regelen velger en tabell etter kilde; den sammenligner ikke prefikslengder mellom tabeller.

Bekreft veien, deretter tjenesten

Spør kjernen hva den ville gjort i stedet for å slutte fra en opptak, med tjenesteadressen som kildevelger. Et riktig svar her sparer en hel pakkesporing.

ip -6 route get 2001:db8:bb::30 from 2001:db8:aa::20

Utdataene bør navngi tunnelen. Test deretter en kilde du ikke har rørt, og bekreft at den fortsatt tar den lokale lenken, slik at endringen holdt seg begrenset til én adresse. En bredere velger ville ikke bevise noe om den opprinnelige klagen.

Hva dette ikke retter

La videresending, brannmurregler og ICMPv6-atferd på gatewayen være som de var, for en kilderute erstatter ingen av dem. En manglende Packet Too Big-melding ødelegger fortsatt store svar, uansett hvilken tabell som vant oppslaget. Rett det før du legger til rutingregler, ellers overlever symptomet endringen.

Bekreft publiseringsmodellen før du bruker noe av dette. En omvendt proxy som åpner sin egen backend-tilkobling, presenterer sin egen kilde og bevarer ikke kallereren, så denne feilen kan ikke oppstå i det designet. Å bruke regelen der ville legge til et rutingunntak som ikke løser noe og skjuler den egentlige årsaken.

Til slutt skriver du reglenumrene og tabellen inn i vertens konfigurasjonsstyring. En policyregel lagt til for hånd forsvinner ved neste gjenoppbygging, og kontorets kallerer kommer tilbake med samme klage.