WireGuardin täystunneli: AllowedIPs 0.0.0.0/0 ei riitä

Kun 0.0.0.0/0, ::/0 on verrokin AllowedIPs-kentässä, kyse on vaiheesta, jonka kaikki muistavat, ja se päättää vain siitä, mitä liikennettä verrokki saa kuljettaa. Nämä etuliitteet eivät luo reittejä, eivät välitä mitään toisella puolella eivätkä koske sovellusten nimipalvelimeen. Neljän erillisen asian on oltava totta samaan aikaan, jotta täystunneli olisi täystunneli, ja ne kannattaa tarkistaa alla olevassa järjestyksessä, koska myöhempi tarkistus ei voi pelastaa aiempaa. Jokainen alla oleva tarkistus on tosiasia, jonka voi lukea koneesta, ei asetus, jonka toivot tulleen käyttöön.

Mitä verrokin etuliite valitsee ja mitä ei

AllowedIPs on samalla sekä valitsin että valtuutus. Se kertoo paikalliselle puolelle, mitä kohteita tälle verrokille saa lähettää, ja vastaanottavalle puolelle, mitä lähdeosoitteita tämä verrokki saa esittää. Siinä on koko työ. Mikään tässä kuvauksessa ei luo reittiä isäntään, ota välitystä käyttöön etäpuolella eikä koske nimien selvitykseen.

Siksi kokoonpano voi näyttää valmiilta ja käyttäytyä kuin jaettu tunneli. Etuliite sanoo, että verrokki hyväksyisi kaiken; isännän reititystaulu päättää, mitä sinne todella saapuu, ja yhdyskäytävä päättää, lähteekö mitään. Mikään näistä kolmesta päätöksestä ei elä verrokin lohkossa.

Reititä asiakas, älä vain verrokkiluetteloa

Hallinnat kuten wg-quick ohjelmoivat isännän reititystaulun puolestasi, minkä vuoksi kaksi samanlaista kokoonpanotiedostoa käyttäytyy eri tavoin riippuen siitä, miten liitäntä nousi. Minimaalinen profiili on riittävän lyhyt luettavaksi yhdellä kertaa:

[Interface]
Address = 10.8.0.2/32
DNS = 10.8.0.1

[Peer]
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = vpn.example.net:51820

Työtä kantaa kaksi yksityiskohtaa. Kenttä Address on yksi isännän etuliite, ei aliverkko, jonka asiakas luulee omistavansa, ja hallinta on se, joka muuntaa oletus-AllowedIPs:n todelliseksi oletusreitiksi. Nosta sama tiedosto komennolla ip link ja wg setconf ja reittejä ei ilmesty lainkaan, mikä näyttää rikkinäiseltä tunnelilta ja on itse asiassa terve tunneli, josta reititysvaihe on jätetty väliin. wg-quick käsikirja dokumentoi reitityksen ja Table käyttäytymisen, jonka nämä hallinnat lisäävät.

Lue tulos tiedoston sijaan: ip route get 1.1.1.1 pitäisi nimetä tunnelin liitäntä ja wg show pitäisi raportoida tuore kättely, jonka siirtolaskuri liikkuu. Kättely ilman reittiä tarkoittaa, että hallinta ei koskaan ajanut, eikä profiilin muokkaaminen uudelleen korjaa sitä. Käynnistä liitäntä niin kuin käyttäjä sen käynnistää, muuten testi mittaa sinun komentotulkkiasi käyttöönoton sijaan.

Päätepisteen pitäminen tunnelin ulkopuolella

Täystunneli kaappaa jokaisen kohteen, myös sen, jonka kanssa sen on puhuttava ollakseen olemassa. Hallinnat hoitavat tämän lisäämällä päätepisteelle isäntäreitin alkuperäisen yhdyskäytävän kautta, minkä vuoksi oikea kokoonpano sisältää lähes aina yhden tarkoituksellisen poikkeuksen. Kokoonpanon puolen käyttäminen hallinnalla ja toisen puolen käsin on tavallinen tapa, jolla tämä poikkeus katoaa.

