Viena ierīce caur maršrutētāja VPN prasa trīs noteikumus, nevis slēdzi

Maršrutētāja VPN nav slēdža katrai ierīcei; slēdzis, ko meklējat, ir saīsne, kas jūsu vietā raksta politikas maršrutēšanas noteikumus. Brīdī, kad vienam klēpjdatoram, vienam portu diapazonam, vienam adrešu sarakstam vai vienam LAN segmentam jāizmanto tunelis, kamēr viss pārējais paliek WAN, jūs veidojat politikas maršrutu, nevis ieslēdzat funkciju. Darbam ir trīs kustīgas daļas, un katra sabojājas savādāk: atzīmēta tabula bez maršruta izskatās pēc klusuma, nepareizā ķēdē uzlikta atzīme izskatās tā, it kā nekas nav noticis, bet trūkstošs NAT noteikums izskatās pēc tuneļa, kas pieslēdzas un neko nepārvadā. Vēl divas daļas pazūd tāpēc, ka tās nekad neparādās mangle noteikumā, un tās ir DNS un IPv6.

Mīts: tunelis ir klienta iestatījums

VPN klients maršrutētāja pusē vienu rupju lietu dara labi: tas ievieto 0.0.0.0/0 galvenajā maršrutēšanas tabulā un vērš to uz tuneli. WireGuard to iegūst no AllowedIPs, OpenVPN bet no servera nosūtītā redirect-gateway, un abi maina ceļu katram resursdatoram aiz maršrutētāja. AllowedIPs sašaurināšana vai route-nopull pievienošana maina to, ko klients instalē. Tas nemaina to, uz ko instalācija attiecas, jo klients nekad neredz ierīces. Tas redz tikai paketes.

Atlase pēc avota vai galamērķa ir maršrutēšanas lēmums, tāpēc tā pieder maršrutētāja politikas slānim: mangle noteikums un otra tabula RouterOS, MARK un ip rule OpenWrt vai DD-WRT, vai ugunsmūra noteikums, kura vārteja ir tunelis, pfSense. Netgate WireGuard klienta recepte ir tā, kas jāizlasa pirms minēšanas, jo šajā platformā noteikuma vārtejai, interfeisa piešķiršanai un izejošā NAT ierakstam jāsaskan, pirms vienu klientu izmanto tunelis.

Mīta otrā puse ir otrais maršrutētājs. Citas kastes pirkšana vai ierīces pārvietošana uz viesu SSID bieži darbojas, un iemesls nav aparatūra: tā ievieto ierīci savā apakštīklā, kas dod avota selektoru, ko programmaparatūra jau saprot. Ja varat definēt šo segmentu savā maršrutētājā, papildu kaste atrisina problēmu, kuras jums nebija.

Pirmā daļa: tunelis, kas nav noklusējuma maršruts

RouterOS pievienojiet klientu bez noklusējuma maršruta un dodiet tunelim savu tabulu. Pirmais maršruts ir atzīmētais noklusējums; otrais ir kļūmes puse.

/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

Nesasniedzamais maršruts ir iemesls, kāpēc atzīmēta tabula pārspēj izņēmumu sarakstu galvenajā tabulā. Kad tunelis nokrīt, atzīmētās paketes uzreiz saņem nesasniedzamību, nevis klusi atgriežas WAN, tāpēc kļūme parādās lietojumprogrammas kļūdas ziņojumā, nevis ģeolokācijas lapā, ko pārbaudāt stundu vēlāk.

RouterOS 7 sadala to, ko 6.x turēja kopā: jūs deklarējat tabulu ar /routing table add name=vpn fib, pēc tam uz to atsaucaties pēc nosaukuma maršrutā un mangle noteikumā. 6.x fragments, kas raksta routing-mark, nedefinējot tabulu, ielādējas tīri un neatbilst nekam. Otrs klasiskais gadījums ir divas 0.0.0.0/1 puses vai divi noklusējumi vienā attālumā vienā tabulā: kodols izvēlas vienu, un uzvedība var mainīties pēc pārstartēšanas.

Otrā daļa: atzīmējiet pirms maršruta meklēšanas

Selektors izlemj, kuras paketes iekļūst šajā tabulā. RouterOS parasti sāk ar adrešu sarakstu galamērķa politikai vai avota adresi ierīces politikai:

/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

Linux programmaparatūra dara to pašu ar netfilter atzīmi un noteikumu, kas atzīmētās paketes virza uz tabulu, kuru jūs aizpildījāt:

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

Ķēde nav stila izvēle. Kad pakete sasniedz FORWARD, maršruta meklēšana jau ir notikusi, tāpēc MARK vai DROP tur var tikai pārrakstīt vai izmest. Atzīmei jānokļūst PREROUTING pārsūtītajai plūsmai un OUTPUT plūsmai, ko ģenerē pats maršrutētājs, un tur dzīvo maršrutētāja DNS, NTP un atjauninājumu pārbaudes. Šis izvades ceļš ir ierastais iemesls, kāpēc pilnībā tunelēta konfigurācija noplūdes testā joprojām atbild no ISP resolvera.

