Pesastatud WireGuard: keskmine hüpe ei suuda omaenda pordile vastata
Kui keskmine hüpe saadab kõik ühte tunnelisse, väljuvad vastused selle sissetulevale teenusele vale teed pidi. Liidese lähtepordi reegel parandab selle.
Kolm WireGuardi hüpet jõuavad võrku, millel pole avalikku aadressi, ja siis lakkab keskmine masin vastamast pordil, millel see pidi kuulama. Tunnel edasi töötab endiselt, kaugem host vastab endiselt ja ainult keskmine server ise on väljast vaikseks jäänud. See kombinatsioon on segane just seetõttu, et see on ise tekitatud: keskmine hüpe kuuletub oma marsruutimistabelile ja tabel saadab selle vastused vale suunda.
Kett, mis töötab seni, kuni keskmise kastiga rääkima hakkad
Võtke näitlik kett: klient A jõuab serverini B UDP 500 kaudu ja B läheb edasi serverini C UDP 500 kaudu. C võtab liiklust vastu ainult oma ainsa partneri aadressilt, mis teeb sellest lehe ja hoiab selle käitumise lihtsana. B ei ole leht ja kõik huvitav selles rikkes toimub just seal.
Erinevus on oluline, sest lehe ja keskme rollid tõmbavad vastassuundades. Leht võib kõik ühte tunnelisse saata tagajärgedeta, kuna mitte miski muu ei sõltu sellest. Keskmine hüpe on korraga nii klientide lõpp-punkt kui ka klient kaugema poole suunas ning need kaks tööd tahavad erinevat marsruutimist.
Miks vastus tunnelist väljub
B-l kannab C poole suunatud liides AllowedIPs = 0.0.0.0/0 koos vastava vaikimisi marsruudiga. Seetõttu läheb iga B loodud pakett sellesse tunnelisse, kui just midagi täpsemat ei ole ülimuslik.
A-lt B-le adresseeritud pakett saabub ja võetakse vastu, sest B on sihtkoht ja kohalik kohaletoimetamine toimub esimesena. Vastus on täiesti uus kohapeal loodud pakett, mis on suunatud A avalikule aadressile, ja see sihtkoht vastab vaikimisi marsruudile tunnelisse. C saab selle kätte, ei oma seda aadressi ja viskab selle ära.
Sümptom loeb nagu tulemüüri probleem või võtme mittevastavus, ja kumbki pole siin tõsi. Tunnelil C poole tehtud püük näitab, et vastused lähevad vales suunas. See üks tähelepanek säästab rohkem aega kui ükskõik kui palju konfiguratsiooni lugemist, nii et kirjutage see üles enne, kui hakkate võtmeid vahetama. Igaüks, kes püüki näinud pole, eeldab, et tunnel ise on katki.
Kitsas parandus: poliitikareeglid, mis vastavad lähtepordile
B kuulava soketi vastused väljuvad lähtepordiga 500. Poliitikareegel saab sellega sobida ja need paketid tagasi tavalise tabeli juurde suunata:
ip rule add sport 500 table main priority 100
ip rule add sport 8080 table main priority 101Poliitikareegleid vaadatakse prioriteedi järjekorras ja põhitabel asub 32766 juures, nii et reeglit 100 juures küsitakse enne, kui tunneli vaikimisi marsruut midagi ütleb. Lisage üks kirje iga pordi kohta, mis peab väljast ligipääsetavaks jääma, ja mitte rohkem, et edasisaadetav liiklus kasutaks edasi tunnelit, mille jaoks see ehitati.
Tundke selle triki piiri. Valija sport sobib kohapeal loodud pakettidega, mis katab täpselt vastuse juhtumi ja teadlikult ei kata liiklust, mida B lihtsalt kellegi teise eest edasi saadab. B taga majutatud teenus vajab endiselt oma vastust, ja vastupidise teesklemine annab paranduse, mis töötab esimese teenuse puhul ja ebaõnnestub teise puhul.
Andke reeglile omanik
Käsureal trükitud reegel kaob järgmisel korral, kui liides uuesti üles ehitatakse. WireGuardi seadistuses pange see sinna, kus liides luuakse ja eemaldatakse:
PostUp = ip rule add sport 500 table main priority 100
PostDown = ip rule del sport 500 table main priority 100Kui liidest omab NetworkManager, distributsiooni konks või konteineri sisenemispunkt, kuulub paar sellele omanikule, mitte käsitsi muudetud failile. Kontrollige kehtivaid reegleid pärast uuesti ühendamist, mitte ainult pärast esimest käivitust, sest esimene käivitus on juhtum, mis töötab alati.
Võrrelge alternatiive ausalt
Lähtepordi reegel on üks neljast väljapääsust ja neist kõige kitsam. Selle eelis on, et see ei puuduta tunnelipoliitikat üldse, mistõttu see kipub hilisemaid muudatusi üle elama. Kitsad parandused ebaõnnestuvad ka valjult, kui need enam ei kehti, samas kui lai erand jätkab vaikselt toimimist kaua pärast seda, kui põhjus on kadunud. See erinevus loeb rohkem kui elegantsus, kui kahe aasta pärast omab kasti keegi teine.
| 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 |
Kontrollige mõlemast otsast, kui olete valinud. A-st alustage ühendust B pordiga ja hoidke seda mõnda aega hõivatud. B-l pange tuum vastusteekonda põhjendama millegagi nagu ip route get <address-of-A> sport 500, ja kinnitage, et see nimetab WAN-liidest, mitte tunnelit. Pärast seda kontrollige, et midagi C taga vastab endiselt läbi keti, mis tõestab, et erand jäi kitsaks, mitte ei muutunud möödaviiguks. Lõpuks kirjutage pordid disainimärkmetesse, muidu avastab järgmine operaator selle mõne teise teenuse juures.