Unu aparato tra VPN de enkursigilo bezonas tri regulojn, ne ŝaltilon

Sur enkursigila VPN ne ekzistas ŝaltilo por unuopa aparato; la ŝaltilo, kiun vi serĉas, estas fulmoklopodo, kiu skribas politikajn enkursigajn regulojn anstataŭ vi. En la momento, kiam unu tekkomputilo, unu pordego-diapazono, unu adreslisto aŭ unu LAN-segmento devas uzi la tunelon dum ĉio alia restas en la WAN, vi konstruas politikan vojon, ne ebligas funkcion. La tasko havas tri moviĝantajn partojn, kaj ĉiu malsukcesas malsame: markita tabelo sen vojo aspektas kiel silento, marko aplikita en la malĝusta ĉeno aspektas kvazaŭ nenio okazis, kaj mankanta NAT-regulo aspektas kiel tunelo, kiu konektiĝas kaj portas nenion. Du pliaj partoj mankas, ĉar ili neniam aperas en la mangle-regulo, kaj tiuj estas DNS kaj IPv6.

La mito: la tunelo estas klienta agordo

VPN-kliento ĉe la enkursigilo bone faras unu krudan aferon: ĝi metas 0.0.0.0/0 en la ĉefan enkursigan tabelon kaj direktas ĝin al la tunelo. WireGuard derivas tion el AllowedIPs, OpenVPN el puŝita redirect-gateway, kaj ambaŭ ŝanĝas la vojon por ĉiu gastiganto malantaŭ la enkursigilo. Mallarĝigi AllowedIPs aŭ aldoni route-nopull ŝanĝas tion, kion la kliento instalas. Ĝi ne ŝanĝas, al kiu la instalado aplikiĝas, ĉar la kliento neniam vidas aparatojn. Ĝi vidas nur pakaĵojn.

Elekti laŭ fonto aŭ celo estas enkursiga decido, do ĝi apartenas al la politika tavolo de la enkursigilo: mangle-regulo plus dua tabelo en RouterOS, MARK plus ip rule en OpenWrt aŭ DD-WRT, aŭ fajroŝirma regulo, kies pordego estas la tunelo, en pfSense. La WireGuard-klienta recepto de Netgate estas tiu, kiun legi antaŭ ol diveni, ĉar en tiu platformo la pordego de la regulo, la interfaca asigno kaj la elira NAT-enskribo ĉiuj devas interkonsenti antaŭ ol unu kliento uzas la tunelon.

La dua duono de la mito estas la dua enkursigilo. Aĉeti plian skatolon aŭ movi la aparaton al gastiga SSID ofte ja funkcias, kaj la kialo ne estas la aparataro: ĝi metas la aparaton sur sian propran subreton, kio donas al vi la fontan selektilon, kiun la firmvaro jam komprenas. Se vi povas difini tiun segmenton sur la enkursigilo, kiun vi posedas, la kroma skatolo solvas problemon, kiun vi ne havis.

Unua parto: tunelo, kiu ne estas la apriora vojo

En RouterOS aldonu la klienton sen apriora vojo kaj donu al la tunelo sian propran tabelon. La unua vojo estas la markita aprioro; la dua estas la malsukcesa duono.

/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

La vojo unreachable estas la kialo, kial markita tabelo venkas esceptliston en la ĉefa tabelo. Kiam la tunelo falas, markitaj pakaĵoj tuj ricevas unreachable anstataŭ silente reiri al la WAN, do la fiasko videblas en la erarmesaĝo de la aplikaĵo, ne en geoloka paĝo, kiun vi kontrolas horon poste.

RouterOS 7 disigas tion, kion 6.x tenis kune: vi deklaras la tabelon per /routing table add name=vpn fib, poste referencas ĝin per nomo en la vojo kaj en la mangle-regulo. Fragmento por 6.x, kiu enigas routing-mark sen difini la tabelon, ŝarĝiĝas pure kaj kongruas kun nenio. La alia klasikaĵo estas du duonoj 0.0.0.0/1, aŭ du aprioraj vojoj je la sama distanco en unu tabelo: la kerno elektas unu, kaj la konduto povas ŝanĝiĝi post relanĉo.

Dua parto: marku antaŭ la vojserĉo

La selektilo decidas, kiuj pakaĵoj eniras tiun tabelon. RouterOS kutime komencas per adreslisto por cela politiko, aŭ per fonta adreso por aparata politiko:

/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-firmvaro faras la samon per netfilter-marko kaj regulo, kiu direktas markitajn pakaĵojn en tabelon, kiun vi plenigis:

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

La ĉeno ne estas stila elekto. Kiam pakaĵo atingas FORWARD, la vojserĉo jam okazis, do MARK aŭ DROP tie povas nur reverki aŭ forĵeti. La marko devas fali en PREROUTING por plusendita trafiko kaj en OUTPUT por trafiko, kiun la enkursigilo mem kreas, ĉar tie loĝas la DNS, NTP kaj ĝisdatigaj kontroloj de la enkursigilo. Ĝuste tiu elira vojo estas la kutima kialo, kial plene tuneligita agordo ankoraŭ respondas el la ISP-resolvilo en likotesto.

