Nested na WireGuard: hindi kayang sagutin ng gitnang hop ang sarili nitong port

Tatlong hop ng WireGuard ang nakarating sa isang network na walang pampublikong address, at pagkatapos ay tumitigil ang gitnang makina sa pagsagot sa port kung saan dapat itong nakikinig. Gumagana pa rin ang tunnel pagtuloy, tumutugon pa rin ang malayong host, at ang tanging matahimik mula sa labas ay ang gitnang server mismo. Nakalilito ang kombinasyong iyon dahil mismong sarili ang may gawa: sinusunod ng gitnang hop ang sarili nitong routing table, at ipinapadala ng tabela ang mga sagot nito sa maling direksyon.

Isang chain na gumagana hanggang makausap mo ang gitnang kahon

Kumuha ng isang halimbawang chain: ang client A ay nakarating sa server B sa UDP 500, at ang B ay tumutuloy sa server C sa UDP 500. Tumatanggap lamang ang C ng trapiko mula sa address ng nag-iisa nitong kapares, na ginagawa itong dahon at pinapanatiling simple ang pag-uugali nito. Hindi dahon ang B, at lahat ng kawili-wili sa kabiguan na ito ay nangyayari doon.

Mahalaga ang pagkakaiba dahil ang mga tungkulin ng dahon at gitna ay humihila sa magkasalungat na direksyon. Maaaring ipadala ng dahon ang lahat sa isang tunnel nang walang bunga, dahil wala nang ibang nakadepende rito. Ang gitnang hop ay sabay na dulo para sa mga client at client patungo sa malayong panig, at ang dalawang gawaing iyon ay nais ng magkaibang routing.

Bakit lumalabas ang tugon sa tunnel

Sa B, ang interface na nakaharap sa C ay may dalang AllowedIPs = 0.0.0.0/0 kasama ang katumbas na default na ruta. Kaya ang bawat packet na ginagawa ng B ay pumapasok sa tunnel na iyon, maliban kung may mas tiyak na nakakakuha ng priyoridad.

Ang packet mula sa A na naka-address sa B ay dumarating at tinatanggap, dahil ang B ang patutunguhan at ang lokal na paghahatid ay nangyayari muna. Ang tugon ay bagong-bagong packet na ginawa nang lokal at naka-address sa pampublikong address ng A, at tumutugma ang patutunguhang iyon sa default na ruta papasok sa tunnel. Tinatanggap ito ng C, hindi pag-aari ang address na iyon, at itinatapon ito.

Ang sintomas ay binabasa na parang problema sa firewall o hindi pagtutugma ng key, at wala sa dalawa ang totoo dito. Ang isang pagkuha sa tunnel patungo sa C ay nagpapakita na ang mga tugon ay papunta sa maling direksyon. Ang nag-iisang obserbasyon na iyon ay nakakatipid ng mas maraming oras kaysa sa anumang dami ng pagbasa ng configuration, kaya isulat ito bago ka magsimulang magpalit ng key. Sinumang hindi pa nakakita ng pagkuha ay mag-aakala na ang tunnel mismo ay sira.

Ang makitid na pagkukumpuni: mga tuntunin ng patakaran na tumutugma sa port ng pinagmulan

Ang mga tugon mula sa nakikinig na socket ng B ay lumalabas na may port ng pinagmulan 500. Maaaring tumugma ang isang tuntunin ng patakaran doon at ibalik ang mga packet na iyon sa ordinaryong table:

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

Ang mga tuntunin ng patakaran ay sinusuri ayon sa pagkakasunod-sunod ng priyoridad, at ang pangunahing table ay nasa 32766, kaya ang tuntunin sa 100 ay tinatanong bago magkaroon ng sasabihin ang default na ruta ng tunnel. Magdagdag ng isang entry bawat port na dapat manatiling maabot mula sa labas at wala nang iba pa, upang ang ipinapasa na trapiko ay patuloy na gumamit ng tunnel na ginawa para dito.

Alamin ang hangganan ng trick na ito. Ang tagapili sport ay tumutugma sa mga packet na ginawa nang lokal, na sumasaklaw nang eksakto sa kaso ng tugon at sadyang hindi sumasaklaw sa trapikong ipinapasa lamang ng B para sa iba. Ang serbisyong naka-host sa likod ng B ay kailangan pa rin ng sarili nitong tugon, at ang pagpapanggap ng kabaligtaran ay gumagawa ng pagkukumpuning gumagana sa unang serbisyo at nabibigo sa pangalawa.

Bigyan ng may-ari ang tuntunin

Ang tuntuning nai-type sa prompt ay nawawala sa susunod na pagbuo muli ng interface. Sa setup ng WireGuard, ilagay ito kung saan ginagawa at tinatanggal ang interface:

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

Kung ang NetworkManager, isang hook ng distribusyon o isang entrypoint ng container ang may-ari ng interface, ang pares ay pag-aari ng may-ari na iyon at hindi ng file na inedit sa kamay. Suriin ang mabisang mga tuntunin pagkatapos ng muling pagkonekta, hindi lamang pagkatapos ng unang pagsisimula, dahil ang unang pagsisimula ang kaso na laging gumagana.

Ihambing ang mga alternatibo nang tapat

Ang tuntunin sa port ng pinagmulan ay isa sa apat na labasan, at ito ang pinakamakitid sa kanila. May kalamangan ito na hindi man lang hinahawakan ang patakaran ng tunnel, kaya madalas itong nakakaligtas sa mga susunod na pagbabago. Ang makitid na pagkukumpuni ay nabibigo rin nang malakas kapag tumigil sa pag-iral, samantalang ang malawak na eksepsyon ay patuloy na tahimik na gumagana matagal pagkatapos mawala ang dahilan nito. Ang pagkakaibang iyon ay mas mahalaga kaysa sa kagandahan kapag iba na ang may-ari ng kahon pagkalipas ng dalawang taon.

I-verify mula sa magkabilang dulo kapag nakapili ka na. Mula sa A, magsimula ng koneksyon sa port ng B at panatilihin itong abala nang ilang sandali. Sa B, ipa-justify sa kernel ang landas ng tugon gamit ang isang bagay na tulad ng ip route get <address-of-A> sport 500, at kumpirmahin na pinapangalanan nito ang WAN interface at hindi ang tunnel. Pagkatapos noon, suriin na may isang bagay sa likod ng C na sumasagot pa rin sa pamamagitan ng chain, na nagpapatunay na nanatiling makitid ang eksepsyon sa halip na maging bypass. Sa huli, itala ang mga port sa mga tala ng disenyo, kung hindi ay muling matutuklasan ito ng susunod na operator sa ibang serbisyo.