WireGuard toimii matkapuhelindatalla mutta ei samassa wifi-verkossa
Pyyntö LANin sisältä reitittimen julkiseen osoitteeseen kulkee eri polkua kuin pyyntö matkapuhelindatalla. Testaa ulkopuolelta ja valitse sitten paikallinen polku.
Tunneli nousee matkapuhelindatalla ja jää sitten kotona yhdistämään -tilaan, samalla profiililla, samalla peer-avaimella eikä mitään konfiguraatiomuutosta välissä. Ero on matkassa: pyyntö LANin sisältä reitittimen julkiseen osoitteeseen ei ole sama matka kuin internetistä saapuva pyyntö. Useimmat kotiyhdyskäytävät joko eivät toteuta paluupolkua lainkaan tai toteuttavat sen vain tietyille protokollille. Siksi oire näyttää rikkinäiseltä avaimelta, vaikka avaimessa mikään ei ole muuttunut. Selvitä, mikä polku epäonnistui, ennen kuin kosket avaimeen, portinohjaukseen tai asiakasprofiiliin.
Yksi osoite, kaksi eri polkua
Ulkopuolelta paketti saavuttaa reitittimen julkisen osoitteen ja portinohjaussääntö antaa sen sisäisessä isännässä kuuntelevalle WireGuardille. Sisäpuolelta asiakas valitsee saman julkisen osoitteen, joten paketti lähtee asiakkaalta, saapuu reitittimelle ja se on käännettävä takaisin LANia kohti. Juuri siinä käännöksessä kaksi polkua eroavat, koska reitittimen on käännettävä virta, joka samalla poistuu ja palaa saman rajapinnan kautta. Moni toteutus pudottaa sen kääntämisen sijaan, ja asiakas jää odottamaan kättelyä, jota ei koskaan lähetetty.
Tätä käyttäytymistä kutsutaan yleensä nimellä NAT loopback tai hairpinning, ja se kuuluu reitittimelle eikä WireGuardille; RFC 4787 esittää käännöstapaukset, joissa yhdyskäytävä voi tukea sitä tai olla tukematta. WireGuard itse ei ota kantaa polkuun, koska se näkee vain sen rajapinnalle saapuvat paketit. Kun reititin pudottaa virran, daemon ei koskaan saa mitään, asiakas ilmoittaa kättelyn aikakatkaisusta ja palvelimen loki jää tyhjäksi. Tyhjä loki on siis vihje siitä, mihin paketti pysähtyi, ei todiste siitä, että palvelin on alhaalla. Siksi uudelleenasennus ei muuta mitään.
Myös päinvastainen on tärkeää: palvelimen loki, joka näyttää kättely-yrityksen LAN-osoitteesta, todistaa, että paketti saapui ja polku on kunnossa, mikä siirtää tutkinnan avaimiin ja sallittuihin osoitteisiin. Lue lokia sen perusteella, mitä se todistaa, älä sen perusteella, mitä toivoit näkeväsi.
Toista ensin, muuta vasta sitten
Testaa valtuutetusta ulkoisesta verkosta samalla laitteella ja samalla profiililla ja toista testi sitten LANin sisällä muuttamatta mitään. Ulkona suoritettu kättely ja asiakas, joka sisällä ei koskaan poistu laitteesta, toistavat tilanteen sen arvaamisen sijaan. Molempien yritysten on käytettävä samaa profiilia, muuten vertailu ei todista mitään.
Katso sitten, mihin päätepisteen nimi ratkeaa tälle laitteelle. Seuraavat kolme komentoa näyttävät myös, minkä osoitteen asiakas todella valitsi:
wg show wg0 endpoints
dig +short vpn.example.net A
resolvectl query vpn.example.netEnsimmäinen komento ilmoittaa päätepisteen, jota rajapinta käyttää juuri nyt, ja kaksi muuta näyttävät, mihin nimi ratkeaa tällä koneella. Asiakas, joka valitsee julkisen osoitteen ollessaan samassa verkossa palvelimen kanssa, käyttää hairpin-polkua. Asiakas, joka valitsee LAN-osoitteen, ei tee niin, ja siellä oleva vika kuuluu toiseen tutkintaan. Tämä ero ratkaisee, soveltuuko seuraava osio lainkaan.
Tuetut tavat päästä läheiselle palvelimelle
Selkein järjestely on jaetun horisontin vastaus: julkinen nimi ratkeaa internetille julkiseen osoitteeseen ja sisällä oleville asiakkaille palvelimen LAN-osoitteeseen. Profiili pitää yhden päätepisteen nimen ja ratkaisija valitsee polun. Se vaatii hallinnan sisäiseen DNS-vastaukseen, jota kotireititin yleensä tarjoaa ja organisaatio voi järjestää tarkoituksella. Ilman sitä hallintaa vaihtoehtoina ovat reitittimen ominaisuus tai toinen profiili.
Reitittimen ominaisuus on heijastus: yhdyskäytävä kääntää virran sisältä ulos ja lähettää sen takaisin sisään. Siellä missä se toimii, se ei vaadi asiakasmuutosta, ja siellä missä se ei toimi, mikään asiakasasetus ei pelasta sitä. Testaa sitä seuraamalla palvelimen lokia sisäisen yrityksen aikana sen sijaan, että lukisit reitittimen ominaisuusluetteloa.
Profiilin muuttaminen yksityiseen osoitteeseen on diagnoosi, ei suunnittelu. Se todistaa, että palvelin vastaa LANissa, ja rikkoo saman profiilin heti, kun kannettava tietokone lähtee kotoa.
| Approach | What it depends on | Where it fails |
|---|---|---|
| Split-horizon name | Control of the internal DNS answer | Clients that resolve through a server outside the zone |
| Router reflection | Gateway support for hairpin translation | Routers that drop the flow silently |
| Private address in the profile | Nothing beyond the LAN | Every network except the one at home |
Pidä profiili käyttökelpoisena kodin ulkopuolella
Minkä polun valitsetkin, jätä identiteetin tarkistus rauhaan. Päätepisteen osoite ei ole peer-identiteetti, eikä osoitteen muutos koskaan oikeuta hyväksymään vierasta julkista avainta, joka sattuu vastaamaan. WireGuard todentaa avaimella, joten väärä isäntä epäonnistuu kättelyssä sen sijaan, että antaisi pääsyn johonkin odottamattomaan.
Jos julkinen osoite liikkuu, dynaaminen DNS on se, joka pitää nimen hyödyllisenä, ja asiakkaan päivityskäyttäytyminen ratkaisee, kuinka nopeasti muutos tulee perille. Testaa se ulkopuolelta osoitteen muutoksen jälkeen, koska LAN-tapaus ei voi vahvistaa sitä. Varo ratkaisijaa, joka välimuistittaa vanhan vastauksen tietueen elinikää pidemmäksi. Nimi, joka osoittaa edelleen edelliseen osoitteeseen, näyttää täsmälleen kaatuneelta palvelimelta.
Kirjoita ylös, mitä nimeä profiili käyttää ja mihin se ratkeaa rajan kummallakin puolella. Profiili, joka riippuu reitittimen ominaisuudesta, jota kukaan ei kirjannut, on tukipuhelu, joka odottaa seuraavaa laiteohjelmistopäivitystä. Muistiinpano kertoo myös seuraavalle ihmiselle, onko sisäinen vika tunnettu hairpin-tapaus vai jotain uutta.