Svaret lämnar LAN:et, inte tunneln: varför och hur

En tjänst som publiceras via en gateway fungerar från större delen av internet och misslyckas från ett kontor. Någon undersöker tunneln, ser begäran anlända och drar slutsatsen att svaret måste följa samma väg tillbaka. Linux fungerar inte så, och ingen undersökning av tunneln ändrar svaret. Svaret routas efter destination, och den enda misslyckade anroparen sitter på ett subnät som värden redan når direkt.

Vad som faktiskt avgör ett utgående paket

Kärnan slår upp en rutt för paketets destination, konsulterar policyregler i prioritetsordning och därefter tabellen som en matchande regel väljer. Gränssnittet som paketet kom in på spelar ingen roll, om inte en regel eller markering skrivits för att göra det viktigt. Det är ett routingfaktum om den här värden, inte ett fel i tunneln.

En begäran som tas emot på tunneln kan därför ge ett svar som lämnar via det fysiska gränssnittet, och flödet blir enkelriktat utan att någon enhet rapporterar ett fel. Kontrollera båda riktningarna innan du drar en slutsats om tunneln. Ett svar som går ut åt fel håll försvinner från tunnelns räknare, och därför är de två ändarna oense om huruvida något skickades. Notera vilken räknare som rörde sig innan du rör en regel.

Varför det lokala subnätet vinner

En värd med en adress på ett lokalt nätverk har en ansluten rutt för det prefixet i huvudtabellen, och en ansluten rutt är en direkt träff. När anroparen kommer från samma subnät hittar uppslaget den lokala länken innan tunneln ens övervägs.

Det är asymmetrin som gör det förvirrande att diagnostisera. Anropare från det bredare internet fungerar eftersom de inte matchar någon lokal rutt, medan den enda anroparen som delar kontorets prefix misslyckas, och det är just den anroparen någon testar med.

Peer-täckning är inte detsamma som installerade rutter

På tunnelsidan beskriver en peers tillåtna intervall vad som får skickas in i tunneln och vilka källor som accepteras från den. De säger ingenting om vart den lokala routingtabellen skickar ett paket.

Om tunnelverktyget installerar en standardrutt på värden kan det dra in orelaterad trafik i tunneln som följdskada. Där en policyregel i stället bör äga beslutet finns verktygets alternativ för ruttinstallation just för att förhindra det, och adresserna, nycklarna och slutpunktsinställningarna förblir exakt som de var. En standardrutt som läggs till för enkelhetens skull är ett vanligt sätt för en värd att förlora sitt eget lokala nätverk.

Välj tabellen efter källadressen

En källbaserad regel skickar svar från tjänstadressen in i en privat tabell vars standard är tunneln, medan allt annat fortsätter att använda huvudtabellen. Välj tabell- och prioritetsnummer som inte används lokalt, och läs de befintliga reglerna innan du infogar något. Läs de levande reglerna i stället för en sparad fil, eftersom de två kan skilja sig efter 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 sista raden får en saknad rutt att misslyckas synligt i stället för att falla tillbaka på den lokala länken. Källan måste verkligen vara tilldelad värden, och de vanliga lokala och primära uppslagen måste stanna på sina tidigare positioner. Regeln väljer en tabell efter källa; den jämför inte prefixlängder mellan tabeller.

Bekräfta vägen, sedan tjänsten

Fråga kärnan vad den skulle göra i stället för att sluta dig till det från en fångst, med tjänstadressen som källväljare. Ett korrekt svar här sparar en hel paketspårning.

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

Utdata bör namnge tunneln. Testa sedan en källa du inte rört och bekräfta att den fortfarande tar den lokala länken, så att ändringen hölls begränsad till en adress. En bredare väljare skulle inte bevisa något om det ursprungliga klagomålet.

Vad detta inte åtgärdar

Låt vidarebefordran, brandväggsregler och ICMPv6-beteende på gatewayen vara som de var, för en källrutt ersätter ingen av dem. Ett saknat Packet Too Big-meddelande bryter fortfarande stora svar, vilken tabell som än vann uppslaget. Åtgärda det innan du lägger till routingregler, annars överlever symtomet ändringen.

Bekräfta publiceringsmodellen innan du tillämpar något av detta. En omvänd proxy som öppnar sin egen backendanslutning presenterar sin egen källa och bevarar inte anroparen, så det här felet kan inte uppstå i den designen. Att tillämpa regeln där skulle lägga till ett routingundantag som inte löser något och döljer den verkliga orsaken.

Skriv slutligen in regelnumren och tabellen i värdens konfigurationshantering. En policyregel som lagts till för hand försvinner vid nästa ombyggnad, och kontorets anropare kommer tillbaka med samma klagomål.