Què ha de permetre un VPS abans de poder allotjar la teva VPN

La instància arrenca, les instal·lacions de paquets tenen èxit i fins i tot el servei informa d’un estat en execució, però res no es connecta. Aquest patró és habitual als servidors privats virtuals, perquè un convidat que arriba còmodament a internet encara pot ser incapaç de crear la interfície que vol el teu protocol. Cinc comprovacions separen un amfitrió que pot servir un túnel d’un que només sembla preparat, i la primera comprovació que falla sol explicar tota la resta. Cadascuna és barata d’executar i acaba en una decisió, no en una nota.

Confirma la interfície que necessita el protocol

OpenVPN sobre TUN necessita el dispositiu de caràcters i el mòdul del nucli que hi ha al darrere; WireGuard necessita el seu propi suport al nucli o una implementació en espai d’usuari amb expectatives coincidents. Els contenidors gestionats poden compartir un nucli d’amfitrió que mai no exposa el dispositiu, i algunes plataformes prohibeixen crear interfícies de túnel directament, sigui quina sigui la instal·lació.

Prova la capacitat en lloc de llegir una pàgina de suport, perquè les etiquetes de màrqueting canvien més de pressa que els límits subjacents. Una llista de funcions escrita per a un pla pot no descriure el nucli on el convidat s’executa realment. Dues ordres curtes responen la pregunta per als protocols d’ús comú, i totes dues es netegen després. Les ordres següents no creen res permanent i s’eliminen immediatament.

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 rebuig al primer parell significa que TUN no està disponible i que el mode predeterminat d’OpenVPN no pot arrencar; un rebuig a l’última línia significa que falta la interfície de nucli de WireGuard. La documentació del nucli sobre TUN/TAP descriu el dispositiu que exerceix la primera comprovació. Cap de les dues fallades no es repara reinstal·lant el paquet VPN.

Recorda que el camí d’entrada té dos propietaris

Les regles de xarxa del proveïdor i el tallafoc del convidat són sistemes separats, i el trànsit ha de sobreviure a tots dos. Un oient lligat al convidat no significa res si el grup de seguretat del proveïdor descarta el port, i una regla oberta del proveïdor no fa res si el convidat rebutja el paquet. Verifica l’oient, després les regles del convidat, després el panell del proveïdor, en aquest ordre, i confirma tant el protocol com el número de port. Saltar primer al panell del proveïdor és com la gent acaba obrint un rang que no necessitava.

UDP és la víctima habitual: moltes plataformes permeten TCP per defecte i tracten les regles UDP com una entrada a part. Si la instància és darrere del NAT del proveïdor en lloc de tenir una adreça pública, el reenviament de ports al costat del proveïdor es converteix en una tercera configuració per conciliar.

Planifica el camí de tornada, no només la sortida

El servei de túnel complet necessita el reenviament activat, un esquema de traducció o encaminament per al trànsit dels clients i un camí de tornada que arribi al conjunt de clients. Obrir un oient no en proporciona cap. Un túnel que s’estableix però no transporta trànsit útil normalment falla aquí, no a l’autenticació. Tracta un intercanvi de claus correcte com l’inici del diagnòstic, no com el seu final.

Escriu el pla com tres decisions concretes: quin rang d’origen reben els clients, com surt el seu trànsit cap a internet i com troben el camí de tornada les respostes. Després confirma que el nucli està d’acord amb el pla abans de provar un client, perquè una discrepància silenciosa no es confongui amb un error del costat del client.

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

Decideix l’assumpte IPv6 explícitament

IPv6 arriba per diversos mecanismes que es comporten de manera diferent per a una passarel·la: una adreça a la instància, un prefix encaminat o res. Només un prefix encaminat permet al servidor lliurar adreces als clients de la manera habitual. Suposar que una adreça IPv6 funcional a l’amfitrió implica un prefix de client utilitzable és un error que apareix més tard com una connectivitat mig trencada. És el tipus de fallada que sobreviu a totes les proves fetes només amb IPv4.

Si el proveïdor no encamina cap prefix, decideix si el túnel és només IPv4 i si cal dir-ho als clients. Una absència documentada és més segura que una configuració parcial que envia silenciosament les destinacions IPv6 a un forat negre per als usuaris connectats.

Demostra-ho des d’un client extern

L’estat local del servei descriu un procés en un amfitrió. La prova útil és un client autoritzat en una xarxa diferent, que es connecta amb el perfil que vols distribuir, després arriba a una aplicació i resol un nom. Torna a connectar-te un cop, perquè un túnel que només funciona al primer intent no compleix el requisit que més importa a la pràctica.

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

Mantén els fonaments operatius al costat de la prova: espai per a actualitzacions, registres limitats, accés administratiu que no depengui del túnel, una consola de recuperació i una nota sobre què passa amb els perfils dels clients quan la instància es reconstrueix i la seva adreça pública canvia. Si una interfície o un model de reenviament necessari simplement no hi és, cap canvi al costat del client no el proporcionarà, i el següent pas honest és un altre tipus d’instància, no més configuració.