Një pajisje përmes VPN-së së routerit kërkon tre rregulla, jo një çelës

Në një VPN routeri nuk ka çelës për çdo pajisje; çelësi që po kërkoni është një shkurtore që shkruan rregulla routing politike në emrin tuaj. Në momentin kur një laptop, një interval portash, një listë adresash ose një segment LAN duhet të përdorë tunelin ndërsa çdo gjë tjetër mbetet në WAN, ju po ndërtoni një rrugë politike dhe nuk po aktivizoni një veçori. Puna ka tre pjesë lëvizëse dhe secila dështon në mënyrë të ndryshme: një tabelë e shënuar pa rrugë duket si heshtje, një shenjë e vendosur në zinxhirin e gabuar duket sikur nuk ndodhi asgjë, dhe një rregull NAT që mungon duket si një tunel që lidhet dhe nuk transporton asgjë. Edhe dy pjesë humbasin sepse nuk shfaqen kurrë në rregullin mangle, dhe ato janë DNS dhe IPv6.

Miti: tuneli është një cilësim i klientit

Një klient VPN në anën e routerit bën mirë një gjë të vrazhdë: vendos 0.0.0.0/0 në tabelën kryesore të routing dhe e drejton drejt tunelit. WireGuard e nxjerr këtë nga AllowedIPs, OpenVPN dhe OpenVPN nga një redirect-gateway që shtyhet nga serveri, dhe të dyja ndryshojnë rrugën për çdo host pas routerit. Ngushtimi i AllowedIPs ose shtimi i route-nopull ndryshon atë që instalon klienti. Nuk ndryshon se kujt i zbatohet instalimi, sepse klienti nuk i sheh kurrë pajisjet. Ai sheh vetëm paketa.

Zgjedhja sipas burimit ose destinacionit është një vendim routing, prandaj i përket shtresës së politikës së routerit: një rregull mangle plus një tabelë e dytë në RouterOS, një MARK plus një ip rule në OpenWrt ose DD-WRT, ose një rregull firewall, gateway-i i të cilit është tuneli, në pfSense. Receta e klientit WireGuard të Netgate është ajo që duhet lexuar përpara se të hamendësoni, sepse në atë platformë gateway-i i rregullit, caktimi i ndërfaqes dhe zëri i NAT-së dalëse duhet të bien dakord përpara se një klient të vetëm të përdorë tunelin.

Gjysma tjetër e mitit është routeri i dytë. Blerja e një kutie tjetër, ose kalimi i pajisjes në një SSID mysafirësh, shpesh funksionon, dhe arsyeja nuk është hardueri: e vendos pajisjen në nënrrjetin e vet, që ju jep zgjedhësin e burimit që firmware-i tashmë e kupton. Nëse mund ta përcaktoni atë segment në routerin tuaj, kutia shtesë zgjidh një problem që nuk e kishit.

Pjesa e parë: një tunel që nuk është rruga e parazgjedhur

Në RouterOS shtoni klientin pa rrugë të parazgjedhur dhe jepini tunelit tabelën e vet. Rruga e parë është e parazgjedhura e shënuar; e dyta është gjysma e dështimit.

/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

Rruga e paarritshme është arsyeja pse një tabelë e shënuar mund një listë përjashtimesh në tabelën kryesore. Kur tuneli bie, paketat e shënuara marrin menjëherë të paarritshme në vend që të kthehen në heshtje në WAN, kështu që dështimi shfaqet në mesazhin e gabimit të aplikacionit dhe jo në një faqe gjeolokacioni që e kontrolloni një orë më vonë.

RouterOS 7 ndan atë që 6.x mbante bashkë: tabelën e shpallni me /routing table add name=vpn fib, pastaj i referoheni me emër në rrugë dhe në rregullin mangle. Një fragment 6.x që shkruan routing-mark pa përcaktuar tabelën ngarkohet pastër dhe nuk përputhet me asgjë. Klassiku tjetër janë dy gjysma 0.0.0.0/1, ose dy të parazgjedhura në të njëjtën distancë në një tabelë: kerneli zgjedh njërën, dhe sjellja mund të ndryshojë pas një rindezjeje.

Pjesa e dytë: shënoni përpara kërkimit të rrugës

Zgjedhësi vendos cilat paketa hyjnë në atë tabelë. RouterOS zakonisht fillon me një listë adresash për politikën e destinacionit, ose me një adresë burimi për politikën e pajisjes:

/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

Firmware-i Linux bën të njëjtën gjë me një shenjë netfilter dhe një rregull që i drejton paketat e shënuara në një tabelë që e keni mbushur:

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

Zinxhiri nuk është zgjedhje stili. Kur një paketë arrin FORWARD, kërkimi i rrugës ka ndodhur tashmë, kështu që një MARK ose DROP atje mund vetëm të rishkruajë ose të hedhë. Shenja duhet të bjerë në PREROUTING për trafikun e përcjellë dhe në OUTPUT për trafikun që routeri vetë krijon, ku jetojnë DNS, NTP dhe kontrollet e përditësimit të routerit. Ai rrugë dalëse është arsyeja e zakonshme pse një konfigurim plotësisht i tunelizuar ende përgjigjet nga resolver-i i ISP-së në një test rrjedhjeje.

