La manpremo de WireGuard funkcias, sed la ofica subreto ne respondas

La manpremo finiĝas, wg show raportas freŝan transigon, kaj la tunela adreso de la servilo respondas al ping. Gastiganto en la loka reto de la servilo ne respondas. Tri kondiĉoj devas validi samtempe: la kliento devas enkursigi la lokretan prefikson en la tunelon, la servilo devas plusendi la pakaĵojn, kaj la respondo bezonas vojon reen. Kiam unu el la tri mankas, la simptomo estas identa.

AllowedIPs estas kaj alirlisto kaj enkursiga tabelo

Ĉe la kliento, la listo AllowedIPs decidas kaj kion oni rajtas sendi al tiu samtavolano kaj kiujn vojojn WireGuard instalas. Entajpo de samtavolano, kiu listigas nur la tunelan adreson de la servilo, instalas unu gastigantan vojon, do lokretaj celoj neniam eniras la tunelon. Aldoni la lokretan prefikson estas la unua afero kontrolenda, kaj ĝi ankaŭ estas la ŝanĝo plej ofte mankanta post kopiita agordo. Samtavolano vastigita al defaŭlta vojo estas alia dezajno, kaj ĝi ankaŭ movos la interretan trafikon de la kliento.

Tenu la gastigantan vojon kaj la lokretan prefikson kiel apartajn riĉaĵojn. Se la oficejo havas du subretojn, ambaŭ apartenas al la listo, kaj la mankanta dua prefikso produktas fiaskon, kiu aspektas selektema anstataŭ totala.

[Peer]
PublicKey = <server public key>
Endpoint = vpn.example.net:51820
AllowedIPs = 10.66.0.1/32, 192.168.50.0/24

Plusendado kaj tradukado apartenas al la servilo

La servilo bezonas ŝaltitan IP-plusendadon, plusendan regulon, kiu akceptas trafikon venantan el la tunelo, kaj tradukan regulon al sia loka reta interfaco. La tradukado estas tio, kio igas la dezajnon funkcii sen tuŝi ĉiun gastiganton en la ofica reto. La respondoj tiam revenas al la servilo anstataŭ al adreso, pri kiu la loka reto neniam aŭdis. Sen ĝi, ĉiu gastiganto bezonas vojon por la tunela subreto kaj fajroŝirmilan regulon, kiu permesas ĝin, kio malofte estas akceptebla en reto, kiun administras iu alia.

sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -i wg0 -j ACCEPT
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Reguloj aldonitaj permane malaperas ĉe restartigo, do ligu ilin al la interfaco per la hokaj komandoj en la servila agordo. Regula aro, kiu postvivas sian interfacon, estas kiel maŝino finas tradukante trafikon por tunelo, kiu ne plu ekzistas.

Kiam la loka reto translokiĝis kaj la regulo ne

Anstataŭigo de enkursigilo, kiu renumeras la ofican subreton, estas la klasika versio de ĉi tiu fiasko. La tunelo restas aktiva, la manpremo restas freŝa, kaj nenio malantaŭ la servilo respondas, ĉar la traduka regulo ankoraŭ nomas la malnovan adreson. Instalaj skriptoj ofte enbakis la lokretan adreson de la servilo en POSTROUTING-regulon, kaj post renumerado tiu adreso ekzistas sur neniu interfaco. La pakaĵoj tiam estas reverkitaj al celo, kiu ne povas respondi.

iptables -t nat -n -L POSTROUTING
ip -br addr show

Komparu la du eligojn. Traduka celo, kiu ne aperas en la interfaca listo, estas la cimo, kaj ripari ĝin estas unulinia ŝanĝo post kiam vi vidis ĝin. La regulo povas vivi en generita unuo anstataŭ en la WireGuard-agordo, do reŝargu tiun unuon post redaktado kaj konfirmu, ke la sekva ekfunkciigo ne reverkas vian ŝanĝon.

Du ejoj malantaŭ NAT bezonas lokon por renkontiĝi

Kiam neniu flanko akceptas envenantajn konektojn, la praktika respondo estas malgranda gastiganto kun publika adreso kaj du WireGuard-interfacoj. Ĉiu ejo konektiĝas eksteren, la meza gastiganto listigas la lokan reton de ĉiu samtavolano en sia propra AllowedIPs, kaj plusendado portas pakaĵojn inter la du tuneloj. Nenio en la fajroŝirmilo de iu ajn ejo devas ŝanĝiĝi, pro kio ĉi tiu dezajno facile disvastiĝas.

Enkursigado inter la ejoj konservas la originajn fontadresojn kaj tial konservas signifan protokoladon laŭ gastiganto. Tradukado ĉe la meza gastiganto estas pli simpla, kiam la du lokaj retoj interkovriĝas, sed je la kosto de perdi la fontan identecon en la protokoloj. Decidu, kiu eco gravas, antaŭ ol vi elektos.

Apartigu la tavolojn per kvar kontroloj

Faru unu kontrolon por tavolo anstataŭ ŝanĝi tri aferojn kaj esperi. La unua montras la aĝon de la manpremo kaj la nombrilojn por ĉiu samtavolano. La dua montras, ĉu la kliento efektive enkursigas tiun celon en la tunelon. La tria kaj la kvara diras al vi, ĉu la peto alvenis kaj ĉu iu politiko forĵetis ĝin post alveno.

wg show
ip route get 192.168.50.20
tcpdump -ni wg0 icmp
iptables -vnL FORWARD --line-numbers

Peto, kiu alvenas kaj ne elvokas respondon, montras al la responda vojo aŭ al la lokreta gastiganto. Peto, kiu neniam alvenas, montras al AllowedIPs aŭ al la vojo de la kliento. Tiuj du rezultoj bezonas malsamajn ripetojn, kaj la kaptaĵo estas tio, kio distingas ilin.