Yksi laite reitittimen VPN:n läpi tarvitsee kolme sääntöä, ei kytkintä

Reitittimen VPN:ssä ei ole laitekohtaista kytkintä; etsimäsi kytkin on pikatie, joka kirjoittaa käytäntöpohjaiset reitityssäännöt puolestasi. Heti kun yhden kannettavan, yhden porttialueen, yhden osoiteluettelon tai yhden LAN-segmentin on käytettävä tunnelia, kun kaikki muu pysyy WANissa, rakennat käytäntöreittiä etkä ota ominaisuutta käyttöön. Työssä on kolme liikkuvaa osaa, ja jokainen epäonnistuu eri tavalla: merkitty taulu ilman reittiä näyttää hiljaisuudelta, väärään ketjuun laitettu merkki näyttää siltä, ettei mitään tapahtunut, ja puuttuva NAT-sääntö näyttää tunnelilta, joka yhdistyy eikä kanna mitään. Kaksi osaa puuttuu lisää, koska ne eivät koskaan esiinny mangle-säännössä, ja ne ovat DNS ja IPv6.

Myytti: tunneli on asiakasasetus

Reitittimen puoleinen VPN-asiakas tekee yhden karkean asian hyvin: se laittaa 0.0.0.0/0 pääreititystauluun ja osoittaa sen tunneliin. WireGuard johtaa sen AllowedIPsistä, OpenVPN työnnetystä redirect-gatewaystä, ja molemmat muuttavat polun jokaiselle reitittimen takana olevalle isännälle. AllowedIPsin kaventaminen tai route-nopullin lisääminen muuttaa sitä, mitä asiakas asentaa. Se ei muuta sitä, ketä asennus koskee, koska asiakas ei koskaan näe laitteita. Se näkee vain paketteja.

Valinta lähteen tai kohteen mukaan on reitityspäätös, joten se kuuluu reitittimen käytäntökerrokseen: mangle-sääntö ja toinen taulu RouterOSissa, MARK ja ip rule OpenWrt:ssä tai DD-WRT:ssä, tai palomuurisääntö, jonka yhdyskäytävä on tunneli, pfSensessä. Netgaten WireGuard-asiakasohje on se, joka kannattaa lukea ennen arvaamista, koska sillä alustalla säännön yhdyskäytävän, liitännän kohdistuksen ja lähtevän NAT-merkinnän on kaikkien sovittava ennen kuin yksikään asiakas käyttää tunnelia.

Myytin toinen puoli on toinen reititin. Toisen laatikon ostaminen tai laitteen siirtäminen vieras-SSID:lle toimii usein, eikä syy ole laitteisto: se siirtää laitteen omaan aliverkkoonsa, mikä antaa sinulle lähdevalitsimen, jonka laiteohjelmisto jo ymmärtää. Jos voit määritellä sen segmentin omistamassasi reitittimessä, ylimääräinen laatikko ratkaisee ongelman, jota sinulla ei ollut.

Osa yksi: tunneli, joka ei ole oletusreitti

Lisää RouterOSissa asiakas ilman oletusreittiä ja anna tunnelille oma taulu. Ensimmäinen reitti on merkitty oletus; toinen on epäonnistumisen puoli.

/ip route add dst-address=0.0.0.0/0 gateway=VPN_GATEWAY_IP routing-mark=vpn distance=1
/ip route add dst-address=0.0.0.0/0 type=unreachable routing-mark=vpn distance=2

Reitti unreachable on syy siihen, miksi merkitty taulu voittaa päätäulun poikkeusluettelon. Kun tunneli putoaa, merkityt paketit saavat heti unreachablen sen sijaan, että ne luisuisivat hiljaa takaisin WANiin, joten vika näkyy sovelluksen virheilmoituksessa eikä geolokaatiosivulla, jota tarkistat tuntia myöhemmin.

RouterOS 7 erottaa sen, mitä 6.x piti yhdessä: taulun ilmoitat komennolla /routing table add name=vpn fib ja viittaat siihen sitten nimellä reitillä ja mangle-säännössä. 6.x:n katkelma, joka laittaa routing-markin rivinsisäisesti määrittelemättä taulua, latautuu puhtaasti eikä vastaa mitään. Toinen klassikko on kaksi 0.0.0.0/1-puoliskoa tai kaksi oletusreittiä samalla etäisyydellä yhdessä taulussa: ydin valitsee yhden, ja käyttäytyminen voi muuttua uudelleenkäynnistyksen jälkeen.

Osa kaksi: merkitse ennen reittihakua

Valitsin päättää, mitkä paketit tulevat siihen tauluun. RouterOS aloittaa yleensä osoiteluettelolla kohdekäytäntöä varten tai lähdeosoitteella laitekäytäntöä varten:

/ip firewall mangle add chain=prerouting src-address=192.168.88.50 action=mark-routing new-routing-mark=vpn
/ip firewall mangle add chain=prerouting dst-address-list=via-vpn action=mark-routing new-routing-mark=vpn
/ip firewall address-list add list=via-vpn address=203.0.113.10

Linuxin laiteohjelmisto tekee saman netfilter-merkillä ja säännöllä, joka ohjaa merkityt paketit täyttämääsi tauluun:

iptables -t mangle -A PREROUTING -p tcp --dport 27000:27050 -j MARK --set-mark 0x200
ip route add default dev tun0 table 100
ip rule add fwmark 0x200 table 100

