WireGuardi handshake töötab, aga internetti pole: jälgi paketti
Handshake tõestab ainult võtmeid ja kättesaadavust. Jälgi üht paketti AllowedIPsist läbi edasisaatmise, NAT-i ja tagasitee, et näha, kus see peatub.
Tunnel on püsti, wg show näitab värsket handshake’i, saad serveri tunneli aadressile pingida ja mitte miski sellest kaugemal ei vasta. Esimene mõte on võtmed uuesti genereerida või konfiguratsiooni uuesti jagada. See muudab täpselt seda teeosa, mis on juba tõestatult korras.
Lõpetatud handshake ütleb, et kaks poolt on võtmetes ühel meelel, et UDP jõuab lõpp-punkti ja et krüptomarsruutimine võtab paketi vastu. See ei ütle midagi selle kohta, kas pakett saab seejärel serverist lahkuda.
Jälgi seega üht paketti, mitte ära oleta. On neli kohta, kus see võib surra, ja igaüks jätab erineva jälje.
Mida handshake tegelikult tõestab
WireGuard on UDP-protokoll, mis loob Noise handshake’iga sessiooni ja krüpteerib seejärel paketid partnerile. Kui wg show näitab mõne sekundi vanust handshake’i ja kasvavat ülekandeloendurit, on lõpp-punkt, võtmed ja partneri avalik võti kõik õiged.
Mida see ei tõesta: et sinu klient üldse saadab internetti suunatud liikluse liidesesse, et server on nõus seda edasi saatma või et vastus leiab tee tagasi. Need on kerneli marsruutimise ja tulemüüri otsused ning need tehakse väljaspool tunnelit.
Just seetõttu on serveri tunneli aadressile pingimine nii eksitav test. See pakett on adresseeritud serverile endale, seega lõpeb see lokaalselt. See ei vaja kunagi edasisaatmist, kunagi tõlkimist ega kunagi tagasimarsruuti internetist.
AllowedIPs on marsruutimisotsus
Kliendis teeb AllowedIPs kahte tööd. See on krüptovõtme-marsruuditabel, mis otsustab, millised sihtaadressid saadetakse selle partneri tunnelisse, ja see on lähteaadresside loend, mille partner sinult vastu võtab. Kui kliendi konfiguratsioonis on ainult 10.8.0.0/24, ei jõua avalikud sihtmärgid kunagi liidesesse ja sinu tavaline vaikemarsruut viib need tunnelist mööda. Siis tunnel töötab laitmatult ega tee midagi sellest, mida soovisid.
Vaata, mida klient tegelikult paigaldas, mitte mida konfiguratsioonifail ütleb:
wg show wg0 allowed-ipsip route get 1.1.1.1
Teine käsk on otsustav. Kui vastus nimetab sinu füüsilist liidest ja tavalist lüüsi, ei lähe pakett tunnelisse ja ükski serveripoolne muudatus ei paranda seda. Lisa 0.0.0.0/0 IPv4 jaoks ja ::/0 IPv6 jaoks eraldi; reegel, mis haarab ühe perekonna jaoks kõik, jätab teise oma algsele teele, ja see on sage põhjus, miks IPv4 tunnel töötab ja IPv6 päring on kinni jäänud.
Kus pakett lüüsil sureb
Kui marsruut on õige ja pakett ei lähe ikka kuhugi, jõuab see serverisse ja peatub seal. Neli kontrolli katavad enamiku lüüsidest.
Edasisaatmine. sysctl net.ipv4.ip_forward vastusega 0 on klassikaline juhtum ja paljud distributsioonid on vaikimisi endiselt 0. See peab olema 1 ja see tuleb püsivalt seada sysctl-failis, mitte käsuga, mis taaskäivitusel kaob. IPv6 edasisaatmine on eraldi lüliti.
Filtreerimispoliitika. FORWARD ahel vaikimisi drop-poliitikaga viskab tunneliliikluse kõrvale, samal ajal kui lubab liiklust hosti enda poole, mis sobib sümptomiga täpselt. Loe elavat reeglistikku, mitte salvestatud faili: nft list ruleset või iptables -S.
Tõlkimine või marsruutimine. Privaatsete tunneliaadressidega kliendid vajavad kas lähtenat-i serveri väljumisliidesel või marsruuditud prefiksit, mida ülemvõrk oskab tagasi saata. Nende vahel valimine järgib aadressiplaani. MASQUERADE lisamine võrku, mis juba marsruudib sinu prefiksi tagasi, on kahjutu, kuid mõttetu, ja selle ärajätmine kohas, kus marsruuti pole, jätab vastused adresseerituks mittemarsruuditavasse privaatsesse vahemikku.
Tagasitee. Marsruuditud lahendustes vajab ülemrouter marsruuti, mis osutab sinu serverile. Teenusepakkuja võrk võib selle ka blokeerida: mitmed pilved lubavad instantsil allika ja sihtkoha kontrolli, mis viskab vaikselt kõrvale paketid, mille allikas pole instantsi enda aadress, kuni see kontroll välja lülitatakse.
DNS ebaõnnestub teisiti kui marsruutimine
Pakett teadaolevale aadressile ja nimepäring on kaks eraldi tõrget ning veateated eksitavad vastassuundades. Kui ping 1.1.1.1 töötab ja brauser ei suuda midagi laadida, on marsruut korras ja nimeersaldus mitte. Kui ping ise ebaõnnestub, on DNS asjakohatu ja oled tagasi eelmises jaotises.
wg-quick saab seada resolveri konfiguratsiooni realt DNS = ja systemd-resolvedil on oma käitumine iga lingi kohta. VPN, mis kirjutab resolveri üle aadressiga, mis on kättesaadav ainult tunneli sees, nurjab iga päringu hetkel, mil tunnel langeb, mis näeb välja nagu tunnel rikuks interneti.
| 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 |
Järjekord, mis annab tõendeid
Tee kõigepealt kliendipoolne kontroll, sest see on üks käsk ja välistab poole võimalustest. Seejärel kinnita, kas server on üldse mõeldud interneti väljapääsuks; privaatseks juurdepääsuks ehitatud lüüs ei ole katki, kui avalikud sihtmärgid ei toimi.
Serveris jälgi liidest, kui saadad kliendist pingi: tcpdump -ni wg0 icmp peaks päringu näitama ja tcpdump -ni eth0 icmp peaks näitama, et see väljub, tõlgituna või mitte. Kui see ilmub esimesel ja mitte kunagi teisel, on peatumine serveri jaoks lokaalne. Kui see väljub ja vastust ei tule, on probleem ülalpool ja see on juba teine vestlus.
Lõpuks tee nii, et parandus jääks püsima ka taaskäivitusel. Edasisaatmine kuulub sysctl-faili, tulemüürireeglid teenusesse, mis need laeb, ja kliendi marsruudid konfiguratsiooni, mis liidese üles toob, mitte shelli, mille unustad. Ühenda uuesti, korda samu kahte testi ja kinnita, et loendurid liiguvad.