Cosa deve consentire un VPS prima di poter ospitare la tua VPN

L’istanza si avvia, le installazioni dei pacchetti riescono e il servizio segnala persino uno stato attivo, ma nulla si connette. Questo schema è comune sui server privati virtuali, perché un ospite che raggiunge comodamente internet può comunque essere incapace di creare l’interfaccia che il tuo protocollo richiede. Cinque controlli separano un host in grado di servire un tunnel da uno che sembra solo pronto, e il primo controllo che fallisce di solito spiega tutto il resto. Ognuno è economico da eseguire e termina con una decisione anziché con una nota.

Conferma l’interfaccia necessaria al protocollo

OpenVPN su TUN richiede il dispositivo a caratteri e il modulo del kernel dietro di esso; WireGuard richiede il proprio supporto nel kernel o un’implementazione in spazio utente con aspettative corrispondenti. I contenitori gestiti possono condividere un kernel host che non espone mai il dispositivo, e alcune piattaforme vietano del tutto la creazione di interfacce tunnel, indipendentemente da ciò che è installato.

Verifica la capacità invece di leggere una pagina di supporto, perché le etichette di marketing cambiano più rapidamente dei limiti sottostanti. Un elenco di funzioni scritto per un piano potrebbe non descrivere il kernel su cui l’ospite viene effettivamente eseguito. Due comandi brevi rispondono alla domanda per i protocolli di uso comune, ed entrambi puliscono dietro di sé. I comandi qui sotto non creano nulla di permanente e vengono rimossi subito.

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

Un rifiuto sulla prima coppia significa che TUN non è disponibile e che la modalità predefinita di OpenVPN non può avviarsi; un rifiuto sull’ultima riga significa che manca l’interfaccia kernel di WireGuard. La documentazione del kernel su TUN/TAP descrive il dispositivo che il primo controllo esercita. Nessuno dei due errori si risolve reinstallando il pacchetto VPN.

Ricorda che il percorso in ingresso ha due proprietari

Le regole di rete del provider e il firewall dell’ospite sono sistemi separati, e il traffico deve sopravvivere a entrambi. Un listener associato sull’ospite non significa nulla se il gruppo di sicurezza del provider scarta la porta, e una regola aperta del provider non fa nulla se l’ospite rifiuta il pacchetto. Verifica il listener, poi le regole dell’ospite, poi il pannello del provider, in quest’ordine, e conferma sia il protocollo sia il numero di porta. Saltare subito al pannello del provider è il modo in cui le persone finiscono per aprire un intervallo di cui non avevano bisogno.

UDP è la vittima abituale: molte piattaforme consentono TCP per impostazione predefinita e trattano le regole UDP come una voce separata. Se l’istanza si trova dietro il NAT del provider invece di avere un indirizzo pubblico, l’inoltro delle porte lato provider diventa una terza configurazione da conciliare.

Pianifica il percorso di ritorno, non solo l’uscita

Il servizio in tunnel completo richiede l’inoltro abilitato, uno schema di traduzione o routing per il traffico dei client e un percorso di ritorno che raggiunga il pool di client. Aprire un listener non fornisce nulla di tutto ciò. Un tunnel che si stabilisce ma non trasporta traffico utile di solito fallisce qui, non all’autenticazione. Tratta una stretta di mano riuscita come l’inizio della diagnosi, non come la sua fine.

Scrivi il piano come tre decisioni concrete : quale intervallo di origine ricevono i client, come il loro traffico esce verso internet e come le risposte ritrovano la strada. Poi conferma che il kernel sia d’accordo con il piano prima di testare un client, così che una discrepanza silenziosa non venga scambiata per un guasto lato client.

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

Decidi esplicitamente la questione IPv6

IPv6 arriva attraverso diversi meccanismi che si comportano in modo diverso per un gateway: un indirizzo sull’istanza, un prefisso instradato o nulla. Solo un prefisso instradato consente al server di assegnare indirizzi ai client nel modo consueto. Supporre che un indirizzo IPv6 funzionante sull’host implichi un prefisso client utilizzabile è un errore che emerge più tardi come connettività mezzo rotta. È il tipo di guasto che sopravvive a ogni test eseguito solo con IPv4.

Se il provider non instrada alcun prefisso, decidi se il tunnel è solo IPv4 e se i client devono esserne informati. Un’assenza documentata è più sicura di una configurazione parziale che manda silenziosamente le destinazioni IPv6 in un buco nero per gli utenti connessi.

Dimostralo da un client esterno

Lo stato locale del servizio descrive un processo su un host. Il test utile è un client autorizzato su un’altra rete, che si connette con il profilo che intendi distribuire, poi raggiunge un’applicazione e risolve un nome. Riconnettiti anche una volta, perché un tunnel che funziona solo al primo tentativo non soddisfa il requisito che conta di più in pratica.

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

Tieni le basi operative accanto al test: spazio per gli aggiornamenti, log limitati, accesso amministrativo che non dipenda dal tunnel, una console di ripristino e una nota su cosa succede ai profili dei client quando l’istanza viene ricostruita e il suo indirizzo pubblico cambia. Se un’interfaccia o un modello di inoltro richiesto semplicemente non è disponibile, nessuna modifica lato client lo fornirà, e il prossimo passo onesto è un altro tipo di istanza, non più configurazione.