Üks seade ruuteri VPN-i kaudu vajab kolme reeglit, mitte lülitit

Ruuteri VPN-il ei ole seadme kaupa lülitit; lüliti, mida otsite, on otsetee, mis kirjutab poliitikapõhised marsruutimisreeglid teie eest. Hetkel, mil üks sülearvuti, üks portide vahemik, üks aadresside loend või üks LAN-i segment peab kasutama tunnelit, samal ajal kui kõik muu jääb WAN-i, ehitate te poliitikamarsruuti, mitte ei lülita funktsiooni sisse. Tööl on kolm liikuvat osa ja igaüks neist ebaõnnestub erinevalt: marsruudita märgistatud tabel näeb välja nagu vaikus, valesse ahelasse pandud märge näeb välja nagu poleks midagi juhtunud, ja puuduv NAT-reegel näeb välja nagu tunnel, mis ühendub ja ei kanna midagi. Veel kaks osa kaob, sest need ei ilmu kunagi mangle-reeglisse, ja need on DNS ja IPv6.

Müüt: tunnel on kliendi seade

Ruuteripoolne VPN-klient teeb ühte jämedat asja hästi: paneb 0.0.0.0/0 põhimarsruutimistabelisse ja suunab selle tunnelisse. WireGuard tuletab selle AllowedIPs-ist, OpenVPN tõugatud redirect-gateway-st, ja mõlemad muudavad teed iga ruuteri taga oleva hosti jaoks. AllowedIPs-i kitsendamine või route-nopull-i lisamine muudab seda, mida klient paigaldab. See ei muuda seda, kelle kohta paigaldus kehtib, sest klient ei näe kunagi seadmeid. Ta näeb ainult pakette.

Allika või sihtkoha järgi valimine on marsruudimisotsus, seega kuulub see ruuteri poliitikakihile: mangle-reegel pluss teine tabel RouterOS-is, MARK pluss ip rule OpenWrt-is või DD-WRT-s, või tulemüürireegel, mille lüüs on tunnel, pfSense-is. Netgate'i WireGuard-kliendi retsept on see, mida tuleb enne oletamist lugeda, sest sellel platvormil peavad reegli lüüs, liidese määramine ja väljaminev NAT-kirje kõik kokku sobima, enne kui ükski klient tunnelit kasutab.

Müüdi teine pool on teine ruuter. Veel ühe karbi ostmine või seadme viimine külalis-SSID-ile töötab sageli, ja põhjus ei ole riistvara: see paneb seadme oma alavõrku, mis annab teile lähteselektori, millest püsivara juba aru saab. Kui saate selle segmendi oma ruuteril määratleda, lahendab lisakarp probleemi, mida teil ei olnud.

Esimene osa: tunnel, mis ei ole vaikemarsruut

RouterOS-is lisage klient ilma vaikemarsruudita ja andke tunnelile oma tabel. Esimene marsruut on märgistatud vaikemarsruut; teine on tõrke pool.

/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

Marsruut unreachable on põhjus, miks märgistatud tabel võidab põhitabelis oleva erandite loendi. Kui tunnel kukub, saavad märgistatud paketid kohe unreachable, selle asemel et vaikselt WAN-i tagasi langeda, nii et tõrge ilmub rakenduse veateates, mitte geolokatsiooni lehel, mida kontrollite tund hiljem.

RouterOS 7 eraldab selle, mida 6.x koos hoidis: te deklareerite tabeli käsuga /routing table add name=vpn fib ja viitate seejärel sellele nime järgi marsruudil ja mangle-reeglis. 6.x-i katkend, mis paneb routing-mark-i rea sisse ilma tabelit määratlemata, laadib puhtalt ja ei sobi millegagi. Teine klassikaline juht on kaks 0.0.0.0/1 poolt või kaks vaikemarsruuti samal kaugusel ühes tabelis: kernel valib ühe ja käitumine võib pärast taaskäivitust muutuda.

Teine osa: märgi enne marsruudiotsingut

Selektor otsustab, millised paketid sellesse tabelisse sisenevad. RouterOS alustab tavaliselt sihtpoliitika jaoks aadresside loendiga või seadme poliitika jaoks lähteaadressiga:

/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

Linuxi püsivara teeb sama netfilter-märgise ja reegliga, mis suunab märgistatud paketid tabelisse, mille te täitsite:

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

Ahel ei ole stiilivalik. Kui pakett jõuab FORWARD-i, on marsruudiotsing juba toimunud, nii et MARK või DROP seal saab ainult ümber kirjutada või kõrvale heita. Märgis peab langema PREROUTING-i edastatava liikluse jaoks ja OUTPUT-i liikluse jaoks, mille ruuter ise loob, sest seal elavad ruuteri DNS, NTP ja värskenduste kontrollid. Just see väljundtee on tavaline põhjus, miks täielikult tunnelisse pandud seadistus vastab lekketestis ikka ISP resolverist.

