Tre WireGuard-hopp når eit nettverk utan offentleg adresse, og då sluttar den midterste maskinen å svare på porten han skulle lytte på. Tunnelen vidare fungerer framleis, den fjerne verten svarar framleis, og berre den midterste serveren sjølv er blitt stille utanfrå. Den kombinasjonen er forvirrande nettopp fordi han er sjølvforskyldt: det midterste hoppet lyder sin eigen rutetabell, og tabellen sender svara hans feil veg.

Ei kjede som verkar heilt til du snakkar med den midterste boksen

Ta ei illustrativ kjede: klient A når server B på UDP 500, og B går vidare til server C på UDP 500. C godtek berre trafikk frå adressa til sin einaste peer, noko som gjer han til eit blad og held åtferda enkel. B er ikkje eit blad, og alt det interessante med denne feilen skjer der.

Forskjellen betyr noko fordi blad- og mellomrollar dreg i motsette retningar. Eit blad kan sende alt inn i éin tunnel utan konsekvensar, sidan ingenting anna er avhengig av det. Eit midterste hopp er samstundes eit endepunkt for klientar og ein klient mot den fjerne sida, og dei to jobbane vil ha ulik ruting.

Kvifor svaret går ut gjennom tunnelen

På B ber grensesnittet mot C AllowedIPs = 0.0.0.0/0 saman med den samsvarande standardruta. Derfor går kvar pakke B genererer inn i den tunnelen, med mindre noko meir spesifikt får forrang.

Ein pakke frå A adressert til B kjem inn og blir godteken, fordi B er målet og lokal levering skjer først. Svaret er ein heilt ny lokalt generert pakke retta mot den offentlege adressa til A, og den destinasjonen samsvarar med standardruta inn i tunnelen. C tek imot han, eig ikkje den adressa, og forkastar han.

Symptomet blir lese som eit brannmurproblem eller ein nøkkelmismatch, og ingen av delane er sanne her. Ein fangst på tunnelen mot C viser at svara går feil veg. Den eine observasjonen sparer meir tid enn noko mengd lesing av konfigurasjon, så skriv han ned før du byrjar å byte nøklar. Alle som ikkje har sett fangsten, vil tru at tunnelen sjølv er øydelagd.

Den smale reparasjonen: policyreglar som samsvarar med ein kjeldeport

Svar frå den lyttande socketen til B går ut med kjeldeport 500. Ein policyregel kan samsvare med det og rute pakkane tilbake til den vanlege tabellen:

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

Policyreglar blir konsulterte i prioritetsrekkjefølgje, og hovudtabellen ligg på 32766, så ein regel på 100 blir spurd før standardruta til tunnelen får noko å seie. Legg til éin oppføring per port som må halde fram med å vere tilgjengeleg utanfrå og ikkje noko meir, slik at vidaresendt trafikk held fram med å bruke tunnelen han vart bygd for.

Kjenn grensa for dette trikset. Veljaren sport samsvarar med lokalt genererte pakkar, noko som dekkjer nøyaktig svar-tilfellet og med vilje ikkje dekkjer trafikk B berre vidaresender for nokon andre. Ei teneste som blir hosta bak B treng framleis sitt eige svar, og å late som noko anna gir ei løysing som verkar for den første tenesta og feilar for den andre.

Gi regelen ein eigar

Ein regel skriven i ei ledetekst forsvinn neste gong grensesnittet blir bygd på nytt. På eit WireGuard-oppsett legg du han der grensesnittet blir oppretta og fjerna:

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

Viss NetworkManager, ein distribusjonshook eller eit container-inngangspunkt eig grensesnittet, høyrer paret til den eigaren i staden for i ei handredigert fil. Kontroller dei effektive reglane etter ei ny tilkopling, ikkje berre etter første start, fordi første start er tilfellet som alltid verkar.

Samanlikn alternativa ærleg

Kjeldeportregelen er éin av fire vegar ut, og den smalaste av dei. Han har fordelen av å ikkje røre tunnelpolitikken i det heile, og det er grunnen til at han har ein tendens til å overleve seinare endringar. Smale rettingar feilar også høgt når dei sluttar å gjelde, medan eit breitt unntak held fram med å verke stille lenge etter at grunnen til det er borte. Den forskjellen betyr meir enn eleganse når nokon andre eig boksen om to år.

ApproachWhat it costsWhere it breaks
Source-port policy ruleOne rule per exposed portAnything B forwards rather than originates
Destination exception routeA route pinned to specific client addressesClients whose address changes
Stop full-tunnelling on BLoses the catch-all path toward CDesigns that depend on it
Split into two tunnelsMore interfaces and more policyNothing, at the cost of complexity

Stadfest frå begge endar når du har valt. Frå A startar du ei tilkopling til porten til B og held ho oppteken ei stund. På B får du kjernen til å grunngi svarvegen med noko som ip route get <address-of-A> sport 500, og stadfest at han nemner WAN-grensesnittet og ikkje tunnelen. Etterpå kontrollerer du at noko bak C framleis svarar gjennom kjeda, noko som provar at unntaket vart smalt i staden for å bli ein omveg. Til slutt skriv du ned portane i designnotata, elles vil neste operatør gjenoppdage dette på ei anna teneste.

Relaterte artiklar