La manpremo de WireGuard funkcias, la servo ne

La manpremo kompletiĝas, la kliento montras freŝan transigan nombrilon, kaj tamen peto al servo sur la sama servilo malsukcesas. Tiu kombino konfuzas homojn, ĉar la tunelo videble funkcias. Kio ne estas pruvita estas loka liverado: la paketo atingis la gastiganton, kaj la gastiganto ankoraŭ devas akcepti ĝin sur la ĝusta ingo kaj transdoni ĝin al procezo kun permeso respondi. Trapasu tiujn tri kontrolpunktojn laŭorde.

Haltu ĉe la unua, kiu ne validas, kaj ne aldonu regulojn por la aliaj.

La manpremo pruvas nur la tunelon

La manpremo de WireGuard starigas ŝlosilojn inter samtavoloj kaj rajtigas trafikon por la intervaloj, kiujn ĉiu samtavolo listigis. Ĝi diras nenion pri tio, kiuj procezoj aŭskultas sur la servilo, kaj nenion pri tio, ĉu la fajroŝirmilo de la gastiganto akceptas paketojn adresitajn al unu el ĝiaj propraj adresoj.

Ĝuste tiu lasta distingo estas plej ofte preteratentata: trafiko al la gastiganto mem estas loka enigo, dum trafiko pasanta tra la gastiganto al aliloke estas plusendado. Iliajn regulojn tenas malsamaj fajroŝirmilaj ĉenoj kaj malsamaj agordoj. Kontroli la malĝustan ĉenon foruzas posttagmezon kaj redonas nombrilojn, kiuj aspektas senkulpaj.

Legu la aŭskultanton kaj la itineron

Ĉe la kliento, konfirmu, ke la tunela adreso de la servilo enkursiĝas en la tunelon. Ĉe la servilo, konfirmu, ke ingo ekzistas sur la adreso, kiun la kliento uzas, kaj ke la procezo malantaŭ ĝi estas la intencita.

wg show
ip route get 10.66.0.1
ss -lntup | grep -E ':80|:443'
nft list ruleset | grep -A6 'chain input'
curl -vk --max-time 5 https://10.66.0.1/

Aŭskultanto sur 127.0.0.1 neniam respondos peton adresitan al 10.66.0.1, kion ajn la fajroŝirmilo permesas. Aŭskultanto sur la ĵokera adreso respondos, se regulo ne blokas ĝin. La ingolisto do decidas duonon de la kazoj antaŭ ol ekzameni ajnan regulon. Pordo kaj adreso kune decidas, ĉu peto povas alveni.

Komparu la adreson, kiun la kliento uzas, kun la adreso, kiun la servilo efektive posedas sur la tunela interfaco. Malnova agordo ĉe iu ajn flanko produktas peton ĝuste enkursigitan al samtavolo, kiu ne havas tiun adreson.

Apliku regulojn por loka enigo, ne por plusendado

Se la paketo alvenas kaj la ingo ekzistas, la restanta limo estas la eniga politiko. Regulo, kiu permesas plusendadon, ne permesas lokan liveradon, kaj regulo limigita al unu interfaco eble ne kongruas kun la atendata nomo de la tunela interfaco.

Testu per unu permesita pordo al la celata servo anstataŭ malfermi la gastiganton. Poste kontrolu la propran rajtigon de la aplikaĵo: permeslisto, kontpostulo aŭ ligo al specifa gastigantnomo povas rifuzi peton, kiun la reto sukcese liveris.

Lasu la atestilkontrolojn en loko. Neatendita atestilidenteco estas informo pri tio, kiu gastiganto respondis, ne obstaklo por preteriri. Klaki preter ĝi kaŝas la solan indicon, kiu identigas la malĝustan servon.

Apartigu malsukcesojn de nomo, grando kaj identeco

Servo, kiu funkcias laŭ adreso sed malsukcesas laŭ nomo, estas DNS-problemo, kaj la korekto apartenas al la solvila agordo sendata al la kliento, ne al la fajroŝirmilo. Servo, kiu respondas malgrandajn petojn sed haltas ĉe pli grandaj respondoj, indikas pakan grandecon kaj MTU, kio estas tute alia enketo.

HTTPS-eraro nomanta la malĝustan gastiganton kutime signifas, ke la peto atingis alian servon, ofte ĉar prokura servilo aŭ alia aŭskultanto posedas tiun pordon. Legu la subjekton de la atestilo kaj komparu ĝin kun la gastiganto, kiun vi celis. Tiu komparo kostas nenion kaj ofte finas la enketon.

Notu, kiu kontrolpunkto malsukcesis: ingo, enigregulo aŭ aplikaĵa politiko. Tiu unu linio distingas retan difekton disde rajtiga decido. Ĝi ankaŭ malhelpas la sekvan personon malfermi pordojn, kiuj neniam estis la problemo.