Webhosting versus VPS: zvládne váš tarif provozovat VPN server?

Fungující web je důkazem, že poskytovatel umí servírovat HTTP, ne že vy ovládáte stroj. Mezi sdíleným tarifem, spravovanou aplikací a samostatně spravovaným serverem je velká propast v tom, co účet smí dělat se sítí. Rozhodněte, kterou stranu této propasti váš návrh VPN potřebuje, než zaplatíte další rok. Tyto dvě možnosti oddělují čtyři schopnosti a žádná z nich není v ceníku.

Co každý tarif skutečně dává

Užitečné srovnání není cena ani velikost disku, ale oprávnění. Ptejte se, co účet umí spustit, ke kterým funkcím jádra se dostane, které porty přijímají příchozí provoz a zda povolený provoz může zase odejít jinam.

Většina hostingových produktů spadá do tří podob a jen ta poslední je server pro obecné použití:

Účet s shellem je obvyklým zdrojem zmatku. Přenos souborů nebo přístup k naplánovaným úlohám může vypadat jako správa, zatímco proces je omezen na adresář a malou sadu povolených operací.

Čtyři schopnosti, které rozhodují odpověď

Berte je popořadě, protože selhání v prvním kroku činí zbytek nepodstatným.

Za prvé, software musí běžet jako dlouhodobý proces, který přežije údržbu. Za druhé, implementace musí umět vytvořit své virtuální rozhraní; na Linuxu to obvykle znamená otevřít /dev/net/tun s příslušným správcovským oprávněním, jak dokumentace jádra k TUN/TAP popisuje, i když ne každý návrh VPN toto zařízení používá. Za třetí, klienti musí dosáhnout na naslouchající proces na veřejné adrese, přenosu a portu, které zamýšlíte, a webová reverzní proxy přijímající HTTPS neříká nic o nesouvisejícím protokolu na stejném čísle. Za čtvrté, povolený provoz musí umět pokračovat dál, s trasami, předáváním a jakýmkoli skutečně podporovaným překladem.

Podmínky služby stojí vedle těch čtyř a nejsou vůbec technické. Neomezené limity provozu obvykle popisují webové požadavky, ne tunel, který nese cizí stahování. Přečtěte si sekci o přijatelném užívání, než kolem ní budete navrhovat, a myslete na přístup pro obnovu pro den, kdy se služba nespustí.

Kde webový účet končí

Webový tarif obvykle spouští váš kód ve spravovaném runtime s pevným vstupním bodem. I když je tunelový binární soubor přítomen, procesu může chybět oprávnění otevřít uzel zařízení, obsadit privilegovaný port nebo změnit směrovací tabulku. Tato omezení jsou produkt, ne přehlédnutí.

Proto plugin slibující VPN obvykle skončí jako proxy jinam. Pokud současný účet nabízí jen webové ovládání, poctivým krokem je samostatný server, ne hledání modulu, který odemkne chybějící oprávnění.

Když jeden hostitel musí provozovat obojí

Sdílení je možné a někdy rozumné, ale berte ho jako bezpečnostní rozhodnutí, ne jako pohodlí. Webová aplikace s formulářem pro nahrávání stojí vedle tunelových přihlašovacích údajů a řídicího socketu a zneužití v jednom dosáhne druhého. Oddělené účty, oddělené služební jednotky a oddělené souborové systémy tuto expozici snižují, aniž byste kupovali druhý stroj.

Soupeření o prostředky je stejně důležité. Záloha přes tunel a vytížený webový proces soutěží o stejný upload a stejný disk a porucha vypadá jako pomalý web, ne jako nasycený tunel. Rozhodněte, která zátěž vyhraje, ještě před incidentem, a omezte tunel, aby web dál odpovídal.

Ani jedno uspořádání není izolované jen proto, že obě služby běží. Schopnost hostovat je společně je začátek návrhu a práce na izolaci je to, co ho činí obhajitelným.

Vyřešte to na zkušebním hostiteli čtyřmi příkazy

Před migrací si na hodinu pronajměte nejmenší instanci cílového produktu a otestujte čtyři schopnosti přímo. Hádání z tabulky funkcí stojí méně peněz než rok se špatným tarifem, ale mnohem více času.

Spusťte tyto příkazy na zkušebním hostiteli a čtěte selhání jako odpovědi, ne jako překážky:

ls -l /dev/net/tun
sudo ip tuntap add dev tun9 mode tun && sudo ip link del tun9
sysctl net.ipv4.ip_forward
ss -lunp | head

První dva řádky říkají, zda tunelové zařízení vůbec může existovat. Třetí hlásí, zda hostitel smí přeposílat pakety, a čtvrtý ukazuje, co už naslouchá, aby se konflikt portů zachytil brzy. Poskytovatel, který selže na druhém řádku, může přesto podporovat implementaci v uživatelském prostoru, proto při dotazu na podporu jmenujte mechanismus, který potřebujete, a ne kategorii produktu.