Seadmepoliitika vajab vastet, mis ei triivi. Reserveerige aadress DHCP-s või sobitage liides spetsiaalse segmendi jaoks; aadress, mis hiljem teisele seadmele liigub, rakendab tunneli vaikselt vale kliendi peal. Iga SSID-i sild oma alavõrguga on sama idee vastupidavam versioon ja annab IPv6 reeglitele koha, kus elada.

Kolmas osa: NAT, DNS ja LAN-i erand

Tunnelist väljuv liiklus vajab lähteaadressi, millele kaugpool vastab. Piirake tõlge tunneli liidesega: out-interface=VPN_NAME RouterOS-is, -o tun0 Linuxis, sobiv väljamineva NAT-i kirje pfSense-is. Masquerade-reegel ilma selle piiranguta kirjutab ümber liikluse, mille tahtsite rahule jätta, ja sümptom on see, et tunnelisse panemata seade kaotab oma avaliku aadressi.

LAN-i erand tekitab rohkem tugilõimesid kui tunnel ise. Kui märgistatud tabelis on ainult vaikemarsruut, sobib valitud seadmelt tulev printeri või NAS-i sihtkoht selle vaikeväärtusega ja kaob tunnelisse. Lisage LAN-i marsruut samasse tabelisse või jätke kohalik alavõrk selektoris välja; mõlemad töötavad ja erandit on hiljem VLAN-e lisades lihtsam korrektsena hoida.

DNS läheb eraldi teed. Päringud, mida ruuter edasi saadab, pärinevad ruuterist ja järgivad OUTPUT-i, mitte edastatavat märgist, nii et täielikult tunnelisse pandud sülearvuti saab ikka ISP kaudu nimesid lahendada. Suunake kliendid tunnelist kättesaadava resolveri poole või märgistage ruuteri enda pordi 53 liiklus, seejärel kontrollige lahendatud aadressi, selle asemel et eeldada, et vastus sõitis veebipäringuga kaasa.

Kui reegel sobib, aga rakendus kasutab ikka WAN-i

Sihtkoha loendid vananevad halvasti. Nimi lahendub aadressiks, mida loendis ei ole, nii et päring läheb WAN-i, samal ajal kui iga test, mille tegite loendis oleva aadressi vastu, töötas. Värskendage loendit samast resolverist, mida klient kasutab, ja eelistage allikapõhist selektorit, kui tõesti tahate kogu liiklust ühest seadmest.

IPv6 on vaikne möödaviik. Seadmel on teine aadressiperekond oma vaikemarsruudi ja oma reeglistikuga ning ainult IPv4 aadressi sobitamine on pool poliitikat. Rakendage sama selektorit ip6tables-ile või nftables-i vastele, või lülitage IPv6 selles segmendis teadlikult välja, mitte kogemata.

Kehtestatud ühendused loevad ka. Enne muudatust loodud conntrack-kirje järgib vana teed, kuni see aegub, nii et muutmise ajal lahti jäänud brauser näeb välja täpselt nagu reegel, mida kunagi ei rakendatud. Avage uus ühendus või tühjendage olek, enne kui poliitikat hindate.

Kontrollige kahe seadme ja taaskäivitusega

Testige seadet, mis peaks tunnelis olema, ja seadet, mis ei peaks, ning võrrelge teist hüpet kiirusnumbri asemel. Traceroute kummastki näitab teisel hüppel kas tunneli lüüsi või ISP lüüsi; kui mõlemad näevad ühesugused välja, ei tee märgis ega tabel seda, mida reegel ütleb. Kasutage testiks uusi ühendusi.

Seejärel taaskäivitage. Käivitamise järjekord on koht, kus töötav poliitika muutub katkiseks, sest klient peab olema üleval enne, kui unreachable marsruut paigaldatakse, ja salvestatud hetktõmmis, mis taastab vana reeglistiku, kirjutab teie tabeli üle. Kontrollige, et iga reegel on salvestatud konfiguratsioonis ja märgistatud vaikemarsruut on olemas pärast alglaadimist, mitte ainult pärast seda, kui te selle sisestasite.

Kui midagi ebaõnnestub, eemaldage esmalt märgis ja vaadake, kas tavaline liiklus taastub, seejärel eemaldage tabel. See järjekord ütleb teile, kas jälitate marsruudimis- või tulemüüriprobleemi, ja jätab majapidamise töötava printeriga, samal ajal kui te töö lõpetate.