AllowedIPs on reitityslista, ei palomuurisääntö
Se valitsee vertaiskumppanin lähtevälle liikenteelle ja validoi saapuvat lähteet. Se ei ole käyttöoikeuslista, eikä reitityksen hallinnan poistaminen korjaa jaettua tunnelia.
Useimmat lukevat AllowedIPs-kentän lupalistana, joukkona osoitteita, jotka saavat yhdistää vertaiskumppaniin, suunnilleen kuin tunnelille kirjoitettu palomuurisääntö. Näin ei ole. Kenttä on reititystaulu, joka toimii molempiin suuntiin: se valitsee vertaiskumppanin lähtevälle paketille ja validoi saapuvan paketin lähteen. Lupalistana lukeminen tuottaa kokoonpanoja, jotka reitittävät liikennettä, jota kukaan ei pyytänyt.
Yksi kenttä, kaksi lukijaa: lähtevän valinta ja lähteen tarkistus
Asiakkaassa etuliitteet päättävät, mitkä kohteet kulkevat tälle vertaiskumppanille ja mitkä jäävät tavalliseen verkkoon. Siksi merkintä 0.0.0.0/0 kaappaa jokaisen IPv4-kohteen, ja siksi täystunnelin profiilin tuonti lähettää tavallisen selailun etäkoneen kautta. Kapeat merkinnät tekevät päinvastoin: ne reitittävät vain luettelemasi verkot ja jättävät kaiken muun paikoilleen. WireGuardin dokumentaation salausavainten reititystä käsittelevä osio esittää molemmat tehtävät yhdessä paikassa: lähtevän vertaiskumppanin valinnan ja saapuvan lähteen validoinnin.
Palvelimella sama kenttä kuvaa, mitä lähdeosoitteita kukin vertaiskumppani saa käyttää. Kyse on salauksellisesta tarkistuksesta eikä pakettisuodattimesta: paketti, jonka sisäinen lähde ei vastaa vertaiskumppanin listaa, pudotetaan WireGuardin sisällä ennen kuin mikään isännän palomuuri näkee sen. Molemmat tehtävät jakavat yhden listan, ja juuri siksi muualta kopioitu lista käyttäytyy väärin paikassa, jota et ottanut huomioon.
Asiakaslohko on paikka, josta suurin osa tästä sekaannuksesta alkaa. Jaettu tunneli nimeää etäverkot, ja täystunneli on sama kenttä, jossa on oletusetuliite:
[Peer]
# split tunnel: only these networks
AllowedIPs = 10.77.0.0/24, 192.168.30.0/24
[Peer]
# full tunnel: everything, both families
AllowedIPs = 0.0.0.0/0, ::/0
Molemmat muodot ovat sinänsä täydellisiä, ja ne ovat vaihtoehtoja, eivät vaiheita. Ensimmäinen lähettää tunnelin läpi vain ne kaksi verkkoa; toinen lähettää jokaisen kohteen, ja merkintä ::/0 lisää IPv6:n IPv4-oletukseen. Kumman valitsetkin, nuo etuliitteet ovat koko reitityspäätös tälle vertaiskumppanille, kun wg-quick alkaa asentaa reittejä.
Keskittimellä on oltava eri lista
Keskitin luettelee jokaisen asiakkaan tunneliosoitteen isäntäetuliitteenä sekä jokaisen verkon, joka todella on kyseisen asiakkaan takana. Asiakkaan leveän listan kopioiminen jokaiseen keskittimen vertaiskumppaniin kertoo keskittimelle, että monet vertaiskumppanit voivat käyttää samoja osoitteita lähteenä, eikä se ole osoitesuunnitelma. Kenttä Endpoint kuuluu kokonaan toiselle kerrokselle: se nimeää vertaiskumppanin ulkoisen osoitteen ja portin, ei koskaan kohdetta tunnelin sisällä.
[Peer]
# laptop: tunnel address 10.77.0.2, office LAN behind it
AllowedIPs = 10.77.0.2/32, 192.168.30.0/24
Isäntäetuliite kantaa tunneliosoitteen ja verkkoetuliite sen, mikä on asiakkaan takana, ja molempia tarvitaan. Ilman isäntäetuliitettä keskitin ei voi palauttaa asiakkaan omaa liikennettä, ja ilman verkkoetuliitettä sen takana oleva LAN jää tavoittamattomaksi; vertaiskumppani, jonka takana ei ole mitään, saa vain isäntäetuliitteen.
Reittien asennuksen ohittaminen jättää aukon
wg-quick, apuri, joka nostaa rajapinnan kokoonpanotiedostosta, asentaa rajapinnan osoitteet ja reitit osana työtään. Table = off:n asettaminen käskee apuria ohittamaan reititystyön, mikä ei asenna korvaavia reittejä eikä tee yksityisverkkoa tavoitettavaksi. Kun automaattiset reitit hoitavat työn jo, tarvittavien etuliitteiden nimeäminen on selkeämpi kokoonpano. Reitityksen hallinnan sammuttaminen ja korvaavan reitin kirjoittamatta jättäminen ei ole suunnittelua, se on laiminlyönti.
Perustyökalu wg käyttäytyy toisin: se konfiguroi rajapinnan eikä koske reitteihin koskaan, joten suoraan sen päälle rakennettu asennus tarvitsee omat reittikäskynsä. Yhdelle työkalulle kirjoitetut ohjeet voivat näyttää vääriltä, kun niitä seurataan toisen kanssa. Onnistunut ping on myös heikko todiste, koska se testaa yhtä polkua eikä jokaista tarvitsemaasi sovelluksen polkua.
DNS ja IPv6 päätetään erikseen
Tarkista DNS-palvelimen osoite, jonka tunneli ilmoittaa, ja varmista, että valittujen etuliitteiden kautta on reitti siihen osoitteeseen. Resolverin asetus ei tee resolverista tavoitettavaa, ja tunnelin kaventaminen voi hiljaa poistaa reitin, joka sinne ennen johti. Tarkastele IPv6:ta myös erikseen, sillä oikea IPv4-jako ei kerro mitään IPv6-oletusreitistä, joka osoittaa edelleen fyysiseen linkkiin. Kolme erillistä päätöstä voi muuttua kerralla, kun muokkaat yhtä vertaiskumppanin lohkoa.
Avaa sitten yksi yksityinen resurssi ja yksi tavallinen verkkosivusto tunnetusta lähtökokoonpanosta. Jos resurssi vastaa ja selailu lähtee edelleen paikallisen yhteyden kautta, jako tekee sen, mitä pyysit. Jos selailu hajoaa samalla hetkellä, tunneli otti oletusreitin ja etuliiteluettelo on paikka, josta kannattaa katsoa.