Svaret forlader LAN'et, ikke tunnelen: hvorfor og hvordan

En tjeneste, der udgives gennem en gateway, virker fra det meste af internettet og fejler fra ét kontor. Nogen undersøger tunnelen, ser anmodningen ankomme og konkluderer, at svaret må følge samme vej tilbage. Linux virker ikke sådan, og ingen mængde undersøgelse af tunnelen ændrer svaret. Svaret routes efter destination, og den ene fejlende kaldende ligger på et subnet, som værten allerede når direkte.

Hvad der egentlig bestemmer en udgående pakke

Kernen slår en rute op til pakkens destination, rådfører sig med politikregler i prioritetsrækkefølge og derefter den tabel, en matchende regel vælger. Den grænseflade, en pakke ankom på, spiller ingen rolle, medmindre en regel eller et mærke er skrevet for at gøre det vigtigt. Det er et routingfaktum om denne vært, ikke en fejl i tunnelen.

En anmodning modtaget på tunnelen kan derfor give et svar, der forlader gennem den fysiske grænseflade, og strømmen bliver ensrettet, uden at nogen enhed rapporterer en fejl. Kontroller begge retninger, før du drager en konklusion om tunnelen. Et svar, der forlader den forkerte vej, forsvinder fra tunnelens tællere, og derfor er de to ender uenige om, hvorvidt noget blev sendt. Læg mærke til, hvilken tæller der flyttede sig, før du rører en regel.

Hvorfor det lokale subnet vinder

En vært med en adresse på et lokalt netværk har en tilsluttet rute til det præfiks i hovedtabellen, og en tilsluttet rute er et direkte match. Når den kaldende kommer fra samme subnet, finder opslaget det lokale link, før tunnelen overhovedet overvejes.

Det er asymmetrien, der gør det forvirrende at diagnosticere. Kaldende fra det bredere internet virker, fordi de ikke matcher nogen lokal rute, mens den ene kaldende, der deler kontorets præfiks, fejler, og det er præcis den kaldende, nogen tester med.

Peer-dækning er ikke det samme som installerede ruter

På tunnelsiden beskriver en peers tilladte intervaller, hvad der må sendes ind i tunnelen, og hvilke kilder der accepteres fra den. De siger intet om, hvor den lokale routingtabel sender en pakke hen.

Hvis tunnelværktøjet installerer en standardrute på værten, kan det trække uvedkommende trafik ind i tunnelen som følgeskade. Hvor en politikregel i stedet bør eje beslutningen, findes værktøjets mulighed for ruteinstallation netop for at forhindre det, og adresserne, nøglerne og endpoint-indstillingerne forbliver præcis som de var. En standardrute tilføjet for nemheds skyld er en almindelig måde, hvorpå en vært mister sit eget lokale netværk.

Vælg tabellen efter kildeadressen

En kildebaseret regel sender svar fra tjenesteadressen ind i en privat tabel, hvis standard er tunnelen, mens alt andet fortsat bruger hovedtabellen. Vælg tabel- og prioritetsnumre, der ikke bruges lokalt, og læs de eksisterende regler, før du indsætter noget. Læs de levende regler i stedet for en gemt fil, for de to kan afvige efter en genstart.

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 sidste linje får en manglende rute til at fejle synligt i stedet for at falde tilbage til det lokale link. Kilden skal reelt være tildelt værten, og de almindelige lokale og primære opslag skal blive på deres tidligere pladser. Reglen vælger en tabel efter kilde; den sammenligner ikke præfikslængder på tværs af tabeller.

Bekræft stien, derefter tjenesten

Spørg kernen, hvad den ville gøre, i stedet for at slutte fra en optagelse, med tjenesteadressen som kildevælger. Et forkert svar her sparer en hel pakkesporing.

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

Outputtet bør navngive tunnelen. Test derefter en kilde, du ikke rørte, og bekræft, at den stadig tager det lokale link, så ændringen blev begrænset til én adresse. En bredere vælger ville ikke bevise noget om den oprindelige klage.

Hvad dette ikke retter

Hold videresendelse, firewallregler og ICMPv6-adfærd på gatewayen som de var, for en kilderute erstatter ingen af dem. En manglende Packet Too Big-besked ødelægger stadig store svar, uanset hvilken tabel der vandt opslaget. Ret det, før du tilføjer routingregler, ellers overlever symptomet ændringen.

Bekræft publiceringsmodellen, før du anvender noget af dette. En omvendt proxy, der åbner sin egen backend-forbindelse, præsenterer sin egen kilde og bevarer ikke den kaldende, så denne fejl kan ikke opstå i det design. At anvende reglen der ville tilføje en routingundtagelse, der intet løser og skjuler den egentlige årsag.

Skriv til sidst reglenumrene og tabellen ind i værtens konfigurationsstyring. En politikregel tilføjet i hånden forsvinder ved næste genopbygning, og kontorets kaldende vender tilbage med samme klage.