Gumagana ang handshake ng WireGuard pero walang internet: subaybayan ang packet
Ang handshake ay nagpapatunay lamang ng mga key at maabot. Subaybayan ang isang packet mula sa AllowedIPs sa pagpapasa, NAT at return route para makita kung saan ito humihinto.
Buhay ang tunel, nag-uulat ang wg show ng kamakailang handshake, maaari mong i-ping ang tunnel address ng server, at wala nang iba pang sumasagot. Ang unang instinct ay muling likhain ang mga key o muling ibahagi ang config. Binabago niyon ang eksaktong parte ng landas na napatunayang gumagana na.
Ang kumpletong handshake ay nagsasabing nagkasundo ang dalawang panig sa mga key, umaabot ang UDP sa endpoint, at tinatanggap ng crypto routing ang packet. Wala itong sinasabi tungkol sa kung makakaalis ang packet sa server pagkatapos.
Kaya subaybayan ang isang packet sa halip na manghula. May apat na lugar kung saan maaari itong mamatay, at bawat isa ay nag-iiwan ng ibang bakas.
Ano ba talaga ang pinapatunayan ng handshake
Ang WireGuard ay isang UDP protocol na nagtatayo ng session gamit ang Noise handshake at pagkatapos ay niencrypt ang mga packet para sa isang peer. Kapag ang wg show ay nagpapakita ng handshake na ilang segundo pa lang at tumataas na transfer counter, tama ang endpoint, ang mga key at ang pampublikong key ng peer.
Ang hindi nito pinapatunayan ay kung ipinapadala ng kliyente mo ang trapikong papunta sa internet sa interface, kung handa ang server na ipasa ito, o kung may makikitang daan pabalik ang isang sagot. Mga desisyon iyon ng kernel routing at firewall, at ginagawa sa labas ng tunel.
Ito ang dahilan kung bakit ang ping sa tunnel address ng server ay ganoon kamapanlinlang na test. Ang packet na iyon ay naka-address sa server mismo, kaya nagtatapos ito nang lokal. Hindi ito kailanman nangangailangan ng pagpapasa, kailanman ng pagsasalin at kailanman ng return route mula sa internet.
Ang AllowedIPs ay desisyon sa ruta
Sa kliyente, gumagawa ang AllowedIPs ng dalawang trabaho. Ito ang talahanayan ng crypto key routing na nagpapasya kung aling mga address ng destinasyon ang pumapasok sa tunel ng peer na ito, at ito ang listahan ng mga source address na tatanggapin ng peer mula sa iyo. Kung ang config ng kliyente ay naglilista lamang ng 10.8.0.0/24, kailanman hindi pumapasok ang mga pampublikong destinasyon sa interface at dinadala sila ng normal mong default route sa labas ng tunel. Pagkatapos ay perpektong gumagana ang tunel at wala itong ginagawa sa mga gusto mo.
Tingnan ang aktwal na inilagay ng kliyente, hindi ang sinasabi ng config file:
wg show wg0 allowed-ipsip route get 1.1.1.1
Ang pangalawang command ang mapagpasyahan. Kung pinangalanan ng sagot ang pisikal mong interface at ang karaniwang gateway, hindi tinutunnel ang packet at walang pagbabago sa panig ng server ang makakaayos niyon. Idagdag ang 0.0.0.0/0 para sa IPv4 at ::/0 para sa IPv6 nang hiwalay; ang patakarang humuhuli sa lahat para sa isang pamilya ay iniiwan ang isa sa orihinal na landas, at ito ang karaniwang dahilan ng gumaganang tunel na IPv4 at natigil na paghahanap ng IPv6.
Saan namamatay ang packet sa gateway
Kung tama ang ruta at hindi pa rin nakakarating ang packet, umaabot ito sa server at humihinto doon. Apat na pagsusuri ang sumasaklaw sa karamihan ng gateway.
Pagpapasa. Ang sysctl net.ipv4.ip_forward na nagbabalik ng 0 ang klasikong sagot, at maraming distribusyon ay naka-default pa rin sa 0. Kailangan itong maging 1, at itakda nang permanente sa isang sysctl file sa halip na sa command na nawawala kapag nag-reboot. Ang pagpapasa ng IPv6 ay hiwalay na switch.
Ang patakaran ng filter. Ang chain na FORWARD na may default na drop policy ay itatapon ang trapiko ng tunel habang pinapayagan ang trapiko patungo sa host mismo, na eksaktong tumutugma sa sintomas. Basahin ang buhay na set ng patakaran, hindi ang naka-save na file: nft list ruleset o iptables -S.
Pagsasalin o ruta. Ang mga kliyenteng gumagamit ng pribadong tunnel address ay nangangailangan ng source NAT sa exit interface ng server, o ng rutang prefix na alam ng nasa itaas na network na ibalik. Ang pagpili sa dalawa ay sumusunod sa plano ng address. Ang pagdaragdag ng MASQUERADE sa network na nagruruta na pabalik ng prefix mo ay hindi mapanganib ngunit walang saysay, at ang pag-iwan dito sa lugar na walang ruta ay nag-iiwan ng mga sagot na naka-address sa pribadong saklaw na hindi maruruta.
Ang return path. Sa mga rutang disenyo, kailangan ng nasa itaas na router ng rutang tumuturo sa server mo. Maaari rin itong harangin ng network ng provider: maraming cloud ang nagpapagana ng source at destination check sa instance, na tahimik na itinatapon ang mga packet na ang source ay hindi ang sariling address ng instance hanggang sa i-off ang check na iyon.
Iba ang pagpalya ng DNS kaysa ruta
Ang packet patungo sa kilalang address at ang paghahanap ng pangalan ay dalawang hiwalay na pagpalya, at ang mga mensahe ng error ay nanliligaw sa magkasalungat na direksyon. Kung gumagana ang ping 1.1.1.1 at walang ma-load ang browser, maayos ang ruta at hindi ang resolusyon ng pangalan. Kung ang ping mismo ang pumalya, walang kinalaman ang DNS at bumalik ka sa nakaraang seksyon.
Maaaring magtakda ang wg-quick ng resolver mula sa linyang DNS = sa config, at may sariling pag-uugali ang systemd-resolved sa bawat link. Ang VPN na nagpapalit sa resolver ng address na maabot lamang sa loob ng tunel ay magpapabagsak sa bawat paghahanap sa sandaling bumagsak ang tunel, na mukhang sinusira ng tunel ang internet.
| Symptom | Layer to inspect |
|---|---|
| Tunnel address pings, nothing else does | Client route, then gateway forwarding |
| Public IP pings, hostnames fail | Resolver selection and reachability |
| Handshake completes, no reply ever | FORWARD policy or missing NAT on the server |
| Small requests work, large transfers stall | MTU and TCP MSS clamping |
Isang pagkakasunod-sunod na gumagawa ng ebidensya
Patakbuhin muna ang pagsusuri sa panig ng kliyente, dahil isang command lamang ito at inaalis ang kalahati ng mga posibilidad. Pagkatapos ay tiyakin kung ang server ay talagang itinakda bilang labasan sa internet; ang gateway na ginawa para sa pribadong pag-access ay hindi sira kapag pumalya ang mga pampublikong destinasyon.
Sa server, panoorin ang interface habang nagpapadala ka ng ping mula sa kliyente: dapat ipakita ng tcpdump -ni wg0 icmp ang kahilingan, at dapat ipakita ng tcpdump -ni eth0 icmp na lumalabas ito, isinalin man o hindi. Kung lumilitaw ito sa una at kailanman ay hindi sa pangalawa, lokal sa server ang paghinto. Kung lumalabas ito at walang sagot na bumabalik, ang problema ay nasa itaas, at iyon ay ibang usapan.
Sa huli, gawing nakakaligtas sa reboot ang pagwawasto. Ang pagpapasa ay kabilang sa sysctl file, ang mga patakaran ng firewall ay kabilang sa serbisyong naglo-load sa kanila, at ang mga ruta ng kliyente ay kabilang sa config na nag-aangat ng interface, hindi sa shell na makakalimutan mo. Kumonekta muli, ulitin ang parehong dalawang pagsubok at tiyakin na gumagalaw ang mga counter.