Hindi maabot ang isang peer ng WireGuard habang gumagana ang isa: checklist

Isang peer ng WireGuard ang nagpapadala ng trapiko at ang pangalawa ay nakakumpleto ng handshake ngunit hindi kailanman nakakarating sa anuman sa likod ng tunnel. Ang gumaganang peer ay nagsasabi sa iyo na ang interface, UDP port at key ng server ay malamang maayos. Wala itong sinasabi tungkol sa AllowedIPs ng pangalawang peer, sa panloob na source address nito o sa mga panuntunan sa pagpapasa sa pagitan nila. Sundan ang listahan sa pagkakasunod-sunod at huminto sa unang hakbang na nabigo ang kundisyon.

Hakbang 1: Isulat ang landas na dapat tahakin ng packet

Dalawang kliyente sa iisang hub ay hindi awtomatikong nakakarating sa isa't isa. Sa disenyong hub at spokes, natatanggap ng server ang packet sa wg0 at kailangan itong ipasa ulit palabas ng wg0 patungo sa kabilang peer, na nangangailangan ng pagpapasa ng IP at panuntunan sa pagpapasa. Sa direktang disenyong peer-to-peer, kailangan ng bawat panig ang endpoint ng kabila at ang address ng tunnel nito sa loob ng AllowedIPs. Magpasya kung aling disenyo ang ini-debug mo bago magbasa ng anumang configuration.

Sinasabi rin ng inaasahang landas kung saan titingin. Kung kailangang tumawid ng packet sa hub, ang nabigong hop ay alinman sa AllowedIPs ng nagpadala, ang pagpapasa ng hub o ang AllowedIPs ng tatanggap. Kung kailangan itong dumiretso, walang kinalaman ang hub at ang mga field ng endpoint sa dalawang peer ang mahalaga.

Hakbang 2: Ihambing ang AllowedIPs sa dalawang panig, hindi lang sa isa

Ginagamit ng WireGuard ang AllowedIPs bilang talahanayan ng routing at bilang listahan ng access nang sabay. Kapag nagpapadala, hinahanap ang destination address sa AllowedIPs ng peer upang piliin ang tunnel; kapag tumatanggap, kailangang mahulog ang panloob na source address sa loob ng AllowedIPs ng nagpapadalang peer o itinatapon ang packet. Ang kulang na saklaw sa alinmang panig ay nagdudulot ng parehong sintomas: gumagana ang transport, nawawala ang payload.

Basahin ang live na estado sa halip na ang file, dahil maaaring tahimik na nabigo ang muling pag-load: sudo wg show wg0 allowed-ips. Sa server, dapat isama ng entry ng nabigong peer ang address ng tunnel nito, halimbawa 10.90.0.3/32. Sa kliyente, dapat isama ng entry ng server peer ang destinasyong sinusubukan mo, maging ang address ng tunnel ng hub o ang malayong subnet. Ang magkakapatong na saklaw ay nagpapaging malabo ang paghahanap at maaaring pumili ng peer na hindi mo sinadya, kaya panatilihing hiwalay ang mga ito.

Hakbang 3: Suriin ang panloob na source address

Ang kliyenteng nagru-route ng 10.90.0.3 sa wg0 ngunit nagpapadala ng packet mula sa kanyang Wi-Fi address ay tatanggihan ng tatanggap, dahil hindi tumutugma ang source sa AllowedIPs ng peer. Tiyakin kung ano talaga ang pinipili ng kernel gamit ang ip route get 10.90.0.3 from 10.90.0.2, at tiyakin ang address na itinalaga sa tunnel interface gamit ang ip -brief addr show wg0.

Sa tumatanggap na Linux host, ang reverse-path filtering ay ikalawang pintuan. Ang mahigpit na rp_filter sa interface na nagmamay-ari ng pabalik na ruta ay maaaring magtapon ng trapiko ng tunnel na ang pabalik na landas ay hindi tumutugma sa interface kung saan ito dumating. Suriin ang epektibong halaga bago ito patayin; sa maraming topology, ang tamang pagwawasto ay isang ruta, hindi isang luwag na filter.

Hakbang 4: Repasuhin ang pagpapasa ng hub at ang pabalik na landas

Kung kailangang magpasa ang hub sa pagitan ng mga peer, kailangan ng kernel ang net.ipv4.ip_forward=1, at kailangang tanggapin ng firewall ang naipasang daloy: papasok sa wg0, palabas sa wg0, mula sa address ng tunnel ng nagpadala hanggang sa ng tatanggap. Ang karaniwang pagkabigo ay isang panuntunan sa input na tumatanggap ng UDP 51820 ngunit walang panuntunan sa pagpapasa], kaya nagtatagumpay ang handshake at namamatay ang payload. Ilista ang epektibong panuntunan gamit ang sudo nft list ruleset o ang katumbas para sa iyong tagapamahala ng firewall.

Pagkatapos ay suriin ang sagot. Kailangang may ruta pabalik sa nagpadala ang destination host, sa pamamagitan ng hub o ng sariling gateway nito. Kung nagna-NAT din ang hub sa subnet ng tunnel, tiyakin na nalalapat ang pagsasalin sa naipasang daloy at na umaabot ang sagot sa hub bago mag-expire ang estado. Ang isang-direksyong pagkabigo na mukhang problema sa key ay kadalasan itong pabalik na ruta lamang.

Sa huli, paghiwalayin ang handshake sa data. Ang peer na nakakumpleto ng handshake ngunit natigil sa malalaking paglilipat ay karaniwang may problema sa MTU o MSS sa partikular na landas na iyon, hindi problema sa AllowedIPs. Subukan muna gamit ang maliit na ping, pagkatapos ay may ping na buong laki, at ihambing ang dalawang peer.

Hakbang 5: Baguhin ang isang bagay at panatilihing buo ang gumaganang peer

Gumawa ng isang pagbabago lamang sa nabigong landas at subukan muli ang dalawang peer. Ang pagpapalit ng AllowedIPs ng bawat peer ng 0.0.0.0/0 ay ang pinakamabilis na paraan upang sirain ang peer na gumagana na, dahil binabago nito ang desisyon sa routing para sa lahat ng trapiko sa interface na iyon. I-edit ang nag-iisang entry na iyon, i-load muli at basahin muli ang live na estado.

Itala kung aling landas ang nagtagumpay, alin ang nabigo, at ang eksaktong output ng command para sa bawat isa. Mas mahalaga ang paghahambing na iyon kaysa sa pangkalahatang ulat na sira ang VPN, at ito ang unang hihingin ng susunod na tao.