Aparata politiko bezonas kongruon, kiu ne drivas. Rezervu la adreson en DHCP, aŭ kongruigu interfacon por dediĉita segmento; adreso, kiu poste moviĝas al alia aparato, silente aplikas la tunelon al la malĝusta kliento. Ponto por ĉiu SSID kun propra subreto estas la pli daŭra versio de la sama ideo, kaj ĝi donas al la IPv6-reguloj lokon por vivi.

Tria parto: NAT, DNS kaj la LAN-escepto

Trafiko, kiu eliras tra la tunelo, bezonas fontan adreson, al kiu la malproksima flanko respondos. Limigu la tradukon al la tunela interfaco: out-interface=VPN_NAME en RouterOS, -o tun0 en Linux, kongrua elira NAT-enskribo en pfSense. Masquerade-regulo sen tiu limigo reverkas trafikon, kiun vi intencis lasi trankvila, kaj la simptomo estas, ke la netuneligita aparato perdas sian publikan adreson.

La LAN-escepto kaŭzas pli da subtenaj fadenoj ol la tunelo mem. Se la markita tabelo tenas nur aprioran vojon, presila aŭ NAS-celo de la elektita aparato kongruas kun tiu aprioro kaj malaperas en la tunelon. Aldonu la LAN-vojon al la sama tabelo, aŭ ekskludu la lokan subreton en la selektilo; ambaŭ funkcias, kaj la escepto restas pli facile ĝusta, kiam vi poste aldonas VLAN-ojn.

DNS prenas apartan vojon. Demandoj, kiujn la enkursigilo plusendas, originas de la enkursigilo kaj sekvas OUTPUT, ne la plusenditan markon, do plene tuneligita tekkomputilo ankoraŭ povas solvi per la ISP. Direktu klientojn al solvilo atingebla tra la tunelo, aŭ marku la propran pordegan-53-trafikon de la enkursigilo, poste kontrolu la solvitan adreson anstataŭ supozi, ke la respondo vojaĝis kun la retpetaĵo.

Kiam la regulo kongruas sed la aplikaĵo ankoraŭ uzas la WAN

Cellistoj maljuniĝas malbone. Nomo solviĝas al adreso, kiu ne estas en la listo, do la peto prenas la WAN, dum ĉiu testo, kiun vi faris kontraŭ la listigita adreso, funkciis. Refreŝigu la liston el la sama solvilo, kiun la kliento uzas, kaj preferu fontbazan selektilon, kiam vi vere volas la tutan trafikon de unu aparato.

IPv6 estas la kvieta pretervojo. La aparato havas duan adresfamilion kun propra apriora vojo kaj propra regulkompleto, kaj kongruigi nur la IPv4-adreson estas duona politiko. Apliku la saman selektilon al ip6tables aŭ al la nftables-ekvivalento, aŭ malŝaltu IPv6 sur tiu segmento intence, ne hazarde.

Establitaj konektoj ankaŭ gravas. Conntrack-enskribo kreita antaŭ la ŝanĝo sekvas la malnovan vojon ĝis ĝi eksvalidiĝas, do retumilo, kiu restis malferma dum la redakto, aspektas ĝuste kiel regulo, kiu neniam aplikiĝis. Malfermu novan konekton, aŭ viŝu la staton, antaŭ ol juĝi la politikon.

Kontrolu per du aparatoj kaj relanĉo

Testu la aparaton, kiu devus esti tuneligita, kaj la aparaton, kiu ne devus, kaj komparu la duan salteton anstataŭ rapidcifero. Traceroute el ĉiu montras ĉe la dua salteto aŭ la tunelan pordegon aŭ la ISP-pordegon; se ambaŭ aspektas same, la marko aŭ la tabelo ne faras tion, kion diras la regulo. Uzu novajn konektojn por la testo.

Poste relanĉu. La starta ordo estas la loko, kie funkcianta politiko fariĝas rompita, ĉar la kliento devas esti aktiva antaŭ ol la unreachable-vojo instaliĝas, kaj konservita momentaĵo, kiu restarigas la malnovan regulkompleton, anstataŭigos vian tabelon. Kontrolu, ke ĉiu regulo estas en la konservita agordo kaj ke la markita aprioro ekzistas post la lanĉo, ne nur post kiam vi tajpis ĝin.

Se io malsukcesas, unue forigu la markon kaj vidu, ĉu normala trafiko revenas, poste forigu la tabelon. Tiu ordo diras al vi, ĉu vi ĉasas enkursigan problemon aŭ fajroŝirman problemon, kaj ĝi lasas la domanaron kun funkcianta presilo dum vi finas la laboron.