WireGuard-samtavolano neatingebla dum alia funkcias: kontrol-listo

Unu WireGuard-samtavolano trapasigas trafikon kaj dua faras la manpremon sed neniam atingas ion ajn malantaŭ la tunelo. La funkcianta samtavolano diras al vi, ke la interfaco, la UDP-pordo kaj la ŝlosilo de la servilo probable estas en ordo. Ĝi diras nenion pri la AllowedIPs de la dua samtavolano, ĝia interna fonta adreso aŭ la plusendaj reguloj inter ili. Trairu la liston laŭorde kaj haltu ĉe la unua paŝo, kies kondiĉo malsukcesas.

Paŝo 1: Notu la vojon, kiun la paketo devus sekvi

Du klientoj sur la sama koncentrigilo ne atingas unu la alian aŭtomate. En koncentrigila kaj radiradia dezajno la servilo ricevas la paketon sur wg0 kaj devas plusendi ĝin reen el wg0 al la alia samtavolano, kio postulas IP-plusendadon kaj plusendan regulon. En rekta samtavola dezajno ĉiu flanko bezonas la finpunkton de la alia kaj la tunelan adreson de la alia ene de AllowedIPs. Decidu, kiun dezajnon vi sencimigas, antaŭ ol legi ajnan agordon.

La atendata vojo ankaŭ diras al vi, kie rigardi. Se la paketo devas transiri la koncentrigilon, la malsukcesa salto estas aŭ la AllowedIPs de la sendinto, aŭ la plusendado de la koncentrigilo, aŭ la AllowedIPs de la ricevanto. Se ĝi devas iri rekte, la koncentrigilo estas nerelevanta kaj la finpunktaj kampoj sur ambaŭ samtavolanoj gravas.

Paŝo 2: Komparu la AllowedIPs sur ambaŭ flankoj, ne nur unu

WireGuard uzas AllowedIPs samtempe kiel enkursigan tabelon kaj kiel alirliston. Ĉe sendo la celloka adreso estas serĉata en la AllowedIPs de la samtavolano por elekti la tunelon; ĉe ricevo la interna fonta adreso devas fali ene de la AllowedIPs de la sendanta samtavolano, alie la paketo estas forĵetata. Mankanta gamo sur iu ajn flanko produktas la saman simptomon: la transporto funkcias, la utila ŝarĝo malaperas.

Legu la vivan staton anstataŭ la dosieron, ĉar reŝargo povus malsukcesi silente: sudo wg show wg0 allowed-ips. Sur la servilo la enskribo de la malsukcesa samtavolano devas inkluzivi ĝian tunelan adreson, ekzemple 10.90.0.3/32. Sur la kliento la enskribo de la servila samtavolano devas inkluzivi la celon, kiun vi testas, ĉu ĝi estas la tunela adreso de la koncentrigilo aŭ la fora subreto. Interkovrantaj gamoj igas la serĉon ambigua kaj povas elekti samtavolanon, kiun vi ne intencis, do tenu ilin aparte.

Paŝo 3: Kontrolu la internan fontan adreson

Kliento, kiu enkursigas 10.90.0.3 tra wg0 sed sendas paketojn el sia Wi-Fi-adreso, estos malakceptita de la ricevanto, ĉar la fonto ne kongruas kun la AllowedIPs de la samtavolano. Konfirmu, kion la kerno efektive elektas per ip route get 10.90.0.3 from 10.90.0.2, kaj konfirmu la adreson atribuitan al la tunela interfaco per ip -brief addr show wg0.

Sur la ricevanta Linux-gastigo, inversvoja filtrado estas dua pordego. Severa rp_filter sur la interfaco, kiu posedas la revenan vojon, povas forĵeti tunelan trafikon, kies reva vojo ne kongruas kun la interfaco, per kiu ĝi alvenis. Kontrolu la efektivan valoron antaŭ ol malŝalti ĝin; en multaj topologioj la ĝusta riparo estas enkursigo, ne malstreĉita filtro.

Paŝo 4: Revizuu la plusendadon de la koncentrigilo kaj la revenan vojon

Se la koncentrigilo devas plusendi inter samtavolanoj, la kerno bezonas net.ipv4.ip_forward=1, kaj la fajroŝirmilo devas akcepti la plusenditan fluon: enen sur wg0, elen sur wg0, de la tunela adreso de la sendinto al tiu de la ricevanto. Ofta difekto estas enira regulo, kiu akceptas UDP 51820 sed mankas plusenda regulo], do la manpremo sukcesas kaj la utila ŝarĝo mortas. Listigu la validajn regulojn per sudo nft list ruleset aŭ la ekvivalento por via fajroŝirmila administrilo.

Poste kontrolu la respondon. La cela gastigo devas havi reen vojon al la sendinto, ĉu tra la koncentrigilo ĉu tra sia propra pordego. Se la koncentrigilo ankaŭ NATas la tunelan subreton, konfirmu, ke la traduko aplikas al la plusendita fluo kaj ke la respondo atingas la koncentrigilon antaŭ ol la stato eksvalidiĝas. Unudirekta difekto, kiu aspektas kiel ŝlosila problemo, ofte estas ĝuste tiu reena enkursigo.

Fine, apartigu la manpremon de la datumoj. Samtavolano, kiu finas la manpremon sed blokiĝas ĉe grandaj transigoj, kutime havas MTU- aŭ MSS-problemon sur ĝuste tiu vojo, ne AllowedIPs-problemon. Testu unue per malgranda ping, poste per plengranda, kaj komparu la du samtavolanojn.

Paŝo 5: Ŝanĝu unu aferon kaj tenu la funkciantan samtavolanon sendifekta

Faru unu solan ŝanĝon sur la malsukcesa vojo kaj retestu ambaŭ samtavolanojn. Anstataŭigi la AllowedIPs de ĉiu samtavolano per 0.0.0.0/0 estas la plej rapida maniero rompi la samtavolanon, kiu jam funkciis, ĉar ĝi ŝanĝas la enkursigan decidon por la tuta trafiko sur tiu interfaco. Redaktu la unu enskribon, reŝargu kaj relegu la vivan staton.

Notu, kiu vojo sukcesis, kiu malsukcesis kaj la precizan komandan eligon por ĉiu. Tiu komparo valoras pli ol ĝenerala raporto, ke la VPN estas rompita, kaj ĝi estas la unua afero, kiun la sekva persono demandos.