WireGuard-manpremo funkcias, sed ne estas interreto: spuru la pakon

La tunelo estas aktiva, wg show raportas freŝan manpremon, vi povas pingi la tunelan adreson de la servilo, kaj nenio malantaŭ ĝi respondas. La instinkto estas regeneri ŝlosilojn aŭ denove dividi la agordon. Tio ŝanĝas ĝuste tiun parton de la vojo, kiu jam pruveble funkcias.

Kompletigita manpremo diras, ke la du partneroj interkonsentas pri ŝlosiloj, ke UDP atingas la finpunkton, kaj ke la kripta enkursigado akceptas la pakon. Ĝi diras nenion pri tio, ĉu la pako poste povas forlasi la servilon.

Do spuru unu pakon anstataŭ diveni. Estas kvar lokoj, kie ĝi povas morti, kaj ĉiu lasas alian spuron.

Kion la manpremo efektive pruvas

WireGuard estas UDP-protokolo, kiu starigas seancon per Noise-manpremo kaj poste ĉifras pakojn por partnero. Kiam wg show montras manpremon de kelkaj sekundoj kaj kreskantan translokigan nombrilon, la finpunkto, la ŝlosiloj kaj la publika ŝlosilo de la partnero ĉiuj estas ĝustaj.

Kion ĝi ne pruvas, estas ke via kliento entute sendas interretan trafikon en la interfacon, ke la servilo pretas plusendi ĝin, aŭ ke respondo povas trovi la vojon reen. Tiuj estas decidoj de kerno-enkursigado kaj fajroŝirmilo, kaj ili fariĝas ekster la tunelo.

Jen kial pingi la tunelan adreson de la servilo estas tiel misgvida testo. Tiu pako estas adresita al la servilo mem, do ĝi finiĝas loke. Ĝi neniam bezonas plusendadon, neniam bezonas tradukon kaj neniam bezonas revenan itineron de la interreto.

AllowedIPs estas enkursiga decido

Ĉe la kliento, AllowedIPs faras du taskojn. Ĝi estas la kriptoŝlosila enkursiga tabelo, kiu decidas, kiuj celadresoj estas sendataj en la tunelon de ĉi tiu partnero, kaj ĝi estas la listo de fontadresoj, kiujn la partnero akceptos de vi. Se la klienta agordo listigas nur 10.8.0.0/24, publikaj celoj neniam eniras la interfacon kaj via normala defaŭlta itinero portas ilin ekster la tunelon. Tiam la tunelo funkcias perfekte kaj faras nenion el tio, kion vi volis.

Rigardu, kion la kliento efektive instalis, anstataŭ kion diras la agorda dosiero:

wg show wg0 allowed-ips
ip route get 1.1.1.1

La dua komando estas la decida. Se la respondo nomas vian fizikan interfacon kaj la normalan pordegon, la pako ne estas tuneligata kaj nenia ŝanĝo ĉe la servila flanko riparos ĝin. Aldonu 0.0.0.0/0 por IPv4 kaj ::/0 por IPv6 aparte; regulo, kiu kaptas ĉion por unu familio, lasas la alian sur sia origina vojo, kaj tio estas ofta kaŭzo de funkcianta IPv4-tunelo kaj blokita IPv6-serĉo.

Kie la pako mortas ĉe la pordego

Se la itinero estas ĝusta kaj la pako tamen iras nenie, ĝi alvenas al la servilo kaj haltas tie. Kvar kontroloj kovras la plej multajn pordegojn.

Plusendado. sysctl net.ipv4.ip_forward redonanta 0 estas la klasika respondo, kaj multaj distribuaĵoj ankoraŭ defaŭltas al 0. Ĝi devas esti 1, kaj fiksita permanenta en sysctl-dosiero anstataŭ per komando, kiu malaperas ĉe restartiĝo. Plusendado de IPv6 estas aparta ŝaltilo.

La filtra politiko. FORWARD-ĉeno kun defaŭlta forĵeta politiko forĵetos tunelan trafikon, dum ĝi permesas trafikon al la gastiganto mem, kio akordas precize kun la simptomo. Legu la vivan regulkompleton, ne konservitan dosieron: nft list ruleset aŭ iptables -S.

Traduko aŭ enkursigado. Klientoj kun privataj tunelaj adresoj bezonas aŭ fontan NAT ĉe la elira interfaco de la servilo, aŭ enkursigitan prefikson, kiun la supra reto scias resendi. La elekto inter ili sekvas la adresplanon. Aldoni MASQUERADE al reto, kiu jam enkursigas vian prefikson reen, estas sendanĝera sed senutila, kaj preterlasi ĝin tie, kie neniu itinero ekzistas, lasas respondojn adresitaj al neenirebla privata gamo.

La revena vojo. En enkursigitaj dizajnoj, la supra enkursigilo bezonas itineron montrantan al via servilo. La reto de la provizanto ankaŭ povas blokadi ĝin: pluraj nuboj ŝaltas fontan kaj celan kontrolon ĉe la instanco, kiu silente forĵetas pakojn, kies fonto ne estas la propra adreso de la instanco, ĝis tiu kontrolo estas malŝaltita.

DNS malsukcesas alimaniere ol enkursigado

Pako al konata adreso kaj nomserĉo estas du apartaj malsukcesoj, kaj la erarmesaĝoj misgvidas en kontraŭajn direktojn. Se ping 1.1.1.1 funkcias kaj retumilo povas ŝargi nenion, la itinero estas bona kaj la nomrezolucio ne. Se la ping mem malsukcesas, DNS estas nerelevanta kaj vi revenis al la antaŭa sekcio.

wg-quick povas agordi solvilon el la linio DNS = en la agordo, kaj systemd-resolved havas sian propran konduton por ĉiu ligilo. VPN, kiu anstataŭigas la solvilon per adreso atingebla nur ene de la tunelo, malsukcesigos ĉiun serĉon en la momento, kiam la tunelo falas, kio aspektas kvazaŭ la tunelo rompas la interreton.

Ordo, kiu produktas pruvojn

Unue faru la kontrolon ĉe la klienta flanko, ĉar ĝi estas unu komando kaj forigas duonon de la ebloj. Poste konfirmu, ĉu la servilo entute estas destinita kiel interreta elirejo; pordego konstruita por privata aliro ne estas difektita, kiam publikaj celoj malsukcesas.

Ĉe la servilo, observu la interfacon dum vi sendas pingon de la kliento: tcpdump -ni wg0 icmp devus montri la peton, kaj tcpdump -ni eth0 icmp devus montri ĝin eliranta, tradukita aŭ ne. Se ĝi aperas ĉe la unua kaj neniam ĉe la dua, la halto estas loka ĉe la servilo. Se ĝi eliras kaj neniu respondo revenas, la problemo estas pli supre, kaj tio estas alia konversacio.

Fine faru, ke la ripeto postvivu restartigon. Plusendado apartenas al sysctl-dosiero, fajroŝirmilaj reguloj apartenas al la servo, kiu ŝargas ilin, kaj klientaj itineroj apartenas al la agordo, kiu suprenigas la interfacon, anstataŭ al ŝelo, kiun vi forgesos. Rekonektiĝu, ripetu la samajn du testojn kaj konfirmu, ke la nombriloj moviĝas.