Šta VPS mora dozvoliti prije nego što može hostati vaš VPN

Instanca se podiže, instalacije paketa prolaze, a servis čak prijavljuje radno stanje, ali ništa se ne povezuje. Taj obrazac je čest na virtualnim privatnim serverima, jer gost koji bez problema dolazi na internet i dalje može biti nesposoban da stvori interfejs koji vaš protokol traži. Pet provjera razdvaja host koji može služiti tunel od onog koji samo izgleda spreman, a prva neuspjela provjera obično objašnjava sve nakon nje. Svaka je jeftina za pokretanje i završava odlukom, a ne bilješkom.

Potvrdite interfejs koji protokol zahtijeva

OpenVPN preko TUN-a treba karakteristični uređaj i kernel modul iza njega; WireGuard treba vlastitu podršku u kernelu ili korisničku implementaciju sa odgovarajućim očekivanjima. Upravljani kontejneri mogu dijeliti host kernel koji nikad ne izlaže uređaj, a neke platforme zabranjuju stvaranje tunelskih interfejsa u potpunosti, bez obzira šta je instalirano.

Testirajte sposobnost umjesto da čitate stranicu podrške, jer se marketinške oznake mijenjaju brže od stvarnih ograničenja. Lista funkcija napisana za jedan plan možda ne opisuje kernel na kojem gost zapravo radi. Dvije kratke komande odgovaraju na pitanje za protokole u uobičajenoj upotrebi, i obje čiste za sobom. Komande ispod ne stvaraju ništa trajno i uklanjaju se odmah.

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

Odbijanje na prvom paru znači da TUN nije dostupan i da podrazumijevani režim OpenVPN-a ne može početi; odbijanje na zadnjoj liniji znači da kernel interfejs WireGuard-a nedostaje. kernel TUN/TAP dokumentacija opisuje uređaj koji prva provjera ispituje. Nijedan od ova dva neuspjeha ne popravlja se ponovnom instalacijom VPN paketa.

Zapamtite da dolazni put ima dva vlasnika

Mrežna pravila provajdera i firewall gosta su odvojeni sistemi, a saobraćaj mora preživjeti oba. Slušalac vezan na gostu ne znači ništa ako sigurnosna grupa provajdera odbaci port, a otvoreno pravilo provajdera ne radi ništa ako gost odbije paket. Provjerite slušalac, zatim pravila gosta, zatim panel provajdera, tim redom, i potvrdite i protokol i broj porta. Preskakanje pravo na panel provajdera je način na koji ljudi otvaraju raspon koji im nije trebao.

UDP je uobičajena žrtva: mnoge platforme podrazumijevano dozvoljavaju TCP i tretiraju UDP pravila kao odvojen unos. Ako instanca stoji iza NAT-a provajdera umjesto da ima javnu adresu, prosljeđivanje portova na strani provajdera postaje treća konfiguracija koju treba uskladiti.

Planirajte povratni put, ne samo izlaz

Usluga punog tunela zahtijeva omogućeno prosljeđivanje, šemu prevođenja ili rutiranja za saobraćaj klijenata i povratni put koji stiže do skupa klijenata. Otvaranje slušaoca ne daje ništa od toga. Tunel koji se uspostavi ali ne nosi koristan saobraćaj obično zakaže ovdje, a ne pri autentifikaciji. Tretirajte uspješno rukovanje kao početak dijagnoze, a ne kao njen kraj.

Napišite plan kao tri konkretne odluke: koji raspon izvora klijenti dobijaju, kako njihov saobraćaj izlazi prema internetu i kako odgovori nalaze put natrag. Zatim potvrdite da se kernel slaže s planom prije testiranja klijenta, da se tiha neusklađenost ne bi zamijenila za kvar na strani klijenta.

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

Jasno odlučite o IPv6 priči

IPv6 dolazi kroz nekoliko mehanizama koji se za gateway ponašaju različito: adresa na instanci, rutirani prefiks ili ništa. Samo rutirani prefiks omogućava serveru da daje adrese klijentima na uobičajen način. Pretpostavka da radna IPv6 adresa na hostu znači upotrebljiv prefiks klijenta greška je koja se kasnije pojavi kao napola pokvarena povezanost. To je vrsta kvara koja preživi svaki test izveden samo s IPv4.

Ako provajder ne rutira nikakav prefiks, odlučite je li tunel samo IPv4 i treba li klijentima to reći. Dokumentovano odsustvo sigurnije je od djelimične konfiguracije koja tiho baca IPv6 odredišta u crnu rupu za povezane korisnike.

Dokažite to s vanjskog klijenta

Lokalni status servisa opisuje jedan proces na jednom hostu. Koristan test je ovlašteni klijent na drugoj mreži, koji se povezuje profilom koji namjeravate distribuirati, zatim dolazi do aplikacije i razrješava ime. Povežite se još jednom, jer tunel koji radi samo iz prvog pokušaja ne ispunjava zahtjev koji je u praksi najvažniji.

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

Držite operativne osnove uz test: prostor za ažuriranja, ograničene logove, administrativni pristup koji ne zavisi od tunela, konzolu za oporavak i bilješku o tome šta se dešava s klijentskim profilima kad se instanca ponovo izgradi i njena javna adresa promijeni. Ako potrebni interfejs ili model prosljeđivanja jednostavno nije dostupan, nikakva promjena na strani klijenta to neće pružiti, a iskren sljedeći korak je drugi tip instance, a ne više konfiguracije.