Какво трябва да позволи 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

Дръжте оперативните основи до теста: място за обновявания, ограничени журнали, административен достъп, който не зависи от тунела, конзола за възстановяване и бележка какво се случва с клиентските профили, когато инстанцията се преустрои и публичният ѝ адрес се промени. Ако необходим интерфейс или модел на препращане просто не е наличен, никаква промяна от страна на клиента няма да го осигури и честната следваща стъпка е друг тип инстанция, а не повече конфигурация.