Што павінен дазваляць VPS, перш чым размясціць ваш VPN

Інстанс загружаецца, усталяванне пакетаў праходзіць паспяхова, і нават сэрвіс паведамляе пра працоўны стан, але нічога не злучаецца. Такая карціна тыповая для віртуальных прыватных сервераў, бо госць, які спакойна выходзіць у інтэрнэт, можа ўсё роўна не мець магчымасці стварыць інтэрфейс, патрэбны вашаму пратаколу. Пяць праверкаў аддзяляюць хост, які здольны абслугоўваць тунель, ад таго, які толькі выглядае гатовым, і першая няўдалая праверка звычайна тлумачыць усё наступнае. Кожная з іх танная ў запуску і сканчаецца рашэннем, а не нататкай.

Пацвердзіце інтэрфейс, які патрабуе пратакол

OpenVPN па-над TUN патрабуе сімвальнага прыстасавання і модуля ядра за ім; WireGuard патрабуе ўласнай падтрымкі ў ядры або рэалізацыі ў прасторы карыстальніка з адпаведнымі чаканнямі. Кіраваныя кантэйнеры могуць дзяліць ядро хоста, якое ніколі не адкрывае прыстасаванне, а некаторыя платформы наогул забараняюць ствараць тунельныя інтэрфейсы незалежна ад усталяванага.

Правярайце магчымасць, а не чытайце старонку падтрымкі, бо маркетынгавыя ярлыкі змяняюцца хутчэй за базавыя абмежаванні. Спіс функцый, напісаны для аднаго плана, можа не апісваць ядро, на якім госць фактычна працуе. Дзве кароткія каманды адказваюць на пытанне для распаўсюджаных пратаколаў, і абедзве прыбіраюць за сабой. Каманды ніжэй не ствараюць нічога сталага і выдаляюцца адразу.

sudo ip tuntap add dev tun9 mode tun
sudo ip tuntap del dev tun9 mode tun
sudo ip link add wgtest type wireguard && sudo ip link del wgtest

Адмова на першай пары азначае, што TUN недаступны і прадвызначаны рэжым OpenVPN не можа запусціцца; адмова ў апошнім радку азначае, што інтэрфейс WireGuard у ядры адсутнічае. дакументацыя ядра пра TUN/TAP апісвае прыстасаванне, якое правярае першая праверка. Ні адну з гэтых няўдач не выпраўляе пераўсталяванне пакета VPN.

Памятайце, што ўваходны шлях мае двух уладальнікаў

Сеткавыя правілы правайдэра і фаервол госця — асобныя сістэмы, і трафік павінен прайсці праз абедзве. Слухач, прывязаны на госці, нічога не значыць, калі група бяспекі правайдэра скідвае порт, а адкрытае правіла правайдэра не дзейнічае, калі госць адхіляе пакет. Праверце слухача, затым правілы госця, затым панэль правайдэра — менавіта ў гэтым парадку — і пацвердзіце як пратакол, так і нумар порта. Менавіта так людзі адкрываюць дыяпазон, які ім не быў патрэбны.

UDP — звычайная ахвяра: шмат платформ дазваляе TCP па змоўчанні і разглядае правілы UDP як асобны запіс. Калі інстанс сядзіць за NAT правайдэра, а не мае публічнага адраса, перадача портаў на баку правайдэра становіцца трэцяй канфігурацыяй, якую трэба ўзгадніць.

Плануйце зваротны шлях, а не толькі выхад

Сэрвіс поўнага тунеля патрабуе ўключанай перадачы, схемы трансляцыі або маршрутызацыі для трафіку кліентаў і зваротнага шляху да пула кліентаў. Адкрыццё слухача не дае нічога з гэтага. Тунель, які ўзнікае, але не нясе карыснага трафіку, звычайна зрываецца менавіта тут, а не на аўтэнтыфікацыі. Лічыце паспяховае рукапоцісканне пачаткам дыягностыкі, а не яе канцом.

Запішыце план як тры канкрэтныя рашэнні: які дыяпазон крыніц атрымаюць кліенты, як іх трафік выходзіць у інтэрнэт і як адказы знойдуць шлях назад. Затым пацвердзіце, што ядро згоднае з планам, перш чым тэставаць кліента, каб маўклівая няўзгодненасць не была прынята за збой на баку кліента.

sysctl -n net.ipv4.ip_forward
sudo nft list ruleset | head -n 40
ip -4 route show default

Вызначце лёс IPv6 яўна

IPv6 прыходзіць праз некалькі механізмаў, якія паводзяць сябе па-рознаму для шлюза: адрас на інстансе, маршрутызаваны прэфікс або зусім нічога. Толькі маршрутызаваны прэфікс дазваляе серверу выдаваць адрасы кліентам звычайным шляхам. Меркаванне, што працоўны адрас IPv6 на хосце азначае прыдатны кліенцкі прэфікс, — гэта памылка, якая пазней выяўляецца як напалову зламанае злучэнне. Гэта менавіта такі збой, які перажывае кожны тэст, выкананы толькі з IPv4.

Калі правайдэр не маршрутызуе ніводнага прэфікса, вырашыце, ці тунель толькі для IPv4 і ці трэба паведаміць пра гэта кліентам. Задакументаваная адсутнасць бяспечнейшая за частковую канфігурацыю, якая маўкліва кідае адрасы IPv6 у чорную дзірку для падключаных карыстальнікаў.

Дакажыце гэта з вонкавага кліента

Лакальны стан сэрвісу апісвае адзін працэс на адным хосце. Карысны тэст — гэта аўтарызаваны кліент у іншай сетцы, які падключаецца з профілем, які вы маеце намер распаўсюджваць, затым дасягае праграмы і развязвае імя. Падключыцеся яшчэ раз, бо тунель, які працуе толькі з першай спробы, не выконвае патрабаванне, якое найбольш важнае на практыцы.

sudo wg show wg0 latest-handshakes
ip -4 route get 203.0.113.44
sudo journalctl -u wg-quick@wg0 -n 15 --no-pager

Трымайце побач з тэстам аперацыйныя асновы: месца для абнаўленняў, абмежаваныя журналы, адміністрацыйны доступ, які не залежыць ад тунеля, кансоль аднаўлення і нататку пра тое, што адбываецца з профілямі кліентаў, калі інстанс перабудоўваецца і яго публічны адрас змяняецца. Калі патрэбны інтэрфейс або мадэль перадачы проста недаступныя, ніякае змяненне на баку кліента іх не дасць, і сумленны наступны крок — іншы тып інстанса, а не больш канфігурацыі.