Hosting współdzielony czy VPS: czy twój plan uniesie serwer VPN?

Działająca strona jest dowodem, że dostawca potrafi serwować HTTP, a nie że ty kontrolujesz maszynę. Między współdzielonym planem, zarządzaną aplikacją a samodzielnie zarządzanym serwerem jest duża luka w tym, co konto może robić z siecią. Zdecyduj, której strony tej luki potrzebuje twój projekt VPN, zanim zapłacisz za kolejny rok. Cztery możliwości oddzielają te dwa przypadki, i żadna nie pojawia się w cenniku.

Co tak naprawdę daje każdy plan

Pożyteczne porównanie to nie cena ani rozmiar dysku, lecz uprawnienia. Zapytaj, co konto może uruchomić, do jakich funkcji jądra sięga, które porty przyjmują ruch przychodzący i czy dopuszczony ruch może znowu wyjść gdzie indziej.

Większość produktów hostingowych mieści się w trzech formach, a tylko ostatnia jest serwerem ogólnego przeznaczenia:

Konto shell to zwykłe źródło zamieszania. Transfer plików lub dostęp do zaplanowanych zadań może wyglądać jak administracja, choć proces jest ograniczony do katalogu i małego zbioru dozwolonych operacji.

Cztery możliwości, które rozstrzygają odpowiedź

Bierz je po kolei, bo porażka na pierwszym kroku czyni resztę bez znaczenia.

Po pierwsze, oprogramowanie musi działać jako długotrwały proces, który przetrwa konserwację. Po drugie, implementacja musi umieć utworzyć własny interfejs wirtualny; w Linuksie oznacza to zwykle otwarcie /dev/net/tun z odpowiednim uprawnieniem administracyjnym, jak dokumentacja jądra dotycząca TUN/TAP opisuje, choć nie każdy projekt VPN używa tego urządzenia. Po trzecie, klienci muszą dotrzeć do nasłuchującego procesu pod publicznym adresem, transportem i portem, które zamierzasz, a webowy odwrotny serwer proxy przyjmujący HTTPS nie mówi nic o niezwiązanym protokole na tym samym numerze. Po czwarte, dopuszczony ruch musi móc iść dalej, z trasami, przekazywaniem i każdym faktycznie obsługiwanym tłumaczeniem adresów.

Warunki usługi stoją obok tych czterech i wcale nie są techniczne. Nielimitowane limity ruchu zwykle opisują żądania webowe, a nie tunel przenoszący cudze pobrania. Przeczytaj sekcję o dopuszczalnym użyciu, zanim zaprojektujesz wokół niej, i pamiętaj o dostępie do odzyskiwania na dzień, w którym usługa nie wystartuje.

Gdzie kończy się konto hostingowe

Plan hostingowy zwykle uruchamia twój kod w zarządzanym środowisku wykonawczym ze stałym punktem wejścia. Nawet gdy istnieje binarka tunelu, procesowi może brakować uprawnień do otwarcia węzła urządzenia, zajęcia uprzywilejowanego portu lub zmiany tabeli routingu. Te ograniczenia to produkt, a nie przeoczenie.

Dlatego wtyczka obiecująca VPN zwykle okazuje się proxy do innego miejsca. Jeśli obecne konto oferuje tylko kontrolki witryny, uczciwym krokiem jest osobny serwer, a nie szukanie modułu, który odblokuje brakujące uprawnienia.

Gdy jeden host musi uruchamiać oba

Współdzielenie jest możliwe i czasem sensowne, ale traktuj je jako decyzję bezpieczeństwa, a nie wygodę. Aplikacja webowa z formularzem wysyłki stoi obok danych logowania tunelu i gniazda sterującego, a luka w jednym sięga drugiego. Osobne konta, osobne jednostki usług i osobne systemy plików zmniejszają tę ekspozycję bez kupowania drugiej maszyny.

Rywalizacja o zasoby liczy się równie mocno. Kopia zapasowa przez tunel i zajęty proces webowy konkurują o tę samą linię wysyłania i ten sam dysk, a awaria wygląda jak wolna witryna, nie jak zatkany tunel. Zdecyduj, które obciążenie wygrywa, przed incydentem, i ogranicz tunel, żeby witryna dalej odpowiadała.

Żaden z tych układów nie jest odizolowany tylko dlatego, że obie usługi działają. Możliwość hostowania ich razem to początek projektu, a praca nad izolacją czyni go obronnym.

Rozstrzygnij to na hoście próbnym czterema poleceniami

Przed migracją wynajmij najmniejszą instancję docelowego produktu na godzinę i sprawdź cztery możliwości bezpośrednio. Zgadywanie z tabeli funkcji marnuje mniej pieniędzy niż rok z niewłaściwym planem, ale znacznie więcej czasu.

Uruchom te polecenia na hoście próbnym i czytaj błędy jako odpowiedzi, nie przeszkody:

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

Pierwsze dwie linie mówią, czy urządzenie tunelowe może w ogóle istnieć. Trzecia donosi, czy host może przekazywać pakiety, a czwarta pokazuje, co już nasłuchuje, żeby konflikt portów złapać wcześnie. Dostawca, który zawodzi na drugiej linii, może nadal wspierać implementację w przestrzeni użytkownika, więc pytając ich pomoc techniczną, nazwij mechanizm, którego potrzebujesz, a nie kategorię produktu.