Mit kell engedélyeznie egy VPS-nek, mielőtt VPN-t fogadhat

A példány elindul, a csomagtelepítések sikerülnek, és a szolgáltatás még futó állapotot is jelent, mégsem csatlakozik semmi. Ez a minta gyakori a virtuális magánszervereken, mert a vendég, amely kényelmesen eléri az internetet, még mindig képtelen lehet létrehozni azt az interfészt, amelyet a protokollja kér. Öt ellenőrzés választja el a tunnelt kiszolgálni képes gazdagépet attól, amely csak késznek látszik, és az első sikertelen ellenőrzés általában mindent megmagyaráz utána. Mindegyik olcsó futtatni, és döntéssel végződik, nem jegyzettel.

Erősítse meg a protokoll által igényelt interfészt

OpenVPN TUN felett karakteres eszközre és a mögötte lévő kernelmodulra van szükség; a WireGuard saját kerneltámogatást vagy megfelelő elvárásokkal rendelkező felhasználói térbeli megvalósítást igényel. A felügyelt konténerek olyan gazdakernelt oszthatnak meg, amely soha nem tárja fel az eszközt, és egyes platformok egyáltalán tiltják az alagút-interfészek létrehozását, függetlenül attól, mi van telepítve.

A képességet tesztelje, ne támogatási oldalt olvasson, mert a marketingcímkék gyorsabban változnak, mint a mögöttes korlátok. Egy csomaghoz írt funkciólista talán nem írja le azt a kernelt, amelyen a vendég valójában fut. Két rövid parancs megválaszolja a kérdést a gyakori protokollokra, és mindkettő eltakarít maga után. Az alábbi parancsok semmi maradandót nem hoznak létre, és azonnal eltávolítják őket.

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

Az első párnál tapasztalt elutasítás azt jelenti, hogy a TUN nem elérhető, és az OpenVPN alapértelmezett módja nem indulhat el; az utolsó sor elutasítása azt jelenti, hogy hiányzik a WireGuard kernelinterfésze. A kernel TUN/TAP dokumentációja leírja az eszközt, amelyet az első ellenőrzés gyakorol. Egyik hibát sem javítja meg a VPN-csomag újratelepítése.

Ne feledje: a bejövő útnak két tulajdonosa van

A szolgáltató hálózati szabályai és a vendég tűzfala külön rendszerek, és a forgalomnak mindkettőn át kell jutnia. A vendégen kötött figyelő semmit sem ér, ha a szolgáltató biztonsági csoportja eldobja a portot, és egy nyitott szolgáltatói szabály sem tesz semmit, ha a vendég elutasítja a csomagot. Ellenőrizze a figyelőt, majd a vendég szabályait, majd a szolgáltatói panelt, ebben a sorrendben, és erősítse meg a protokollt és a portszámot is. Egyenesen a szolgáltatói panelre ugrani az az út, amelyen az emberek olyan tartományt nyitnak, amelyre nem volt szükségük.

Az UDP a szokásos áldozat: sok platform alapértelmezésben engedélyezi a TCP-t, és az UDP-szabályokat külön bejegyzésként kezeli. Ha a példány a szolgáltató NAT-ja mögött áll, nem pedig nyilvános címmel rendelkezik, a szolgáltatói oldali porttovábbítás harmadik, összehangolandó konfigurációvá válik.

Tervezze meg a visszautat is, ne csak a kijáratot

A teljes alagút szolgáltatásához engedélyezett továbbítás, az ügyfélforgalomhoz fordítási vagy útválasztási séma, valamint az ügyfélkészlethez eljutó visszaút kell. Egy figyelő megnyitása ezek közül egyiket sem nyújtja. Az az alagút, amely létrejön, de nem szállít hasznos forgalmat, általában itt bukik el, nem a hitelesítésnél. Tekintse a sikeres kézfogást a diagnózis kezdetének, nem a végének.

Írja le a tervet három konkrét döntésként: milyen forrástartományt kapnak az ügyfelek, hogyan lép ki forgalmuk az internet felé, és hogyan találnak vissza a válaszok. Ezután erősítse meg, hogy a kernel egyetért a tervvel, mielőtt ügyfelet tesztel, hogy a csendes eltérést ne nézzék ügyféloldali hibának.

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

Döntse el az IPv6 kérdését kifejezetten

Az IPv6 több mechanizmuson át érkezik, amelyek átjáróként eltérően viselkednek: cím a példányon, irányított előtag vagy semmi. Csak az irányított előtag engedi, hogy a kiszolgáló a szokásos módon adjon címeket az ügyfeleknek. Az a feltevés, hogy a gazdagépen működő IPv6-cím használható ügyfél-előtagot jelent, olyan hiba, amely később félig törött kapcsolatként jelenik meg. Ez az a fajta hiba, amely túlél minden csak IPv4-gyel végzett tesztet.

Ha a szolgáltató egyetlen előtagot sem irányít, döntse el, hogy az alagút csak IPv4-es-e, és hogy erről tájékoztatni kell-e az ügyfeleket. Egy dokumentált hiány biztonságosabb, mint egy részleges konfiguráció, amely csendesen fekete lyukba küldi az IPv6-célokat a csatlakozott felhasználóknak.

Bizonyítsa külső ügyfélről

A helyi szolgáltatásállapot egy folyamatot ír le egy gazdagépen. A hasznos teszt egy másik hálózaton lévő jogosult ügyfél, amely a terjeszteni kívánt profillal csatlakozik, majd elér egy alkalmazást és felold egy nevet. Csatlakozzon még egyszer, mert az az alagút, amely csak az első próbálkozáskor működik, nem teljesíti a gyakorlatban legfontosabb követelményt.

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

Tartsa a teszt mellett az üzemeltetési alapokat: hely a frissítéseknek, korlátozott naplók, az alagúttól nem függő adminisztratív hozzáférés, helyreállítási konzol, és egy jegyzet arról, mi történik az ügyfélprofilokkal, amikor a példány újraépül és nyilvános címe megváltozik. Ha egy szükséges interfész vagy továbbítási modell egyszerűen nem érhető el, semmilyen ügyféloldali változtatás nem nyújtja azt, és az őszinte következő lépés egy másik példánytípus, nem több konfiguráció.