Jos päätepiste on isäntänimi, joka selviää useaksi osoitteeksi tai perheeksi, jota et kuljeta, poikkeus vanhenee huonosti ja tunneli voi epäonnistua rutiinilta näyttäneen uudelleenyhdistämisen jälkeen. Kiinnitä päätepiste osoitteeseen, jota hallitset, tai varmista, että hallinta arvioi sen uudelleen, ja lue isäntäreitti uudelleen jokaisen verkkomuutoksen jälkeen.

Sama mekanismi selittää, miksi täystunneli ja captive-portaali riitelevät. Portaali odottaa sieppaavansa liikennettä, jonka tunnelisi nyt kaappaa, joten hotelli- ja lentoasemaverkoissa nostat tunnelin portaalin kirjautumisen jälkeen, et koskaan ennen sitä.

Välitys ja paluupolku yhdyskäytävällä

Ota yhdyskäytävällä käyttöön välitys sille perheelle, jota kuljetat, salli forward-ketju molempiin suuntiin, kun käännät, ja varmista paluupolku lähteeseen sidotulla haulla. Mikään tästä ei seuraa onnistuneesta kättelystä, koska kättely todistaa vain, että kaksi verrokkia voi vaihtaa UDP:tä. Se ei kerro mitään siitä, mitä purkautuneelle paketille tapahtuu sen jälkeen.

sysctl net.ipv4.ip_forward net.ipv6.conf.all.forwarding
ip route get 1.1.1.1 from 10.8.0.2

Haku ajetaan yhdyskäytävällä eikä asiakkaalla, muuten luet toista reititystaulua. Jos se nimeää väärän liitännän tai ilmoittaa, ettei reittiä ole, yksikään asiakaspuolen muutos ei tuota internet-uloskäyntiä. Kun yhdyskäytävä kääntää asiakkaiden osoitteita ulospäin, vastaus riippuu tästä käännöstilasta, joten säännön on oltava olemassa virran molemmille suunnille, ei vain lähtevälle.

DNS ja vikatila, erikseen testattuna

Protokolla itse ei määritä minkään sovelluksen nimipalvelinta. wg-quick soveltaa rivin DNS jakelun nimipalvelinintegroinnin kautta, kontit ja selaimet omilla pinoillaan voivat jättää sen huomiotta, ja siksi nimi voi epäonnistua samalla kun tunneli kuljettaa paketteja moitteettomasti. Testaa isäntänimellä osoitteen sijaan ja kirjaa ylös, mikä palvelin vastasi sen sijaan, että olettaisit profiilissa olevan vastanneen.

Osoiteperheet ovat erillinen testi erillisellä vastauksella. v4-oletusreitti ei kerro mitään siitä, mitä sovelluksen v6-yhteys tekee, ja tunneli, joka vuotaa toisen perheen hiljaa, on huonompi kuin se, joka epäonnistuu äänekkäästi. Kysy nimeä jokaisen perheen kautta, lue liitäntä, jota jokainen pyyntö käytti, ja tarkista käännöslaskurit ennen ja jälkeen, koska sääntö, joka ei vastaa mitään, näyttää samalta kuin puuttuva sääntö.

Testaa lopuksi tila, jonka haluat tunnelin pysähtyessä. Täystunnelin pitäisi epäonnistua suljetusti sen väittämälle liikenteelle: jos liitäntä putoaa ja sovellukset jatkavat hiljaa fyysisen linkin kautta, suunnittelu on jaettu tunneli lisävaiheilla. Kirjoita aiottu vikakäyttäytyminen ylös, tarkista se tarkoituksella ja lopeta kirjaamalla neljä vastausta — mikä hallinta nostaa liitännän, mikä reitti kantaa oletuksen, kuka välittää ja kääntää yhdyskäytävällä, ja mikä nimipalvelin vastaa.