Co musí VPS umožnit, než na něm můžete provozovat VPN

Instance se spustí, instalace balíčků proběhnou, služba dokonce hlásí běžící stav, a přesto se nic nepřipojí. Tento vzorec je u virtuálních privátních serverů běžný, protože host, který se pohodlně dostane na internet, stále nemusí umět vytvořit rozhraní, které váš protokol vyžaduje. Pět kontrol odděluje hostitele, který dokáže obsloužit tunel, od toho, který jen vypadá připraveně, a první neúspěšná kontrola obvykle vysvětlí vše po sobě. Každá je levná na spuštění a končí rozhodnutím, ne poznámkou.

Ověřte rozhraní, které protokol potřebuje

OpenVPN přes TUN potřebuje znakové zařízení a jaderný modul za ním; WireGuard potřebuje vlastní podporu v jádře nebo uživatelskou implementaci s odpovídajícími očekáváními. Spravované kontejnery mohou sdílet jádro hostitele, které zařízení nikdy nevystaví, a některé platformy vytváření tunelových rozhraní úplně zakazují bez ohledu na to, co je nainstalováno.

Testujte schopnost, místo abyste četli stránku podpory, protože marketingové štítky se mění rychleji než skutečné limity. Seznam funkcí napsaný pro jeden tarif nemusí popisovat jádro, na kterém host skutečně běží. Dva krátké příkazy odpovídají na otázku pro běžně používané protokoly a oba po sobě uklidí. Níže uvedené příkazy nic trvalého nevytvářejí a okamžitě se odstraňují.

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

Odmítnutí u první dvojice znamená, že TUN není dostupný a výchozí režim OpenVPN nemůže startovat; odmítnutí na posledním řádku znamená, že chybí jaderné rozhraní WireGuard. dokumentace jádra k TUN/TAP popisuje zařízení, které první kontrola procvičuje. Ani jedno z těchto selhání se neopraví přeinstalováním balíčku VPN.

Pamatujte, že příchozí cesta má dva vlastníky

Síťová pravidla poskytovatele a firewall hosta jsou oddělené systémy a provoz musí projít oběma. Naslouchač navázaný na hostu nic neznamená, pokud bezpečnostní skupina poskytovatele port zahodí, a otevřené pravidlo poskytovatele nic nedělá, pokud host paket odmítne. Ověřte naslouchač, potom pravidla hosta, potom panel poskytovatele, v tomto pořadí, a potvrďte jak protokol, tak číslo portu. Přeskočení rovnou na panel poskytovatele je způsob, jak lidé otevřou rozsah, který nepotřebovali.

UDP je obvyklá oběť: mnoho platforem povoluje TCP ve výchozím nastavení a pravidla UDP považuje za samostatnou položku. Pokud instance stojí za NAT poskytovatele místo toho, aby měla veřejnou adresu, stává se přesměrování portů na straně poskytovatele třetí konfigurací, kterou je třeba sladit.

Plánujte zpáteční cestu, ne jen výstup

Služba plného tunelu potřebuje zapnutý forwarding, schéma překladu nebo směrování pro klientský provoz a zpáteční cestu, která dosáhne na skupinu klientů. Otevření naslouchače nic z toho nedodá. Tunel, který se naváže, ale nenese užitečný provoz, obvykle selhává tady, ne při autentizaci. Úspěšný handshake berte jako začátek diagnostiky, ne jako její konec.

Napište plán jako tři konkrétní rozhodnutí: jaký rozsah zdrojů klienti dostanou, jak jejich provoz odchází k internetu a jak se odpovědi vracejí zpět. Poté ověřte, že jádro s plánem souhlasí, ještě než otestujete klienta, aby se tichý nesoulad nepletl s chybou na straně klienta.

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

Rozhodněte o IPv6 výslovně

IPv6 přichází několika mechanismy, které se pro bránu chovají různě: adresa na instanci, směrovaný prefix, nebo nic. Jen směrovaný prefix umožňuje serveru dávat adresy klientům obvyklým způsobem. Předpoklad, že funkční adresa IPv6 na hostiteli znamená použitelný klientský prefix, je chyba, která se později projeví jako napůl rozbité připojení. Je to druh závady, který přežije každý test provedený jen s IPv4.

Pokud poskytovatel nesměruje žádný prefix, rozhodněte, zda je tunel jen pro IPv4 a zda to mají klienti vědět. Zdokumentovaná nepřítomnost je bezpečnější než částečná konfigurace, která tiše posílá destinace IPv6 do černé díry pro připojené uživatele.

Dokažte to z vnějšího klienta

Místní stav služby popisuje jeden proces na jednom hostiteli. Užitečný test je autorizovaný klient v jiné síti, který se připojí profilem, který hodláte distribuovat, pak dosáhne na aplikaci a přeloží jméno. Připojte se ještě jednou, protože tunel, který funguje jen na první pokus, nesplňuje požadavek, na kterém v praxi záleží nejvíc.

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

K testu si držte provozní základy: prostor pro aktualizace, omezené logy, administrativní přístup, který nezávisí na tunelu, konzoli pro obnovu a poznámku o tom, co se stane s klientskými profily, když se instance přestaví a její veřejná adresa se změní. Pokud požadované rozhraní nebo model forwardingu prostě není k dispozici, žádná změna na straně klienta to nedodá, a poctivým dalším krokem je jiný typ instance, ne více konfigurace.