Hosting web o un VPS: il tuo piano può eseguire un server VPN?

Un sito che funziona è la prova che un fornitore sa servire HTTP, non che tu controlli una macchina. Tra un piano condiviso, un’applicazione gestita e un server autogestito c’è un ampio divario in ciò che l’account può fare alla rete. Decidi quale lato di quel divario serve al tuo progetto VPN prima di pagare un altro anno. Quattro capacità separano i due casi, e nessuna compare in un listino prezzi.

Che cosa dà davvero ogni piano

Il confronto utile non è il prezzo o la dimensione del disco, ma l’autorità. Chiedi che cosa può avviare l’account, a quali funzioni del kernel arriva, quali porte accettano traffico in entrata e se il traffico ammesso può uscire di nuovo altrove.

La maggior parte dei prodotti di hosting rientra in tre forme, e solo l’ultima è un server generico:

L’account shell è la solita fonte di confusione. Il trasferimento di file o l’accesso a compiti pianificati può sembrare amministrazione mentre il processo è confinato a una directory e a un piccolo insieme di operazioni consentite.

Quattro capacità che decidono la risposta

Prendile in ordine, perché un fallimento al primo passo rende il resto irrilevante.

Primo, il software deve girare come processo di lunga durata che sopravvive alla manutenzione. Secondo, l’implementazione deve poter creare la propria interfaccia virtuale; su Linux di solito significa aprire /dev/net/tun con il permesso amministrativo pertinente, come la documentazione del kernel su TUN/TAP descrive, anche se non ogni progetto VPN usa quel dispositivo. Terzo, i client devono raggiungere l’ascoltatore sull’indirizzo pubblico, il trasporto e la porta che intendi, e un proxy inverso web che accetta HTTPS non dice nulla su un protocollo non correlato sullo stesso numero. Quarto, il traffico ammesso deve poter proseguire, con rotte, inoltro e qualsiasi traduzione realmente supportata.

I termini di servizio stanno accanto a quei quattro e non sono affatto tecnici. Le soglie di traffico illimitato descrivono di solito richieste web, non un tunnel che trasporta i download altrui. Leggi la sezione sull’uso accettabile prima di progettare intorno ad essa, e tieni presente l’accesso di ripristino per il giorno in cui il servizio non partirà.

Dove si ferma un account di sito web

Un piano di sito web di solito esegue il tuo codice dentro un runtime gestito con un punto di ingresso fisso. Anche quando c’è un binario del tunnel, il processo può non avere il permesso di aprire un nodo di dispositivo, occupare una porta privilegiata o modificare la tabella di routing. Quelle restrizioni sono il prodotto, non una svista.

Per questo un plugin che promette una VPN di solito si rivela un proxy verso altrove. Se l’account attuale offre solo controlli del sito web, il passo onesto è un server separato, non la ricerca del modulo che sblocca l’autorità mancante.

Quando un solo host deve eseguire entrambe le cose

La condivisione è possibile e a volte sensata, ma trattala come una decisione di sicurezza e non come una comodità. Un’applicazione web con un modulo di caricamento sta accanto a credenziali del tunnel e a un socket di controllo, e un exploit in una raggiunge l’altra. Account separati, unità di servizio separate e filesystem separati riducono quell’esposizione senza comprare una seconda macchina.

La contesa delle risorse conta altrettanto. Un backup sul tunnel e un processo web occupato competono per lo stesso uplink e lo stesso disco, e il guasto sembra un sito lento invece di un tunnel saturo. Decidi quale carico vince prima dell’incidente, e limita il tunnel perché il sito continui a rispondere.

Nessuna delle due disposizioni è isolata solo perché entrambi i servizi girano. La capacità di ospitarli insieme è l’inizio del progetto, e il lavoro di isolamento è ciò che lo rende difendibile.

Risolvilo su un host di prova con quattro comandi

Prima di migrare, affitta l’istanza più piccola del prodotto scelto per un’ora e prova le quattro capacità direttamente. Indovinare da una tabella di funzioni spreca meno denaro di un anno con il piano sbagliato, ma molto più tempo.

Esegui questi sull’host di prova e leggi i fallimenti come risposte, non come ostacoli:

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

Le prime due righe dicono se un dispositivo di tunnel può esistere. La terza riporta se l’host può inoltrare pacchetti, e la quarta mostra che cosa è già in ascolto perché un conflitto di porte si colga presto. Un fornitore che fallisce la seconda riga può comunque supportare un’implementazione nello spazio utente, quindi nomina il meccanismo che ti serve, non la categoria di prodotto, quando chiedi al loro supporto.