Nestet WireGuard: det midterste hoppet kan ikke svare på sin egen port
Når det midterste hoppet sender alt inn i én tunnel, forlater svar på tjenesten mot inngangen den gale veien. En kildeportregel på grensesnittet retter det.
Tre WireGuard-hopp når et nettverk uten offentlig adresse, og da slutter den midterste maskinen å svare på porten den skulle lytte på. Tunnelen videre fungerer fortsatt, den fjerne verten svarer fortsatt, og bare den midterste serveren selv er blitt stille utenfra. Den kombinasjonen er forvirrende nettopp fordi den er selvforskyldt: det midterste hoppet adlyder sin egen rutetabell, og tabellen sender svarene dens feil vei.
En kjede som virker helt til du snakker med den midterste boksen
Ta en illustrativ kjede: klient A når server B på UDP 500, og B går videre til server C på UDP 500. C godtar bare trafikk fra adressen til sin eneste peer, noe som gjør den til et blad og holder oppførselen enkel. B er ikke et blad, og alt det interessante med denne feilen skjer der.
Forskjellen betyr noe fordi blad- og mellomroller trekker i motsatte retninger. Et blad kan sende alt inn i én tunnel uten konsekvenser, siden ingenting annet avhenger av det. Et midterste hopp er samtidig et endepunkt for klienter og en klient mot den fjerne siden, og de to jobbene vil ha ulik ruting.
Hvorfor svaret går ut gjennom tunnelen
På B bærer grensesnittet mot C AllowedIPs = 0.0.0.0/0 sammen med den samsvarende standardruten. Derfor går hver pakke B genererer inn i den tunnelen, med mindre noe mer spesifikt får forrang.
En pakke fra A adressert til B kommer inn og godtas, fordi B er målet og lokal levering skjer først. Svaret er en helt ny lokalt generert pakke rettet mot A sin offentlige adresse, og den destinasjonen samsvarer med standardruten inn i tunnelen. C mottar den, eier ikke den adressen, og forkaster den.
Symptomet leses som et brannmurproblem eller en nøkkelmismatch, og ingen av delene er sant her. En fangst på tunnelen mot C viser at svarene går feil vei. Den ene observasjonen sparer mer tid enn noen mengde lesing av konfigurasjon, så skriv den ned før du begynner å bytte nøkler. Alle som ikke har sett fangsten, vil anta at tunnelen selv er ødelagt.
Den smale reparasjonen: policyregler som samsvarer med en kildeport
Svar fra B sin lyttende socket går ut med kildeport 500. En policyregel kan samsvare med det og rute pakkene tilbake til den vanlige tabellen:
ip rule add sport 500 table main priority 100
ip rule add sport 8080 table main priority 101Policyregler konsulteres i prioritetsrekkefølge, og hovedtabellen ligger på 32766, så en regel på 100 spørres før tunnelens standardrute får noe å si. Legg til én oppføring per port som må forbli tilgjengelig utenfra og ikke noe mer, slik at videresendt trafikk fortsetter å bruke tunnelen den ble bygget for.
Kjenn grensen for dette trikset. Velgeren sport samsvarer med lokalt genererte pakker, noe som dekker nøyaktig svar-tilfellet og bevisst ikke dekker trafikk B bare videresender for noen andre. En tjeneste som hostes bak B trenger fortsatt sitt eget svar, og å late som noe annet gir en løsning som virker for den første tjenesten og feiler for den andre.
Gi regelen en eier
En regel skrevet i en ledetekst forsvinner neste gang grensesnittet bygges på nytt. På et WireGuard-oppsett legger du den der grensesnittet opprettes og fjernes:
PostUp = ip rule add sport 500 table main priority 100
PostDown = ip rule del sport 500 table main priority 100Hvis NetworkManager, en distribusjonshook eller et container-inngangspunkt eier grensesnittet, hører paret til den eieren i stedet for i en håndredigert fil. Kontroller de effektive reglene etter en ny tilkobling, ikke bare etter første start, fordi første start er tilfellet som alltid virker.
Sammenlign alternativene ærlig
Kildeportregelen er én av fire veier ut, og den er den smaleste av dem. Den har fordelen av å ikke røre tunnelpolitikken i det hele tatt, og det er grunnen til at den har en tendens til å overleve senere endringer. Smale rettelser feiler også høylytt når de slutter å gjelde, mens et bredt unntak fortsetter å virke stille lenge etter at grunnen til det er borte. Den forskjellen betyr mer enn eleganse når noen andre eier boksen om to år.
| Approach | What it costs | Where it breaks |
|---|---|---|
| Source-port policy rule | One rule per exposed port | Anything B forwards rather than originates |
| Destination exception route | A route pinned to specific client addresses | Clients whose address changes |
| Stop full-tunnelling on B | Loses the catch-all path toward C | Designs that depend on it |
| Split into two tunnels | More interfaces and more policy | Nothing, at the cost of complexity |
Bekreft fra begge ender når du har valgt. Fra A starter du en forbindelse til B sin port og holder den opptatt en stund. På B får du kjernen til å begrunne svarveien med noe som ip route get <address-of-A> sport 500, og bekreft at den nevner WAN-grensesnittet og ikke tunnelen. Etterpå kontrollerer du at noe bak C fortsatt svarer gjennom kjeden, noe som beviser at unntaket forble smalt i stedet for å bli en omvei. Til slutt skriver du ned portene i designnotatene, ellers vil neste operatør gjenoppdage dette på en annen tjeneste.