Liitäntä nousee, vertaiskonfiguraatio näyttää oikealta eikä yksikään kättely koskaan valmistu. Oletusreitin lisääminen tunnelin kautta on vaihe, joka usein aiheuttaa sen: sama reititystaulu päättää nyt, minne tunnelin omien salattujen pakettien pitäisi mennä, ja tuottamansa vastaus vie takaisin tunneliin. Mikään ei voi kuljettaa ulompaa pakettia, joka kuljettaisi sisemmän, joten yhteys pysähtyy ennen kuin se alkaa. Korjaus on pieni, mutta sillä on järjestys, ja tarkistaminen on tärkeämpää kuin muokkaus.

Vahvista silmukka ennen reitin muuttamista

Lue vertaisen nykyinen päätepisteosoite ja kysy sitten reitityspinolta, minne kyseiseen osoitteeseen menevä paketti menisi. Jos vastaus nimeää tunnelin liitännän, silmukka on vahvistettu eikä lisädiagnostiikkaa tarvita. Tallenna molemmat tulosteet muutoslokkiin ennen mihinkään koskemista, koska korjauksen jälkeinen vertailu on samat kaksi komentoa. Silmukka ei ole hienovarainen, kun sen on nähnyt; vaikeus on siinä, että liitäntä näyttää terveeltä, kun se tapahtuu.

sudo wg show wg1 endpoints
ip route get 198.51.100.20
ip rule show

Sisällytä käytäntösäännöt tuohon tallenteeseen. Oletusreitti, joka näyttää päätaulussa oikealta, voi silti hävitä säännölle, joka valitsee toisen taulun merkitylle tai merkitsemättömälle liikenteelle, ja silmukka ilmestyy uudelleen reititystaulun näyttäessä kunnolliselta.

Lue päätepisteen polku, älä tunnelin polkua

Päätepisteen polku on reitti, jonka salatut datagrammit kulkevat vertaisen julkiseen osoitteeseen, ja sen on pysyttävä tunnelin ulkopuolella niin kauan kuin tunneli on olemassa. Tunnelin polku on kaikki, mitä vertaisen sallitaan kuljettaa. Nämä kaksi polkua jakavat yhden reititystaulun, ja juuri siksi yksi kaiken kattava merkintä voi romahduttaa ne toisiinsa. Tunnelin liikenteen erottaminen tunnelin omasta kuljetuksesta on koko suunnitteluongelma, ja jokainen tuettu työkalu ratkaisee sen jossain hieman eri tavalla.

Tarkista molemmat osoiteperheet erikseen, jos liitäntä kantaa molemmat. Toimiva IPv4-poissulkeminen ei kerro mitään siitä, onko IPv6-päätepiste yhä tavoitettavissa, ja sekakonfiguraatio voi näyttää toimivalta, kunnes vertaisen IPv6-osoite valitaan.

Palauta päätepisteen polku yhdellä johdonmukaisella muutoksella

On olemassa kaksi tuettua lähestymistapaa, ja niiden sekoittaminen on tapa, jolla toimiva asennus muuttuu arvaamattomaksi. Ensimmäinen on antaa liitäntää hallitsevan työkalun hoitaa koko tunneli: wg-quick on erityinen käsittely oletusvertaisalueelle, joka asentaa erillisen taulun, käytäntösäännöt ja socket-merkin, mikä pitää ulommat paketit poissa tunnelista. Jätä tuo mekanismi ehjäksi sen sijaan, että toistaisit siitä puolet käsin. Asennus, joka sekoittaa käsin lisätyn oletusreitin hallintaan, joka jo asentaa merkit ja säännöt, tapaa epäonnistua uudelleenyhdistämisen jälkeen, kun hallinta kirjoittaa uudelleen tilan, jonka käsin tehty vaihe oletti.

Toinen on käsin tehty suunnittelu, jossa päätepiste saa eksplisiittisen isäntäreitin fyysisen yhdyskäytävän kautta. Lisää kyseinen reitti ennen oletusreittiä, korvaa sen sijaan että lisäisit, jotta vanhentunut merkintä ei voi voittaa, ja vahvista haku sen jälkeen.

sudo ip route replace 198.51.100.20/32 via 192.0.2.1 dev eth0
ip route get 198.51.100.20
sudo ip route add default dev wg1

Tarkista ja pidä sitten paluutie

Etenevä kättelyn aikaleima on ensimmäinen todiste, ja se on vahvempi kuin liitäntä, joka vain on olemassa. Seuraa sitä tunnelin kautta tehtävällä sovellustestillä, ota sitten liitäntä tarkoituksella alas ja vahvista, että isäntä palaa käyttökelpoiseen tilaan sen sijaan, että pitäisi oletusreitin, joka osoittaa tyhjään. Tuon viimeisen vaiheen ihmiset ohittavat, ja se ratkaisee, jättääkö uudelleenkäynnistys koneen ilman yhteyttä.

sudo wg show wg1 latest-handshakes
sudo wg-quick down wg1
ip route show default
ip route get 198.51.100.20

Ennen mitään tätä tallenna nykyinen reititystila ja varmista, että on olemassa pääsyreitti, joka ei riipu tunnelista: konsoli, hallintaverkon ulkopuolinen osoite tai paikalla oleva kollega. Etäkone, joka menettää oletusreittinsä, ei ole palautettavissa juuri menetetyn yhteyden kautta, ja runbookin turvallisin vaihe on se, joka tehdään ennen ensimmäistä komentoa.

Aiheeseen liittyvät artikkelit