Politika e pajisjes kërkon një përputhje që nuk rrëshqet. Rezervoni adresën në DHCP, ose përputhni një ndërfaqe për një segment të dedikuar; një adresë që më vonë kalon në një pajisje tjetër zbaton në heshtje tunelin te klienti i gabuar. Një urë për çdo SSID me nënrrjet të vet është versioni më i qëndrueshëm i së njëjtës ide, dhe u jep edhe rregullave IPv6 një vend ku të jetojnë.

Pjesa e tretë: NAT, DNS dhe përjashtimi i LAN

Trafiku që del përmes tunelit ka nevojë për një adresë burimi të cilës ana tjetër do t'i përgjigjet. Kufizojeni përkthimin te ndërfaqja e tunelit: out-interface=VPN_NAME në RouterOS, -o tun0 në Linux, një zë NAT dalëse përputhës në pfSense. Një rregull masquerade pa atë kufizim rishkruan trafikun që kishit ndërmend ta linin të qetë, dhe simptoma është që pajisja jashtë tunelit humbet adresën publike.

Përjashtimi i LAN shkakton më shumë tema mbështetjeje sesa vetë tuneli. Nëse tabela e shënuar mban vetëm një rrugë të parazgjedhur, një destinacion printeri ose NAS nga pajisja e zgjedhur përputhet me atë të parazgjedhur dhe zhduket në tunel. Shtoni rrugën LAN në të njëjtën tabelë, ose përjashtoni nënrrjetin lokal në zgjedhës; të dyja funksionojnë, dhe përjashtimi është më i lehtë për t'u mbajtur saktë kur shtoni VLAN më vonë.

DNS merr një rrugë të veçantë. Kërkesat që routeri përcjell vijnë nga routeri dhe ndjekin OUTPUT, jo shenjën e përcjellë, kështu që një laptop plotësisht i tunelizuar ende mund të zgjidhë emra përmes ISP-së. Drejtojini klientët drejt një resolver-i të arritshëm përmes tunelit, ose shënoni trafikun port-53 të vetë routerit, pastaj kontrolloni adresën e zgjidhur në vend që të supozoni se përgjigja udhëtoi bashkë me kërkesën web.

Kur rregulli përputhet por aplikacioni ende përdor WAN-in

Listat e destinacioneve plaken keq. Një emër zgjidhet në një adresë që nuk është në listë, kështu që kërkesa merr WAN-in ndërsa çdo test që bëtë në adresën e listuar funksiononte. Rifreskoni listën nga i njëjti resolver që përdor klienti, dhe preferoni një zgjedhës të bazuar në burim kur vërtet dëshironi të gjithë trafikun nga një pajisje.

IPv6 është anashkalimi i heshtur. Pajisja ka një familje të dytë adresash me rrugën e vet të parazgjedhur dhe grupin e vet të rregullave, dhe përputhja vetëm me adresën IPv4 është gjysma e politikës. Zbatoni të njëjtin zgjedhës në ip6tables ose në ekuivalentin nftables, ose çaktivizoni IPv6 në atë segment me qëllim dhe jo rastësisht.

Lidhjet e vendosura gjithashtu kanë rëndësi. Një zë conntrack i krijuar përpara ndryshimit vazhdon të ndjekë rrugën e vjetër derisa të skadojë, kështu që një shfletues që mbeti i hapur gjatë redaktimit duket saktësisht si një rregull që nuk u zbatua kurrë. Hapni një lidhje të re, ose pastroni gjendjen, përpara se ta gjykoni politikën.

Verifikoni me dy pajisje dhe një rindezje

Testoni pajisjen që duhet të jetë në tunel dhe pajisjen që nuk duhet, dhe krahasoni hopin e dytë në vend të një numri shpejtësie. Një traceroute nga secila tregon ose gateway-in e tunelit ose gateway-in e ISP-së në hopin e dytë; nëse të dyja duken njësoj, shenja ose tabela nuk po bën atë që thotë rregulli. Për testin përdorni lidhje të reja.

Pastaj rindizeni. Rendi i nisjes është vendi ku një politikë funksionuese prishet, sepse klienti duhet të jetë lart përpara se rruga e paarritshme të instalohet, dhe një snepshote e ruajtur që rikthen grupin e vjetër të rregullave do të mbishkruajë tabelën tuaj. Kontrolloni që çdo rregull është në konfigurimin e ruajtur dhe që e parazgjedhura e shënuar ekziston pas nisjes, jo vetëm pasi e shkruat.

Nëse diçka dështon, hiqni së pari shenjën dhe shihni nëse trafiku normal kthehet, pastaj hiqni tabelën. Ky rend ju tregon nëse po ndiqni një problem routing apo një problem firewall, dhe i lë familjes një printer funksionues ndërsa ju e përfundoni punën.