IPv6:n estäminen WireGuardin suojaamiseksi rikkoo isäntää

Tavoite on järkevä: vain tunnelin käyttäjien pitäisi päästä tämän koneen palveluihin. Ratkaisu, johon ihmiset tarttuvat, on IPv6-syöteketju, joka hylkää kaiken paitsi WireGuardin, ja se hylkää myös liikenteen, joka pitää isännän omalla linkillään. Naapurien löytäminen ja polun ylläpitoviestit eivät ole palvelun käyttöä, ja niiden poistaminen tuottaa koneen, joka on tavoittamaton syistä, joilla ei ole mitään tekemistä käytäntösi kanssa. Tunneli nousee, palvelut on rajattu oikein, eikä mikään muu linkillä toimi.

Kolme vastuuta, yksi sääntökokonaisuus

Ensimmäinen vastuu on ulkoverkon toiminta: isännän on pysyttävä linkillään, ratkaistava naapurit ja opittava kyseisen linkin polun rajat. Toinen on salattu kuuntelija, joka ottaa UDP:n vastaan valitsemallasi osoitteella ja portilla. Kolmas on joukko puretun salauksen palveluja, joihin haluat tunnelin käyttäjien pääsevän.

Kyse on kolmesta eri käytännöstä, ja vain toinen ja kolmas liittyvät VPN:ään. Sääntökokonaisuus, joka kohtelee niitä yhtenä, perii vikamuodon, jossa sovellusrajan kiristäminen rikkoo isännän liittymän hiljaa.

Pidä ne erillisissä ketjuissa tai ainakin erillisissä kommenteissa, jotta seuraava henkilö näkee, mikä rivi on olemassa mistä syystä.

Mitä ICMPv6 tekee isännälle

IPv6 nojaa ICMPv6:een paljon muuhunkin kuin kaikuun. Naapuripyyntö ja -ilmoitus korvaavat ARP:n ja ovat välttämättömiä paikalliselle toimitukselle. Packet Too Big kuljettaa polun MTU-tietoa, ja sen huomiotta jättäminen tuottaa siirtoja, jotka pysähtyvät suurilla paketeilla. Reitittimen ilmoitukset kuljettavat oletusreitin ja etuliitetiedon, kun linkki käyttää automaattista määritystä.

RFC 4890 erottaa viestit, jotka isäntäsuodattimen on sallittava, niistä, jotka ovat hallinnollinen valinta, ja tekee sen isäntää koskevassa osassa, joka eroaa verkkojen välillä välittävän reitittimen säännöistä. Pelkän välitysosan lukeminen tuottaa syötekäytännön, joka on suojattavalle isännälle liian tiukka.

Käytännön sääntö on sallia olennaiset virhe- ja määritysviestit rajapinnalla, joka niitä tarvitsee, tyypin ja lähteen mukaan rajattuna siellä missä alusta sen sallii, ja päättää lopuista nimenomaisesti.

Kaiken tuon korvaaminen yleisellä ICMPv6-luvalla ratkaisee saatavuusongelman ja luopuu suodatuksesta. Sen korvaaminen yleisellä hylkäyksellä ratkaisee suodatusongelman ja luopuu isännästä.

Päästä ensin tunneli, sitten palvelu

Hyväksy WireGuardin kuljetus aiotulla ulkoisella osoitteella ja UDP-portilla sekä paluuliikenne yhteyksien seurannan kautta. Salli sitten sovelluspalvelut tunnelirajapinnan kautta niistä lähteistä, jotka todella valtuutat.

Ulkoisen UDP-portin lupa ei valtuuta sen sisällä olevia puretun salauksen pyyntöjä. Juuri tämä ero on koko syy siihen, miksi tunnelirajapinta esiintyy palvelusäännöissä.

Lue sääntökokonaisuus sellaisena kuin se on, ei sellaisena kuin tiedosto sen kuvaa:

sudo nft list ruleset
ip -6 addr show
ip -6 route show default

Fyysisellä osoitteella kuunteleva on erillinen altistus samasta palvelusta tunneliosoitteella. Jos kone välittää liikennettä myös toiselle koneelle, se on välitysketjun päätös eikä tämä syötekäytäntö, ja se vaatii oman perustelunsa.

Testaa linkkiä, älä vain tunnelia

Muutoksen jälkeen toimiva tunneli todistaa vähemmän kuin näyttää, koska olemassa oleva naapurimerkintä ja muodostettu yhteys voivat piilottaa ohjausviestin, jonka käytäntö nyt hylkää.

Tarkista liittyminen suoraan ja tarkista sitten, että poissuljettu polku edelleen epäonnistuu:

ip -6 neigh show
ping -6 -c 3 2001:db8:1::1
sudo nft -c -f /etc/nftables.conf

Naapuritaulu, joka pysyy täydellisenä uudelleenkäynnistyksen jälkeen, on merkki siitä, että löytäminen toimii edelleen. Taulu, joka tyhjenee eikä koskaan täyty uudelleen, on merkki siitä, että suodatit sen pois. Kolmas komento validoi sääntökokonaisuuden syntaksin soveltamatta sitä, mikä kannattaa tehdä, kun sinulla on vielä istunto.

Palauta isäntä, jonka ulkopuolelle lukitsit itsesi

Ennen kuin muutat palomuurisääntöjä, jotka kuljettavat omaa hallintayhteyttäsi, pidä toinen kanava: konsoli, sarjayhteys tai ajastettu palautus, joka poistaa uudet säännöt, jos et peru sitä.

Jos muutos silti lukitsee sinut ulos, palautus tapahtuu tuon kanavan kautta eikä juuri poistamasi verkon kautta. Palauta edellinen sääntökokonaisuus tallennetusta kopiosta, varmista että isäntä on taas tavoitettavissa ja sovella vasta sitten aiottu käytäntö pienemmissä osissa.

Lopullinen käytäntö ei ole yleispätevä. Osoitteistus, reititys ja palomuurin toteutus ovat käyttöönoton syötteitä, mutta raja on kaikkialla sama: kiellä tahaton sovelluskäyttö ja säilytä ohjausliikenne, joka kuljettaa valtuutetun tunnelin.