Nästlad WireGuard: det mellersta hoppet kan inte svara på sin egen port

Tre WireGuard-hopp når ett nätverk utan offentlig adress, och då slutar den mellersta maskinen att svara på den port den skulle lyssna på. Tunneln vidare fungerar fortfarande, den avlägsna värden svarar fortfarande, och bara den mellersta servern själv har tystnat utifrån. Den kombinationen är förvirrande just för att den är självförvållad: det mellersta hoppet lyder sin egen routingtabell, och tabellen skickar dess svar i fel riktning.

En kedja som fungerar tills du pratar med den mellersta lådan

Ta en illustrativ kedja: klient A når server B på UDP 500, och B går vidare till server C på UDP 500. C accepterar bara trafik från adressen till sin enda peer, vilket gör den till ett löv och håller dess beteende enkelt. B är inte ett löv, och allt intressant med det här felet händer där.

Skillnaden spelar roll eftersom löv- och mittroller drar i motsatta riktningar. Ett löv kan skicka allt in i en enda tunnel utan konsekvenser, eftersom inget annat är beroende av det. Ett mellersta hopp är samtidigt en ändpunkt för klienter och en klient mot den avlägsna sidan, och de två jobben vill ha olika routing.

Varför svaret lämnar genom tunneln

På B bär gränssnittet mot C AllowedIPs = 0.0.0.0/0 tillsammans med den matchande standardvägen. Därför går varje paket som B skapar in i den tunneln, om inte något mer specifikt får företräde.

Ett paket från A adresserat till B kommer in och accepteras, eftersom B är målet och lokal leverans sker först. Svaret är ett helt nytt lokalt genererat paket riktat till A:s offentliga adress, och den destinationen matchar standardvägen in i tunneln. C tar emot det, äger inte den adressen och släpper det.

Symtomet läses som ett brandväggsproblem eller en nyckelmismatch, och ingen av dem är sann här. En avlyssning på tunneln mot C visar att svaren går i fel riktning. Den enda observationen sparar mer tid än någon mängd läsning av konfiguration, så skriv ner den innan du börjar byta nycklar. Den som inte sett avlyssningen kommer att anta att själva tunneln är trasig.

Den smala reparationen: policyregler som matchar en källport

Svar från B:s lyssnande socket går ut med källport 500. En policyregel kan matcha det och skicka tillbaka paketen till den vanliga tabellen:

ip rule add sport 500 table main priority 100
ip rule add sport 8080 table main priority 101

Policyregler konsulteras i prioritetsordning, och huvudtabellen ligger på 32766, så en regel på 100 tillfrågas innan tunnelns standardväg har något att säga. Lägg till en post per port som måste förbli nåbar utifrån och inget mer, så att vidarebefordrad trafik fortsätter använda tunneln den byggdes för.

Känn gränsen för det här tricket. Väljaren sport matchar lokalt genererade paket, vilket täcker exakt svarsfallet och medvetet inte täcker trafik som B bara vidarebefordrar för någon annan. En tjänst som hostas bakom B behöver fortfarande sitt eget svar, och att låtsas motsatsen ger en lösning som fungerar för den första tjänsten och misslyckas för den andra.

Ge regeln en ägare

En regel som skrivs i en prompt försvinner nästa gång gränssnittet byggs om. I en WireGuard-installation lägger du den där gränssnittet skapas och tas bort:

PostUp = ip rule add sport 500 table main priority 100
PostDown = ip rule del sport 500 table main priority 100

Om NetworkManager, en distributionshook eller en container-entrypoint äger gränssnittet hör paret till den ägaren i stället för i en handredigerad fil. Kontrollera de effektiva reglerna efter en återanslutning, inte bara efter första starten, eftersom första starten är fallet som alltid fungerar.

Jämför alternativen ärligt

Källportsregeln är en av fyra vägar ut, och den smalaste av dem. Den har fördelen att inte röra tunnelpolicyn alls, vilket är varför den tenderar att överleva senare ändringar. Smala reparationer misslyckas också högljutt när de slutar gälla, medan ett brett undantag fortsätter fungera tyst långt efter att skälet till det försvunnit. Den skillnaden betyder mer än elegans när någon annan äger lådan om två år.

Verifiera från båda ändar när du har valt. Från A startar du en anslutning till B:s port och håller den upptagen en stund. På B låter du kärnan motivera svarsvägen med något som ip route get <address-of-A> sport 500, och bekräfta att den namnger WAN-gränssnittet och inte tunneln. Kontrollera därefter att något bakom C fortfarande svarar genom kedjan, vilket bevisar att undantaget förblev smalt i stället för att bli en omväg. Skriv slutligen ner portarna i designanteckningarna, annars återupptäcker nästa operatör detta på en annan tjänst.