Svaret forlèt LAN-et, ikkje tunnelen: kvifor og korleis

Ei teneste som blir publisert gjennom ein gateway, verkar frå det meste av internett og feilar frå eitt kontor. Nokon undersøkjer tunnelen, ser førespurnaden kome inn og konkluderer med at svaret må følgje same vegen tilbake. Linux verkar ikkje slik, og inga undersøking av tunnelen endrar svaret. Svaret blir ruta etter destinasjon, og den eine feilande kallaren ligg på eit subnett som verten allereie når direkte.

Kva som faktisk avgjer ein utgåande pakke

Kjernen slår opp ei rute for destinasjonen til pakken, konsulterer policyreglar i prioritetsrekkjefølgje og deretter tabellen ein samsvarande regel vel. Grensesnittet ein pakke kom inn på spelar inga rolle, med mindre ein regel eller eit merke er skrive for å gjere det viktig. Det er eit rutingsfaktum om denne verten, ikkje ein feil i tunnelen.

Ein førespurnad som blir motteken på tunnelen kan difor gje eit svar som forlèt gjennom det fysiske grensesnittet, og straumen blir einvegs utan at noka eining rapporterer ein feil. Kontroller begge retningar før du dreg ein konklusjon om tunnelen. Eit svar som går ut feil veg, forsvinn frå teljarane til tunnelen, og difor er dei to endane usamde om noko vart sendt. Legg merke til kva teljar som flytta seg før du rører ein regel.

Kvifor det lokale subnettet vinn

Ein vert med ei adresse på eit lokalt nettverk har ei tilkopla rute for det prefikset i hovudtabellen, og ei tilkopla rute er eit direkte treff. Når kallaren kjem frå same subnett, finn oppslaget den lokale lenkja før tunnelen i det heile blir vurdert.

Det er asymmetrien som gjer det forvirrande å diagnostisere. Kallarar frå det breiare internettet verkar fordi dei ikkje samsvarar med noka lokal rute, medan den eine kallaren som deler kontorprefikset feilar, og det er nettopp den kallaren nokon testar med.

Peer-dekking er ikkje det same som installerte ruter

På tunnelsida skildrar dei tillatne områda til ein peer kva som kan sendast inn i tunnelen og kva kjelder som blir godtekne frå han. Dei seier ingenting om kvar den lokale rutetabellen vil sende ein pakke.

Viss tunnelverktyet installerer ei standardrute på verten, kan det dra uslekta trafikk inn i tunnelen som følgjeskade. Der ein policyregel i staden bør eige avgjerda, finst valet for ruteinstallasjon nettopp for å hindre det, og adressene, nøklane og endepunktinnstillingane blir nøyaktig som dei var. Ei standardrute lagd til for enkelheits skuld er ein vanleg måte ein vert mistar sitt eige lokale nettverk på.

Vel tabellen etter kjeldeadressa

Ein kildebasert regel sender svar frå tenesteadressa inn i ein privat tabell der standarden er tunnelen, medan alt anna held fram med å bruke hovudtabellen. Vel tabell- og prioritetsnummer som ikkje blir brukte lokalt, og les dei eksisterande reglane før du set inn noko. Les dei levande reglane i staden for ei lagra fil, for dei to kan avvike etter ein 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 lina får ei manglande rute til å feile synleg i staden for å falle tilbake til den lokale lenkja. Kjelda må faktisk vere tildelt verten, og dei vanlege lokale og primære oppslaga må bli på sine tidlegare plassar. Regelen vel ein tabell etter kjelde; han samanliknar ikkje prefikslengder mellom tabellar.

Stadfest vegen, så tenesta

Spør kjernen kva han ville gjere i staden for å slutte frå eit opptak, med tenesteadressa som kildeveljar. Eit rett svar her sparar ein heil pakkesporing.

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

Utdataa bør nemne tunnelen. Test deretter ei kjelde du ikkje har rørt, og stadfest at ho framleis tek den lokale lenkja, slik at endringa heldt seg avgrensa til éi adresse. Ein breiare veljar ville ikkje bevise noko om den opphavlege klaga.

Kva dette ikkje rettar

Lat vidaresending, brannmurreglar og ICMPv6-åtferd på gatewayen vere som dei var, for ei kjelderute erstattar ingen av dei. Ei manglande Packet Too Big-melding øydelegg framleis store svar, uansett kva tabell som vann oppslaget. Rett det før du legg til rutingreglar, elles overlever symptomet endringa.

Stadfest publiseringsmodellen før du brukar noko av dette. Ein omvend proxy som opnar si eiga backend-tilkopling, presenterer si eiga kjelde og bevarer ikkje kallaren, så denne feilen kan ikkje oppstå i det designet. Å bruke regelen der ville leggje til eit rutingunntak som ikkje løyser noko og skjuler den eigentlege årsaka.

Til slutt skriv du reglenumra og tabellen inn i konfigurasjonsstyringa til verten. Ein policyregel lagd til for hand forsvinn ved neste gjenoppbygging, og kontorkallaren kjem tilbake med same klaga.