Geneste WireGuard: die middelste skakel kan nie sy eie poort antwoord nie
Wanneer die middelste skakel alles in een tonnel stuur, verlaat antwoorde op sy inkomende diens via die verkeerde pad. ’n Reël vir die bronspoort by die koppelvlak maak dit reg.
Drie WireGuard-skakels bereik ’n netwerk wat geen publieke adres het nie, en dan hou die middelste masjien op om te antwoord op die poort waarop dit veronderstel was om te luister. Die tonnel verder werk steeds, die verre gasheer reageer steeds, en net die middelste bediener self het van buite stil geword. Daardie kombinasie is verwarrend juis omdat dit self veroorsaak is: die middelste skakel gehoorsaam sy eie roetertabel, en die tabel stuur sy antwoorde die verkeerde kant toe.
’n Ketting wat werk totdat jy met die middelste blok praat
Neem ’n illustratiewe ketting: kliënt A bereik bediener B op UDP 500, en B bereik verder na bediener C op UDP 500. C aanvaar verkeer slegs van sy enkele eweknie-adres, wat dit ’n blaar maak en sy gedrag eenvoudig hou. B is nie ’n blaar nie, en alles interessant aan hierdie faling gebeur daar.
Die onderskeid maak saak omdat blaar- en middelrolle in teenoorgestelde rigtings trek. ’n Blaar kan alles in een tonnel stuur sonder gevolge, want niks anders is daarvan afhanklik nie. ’n Middelste skakel is gelyktydig ’n eindpunt vir kliënte en ’n kliënt na die verre kant, en daardie twee take wil verskillende roetering hê.
Waarom die antwoord deur die tonnel vertrek
Op B dra die koppelvlak wat na C wys AllowedIPs = 0.0.0.0/0 saam met die ooreenstemmende verstekroete. Elke pakket wat B oorsprong het, gaan dus in daardie tonnel in, tensy iets meer spesifiek voorrang kry.
’n Pakket van A gerig aan B kom aan en word aanvaar, want B is die bestemming en plaaslike aflewering gebeur eerste. Die antwoord is ’n splinternuwe plaaslik gegenereerde pakket wat op A se publieke adres gerig is, en daardie bestemming pas by die verstekroete in die tonnel. C ontvang dit, besit nie daardie adres nie, en laat dit val.
Die simptoom lees soos ’n brandmuurprobleem of ’n sleutelwanpassing, en nie een is hier waar nie. ’n Opname op die tonnel na C wys die antwoorde beweeg in die verkeerde rigting. Daardie enkele waarneming spaar meer tyd as enige hoeveelheid lees van konfigurasie, so skryf dit neer voordat jy sleutels begin verander. Enigiemand wat nie die opname gesien het nie, sal aanneem die tonnel self is stukkend.
Die nou herstel: beleidsreëls wat by ’n bronspoort pas
Antwoorde van B se luisterende soket vertrek met bronspoort 500. ’n Beleidsreël kan daarby pas en daardie pakkette terug na die gewone tabel stuur:
ip rule add sport 500 table main priority 100
ip rule add sport 8080 table main priority 101Beleidsreëls word in prioriteitsorde geraadpleeg, en die hooftabel sit op 32766, so ’n reël op 100 word gevra voordat die tonnel se verstekroete iets te sê kry. Voeg een inskrywing by per poort wat van buite bereikbaar moet bly en niks meer nie, sodat deurgestuurde verkeer die tonnel bly gebruik waarvoor dit gebou is.
Ken die grens van hierdie truuk. Die keurder sport pas by plaaslik gegenereerde pakkette, wat presies die antwoordgeval dek en doelbewus nie verkeer dek wat B bloot vir iemand anders deurstuur nie. ’n Diens wat agter B gehuisves word, het steeds sy eie antwoord nodig, en om anders voor te gee lewer ’n oplossing wat vir die eerste diens werk en vir die tweede faal.
Gee die reël ’n eienaar
’n Reël wat by ’n opdragprompt getik word, verdwyn die volgende keer wanneer die koppelvlak herbou word. Op ’n WireGuard-opstelling moet jy dit plaas waar die koppelvlak geskep en verwyder word:
PostUp = ip rule add sport 500 table main priority 100
PostDown = ip rule del sport 500 table main priority 100As NetworkManager, ’n distribusie-haak of ’n houer-inskrywingspunt die koppelvlak besit, hoort die paar in daardie eienaar eerder as in ’n handmatig bewerkte lêer. Kontroleer die effektiewe reëls ná ’n herverbinding, nie net ná die eerste begin nie, want die eerste begin is die geval wat altyd werk.
Vergelyk die alternatiewe eerlik
Die bronspoort-reël is een van vier uitweë, en dit is die nouste van hulle. Dit het die voordeel dat dit glad nie aan die tonnelbeleid raak nie, en daarom oorleef dit gewoonlik latere veranderinge. Nou regmaaksels faal ook hardop wanneer hulle ophou geld, terwyl ’n breë uitsondering stil aanhou werk lank nadat die rede daarvoor verdwyn het. Daardie verskil maak meer saak as elegansie wanneer iemand anders die boks oor twee jaar besit.
| 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 |
Verifieer van beide kante sodra jy gekies het. Vanaf A, begin ’n verbinding na B se poort en hou dit ’n ruk besig. Op B, laat die kern die antwoordpad regverdig met iets soos ip route get <address-of-A> sport 500, en bevestig dat dit die WAN-koppelvlak noem eerder as die tonnel. Daarna, kontroleer dat iets agter C steeds deur die ketting antwoord, wat bewys die uitsondering het nou gebly in plaas daarvan om ’n omweiding te word. Ten slotte, teken die poorte in die ontwerpnotas aan, of die volgende operateur herontdek dit op ’n ander diens.