WireGuard-kättely toimii, mutta internet ei: seuraa pakettia

Tunneli on ylhäällä, wg show näyttää tuoreen kättelyn, voit pingata palvelimen tunneliosoitetta, eikä mikään sen takana vastaa. Ensimmäinen ajatus on luoda avaimet uudelleen tai jakaa kokoonpano uudestaan. Se muuttaa juuri sitä polun osaa, jonka on jo todistettu toimivan.

Valmis kättely kertoo, että kaksi osapuolta sopivat avaimista, että UDP saavuttaa päätepisteen ja että salausreititys hyväksyy paketin. Se ei kerro mitään siitä, voiko paketti sen jälkeen poistua palvelimelta.

Seuraa siis yhtä pakettia arvaamisen sijaan. On neljä paikkaa, joihin se voi kuolla, ja jokainen jättää erilaisen jäljen.

Mitä kättely todella todistaa

WireGuard on UDP-protokolla, joka muodostaa istunnon Noise-kättelyllä ja salaa sitten paketit vertaiselle. Kun wg show näyttää muutaman sekunnin ikäisen kättelyn ja kasvavan siirtolaskurin, päätepiste, avaimet ja vertaisen julkinen avain ovat kaikki oikein.

Mitä se ei todista: että asiakkaasi ylipäätään lähettää internetiin menevää liikennettä rajapintaan, että palvelin on halukas välittämään sitä eteenpäin tai että vastaus löytää tien takaisin. Ne ovat ytimen reitityksen ja palomuurin päätöksiä, ja ne tehdään tunnelin ulkopuolella.

Siksi palvelimen tunneliosoitteen pingaaminen on niin harhaanjohtava testi. Se paketti on osoitettu palvelimelle itselleen, joten se päättyy paikallisesti. Se ei koskaan tarvitse edelleenlähetystä, ei koskaan käännöstä eikä koskaan paluureittiä internetistä.

AllowedIPs on reitityspäätös

Asiakkaassa AllowedIPs tekee kaksi työtä. Se on salausavainreititystaulu, joka päättää, mitkä kohdeosoitteet lähetetään tämän vertaisen tunneliin, ja se on lähdeosoitteiden luettelo, jonka vertainen hyväksyy sinulta. Jos asiakkaan kokoonpanossa luetellaan vain 10.8.0.0/24, julkiset kohteet eivät koskaan tule rajapintaan ja tavallinen oletusreittisi kuljettaa ne tunnelin ohi. Silloin tunneli toimii täydellisesti eikä tee mitään siitä, mitä halusit.

Katso, mitä asiakas todella asensi, älä sitä, mitä kokoonpanotiedosto sanoo:

wg show wg0 allowed-ips
ip route get 1.1.1.1

Toinen komento on ratkaiseva. Jos vastaus nimeää fyysisen rajapintasi ja tavallisen yhdyskäytävän, pakettia ei tunneloida eikä mikään palvelimen puolen muutos korjaa sitä. Lisää 0.0.0.0/0 IPv4:lle ja ::/0 IPv6:lle erikseen; sääntö, joka kattaa kaiken yhdelle perheelle, jättää toisen alkuperäiselle polulleen, ja se on tavallinen syy toimivalle IPv4-tunnelille ja jumittuneelle IPv6-haulle.

Missä paketti kuolee yhdyskäytävällä

Jos reitti on oikein ja paketti ei silti mene mihinkään, se saapuu palvelimelle ja pysähtyy sinne. Neljä tarkistusta kattaa useimmat yhdyskäytävät.

Edelleenlähetys. sysctl net.ipv4.ip_forward vastauksena 0 on klassinen tapaus, ja monet jakelut ovat edelleen oletuksena 0. Sen on oltava 1, ja se on asetettava pysyvästi sysctl-tiedostoon eikä komennolla, joka katoaa uudelleenkäynnistyksessä. IPv6:n edelleenlähetys on erillinen kytkin.

Suodatuskäytäntö. FORWARD-ketju, jonka oletuskäytäntö on pudottaa, hylkää tunneliliikenteen mutta sallii liikenteen itse isäntään, mikä vastaa oiretta täsmälleen. Lue elävä sääntöjoukko, älä tallennettua tiedostoa: nft list ruleset tai iptables -S.

Käännös vai reititys. Yksityisiä tunneliosoitteita käyttävät asiakkaat tarvitsevat joko lähde-NATin palvelimen lähtörajapinnalla tai reititetyn etuliitteen, jonka ylempi verkko osaa palauttaa. Valinta näiden välillä seuraa osoitesuunnitelmaa. MASQUERADEn lisääminen verkkoon, joka jo reitittää etuliitteesi takaisin, on harmitonta mutta hyödytöntä, ja sen jättäminen pois sinne, missä reittiä ei ole, jättää vastaukset osoitetuiksi reitittämättömään yksityiseen alueeseen.

Paluupolku. Reititetyissä ratkaisuissa ylempi reititin tarvitsee reitin, joka osoittaa palvelimeesi. Palveluntarjoajan verkko voi myös estää sen: useat pilvet ottavat instanssissa käyttöön lähde- ja kohdetarkistuksen, joka pudottaa hiljaisesti paketit, joiden lähde ei ole instanssin oma osoite, kunnes tarkistus poistetaan käytöstä.

DNS epäonnistuu eri tavalla kuin reititys

Paketti tunnettuun osoitteeseen ja nimihaku ovat kaksi eri vikaa, ja virheilmoitukset johtavat harhaan vastakkaisiin suuntiin. Jos ping 1.1.1.1 toimii eikä selain lataa mitään, reitti on kunnossa ja nimien selvitys ei. Jos itse ping epäonnistuu, DNS on merkityksetön ja olet takaisin edellisessä osassa.

wg-quick voi asettaa resolverin kokoonpanon riviltä DNS =, ja systemd-resolvedilla on oma käyttäytymisensä linkkiä kohden. VPN, joka korvaa resolverin osoitteella, joka on tavoitettavissa vain tunnelin sisällä, epäonnistuu jokaisessa haussa heti, kun tunneli putoaa, mikä näyttää siltä kuin tunneli rikkoisi internetin.

Järjestys, joka tuottaa todisteita

Tee ensin asiakkaan puolen tarkistus, koska se on yksi komento ja poistaa puolet mahdollisuuksista. Vahvista sitten, onko palvelin ylipäätään tarkoitettu internetin ulostuloksi; yksityiseen käyttöön rakennettu yhdyskäytävä ei ole rikki, kun julkiset kohteet epäonnistuvat.

Palvelimella seuraa rajapintaa, kun lähetät pingin asiakkaalta: tcpdump -ni wg0 icmp näyttää pyynnön ja tcpdump -ni eth0 icmp näyttää, että se lähtee, käännettynä tai ei. Jos se näkyy ensimmäisessä eikä koskaan toisessa, pysähdys on palvelimen paikallinen. Jos se lähtee eikä vastausta tule, ongelma on ylempänä, ja se on eri keskustelu.

Tee lopuksi niin, että korjaus kestää uudelleenkäynnistyksen. Edelleenlähetys kuuluu sysctl-tiedostoon, palomuurisäännöt palveluun, joka ne lataa, ja asiakkaan reitit kokoonpanoon, joka nostaa rajapinnan, eikä komentotulkkiin, jonka unohdat. Yhdistä uudelleen, toista samat kaksi testiä ja vahvista, että laskurit liikkuvat.