Įdėtasis WireGuard: vidurinis šuolis negali atsakyti į savo paties prievadą
Kai vidurinis šuolis siunčia viską į vieną tunelį, atsakymai į jo gaunamąją paslaugą išeina neteisingu keliu. Šaltinio prievado taisyklė sąsajoje tai ištaiso.
Trys WireGuard šuoliai pasiekia tinklą, kuris neturi viešojo adreso, ir tada vidurinė mašina nustoja atsakinėti į prievadą, kuriame ji turėjo klausytis. Tunelis toliau vis dar veikia, tolimasis hostas vis dar atsako, ir tik pats vidurinis serveris nutilo iš išorės. Šis derinys klaidina būtent todėl, kad jis pats sau sukeltas: vidurinis šuolis paklūsta savo paties maršrutizavimo lentelei, o lentelė siunčia jo atsakymus neteisinga kryptimi.
Grandinė, kuri veikia tol, kol nepakalbi su vidurine dėže
Paimkime iliustracinę grandinę: klientas A pasiekia serverį B per UDP 500, o B tęsiasi toliau į serverį C per UDP 500. C priima srautą tik iš savo vienintelio partnerio adreso, todėl jis tampa lapu ir jo elgsena išlieka paprasta. B nėra lapas, ir viskas, kas įdomaus šiame gedime, vyksta ten.
Šis skirtumas svarbus, nes lapo ir vidurio vaidmenys traukia priešingomis kryptimis. Lapas gali siųsti viską į vieną tunelį be pasekmių, nes niekas kitas nuo jo nepriklauso. Vidurinis šuolis vienu metu yra galinis taškas klientams ir klientas tolimosios pusės link, ir tie du darbai nori skirtingo maršrutizavimo.
Kodėl atsakymas išeina per tunelį
B kompiuteryje sąsaja, nukreipta į C, neša AllowedIPs = 0.0.0.0/0 kartu su atitinkamu numatytuoju maršrutu. Todėl kiekvienas B sugeneruotas paketas patenka į tą tunelį, nebent kas nors konkretesnio turi pirmenybę.
Paketas iš A, adresuotas B, atvyksta ir yra priimamas, nes B yra paskirties vieta ir vietinis pristatymas įvyksta pirmiausia. Atsakymas yra visiškai naujas vietoje sugeneruotas paketas, nukreiptas į A viešąjį adresą, ir ta paskirties vieta atitinka numatytąjį maršrutą į tunelį. C jį gauna, neturi to adreso ir jį išmeta.
Simptomas skaitomas kaip ugniasienės problema arba raktų nesutapimas, ir nė vienas čia nėra tiesa. Užfiksuotas srautas tunele link C rodo, kad atsakymai eina neteisinga kryptimi. Tas vienas pastebėjimas sutaupo daugiau laiko nei bet kiek konfigūracijos skaitymo, todėl užsirašykite jį prieš pradėdami keisti raktus. Kas nematė įrašo, manys, kad pats tunelis sugedęs.
Siauras taisymas: politikos taisyklės, atitinkančios šaltinio prievadą
Atsakymai iš B klausančiojo lizdo išeina su šaltinio prievadu 500. Politikos taisyklė gali tai atitikti ir grąžinti tuos paketus į įprastą lentelę:
ip rule add sport 500 table main priority 100
ip rule add sport 8080 table main priority 101Politikos taisyklės nagrinėjamos prioriteto tvarka, o pagrindinė lentelė yra ties 32766, todėl taisyklė ties 100 paklausiama anksčiau, nei tunelio numatytasis maršrutas turi ką pasakyti. Pridėkite po vieną įrašą kiekvienam prievadui, kuris turi likti pasiekiamas iš išorės, ir nieko daugiau, kad persiunčiamas srautas ir toliau naudotų tunelį, kuriam jis buvo pastatytas.
Žinokite šio triuko ribą. sport selektorius atitinka vietoje sugeneruotus paketus, o tai apima būtent atsakymo atvejį ir sąmoningai neapima srauto, kurį B tik persiunčia kam nors kitam. Paslaugai, talpinamai už B, vis dar reikia savo atsakymo, o teigiant priešingai gaunamas taisymas, kuris veikia pirmajai paslaugai ir nepavyksta antrajai.
Suteikite taisyklei šeimininką
Į komandinę eilutę įvesta taisyklė dingsta kitą kartą perstatant sąsają. WireGuard sąrankoje įdėkite ją ten, kur sąsaja sukuriama ir pašalinama:
PostUp = ip rule add sport 500 table main priority 100
PostDown = ip rule del sport 500 table main priority 100Jei sąsają valdo NetworkManager, distribucijos kablys ar konteinerio įėjimo taškas, pora priklauso tam valdytojui, o ne rankiniu būdu redaguotam failui. Patikrinkite galiojančias taisykles po prisijungimo iš naujo, o ne tik po pirmo paleidimo, nes pirmas paleidimas yra atvejis, kuris visada veikia.
Palyginkite alternatyvas sąžiningai
Šaltinio prievado taisyklė yra vienas iš keturių išėjimų ir siauriausias iš jų. Ji turi pranašumą visiškai neliesti tunelio politikos, todėl paprastai išgyvena vėlesnius pakeitimus. Siauri taisymai taip pat garsiai žlunga, kai nustoja galioti, o plati išimtis toliau tyliai veikia dar ilgai po to, kai priežastis dingo. Šis skirtumas svarbesnis už eleganciją, kai po dvejų metų dėžę valdo kas nors kitas.
| 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 |
Patikrinkite iš abiejų galų, kai jau pasirinkote. Iš A pradėkite ryšį į B prievadą ir kurį laiką laikykite jį užimtą. B kompiuteryje priverstkite branduolį pagrįsti atsakymo kelią kažkuo panašiu į ip route get <address-of-A> sport 500, ir patvirtinkite, kad jis įvardija WAN sąsają, o ne tunelį. Po to patikrinkite, ar kažkas už C vis dar atsako per grandinę, o tai įrodo, kad išimtis liko siaura, o ne virto apėjimu. Galiausiai užrašykite prievadus projektavimo pastabose, kitaip kitas operatorius tai vėl atras kitoje paslaugoje.