WireGuard toimii vasta kun palvelin lähettää: päätepisteen tuntemus
Suunnasta riippuva onnistuminen tarkoittaa yleensä, että toinen osapuoli ei koskaan oppinut toisen osoitetta. Vertaa päätepisteitä ja tarkista sitten, onko käännöskartoitus vanhentunut.
Tunneli näyttää toimivan vasta kun palvelin lähettää jotain ensin. Aloita asiakkaasta, eikä mitään tapahdu, odota muutama sekunti, yritä uudelleen ja se onnistuu. Tavallinen diagnoosi on rikkinäinen NAT, ja tavallinen diagnoosi on väärä. Muutos on siinä, että toinen osapuoli oppi, missä toinen asuu.
Päätepisteen tuntemus, ei tavoitettavuus
WireGuard-osapuoli ei aloita kättelyä ennen kuin tietää, mihin se lähetetään. Kokoonpano antaa sen osoitteen ja portin päätepisteenä, ja käynnissä oleva tila seuraa päätepistettä, johon se tällä hetkellä uskoo.
wg show tulostaa kuvan molemmat puolet, eikä osapuoli, jolla ei ole tulosteessa päätepistettä, voi aloittaa mitään, niin oikea kuin sen julkinen avain ja sallitut etuliitteet ovatkin. Vertaa asiakkaan näkemystä palvelimen näkemykseen ennen minkään säännön muuttamista, koska nämä kaksi ovat usein eri mieltä siitä, kuka tietää mitä.
Miten osapuoli oppii päätepisteen
WireGuard on tarkoituksella hiljainen. Kun oikein todennettu paketti saapuu osoitteesta, jota osapuoli ei odottanut, toteutus päivittää kyseisen osapuolen päätepisteen uudeksi lähteeksi, ja näin verkkoja vaihtavan kannettavan tietokoneen roaming toimii. Tämä käyttäytyminen selittää suuntariippuvuuden: jos palvelin lähettää ensin ja sen paketti saapuu asiakkaalle, asiakas oppii palvelimen nykyisen osoitteen ja voi vastata. Siihen asti sillä ei ole mihin lähettää. Mekanismi on todennettu roaming eikä ensimmäisen käytön luottamuksen oikotie, koska paketin oli oltava kelvollinen ennen kuin päätepiste siirtyi.
wg:n työkaludokumentaatio kuvaa tämän päivityksen, ja se kannattaa lukea kerran, jos aiot suunnitella sen ympärille.
Tilallinen käännös lisää oman suuntansa
Kun UDP kulkee kääntävän yhdyskäytävän läpi, yhdyskäytävä luo tilan ensimmäiselle näkemälleen paketille. RFC 4787 kuvaa tämän käyttäytymisen ja aikakatkaisut, jotka lopulta poistavat kartoituksen. Käyttämätön kartoitus vanhentuu, ja kauempaa tuleva saapuva paketti pudotetaan silloin yhdyskäytävässä ennen kuin se saavuttaa isäntäkoneen. Koko aamupäivän toiminut tunneli lakkaa vastaamasta iltapäivällä juuri tästä syystä.
Tämä on toinen ja riippumaton mekanismi, joka tuottaa saman suuntaisen oireen. Sekä päätepisteen tuntemuksen että käännöksen tilan on oltava oikein, eikä toisen korjaaminen korjaa toista.
Määritä suunta, jonka todella haluat
Asiakkaalle, jonka on aloitettava yhteys, aseta palvelimen päätepiste asiakkaan osapuoliosioon ja pidä se siellä. Se, että luottaa palvelimen lähettävän ensin, on luottamista liikenteen järjestyksen sattumaan, joka muuttuu hiljaisessa verkossa. Kokoonpanon pitäisi ilmoittaa aiottu suunta, ei löytää sitä.
Osapuolelle käännöksen takana, jonka on pysyttävä tavoitettavana, ota käyttöön pysyvä keepalive sillä puolella. Keepalive 25 sekunnin välein on tavallinen aloitusarvo, ja sen tarkoitus on pitää kartoitus auki eikä testata tunnelia. Valitse yksi puoli kantamaan se, koska molemmilla puolilla käyttöönotto kaksinkertaistaa liikenteen ja lokikohinan parantamatta tulosta.
Vertaa tilaa ennen laukaisinta ja sen jälkeen
Tallenna kaksi näkymää hetkellä, jolloin se epäonnistuu, ja sitten uudelleen sen jälkeen kun palvelin lähettää. Ensimmäinen komento näyttää päätepisteet ja kättelyn iän. Toinen näyttää, onko portille käännöskirjausta. Tallenne näyttää, mikä suunta todella ylitti johdon, ja reittitarkistus vahvistaa, että asiakas ei lähetä tätä liikennettä aivan muualle.
wg show conntrack -L -p udp 2>/dev/null | grep 51820 tcpdump -ni any -c 20 'udp port 51820' ip route get 198.51.100.7
Kirjaa päätepistesarake ja käännöskirjaus yhdessä. Osapuoli ilman päätepistettä ja yhdyskäytävä ilman kartoitusta ovat kaksi eri vikaa. Vain toisen niistä keepalive korjaa.