Маршрутызатар ці асобны камп’ютар як VPN-сервер: як выбіраць
VPN на маршрутызатары эканоміць машыну, але дзеліць яго цыкл перазагрузкі. Параўнайце, хто валодае абнаўленнямі, шляхі прыватнай сеткі і аднаўленне, перш чым выбраць хост.
І маршрутызатар, і невялікі камп’ютар могуць завяршаць VPN, і рашэнне рэдка залежыць ад прапускной здольнасці. Яно залежыць ад таго, хто ўжывае абнаўленне а другой гадзіне ночы, што яшчэ спыняецца, калі гэтая скрынка перазагружаецца, і ці можна ўсё яшчэ дабрацца да кансолі, калі зламаўся менавіта тунель. Адказвайце на гэтыя тры пытанні для кожнага кандыдата, і выбар звычайна робіцца сам. Працэдура ніжэй ператварае параўнанне ў кароткі спіс таго, што можна праверыць перад абавязальніцтвам.
Пачніце з таго, што павінна заставацца працаздольным, калі тунель адмаўляе
Збой, да якога трэба праектаваць, — гэта той, калі працэс VPN памірае, а вам усё роўна трэба дабрацца да хоста. На маршрутызатары тунель і інтэрнэт-шлюз дзеляць адзін лёс: адно дрэннае змяненне канфігурацыі можа пакласці абодва, і шлях аднаўлення часта — фізічны скід. На асобным камп’ютары шлюз працягвае працаваць, і хост па-ранейшаму дасягальны праз LAN. Які з гэтых вынікаў вы можаце вытрымаць, вырашае больш, чым любы спіс функцый.
Запішыце адказ як сказ: калі VPN-хост перазагружаецца, што губляе дом ці офіс? Калі адказ уключае ўвесь доступ да інтэрнэту, вы прынялі агульную зону збою і павінны сказаць гэта свядома, а не выявіць пазней.
Другая служба на тым жа прыстасаванні — не рэзервовая кансоль. Яна дзеліць блок сілкавання, прашыўку і ўліковы запіс адміністратара.
Падлічыце паверхні абслугоўвання, якія дадае кожны хост
Маршрутызатар прыносіць прашыўку вытворцы з уласным рытмам выпуску, а функцыя VPN звычайна — адзін модуль у значна большым вобразе. Камп’ютар прыносіць аперацыйную сістэму, менеджэр пакетаў, ядро і набор службаў, якімі вы цяпер валодаеце. Абодва патрабуюць латання, і сапраўднае пытанне — які рытм вы будзеце трымаць, калі навізна скончыцца.
На Linux-хосце зрабіце гэты рытм бачным, а не спадзявайцеся на яго. systemctl list-timers паказвае запланаваныя задачы, а apt list --upgradable — што чакае. Запішыце, якія абнаўленні патрабуюць перазагрузкі, бо VPN-хост, які перазагружаецца, — гэта перапынак, калі вы не планавалі яго. Маршрутызатару без аўтаматычнага шляху абнаўлення патрэбны замест гэтага запіс у календары, што слабейшы кантроль, але сумленны.
Падлічыце таксама ўліковыя запісы. Кожны дадатковы ўваход адміністратара на VPN-хосце — гэта яшчэ адзін пасведчанне для ротацыі і яшчэ адзін шлях для адклікання.
Прасочвайце шлях прыватнай сеткі, а не этыкетку на скрынцы
Кліентам не важна, дзе працуе сервер; ім важна, ці дасягальныя абароненыя прэфіксы і ці існуе зваротны шлях. Пастаўце сервер туды, дзе маршрутызацыя найпрасцейшая, — звычайна гэта непасрэдна на сегменце, які трымае рэсурсы. Камп’ютар за маршрутызатарам усё яшчэ патрабуе перанакіравання порта, а рэсурсы ў той LAN — маршруту назад у падсетку тунелю.
Праверце перанакіраванне на хосце, перш чым вінаваціць кліента. sysctl net.ipv4.ip_forward павінен паведамляць 1, а nft list ruleset ці iptables -S паказвае, ці наогул інтэрфейсу тунелю дазволена перанакіроўваць. Адсутнае правіла masquerade выглядае з боку кліента зусім як зламаны тунель.
Вызначыце таксама, чаго тунель не павінен дасягаць. Сервер, размешчаны на маршрутызатары, бачыць кожную падсетку, якую маршрутызуе гэты маршрутызатар, а гэта часта больш, чым мае на ўвазе палітыка доступу. На асобным хосце тая ж ізаляцыя — на адлегласці аднаго правіла фаеруолу, і радыус паразы скампраметаванага кліента меншы. Апісанне шлюза IPsec у RFC 7296 разглядае гэта як пытанне маршрутызацыі і палітыкі, а не абсталявання, і ні адна з форм не бяспечнейшая па змаўчанні, пакуль палітыка не запісана.
Трымайце кансоль аднаўлення, якая не залежыць ад тунелю
Кансоль, якой вы рамантуеце VPN, не можа быць самім VPN. Трымайце адрас LAN, паслядоўную кансоль або кансоль правайдэра, якая працуе, пакуль тунель ляжыць, і скарыстайцеся ёй хаця б раз, перш чым яна спатрэбіцца. Па-запалосны шлях, які ніколі не практыкаваўся, — гэта план, а не магчымасць.
Зрабіце рэзервовую копію канфігурацыі там, адкуль сам хост не зможа яе выдаліць. tar -czf vpn-config-2026-11-03.tar.gz /etc/wireguard /etc/openvpn захоплівае ключы і вызначэнні службаў, і копія павінна пакінуць машыну. Уключыце правілы фаеруолу і інвентар кліентаў, бо аднаўленне ключоў без спісу партнёраў стварае сервер, да якога ніхто не можа далучыцца. Захоўвайце архіў там, адкуль кансоль аднаўлення можа яго дастаць.
Запішыце крок адкату ў той жа нататцы. Змяненне канфігурацыі без дакументаванага адваротнага дзеяння — гэта пастаяннае змяненне, якім бы ні было намер.
Праверце выбар перазагрузкай і абнаўленнем
Тэстуйце ўладкаванне так, як яно адмовіць, а не так, як яно працуе ў добры дзень. Перазагрузіце хост, ужывіце чаканае абнаўленне і пераканайцеся, што тунель вяртаецца без ручных крокаў.
Пасля перазагрузкі праверце тры рэчы, якія ламаюцца найчасцей. systemctl is-active wg-quick@wg0 паведамляе, ці вярнуўся інтэрфейс, ss -lunp паказвае, ці нешта слухае порт, а wg show пералічвае партнёра з завершаным рукапацісканнем. Служба, якая актыўная без рукапаціскання, азначае, што памылковыя фаеруол або маршрут, а не дэман.
Паўтарыце праверку з кліента ў іншай сетцы, чым тая, з якой вы наладжвалі. Калі тунель перажывае перазагрузку, абнаўленне і змену сеткі кліента, выбар хоста на дадзены момант вырашаны. Калі не, адсутная частка звычайна — дакументаваны крок, а не іншая скрынка.