WireGuard rokasspiediens darbojas, bet interneta nav: izseko pakešu ceļu
Rokasspiediens pierāda tikai atslēgas un sasniedzamību. Izseko vienu paketi no AllowedIPs caur pāradresāciju, NAT un atgaitas maršrutu, lai redzētu, kur tā apstājas.
Tunelis ir aktīvs, wg show ziņo par nesen notikušu rokasspiedienu, vari pingot servera tuneļa adresi, un nekas aiz tās neatbild. Pirmā doma ir ģenerēt atslēgas no jauna vai atkārtoti kopīgot konfigurāciju. Tas maina tieši to ceļa daļu, kuras darbība jau ir pierādīta.
Pabeigts rokasspiediens nozīmē, ka abas puses vienojas par atslēgām, ka UDP sasniedz galapunktu un ka kripto maršrutēšana pieņem paketi. Tas neko nesaka par to, vai pakete pēc tam var atstāt serveri.
Tāpēc izseko vienu paketi, nevis minē. Ir četras vietas, kur tā var iet bojā, un katra atstāj citu pēdu.
Ko rokasspiediens patiešām pierāda
WireGuard ir UDP protokols, kas izveido sesiju ar Noise rokasspiedienu un pēc tam šifrē paketes partnerim. Kad wg show rāda dažas sekundes vecu rokasspiedienu un augošu pārsūtīšanas skaitītāju, galapunkts, atslēgas un partnera publiskā atslēga visas ir pareizas.
Ko tas nepierāda: ka tavs klients vispār sūta uz internetu vērstu trafiku saskarnē, ka serveris ir gatavs to pāradresēt vai ka atbilde var atrast ceļu atpakaļ. Tie ir kodola maršrutēšanas un ugunsmūra lēmumi, un tie tiek pieņemti ārpus tuneļa.
Tāpēc ping uz servera tuneļa adresi ir tik mānīgs tests. Tā pakete ir adresēta pašam serverim, tāpēc tā beidzas lokāli. Tai nekad nav vajadzīga pāradresācija, nekad tulkošana un nekad atgaitas maršruts no interneta.
AllowedIPs ir maršrutēšanas lēmums
Klientā AllowedIPs veic divus darbus. Tā ir kriptoatslēgas maršrutēšanas tabula, kas izlemj, kuras galamērķa adreses tiek sūtītas šī partnera tunelī, un tā ir avota adrešu saraksts, ko partneris pieņems no tevis. Ja klienta konfigurācijā norādīta tikai 10.8.0.0/24, publiski galamērķi nekad neiekļūst saskarnē, un tavs parastais noklusējuma maršruts tos aizved ārpus tuneļa. Tad tunelis darbojas nevainojami un nedara neko no tā, ko tu gribēji.
Paskaties, ko klients patiešām instalēja, nevis ko saka konfigurācijas fails:
wg show wg0 allowed-ipsip route get 1.1.1.1
Otrā komanda ir izšķirošā. Ja atbildē nosaukta tava fiziskā saskarne un parastā vārteja, pakete netiek tunelēta un nekādas izmaiņas servera pusē to nelabos. Pievieno 0.0.0.0/0 IPv4 un ::/0 IPv6 atsevišķi; noteikums, kas vienai saimei aptver visu, otru atstāj uz tā sākotnējā ceļa, un tas ir biežs iemesls strādājošam IPv4 tunelim un iestrēgušai IPv6 meklēšanai.
Kur pakete iet bojā uz vārtejas
Ja maršruts ir pareizs un pakete joprojām nekur nenonāk, tā nonāk serverī un tur apstājas. Četras pārbaudes aptver lielāko daļu vārteju.
Pāradresācija. sysctl net.ipv4.ip_forward, kas atgriež 0, ir klasiskā atbilde, un daudzas distribūcijas joprojām pēc noklusējuma ir 0. Tai jābūt 1, un tā jāiestata pastāvīgi sysctl failā, nevis ar komandu, kas pazūd pēc pārstartēšanas. IPv6 pāradresācija ir atsevišķs slēdzis.
Filtrēšanas politika. Ķēde FORWARD ar noklusējuma nomešanas politiku izmetīs tuneļa trafiku, bet laidīs trafiku uz pašu resursdatoru, un tas precīzi atbilst simptomam. Lasi dzīvo noteikumu kopumu, nevis saglabātu failu: nft list ruleset vai iptables -S.
Tulkošana vai maršrutēšana. Klientiem ar privātām tuneļa adresēm vajag vai nu avota NAT servera izejas saskarnē, vai maršrutētu prefiksu, ko augšējais tīkls prot atgriezt. Izvēle starp tiem seko adrešu plānam. MASQUERADE pievienošana tīklam, kas jau maršrutē tavu prefiksu atpakaļ, ir nekaitīga, bet bezjēdzīga, un tā izlaišana tur, kur maršruta nav, atstāj atbildes adresētas uz nemaršrutējamu privātu diapazonu.
Atgaitas ceļš. Maršrutētos risinājumos augšējam maršrutētājam vajag maršrutu, kas norāda uz tavu serveri. Pakalpojumu sniedzēja tīkls to arī var bloķēt: vairāki mākoņi ieslēdz avota un galamērķa pārbaudi instancē, kas klusi izmet paketes, kuru avots nav pašas instances adrese, līdz šī pārbaude tiek izslēgta.
DNS neizdodas citādi nekā maršrutēšana
Pakete uz zināmu adresi un vārda meklēšana ir divas atsevišķas kļūdas, un kļūdu ziņojumi maldina pretējos virzienos. Ja ping 1.1.1.1 darbojas un pārlūks neko neielādē, maršruts ir kārtībā, bet vārdu atrisināšana nav. Ja pats pings neizdodas, DNS nav svarīgs un tu esi atgriezies iepriekšējā sadaļā.
wg-quick var iestatīt risinātāju no konfigurācijas rindas DNS =, un systemd-resolved ir sava uzvedība katram savienojumam. VPN, kas pārraksta risinātāju ar adresi, kas sasniedzama tikai tuneļa iekšienē, izgāzīs katru meklēšanu tajā brīdī, kad tunelis krīt, un tas izskatās, it kā tunelis lauztu internetu.
| 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 |
Secība, kas dod pierādījumus
Vispirms veic klienta puses pārbaudi, jo tā ir viena komanda un novērš pusi iespēju. Pēc tam apstiprini, vai serveris vispār ir paredzēts kā interneta izeja; vārteja, kas būvēta privātai piekļuvei, nav salūzusi, ja publiski galamērķi nedarbojas.
Serverī vēro saskarni, kamēr sūti ping no klienta: tcpdump -ni wg0 icmp būtu jārāda pieprasījums, un tcpdump -ni eth0 icmp būtu jārāda, ka tas iziet, tulkots vai nē. Ja tas parādās pirmajā un nekad otrajā, apstāšanās ir lokāla serverim. Ja tas iziet un atbilde neatgriežas, problēma ir augstāk, un tā ir cita saruna.
Visbeidzot panāc, lai labojums pārdzīvo pārstartēšanu. Pāradresācija pieder sysctl failam, ugunsmūra noteikumi — servisam, kas tos ielādē, un klienta maršruti — konfigurācijai, kas paceļ saskarni, nevis čaulai, ko aizmirsīsi. Pieslēdzies no jauna, atkārto tos pašus divus testus un apstiprini, ka skaitītāji kustas.