Hosting web sau un VPS: poate planul tău să ruleze un server VPN?
Hostingul partajat, o aplicație administrată și un server autoadministrat oferă un control diferit asupra rețelei. Compară patru capacități înainte de a cumpăra sau migra ceva.
Un site care funcționează este dovada că un furnizor poate servi HTTP, nu că tu controlezi o mașină. Între un plan partajat, o aplicație administrată și un server autoadministrat există un decalaj mare în ce poate face contul cu rețeaua. Decide de ce parte a acelui decalaj are nevoie proiectul tău VPN înainte de a plăti încă un an. Patru capacități despart cele două situații, și niciuna nu apare într-o listă de prețuri.
Ce oferă de fapt fiecare plan
Comparația utilă nu este prețul sau dimensiunea discului, ci autoritatea. Întreabă ce poate porni contul, la ce funcții ale nucleului ajunge, ce porturi acceptă trafic de intrare și dacă traficul admis poate ieși din nou în altă parte.
Majoritatea produselor de hosting se încadrează în trei forme, și doar ultima este un server de uz general:
| Capability | Website plan | Self-managed server |
|---|---|---|
| Long-running custom process | Usually not permitted | Yours to run under a service manager |
| Virtual network interface | Almost never available | Present when the kernel module and privilege allow it |
| Arbitrary inbound port | Restricted to the web stack | Provider filtering still applies |
| Forwarding for clients | Not offered | Possible once routing and policy are configured |
Contul shell este sursa obișnuită de confuzie. Transferul de fișiere sau accesul la sarcini programate poate părea administrare, în timp ce procesul este limitat la un director și la un set mic de operații permise.
Patru capacități care decid răspunsul
Ia-le în ordine, pentru că un eșec la primul pas face restul irelevant.
În primul rând, software-ul trebuie să ruleze ca proces de lungă durată care supraviețuiește mentenanței. În al doilea rând, implementarea trebuie să poată crea propria interfață virtuală; pe Linux asta înseamnă de obicei deschiderea /dev/net/tun cu permisiunea administrativă relevantă, așa cum documentația nucleului despre TUN/TAP descrie, deși nu orice proiect VPN folosește acel dispozitiv. În al treilea rând, clienții trebuie să ajungă la ascultător pe adresa publică, pe transportul și portul pe care le intenționezi, iar un proxy invers web care acceptă HTTPS nu spune nimic despre un protocol nelegat pe același număr. În al patrulea rând, traficul admis trebuie să poată merge mai departe, cu rute, redirecționare și orice traducere de adrese cu adevărat acceptată.
Termenii serviciului stau lângă acele patru și nu sunt deloc tehnici. Limitele de trafic nelimitat descriu de obicei cereri web, nu un tunel care transportă descărcările altora. Citește secțiunea despre utilizarea acceptabilă înainte de a proiecta în jurul ei, și ține cont de accesul de recuperare pentru ziua în care serviciul nu va porni.
Unde se oprește un cont de site
Un plan de site rulează de obicei codul tău într-un mediu de execuție administrat cu un punct de intrare fix. Chiar dacă există un binar de tunel, procesului îi poate lipsi permisiunea de a deschide un nod de dispozitiv, de a lega un port privilegiat sau de a modifica tabela de rutare. Aceste restricții sunt produsul, nu o scăpare.
De aceea un plugin care promite un VPN se dovedește de obicei un proxy către altundeva. Dacă contul actual oferă doar controale de site, pasul cinstit este un server separat, nu căutarea modulului care deblochează autoritatea lipsă.
Când un singur host trebuie să ruleze ambele
Partajarea este posibilă și uneori rezonabilă, dar trateaz-o ca pe o decizie de securitate, nu ca pe o comozitate. O aplicație web cu formular de încărcare stă lângă acreditările tunelului și un socket de control, iar o vulnerabilitate într-una ajunge la cealaltă. Conturi separate, unități de serviciu separate și sisteme de fișiere separate reduc acea expunere fără a cumpăra o a doua mașină.
Concurența pentru resurse contează la fel de mult. O copie de siguranță prin tunel și un proces web ocupat concurează pentru aceeași linie de urcare și același disc, iar defecțiunea arată ca un site lent, nu ca un tunel saturat. Decide ce sarcină câștigă înainte de incident, și limitează tunelul ca site-ul să continue să răspundă.
Niciuna dintre cele două aranjamente nu este izolată doar pentru că ambele servicii rulează. Capacitatea de a le găzdui împreună este începutul proiectării, iar munca de izolare este cea care o face defendabilă.
Rezolvă-o pe un host de test cu patru comenzi
Înainte de migrare, închiriază cea mai mică instanță a produsului țintă pentru o oră și testează cele patru capacități direct. Ghiceala dintr-un tabel de funcții risipește mai puțini bani decât un an cu planul greșit, dar mult mai mult timp.
Rulează acestea pe hostul de test și citește eșecurile ca răspunsuri, nu ca obstacole:
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 | headPrimele două linii spun dacă un dispozitiv de tunel poate exista măcar. A treia raportează dacă hostul poate redirecționa pachete, iar a patra arată ce ascultă deja, ca un conflict de port să fie prins devreme. Un furnizor care eșuează la a doua linie poate totuși să sprijine o implementare în spațiul utilizatorului, așa că numește mecanismul de care ai nevoie, nu categoria de produs, când întrebi asistența lor.