Que debe permitir un VPS antes de poder aloxar a túa VPN

A instancia arrinca, as instalacións de paquetes teñen éxito e o servizo mesmo informa dun estado en execución, pero nada se conecta. Ese patrón é habitual nos servidores privados virtuais, porque un convidado que chega comodamente a internet aínda pode ser incapaz de crear a interface que quere o teu protocolo. Cinco comprobacións separan un host que pode servir un túnel dun que só parece preparado, e a primeira comprobación que falla adoita explicar todo o demais. Cada unha é barata de executar e remata nunha decisión, non nunha nota.

Confirma a interface que necesita o protocolo

OpenVPN sobre TUN necesita o dispositivo de caracteres e o módulo do núcleo que hai detrás; WireGuard necesita o seu propio soporte no núcleo ou unha implementación en espazo de usuario con expectativas coincidentes. Os contedores xestionados poden compartir un núcleo de host que nunca expón o dispositivo, e algunhas plataformas prohiben crear interfaces de túnel sen máis, independentemente do instalado.

Proba a capacidade en lugar de ler unha páxina de soporte, porque as etiquetas de márketing cambian máis rápido que os límites subxacentes. Unha lista de funcións escrita para un plan pode non describir o núcleo no que o convidado se executa realmente. Dous comandos curtos responden á pregunta para os protocolos de uso común, e ambos limpan tras de si. Os comandos de abaixo non crean nada permanente e elimínanse de inmediato.

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 rexeitamento no primeiro par significa que TUN non está dispoñible e que o modo predeterminado de OpenVPN non pode arrincar; un rexeitamento na última liña significa que falta a interface de núcleo de WireGuard. A documentación do núcleo sobre TUN/TAP describe o dispositivo que exercita a primeira comprobación. Ningún dos dous fallos se repara reinstalando o paquete VPN.

Lembra que a ruta de entrada ten dous donos

As regras de rede do provedor e o cortalumes do convidado son sistemas separados, e o tráfico debe sobrevivir a ambos. Un oínte vinculado no convidado non significa nada se o grupo de seguridade do provedor descarta o porto, e unha regra aberta do provedor non fai nada se o convidado rexeita o paquete. Verifica o oínte, logo as regras do convidado, logo o panel do provedor, nesa orde, e confirma tanto o protocolo como o número de porto. Saltar primeiro ao panel do provedor é como a xente acaba abrindo un rango que non necesitaba.

UDP é a vítima habitual: moitas plataformas permiten TCP por defecto e tratan as regras UDP como unha entrada aparte. Se a instancia está detrás do NAT do provedor en lugar de ter un enderezo público, o reenvío de portos no lado do provedor convértese nunha terceira configuración que conciliar.

Planifica a ruta de volta, non só a saída

O servizo de túnel completo necesita o reenvío activado, un esquema de tradución ou encamiñamento para o tráfico dos clientes e unha ruta de volta que chegue ao conxunto de clientes. Abrir un oínte non achega nada diso. Un túnel que se establece pero non transporta tráfico útil adoita fallar aquí, non na autenticación. Trata unha aperta de mans correcta como o inicio do diagnóstico, non como o seu final.

Escribe o plan como tres decisións concretas: que rango de orixe reciben os clientes, como sae o seu tráfico cara a internet e como atopan o camiño de volta as respostas. Despois confirma que o núcleo está de acordo co plan antes de probar un cliente, para que unha discrepancia silenciosa non se confunda cun fallo do lado do cliente.

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

Decide o asunto IPv6 explicitamente

IPv6 chega por varios mecanismos que se comportan de forma distinta para unha pasarela: un enderezo na instancia, un prefixo encamiñado ou nada. Só un prefixo encamiñado permite ao servidor entregar enderezos aos clientes do xeito habitual. Supor que un enderezo IPv6 funcional no host implica un prefixo de cliente utilizábel é un erro que aparece máis tarde como conectividade medio rota. É o tipo de fallo que sobrevive a todas as probas realizadas só con IPv4.

Se o provedor non encamiña ningún prefixo, decide se o túnel é só IPv4 e se hai que dicirllelo aos clientes. Unha ausencia documentada é máis segura que unha configuración parcial que manda en silencio os destinos IPv6 a un burato negro para os usuarios conectados.

Demostrao desde un cliente externo

O estado local do servizo describe un proceso nun host. A proba útil é un cliente autorizado noutra rede, que se conecta co perfil que pensas distribuír, logo chega a unha aplicación e resolve un nome. Vólvete conectar unha vez tamén, porque un túnel que só funciona ao primeiro intento non cumpre o requisito que máis importa na 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 os fundamentos operativos xunto á proba: espazo para actualizacións, rexistros acoutados, acceso administrativo que non dependa do túnel, unha consola de recuperación e unha nota sobre que pasa cos perfís dos clientes cando a instancia se reconstrúe e cambia o seu enderezo público. Se unha interface ou un modelo de reenvío necesario simplemente non está dispoñible, ningún cambio do lado do cliente o achegará, e o seguinte paso honesto é outro tipo de instancia, non máis configuración.