Nestita WireGuard: la meza salto ne povas respondi sian propran pordon

Tri WireGuard-saltoj atingas reton sen publika adreso, kaj tiam la meza maŝino ĉesas respondi ĉe la pordo, ĉe kiu ĝi devis aŭskulti. La tunelo plu funkcias, la malproksima gastiganto ankoraŭ respondas, kaj nur la meza servilo mem silentis de ekstere. Tiu kombinaĵo konfuzas ĝuste ĉar ĝi estas mem kaŭzita: la meza salto obeas sian propran enkursigan tabelon, kaj la tabelo sendas ĝiajn respondojn la malĝustan vojon.

Ĉeno, kiu funkcias ĝis vi parolas kun la meza skatolo

Prenu ilustran ĉenon: kliento A atingas servilon B per UDP 500, kaj B iras plu al servilo C per UDP 500. C akceptas trafikon nur de la adreso de sia sola samtavolano, kio faras ĝin folio kaj tenas ĝian konduton simpla. B ne estas folio, kaj ĉio interesa pri ĉi tiu paneo okazas ĝuste tie.

La distingo gravas ĉar la roloj de folio kaj mezo tiras en kontraŭajn direktojn. Folio povas sendi ĉion en unu tunelon sen sekvoj, ĉar nenio alia dependas de ĝi. Meza salto estas samtempe finpunkto por klientoj kaj kliento al la malproksima flanko, kaj tiuj du laboroj volas malsaman enkursigon.

Kial la respondo eliras tra la tunelo

Ĉe B, la interfaco turnita al C portas AllowedIPs = 0.0.0.0/0 kune kun la kongrua apriora vojo. Ĉiu paketo, kiun B originas, do iras en tiun tunelon, krom se io pli specifa havas prioritaton.

Paketo de A adresita al B alvenas kaj estas akceptata, ĉar B estas la celo kaj loka livero okazas unue. La respondo estas tute nova loke generita paketo direktita al la publika adreso de A, kaj tiu celo kongruas kun la apriora vojo en la tunelon. C ricevas ĝin, ne posedas tiun adreson, kaj forĵetas ĝin.

La simptomo legiĝas kiel fajroŝirma problemo aŭ ŝlosila malkongruo, kaj neniu el ambaŭ veras ĉi tie. Kaptaĵo ĉe la tunelo al C montras la respondojn iri la malĝustan direkton. Tiu unu observo ŝparas pli da tempo ol iu ajn kvanto da legado de agordo, do notu ĝin antaŭ ol vi komencos ŝanĝi ŝlosilojn. Iu, kiu ne vidis la kaptaĵon, supozos, ke la tunelo mem rompiĝis.

La mallarĝa riparo: politikaj reguloj, kiuj kongruas kun fonta pordo

Respondoj el la aŭskultanta soketo de B eliras kun fonta pordo 500. Politika regulo povas kongrui kun tio kaj resendi tiujn paketojn al la ordinara tabelo:

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

Politikaj reguloj estas konsultataj laŭ prioritata ordo, kaj la ĉefa tabelo estas ĉe 32766, do regulo ĉe 100 estas demandata antaŭ ol la apriora vojo de la tunelo rajtas paroli. Aldonu unu eron por ĉiu pordo, kiu devas resti atingebla de ekstere, kaj nenion pli, por ke plusendita trafiko daŭre uzu la tunelon por kiu ĝi estis konstruita.

Konu la limon de ĉi tiu artifiko. La elektilo sport kongruas kun loke generitaj paketoj, kio kovras ĝuste la respondan kazon kaj intence ne kovras trafikon, kiun B nur plusendas por iu alia. Servo gastigata malantaŭ B ankoraŭ bezonas sian propran respondon, kaj ŝajnigi alie produktas riparon, kiu funkcias por la unua servo kaj malsukcesas por la dua.

Donu posedanton al la regulo

Regulo tajpita en prompto malaperas la venontan fojon, kiam la interfaco estas rekonstruata. Ĉe WireGuard-agordo, metu ĝin tien, kie la interfaco estas kreata kaj forigata:

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

Se NetworkManager, distribua hoko aŭ uja enirpunkto posedas la interfacon, la paro apartenas al tiu posedanto anstataŭ al mane redaktita dosiero. Kontrolu la efikajn regulojn post rekonekto, ne nur post la unua starto, ĉar la unua starto estas la kazo, kiu ĉiam funkcias.

Komparu la alternativojn honeste

La fonta-porda regulo estas unu el kvar eliroj, kaj ĝi estas la plej mallarĝa el ili. Ĝi havas la avantaĝon tute ne tuŝi la tunelan politikon, kio estas kial ĝi emas postvivi postajn ŝanĝojn. Mallarĝaj riparoj ankaŭ laŭte malsukcesas, kiam ili ĉesas aplikiĝi, dum larĝa escepto daŭre silente funkcias longe post kiam la kialo por ĝi malaperis. Tiu diferenco pli gravas ol eleganteco, kiam iu alia posedas la skatolon post du jaroj.

Kontrolu de ambaŭ finoj post kiam vi elektis. De A, komencu konekton al la pordo de B kaj tenu ĝin okupata dum iom da tempo. Ĉe B, igi la kernon pravigi la respondan vojon per io kiel ip route get <address-of-A> sport 500, kaj konfirmu, ke ĝi nomas la WAN-interfacon prefere ol la tunelon. Post tio, kontrolu, ke io malantaŭ C ankoraŭ respondas tra la ĉeno, kio pruvas, ke la escepto restis mallarĝa anstataŭ fariĝi pretervojo. Finfine, skribu la pordojn en la dizajnajn notojn, alie la sekva operatoro remalkovros ĉi tion ĉe alia servo.