Ierīces politikai vajadzīga atbilstība, kas neizslīd. Rezervējiet adresi DHCP vai saskaņojiet interfeisu ar īpašu segmentu; adrese, kas vēlāk pāriet uz citu ierīci, klusi piemēro tuneli nepareizajam klientam. Tilts katram SSID ar savu apakštīklu ir izturīgākā tās pašas idejas versija, un tas dod vietu arī IPv6 noteikumiem.

Trešā daļa: NAT, DNS un LAN izņēmums

Plūsmai, kas iziet caur tuneli, vajadzīga avota adrese, uz kuru atbildēs otrā puse. Ierobežojiet tulkošanu ar tuneļa interfeisu: out-interface=VPN_NAME RouterOS, -o tun0 Linux, atbilstošs izejošā NAT ieraksts pfSense. Masquerade noteikums bez šī ierobežojuma pārraksta plūsmu, kuru gribējāt atstāt, un simptoms ir tas, ka ierīce bez tuneļa zaudē publisko adresi.

LAN izņēmums rada vairāk atbalsta pavedienu nekā pats tunelis. Ja atzīmētajā tabulā ir tikai noklusējuma maršruts, printera vai NAS galamērķis no atlasītās ierīces atbilst šim noklusējumam un pazūd tunelī. Pievienojiet LAN maršrutu tai pašai tabulai vai izslēdziet vietējo apakštīklu selektorā; abi darbojas, un izslēgšanu ir vieglāk noturēt pareizu, vēlāk pievienojot VLAN.

DNS iet atsevišķu ceļu. Vaicājumi, ko maršrutētājs pārsūta, ir maršrutētāja izcelsmes un seko OUTPUT, nevis pārsūtītajai atzīmei, tāpēc pilnībā tunelēts klēpjdators joprojām var atrisināt vārdus caur ISP. Virziet klientus uz resolveri, kas sasniedzams caur tuneli, vai atzīmējiet paša maršrutētāja port-53 plūsmu, pēc tam pārbaudiet atrisināto adresi, nevis pieņemiet, ka atbilde ceļoja kopā ar tīmekļa pieprasījumu.

Kad noteikums atbilst, bet lietotne joprojām izmanto WAN

Galamērķu saraksti noveco slikti. Vārds atrisinās uz adresi, kuras sarakstā nav, tāpēc pieprasījums iet caur WAN, kamēr katrs tests ar sarakstā esošo adresi darbojās. Atsvaidziniet sarakstu no tā paša resolvera, ko izmanto klients, un dodiet priekšroku avota balstītam selektoram, ja tiešām vēlaties visu plūsmu no vienas ierīces.

IPv6 ir klusā apiešana. Ierīcei ir otra adrešu saime ar savu noklusējuma maršrutu un savu noteikumu kopumu, un saskaņošana tikai ar IPv4 adresi ir puse politikas. Piemērojiet to pašu selektoru ip6tables vai nftables ekvivalentam, vai arī apzināti, nevis nejauši, atspējojiet IPv6 šajā segmentā.

Nodibinātie savienojumi arī svarīgi. Conntrack ieraksts, kas izveidots pirms izmaiņām, turpina sekot vecajam ceļam, līdz beidzas tā derīgums, tāpēc pārlūks, kas palika atvērts labošanas laikā, izskatās tieši kā noteikums, kas nekad netika piemērots. Atveriet jaunu savienojumu vai notīriet stāvokli, pirms vērtējat politiku.

Pārbaudiet ar divām ierīcēm un pārstartēšanu

Pārbaudiet ierīci, kurai jābūt tunelī, un ierīci, kurai nevajadzētu, un salīdziniet otro lēcienu, nevis ātruma skaitli. Traceroute no katras rāda tuneļa vārteju vai ISP vārteju otrajā lēcienā; ja abas izskatās vienādi, atzīme vai tabula nedara to, ko saka noteikums. Testam izmantojiet jaunus savienojumus.

Pēc tam pārstartējiet. Sāknēšanas secība ir vieta, kur strādājoša politika kļūst salauzta, jo klientam jābūt augšā, pirms tiek instalēts nesasniedzamais maršruts, un saglabāta momentuzņēmuma atjaunošana pārrakstīs jūsu tabulu. Pārbaudiet, vai katrs noteikums ir saglabātajā konfigurācijā un vai atzīmētais noklusējums pastāv pēc sāknēšanas, ne tikai pēc tam, kad to ierakstījāt.

Ja kaut kas neizdodas, vispirms noņemiet atzīmi un paskatieties, vai atgriežas normāla plūsma, tad noņemiet tabulu. Šī secība pasaka, vai dzenaties pēc maršrutēšanas vai ugunsmūra problēmas, un atstāj mājsaimniecībai strādājošu printeri, kamēr pabeidzat darbu.