Handshake WireGuard virkar en ekkert internet: fylgdu pakkanum
Handshake sannar aðeins lykla og náanleika. Fylgdu einum pakka frá AllowedIPs í gegnum áframsendingu, NAT og afturleið til að sjá hvar hann stöðvast.
Göngin eru uppi, wg show tilkynnir nýlegt handshake, þú getur pingað göngufang netþjónsins, og ekkert handan þess svarar. Fyrsta hvatningin er að endurgera lykla eða deila stillingunni aftur. Það breytir einmitt þeim hluta leiðarinnar sem þegar er sannað að virki.
Lokið handshake segir að aðilarnir tveir séu sammála um lyklana, að UDP nái endapunktinum og að dulritunarleiðsögnin samþykki pakkann. Það segir ekkert um hvort pakkinn geti yfirgefið netþjóninn eftir á.
Fylgdu því einum pakka í stað þess að giska. Það eru fjórir staðir þar sem hann getur dáið, og hver um sig skilur eftir sig annað ummerki.
Hvað handshake sannar í raun
WireGuard er UDP-samskiptareglur sem kemur á lotu með Noise-handshake og dulritar síðan pakka fyrir jafningja. Þegar wg show sýnir handshake sem er nokkrar sekúndur gamalt og hækkandi flutningsteljara, eru endapunkturinn, lyklarnir og dreifilykill jafningjans allt rétt.
Það sem það sannar ekki er að biðlarinn þinn sendi yfir höfuð nettraffic inn í viðmótið, að netþjóninum sé í lagi að áframsenda það, eða að svar geti fundið leiðina til baka. Það eru ákvarðanir kjarna-leiðakerfis og eldveggs, og þær eru teknar fyrir utan göngin.
Þess vegna er ping á göngufang netþjónsins svo villandi próf. Sá pakki er stílaður á netþjóninn sjálfan, svo hann endar staðbundið. Hann þarf aldrei áframsendingu, aldrei þýðingu og aldrei afturleið frá internetinu.
AllowedIPs er leiðarákvörðun
Á biðlaranum gegnir AllowedIPs tvennu hlutverki. Það er dulritunarlyklaleiðartaflan sem ákveður hvaða áfangaföng eru send inn í göng þessa jafningja, og það er listinn yfir upprunaföng sem jafninginn tekur við frá þér. Ef stilling biðlarans telur aðeins upp 10.8.0.0/24, komast opinber áfangastaðir aldrei inn í viðmótið og venjulega sjálfgefna leiðin þín flytur þá út fyrir göngin. Þá virka göngin fullkomlega og gera ekkert af því sem þú vildir.
Líttu á hvað biðlarinn setti í raun upp frekar en hvað stillingarskráin segir:
wg show wg0 allowed-ipsip route get 1.1.1.1
Seinna skipunin er hin afgerandi. Ef svarið nefnir líkamlega viðmótið þitt og venjulegu gáttina, er pakkinn ekki sendur í gegnum göngin og engin breyting á netþjónshlið mun laga það. Bættu 0.0.0.0/0 við fyrir IPv4 og ::/0 fyrir IPv6 sérstaklega; regla sem grípur allt fyrir eina fjölskyldu lætur hina vera á upprunalegri leið sinni, og það er algeng orsök virkra IPv4-ganga og fastra IPv6-uppflettinga.
Hvar pakkinn deyr á gáttinni
Ef leiðin er rétt og pakkinn fer samt hvergi, kemur hann að netþjóninum og stöðvast þar. Fjórar athuganir ná yfir flestar gáttir.
Áframsending. sysctl net.ipv4.ip_forward sem skilar 0 er klassíska svarið, og mörg dreifingar eru enn sjálfgefið á 0. Það verður að vera 1, og setja það varanlega í sysctl-skrá frekar en með skipun sem hverfur við endurræsingu. Áframsending IPv6 er sérstakur rofi.
Síunin stefnan. Keðja FORWARD með sjálfgefinni drop-stefnu mun henda gönguumferð á meðan hún leyfir umferð til sjálfs hýsilsins, sem passar nákvæmlega við einkennin. Lestu lifandi reglusafnið, ekki vistaða skrá: nft list ruleset eða iptables -S.
Þýðing eða leiðsögn. Biðlarar með einkagönguföng þurfa annaðhvort upprunanat á útgangsviðmóti netþjónsins eða leiðstýrt forskeyti sem netið fyrir ofan veit hvernig á að skila. Valið þar á milli fylgir fangaskipulaginu. Að bæta MASQUERADE við net sem leiðar þegar forskeytið þitt til baka er skaðlaust en gagnslaust, og að sleppa því þar sem engin leið er til lætur svörin stíluð á óleiðanlegt einkanet.
Afturleiðin. Í leiðstýrðum hönnunum þarf beininn fyrir ofan leið sem vísar á netþjóninn þinn. Netveitan getur líka lokað á það: nokkur ský virkja uppruna- og áfangastaðaathugun á eintakinu, sem sleppir hljóðlega pökkum sem eiga uppruna sem er ekki eigið fang eintaksins, þar til slökkt er á þeirri athugun.
DNS bregst öðru vísi en leiðsögn
Pakki á þekkt fang og nafnuppfletting eru tveir aðskildir brestir, og villuboðin villa um veg vísa í gagnstæðar áttir. Ef ping 1.1.1.1 virkar og vafri getur ekkert hlaðið, er leiðin í lagi og nafnlausnin ekki. Ef pingið sjálft bregst, er DNS óviðkomandi og þú ert aftur í fyrri kafla.
wg-quick getur stillt leysi út frá línunni DNS = í stillingunni, og systemd-resolved hefur sína eigin hegðun fyrir hverja tengingu. VPN sem skrifar yfir leysinn með fangi sem aðeins er hægt að ná innan ganganna mun láta hverja uppflettingu bregðast á þeirri stundu sem göngin falla, sem lítur út eins og göngin brjóti 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 |
Röð sem framleiðir sönnunargögn
Keyrðu athugunina á biðlarahlið fyrst, því hún er ein skipun og útilokar helming möguleikanna. Staðfestu svo hvort netþjóninum sé yfir höfuð ætlað að vera internetútgangur; gátt sem er byggð fyrir einkaaðgang er ekki brotin þegar opinberir áfangastaðir bregðast.
Á netþjóninum, fylgstu með viðmótinu á meðan þú sendir ping frá biðlaranum: tcpdump -ni wg0 icmp ætti að sýna beiðnina, og tcpdump -ni eth0 icmp ætti að sýna að hún fari út, þýdd eða ekki. Ef hún birtist á þeirri fyrri og aldrei á þeirri seinni, er stöðvunin staðbundin á netþjóninum. Ef hún fer út og ekkert svar kemur til baka, er vandamálið ofar, og það er annað samtal.
Að lokum skaltu láta lagfæringuna standa af sér endurræsingu. Áframsending á heima í sysctl-skrá, eldveggsreglur eiga heima í þjónustunni sem hleður þær, og leiðir biðlarans eiga heima í stillingunni sem ræsir viðmótið frekar en í skel sem þú munt gleyma. Taktu tengingu aftur, endurtaktu sömu tvö prófin og staðfestu að teljararnir hreyfist.