Peer WireGuarda ni dosegljiv, medtem ko drugi deluje: kontrolni seznam

En peer WireGuarda prepušča promet, drugi pa opravi rokovanje, a nikoli ne doseže ničesar za tunelom. Delujoči peer vam pove, da so vmesnik, vrata UDP in ključ strežnika verjetno v redu. O AllowedIPs drugega peera, njegovem notranjem naslovu vira ali pravilih posredovanja med njima ne pove ničesar. Predite seznam po vrsti in ustavite se pri prvem koraku, katerega pogoj ne velja.

Korak 1: Zapišite pot, po kateri naj bi šel paket

Dva odjemalca na istem vozlišču se ne dosežeta samodejno. V zasnovi z vozliščem in žarki strežnik prejme paket na wg0 in ga mora posredovati nazaj iz wg0 drugemu peeru, kar zahteva posredovanje IP in pravilo posredovanja. V neposredni zasnovi peer proti peeru vsaka stran potrebuje končno točko druge in naslov njenega tunela v AllowedIPs. Odločite se, katero zasnovo odpravljate, preden preberete katero koli konfiguracijo.

Pričakovana pot vam pove tudi, kam gledati. Če mora paket prečkati vozlišče, je neuspešni skok bodisi AllowedIPs pošiljatelja, bodisi posredovanje na vozlišču, bodisi AllowedIPs prejemnika. Če mora iti neposredno, je vozlišče nepomembno in štejejo polja končne točke na obeh peerih.

Korak 2: Primerjajte AllowedIPs na obeh straneh, ne le na eni

WireGuard uporablja AllowedIPs hkrati kot usmerjevalno tabelo in kot seznam dostopa. Pri pošiljanju se ciljni naslov poišče v AllowedIPs peera, da se izbere tunel; pri prejemanju mora notranji naslov vira pasti znotraj AllowedIPs peera, ki pošilja, sicer se paket zavrže. Manjkajoči obseg na kateri koli strani daje enak simptom: promet deluje, tovor izgine.

Berite živo stanje namesto datoteke, ker lahko ponovno nalaganje tiho spodleti: sudo wg show wg0 allowed-ips. Na strežniku mora vnos peera, ki spodleti, vsebovati naslov njegovega tunela, na primer 10.90.0.3/32. Na odjemalcu mora vnos peera strežnika vsebovati cilj, ki ga preizkušate, pa naj bo to naslov tunela vozlišča ali oddaljeno podomrežje. Prekrivajoči se obsegi naredijo iskanje dvoumno in lahko izberejo peera, ki ga niste nameravali, zato jih držite ločene.

Korak 3: Preverite notranji naslov vira

Odjemalec, ki usmerja 10.90.0.3 skozi wg0, a pošilja pakete s svojega naslova Wi-Fi, bo prejemnik zavrnil, ker vir ne ustreza AllowedIPs peera. Potrdite, kaj jedro dejansko izbere, z ip route get 10.90.0.3 from 10.90.0.2, in potrdite naslov, dodeljen vmesniku tunela, z ip -brief addr show wg0.

Na prejemajočem gostitelju Linux je filtriranje povratne poti druga vrata. Strogi rp_filter na vmesniku, ki ima povratno pot, lahko zavrže tunelski promet, katerega povratna pot ne ustreza vmesniku, po katerem je prispel. Preverite dejansko vrednost, preden ga izklopite; v mnogih topologijah je pravilen popravek pot, ne omiljen filter.

Korak 4: Preglejte posredovanje na vozlišču in povratno pot

Če mora vozlišče posredovati med peeri, jedro potrebuje net.ipv4.ip_forward=1, požarni zid pa mora sprejeti posredovani tok: vstop na wg0, izstop na wg0, od naslova tunela pošiljatelja do naslova prejemnika. Pogosta okvara je vhodno pravilo, ki sprejme UDP 51820, a ni pravila posredovanja], zato rokovanje uspe in tovor umre. Naštejte veljavna pravila z sudo nft list ruleset ali ustreznikom za vaš upravitelj požarnega zidu.

Nato preverite odgovor. Ciljni gostitelj mora imeti pot nazaj do pošiljatelja, bodisi prek vozlišča bodisi prek lastnih vrat. Če vozlišče izvaja tudi NAT za podomrežje tunela, potrdite, da prevajanje velja za posredovani tok in da odgovor doseže vozlišče, preden stanje poteče. Enosmerna okvara, ki je videti kot težava s ključem, je pogosto prav ta povratna pot.

Na koncu ločite rokovanje od podatkov. Peer, ki zaključi rokovanje, a se ustavi pri velikih prenosih, ima običajno težavo z MTU ali MSS prav na tej poti, ne težave z AllowedIPs. Najprej preizkusite z majhnim pingom, nato s pingom polne velikosti, in primerjajte oba peera.

Korak 5: Spremenite eno stvar in ohranite delujočega peera nedotaknjenega

Naredite eno samo spremembo na poti, ki spodleti, in znova preizkusite oba peera. Zamenjava AllowedIPs vsakega peera z 0.0.0.0/0 je najhitrejša pot do tega, da pokvarite peera, ki je že deloval, ker spremeni odločitev o usmerjanju za ves promet na tem vmesniku. Uredite ta en vnos, znova naložite in preberite živo stanje.

Zabeležite, katera pot je uspela, katera ni, in natančen izpis ukaza za vsako. Ta primerjava je vredna več kot splošno poročilo, da je VPN pokvarjen, in to je prva stvar, ki jo bo naslednja oseba zahtevala.