WireGuard AllowedIPs: reitti, jota NetworkManager ei koskaan lisännyt
Kelvollinen WireGuard-profiili voi saada kättelynsä valmiiksi ja silti lähettää ei mitään. Vertaa ytimen taulukkoa AllowedIPs-luetteloon ja anna sitten reittipolulle yksi omistaja.
Kättelylaskuri päivittyy, rajapinta pitää osoitteensa, eikä ping toiselle puolelle mene minnekään. Tämä yhdistelmä hämmentää ihmisiä, koska toimiva kättely tuntuu todisteelta siitä, että tunneli on valmis. Se ei ole: tunneli voi olla täysin neuvoteltu ja silti sillä ei ole yhtään reittiä, joka ohjaisi liikennettä siihen, ja ne ovat kaksi erillistä työtä, jotka tekevät kaksi erillistä tilanpalasta. Korjaus riippuu täysin siitä, kumpi näistä kahdesta puuttuu, joten ensimmäinen askel on selvittää se.
wg-quick tekee molemmat pyytämättä. NetworkManagerin sisäänrakennettu WireGuard-tuki asentaa myös peer-reitit oletuksena, mikä rajaa epäillyt pois päältä olevaan asetukseen, toiseen reititystaulukkoon tai jonkin muun kautta tuotuun kokoonpanoon.
Vahvista tunneli ennen kuin jahtaat reittiä
wg show tulostaa rajapinnan, peerin, päätepisteen ja viimeisimmän kättelyn iän, ja ip addr show vahvistaa, että osoite on paikalla. Tuore kättely tarkoittaa, että avaimet, päätepiste ja UDP-polku toimivat. Kaikki rikki oleva istuu niiden alavirrassa: reititys, suodatus tai nimien selvitys.
Kysy sitten ytimeltä, mitä se tekisi todelliselle kohteelle hypoteettisen sijaan: ip route get 10.42.7.9. Vastaus nimeää lähtevän rajapinnan ja lähdeosoitteen, jonka paketti kantaisi. Kun se nimeää fyysisen sovittimen, paketti ei koskaan päädy tunneliin, niin terveeltä kättely näyttäköön.
AllowedIPs on suodatin ja reittiluettelo
AllowedIPs-luettelon etuliitteet tekevät kaksi työtä. Ne valitsevat, mikä peer kantaa lähtevän kohteen, ja ne validoivat saapuvien pakettien lähdeosoitteen, mikä on salausavainreitityksen raja. wg-quickissa ne myös ajavat automaattista reittien asennusta, ja juuri se lisäkäyttäytyminen on syy siihen, miksi sama kokoonpano toimii päätteestä eikä työpöytäasiakkaasta.
Tämän artikkelin taustalla olevassa tapauksessa profiili tuotiin kolmannen osapuolen liitännäisellä eikä sisäänrakennetulla tuella, ja rajapinta nousi ilman etuliitereittiä. Taulukon listaus näyttää sen heti: ip route show sisältää vain rajapinnan osoitteen yhdistetyn reitin eikä mitään etäiselle alueelle.
Kysy, ovatko peer-reitit ylipäätään käytössä
Lue asetus ennen kuin muutat mitään: nmcli -f wireguard.peer-routes,ipv4.route-table connection show work-wg. Kun peer-routes näyttää no, tuettu korjaus on nmcli connection modify work-wg wireguard.peer-routes yes ja sen jälkeen yhteyden uudelleenmuodostus. Staattisen reitin lisääminen sen sijaan toimii seuraavaan aktivointiin asti ja katoaa sitten hiljaa. Se katoaminen on vihje: reittiä, joka palaa arvoituksena joka aamu, ei asenna profiili.
Jos asetus on jo käytössä, tarkista ip route show table all | grep 10-komennolla, elääkö etuliite toisessa taulukossa. Reitti, joka on muussa kuin päätaulukossa, ei puutu, se on vain näkymätön haulle, joka katsoo vain päätaulukkoa. Korjaa käytäntöreititys sen sijaan, että pinoaisit päälle kaksoiskappaleen.
Lisää etuliite yhteyteen, ei käynnissä olevaan järjestelmään
Yhteyksien muokkaimessa WireGuard-sivu pitää peerin ja sen AllowedIPs-luettelon, ja IPv4-sivu pitää lisäreitit. Sinne lisätty reitti selviää uudelleenyhdistämisistä, koska se kuuluu profiiliin. Komentorivillä vastine on lisätä reitti yhteyteen tyhjän yhdyskäytävän muodossa ja laskea ja nostaa yhteys, jotta muutos astuu voimaan.
Valitse kapein etuliite, joka kattaa tarvitsemasi isännät. Palveluntarjoajan esimerkin /8 kopioiminen voi niellä paikalliset alueet, jotka sattuvat olemaan sen sisällä, ja tuloksena olevat viat näyttävät rikkinäiseltä tunnelilta eivätkä liian leveältä reitiltä.
Jaetun tunnelin päättää etuliiteluettelo
Jaetun tunnelin kytkintä ei ole; etuliiteluettelo on päätös. Peer, jolla on yksi alue toimiston LAN-verkkoon ja toinen laboratorioverkkoon, lähettää täsmälleen ne kohteet tunnelin kautta ja jättää kaiken muun rauhaan. Yksi isäntä tarvitsee /32:n, ja kahdessa paikassa päällekkäiset alueet tarvitsevat isäntäetuliitteitä, kunnes joku numeroi aliverkon uudelleen.
Valinta olla lähettämättä mitään tunnelin kautta vie saman päätöksen rajaansa: minimaalinen luettelo pitää yhteyden pystyssä, kun tavallinen liikenne kulkee tavanomaista polkuaan. Kirjoita aikomus muistiin, koska muuten seuraava lukija pitää lyhyttä luetteloa laiminlyöntinä ja laajentaa sitä avuliaasti.
Yksi omistaja reititystaulukolle
wg-quick ja NetworkManager uskovat molemmat omistavansa rajapinnan reitit. Tuo wg-quickille kirjoitettu kokoonpano ja käynnistä sitten myös wg-quick-palvelu, niin saat kopioituja tai ristiriitaisia merkintöjä, joiden käyttäytyminen riippuu siitä, kumpi ajettiin viimeksi. Valitse yksi omistaja ja poista toinen: jos NetworkManager hallinnoi yhteyttä, poista wg-quick-yksikkö käytöstä kyseiselle rajapinnalle äläkä koskaan lisää toista profiilia samalle laitteelle.
Kun jaon täytyy seurata fyysistä sovitinta eikä kohdetta, olet siirtynyt käytäntöreititykseen, ja käytäntöreititys tarvitsee myös yhden tekijän. Vahvista toistamalla ip route get ja saavuttamalla sitten isäntä etäisen etuliitteen sisällä jollakin, joka tulostaa valitsemansa lähdeosoitteen. Tarkista IPv6 ja DNS erikseen, jos profiili kantaa jompaakumpaa.