Ketju ei ole tyylivalinta. Kun paketti saapuu FORWARDiin, reittihaku on jo tapahtunut, joten MARK tai DROP siellä voi vain kirjoittaa uudelleen tai hylätä. Merkin on osuttava PREROUTINGiin välitetylle liikenteelle ja OUTPUTiin liikenteelle, jonka reititin itse luo, sillä siellä elävät reitittimen DNS, NTP ja päivitystarkistukset. Juuri tämä lähtöpolku on tavallinen syy siihen, että täysin tunnelioitu asetelma vastaa vuototestissä yhä ISP:n resoluuterilta.

Laitekäytäntö tarvitsee osuman, joka ei ajelehtii. Varaa osoite DHCP:ssä tai sovita liitäntä omaan segmenttiin; osoite, joka myöhemmin siirtyy toiselle laitteelle, soveltaa tunnelia hiljaa väärään asiakkaaseen. Jokaiselle SSID:lle oma silta aliverkkoineen on saman idean kestävämpi versio, ja se antaa IPv6-säännöille paikan elää.

Osa kolme: NAT, DNS ja LAN-poikkeus

Tunnelista lähtevä liikenne tarvitsee lähdeosoitteen, johon kaukopää vastaa. Rajaa käännös tunnelin liitäntään: out-interface=VPN_NAME RouterOSissa, -o tun0 Linuxissa, vastaava lähtevän NAT:n merkintä pfSensessä. Masquerade-sääntö ilman tätä rajausta kirjoittaa uudelleen liikennettä, jonka halusit jättää rauhaan, ja oireena on, että tunnelioimaton laite menettää julkisen osoitteensa.

LAN-poikkeus aiheuttaa enemmän tukiketjuja kuin itse tunneli. Jos merkityssä taulussa on vain oletusreitti, valitun laitteen tulostin- tai NAS-kohde osuu tuohon oletukseen ja katoaa tunneliin. Lisää LAN-reitti samaan tauluun tai sulje paikallinen aliverkko pois valitsimesta; molemmat toimivat, ja poikkeus on helpompi pitää oikeana, kun myöhemmin lisäät VLANeja.

DNS kulkee eri polkua. Kyselyt, jotka reititin välittää, ovat lähtöisin reitittimestä ja seuraavat OUTPUTia, eivät välitysmerkkiä, joten täysin tunnelioitu kannettava voi yhä ratkaista ISP:n kautta. Ohjaa asiakkaat tunnelin kautta tavoitettavaan resoluuteriin tai merkitse reitittimen oma portin 53 liikenne, ja tarkista sitten ratkaistu osoite sen sijaan, että olettaisit vastauksen matkustaneen verkkopyynnön mukana.

Kun sääntö osuu, mutta sovellus käyttää yhä WANia

Kohdeluettelot vanhenevat huonosti. Nimi ratkeaa osoitteeksi, joka ei ole luettelossa, joten pyyntö ottaa WANin, vaikka jokainen luetteloituun osoitteeseen tekemäsi testi toimi. Päivitä luettelo samasta resoluuterista, jota asiakas käyttää, ja suosi lähdepohjaista valitsinta, kun todella haluat kaiken liikenteen yhdestä laitteesta.

IPv6 on hiljainen ohitus. Laitteella on toinen osoiteperhe omalla oletusreitillään ja omalla sääntöjoukollaan, ja vain IPv4-osoitteen sovittaminen on puoli käytäntöä. Sovella sama valitsin ip6tablesiin tai nftablesin vastineeseen tai poista IPv6 käytöstä siinä segmentissä tarkoituksella, ei vahingossa.

Muodostetut yhteydetkin merkitsevät. Ennen muutosta luotu conntrack-merkintä seuraa vanhaa polkua, kunnes se vanhenee, joten muokkauksen aikana auki jäänyt selain näyttää täsmälleen säännöltä, jota ei koskaan sovellettu. Avaa uusi yhteys tai tyhjennä tila ennen kuin arvioit käytäntöä.

Varmista kahdella laitteella ja uudelleenkäynnistyksellä

Testaa laite, jonka pitäisi olla tunnelissa, ja laite, jonka ei pitäisi, ja vertaa toista hyppyä nopeusluvun sijaan. Traceroute kummastakin näyttää toisella hypyllä joko tunnelin yhdyskäytävän tai ISP:n yhdyskäytävän; jos molemmat näyttävät samalta, merkki tai taulu ei tee sitä, mitä sääntö sanoo. Käytä testiin uusia yhteyksiä.

Käynnistä sitten uudelleen. Käynnistysjärjestys on paikka, jossa toimivasta käytännöstä tulee rikkinäinen, koska asiakkaan on oltava käynnissä ennen kuin unreachable-reitti asennetaan, ja tallennettu tilannekuva, joka palauttaa vanhan sääntöjoukon, kirjoittaa taulusi yli. Tarkista, että jokainen sääntö on tallennetussa kokoonpanossa ja että merkitty oletus on olemassa käynnistyksen jälkeen, ei vain sen jälkeen kun kirjoitit sen.

Jos jokin epäonnistuu, poista ensin merkki ja katso palaako normaali liikenne, poista sitten taulu. Tämä järjestys kertoo, jahtaatko reititysongelmaa vai palomuuriongelmaa, ja se jättää talouden toimivan tulostimen kanssa, kun viimeistelet työn.