As definições de VPN do Mac não iniciam um servidor: onde vive o gateway

Dois trabalhos diferentes usam o nome VPN no macOS, e o painel de definições trata apenas de um deles. Se quer que o tráfego deste Mac saia através de um fornecedor ou de um gateway remoto, basta uma entrada de cliente. Se quer chegar à impressora, ao NAS ou a uma página de administração da sua rede doméstica a partir de um quarto de hotel, algo nessa rede tem de aceitar ligações de fora, e um Mac atual não é esse algo de origem. Três perguntas determinam em que caso está, e vale a pena respondê-las antes de escrever um endereço num campo.

Uma entrada de cliente nomeia um destino, não um ouvinte

Em Definições do Sistema > Rede > VPN no macOS Ventura e posteriores, os campos que as versões antigas guardam em Preferências de Rede descrevem como chegar ao endpoint de outra pessoa: um endereço de servidor, um ID remoto, uma conta ou certificado e regras opcionais de ligação a pedido. Guardar essa entrada armazena uma ligação na configuração de rede do seu Mac. Nada no processo liga uma porta, abre um ouvinte ou inscreve um utilizador remoto.

Pode verificar isto a partir da shell. Num Mac que suspeita estar a servir, execute sudo lsof -nP -iUDP e procure as portas que o seu protocolo usa: 500 e 4500 para IKEv2, 1194 para a predefinição do OpenVPN, 51820 para WireGuard. Uma máquina só cliente mostra sockets emparelhados com um endereço e porta remotos, não uma ligação universal que qualquer coisa na internet pudesse alcançar. Os túneis que correm dentro de uma Network Extension podem esconder-se do lsof, por isso verifique também o painel de estado da aplicação; o que não encontrará é uma preferência da Apple que transforme este Mac no gateway.

Três perguntas separam os dois papéis

Resolva-as por ordem. A primeira costuma decidir o resto, e a terceira é onde a maior parte do planeamento específico do Mac falha.

1. Quem começa a conversa? Se o seu Mac marca para fora e o outro lado responde, precisa de um cliente. Se os dispositivos na internet tiverem de marcar para dentro para chegar à sua rede, precisa de um gateway com um ponto de entrada público, e o Mac pode continuar cliente desse gateway.

2. O que tem de estar acessível enquanto o túnel está ativo? Um serviço num anfitrião é uma decisão de reencaminhamento de portas. Uma sub-rede inteira, incluindo resolução de nomes, é uma decisão de encaminhamento e DNS, e muda o que o gateway tem de reencaminhar, não o que diz a entrada de cliente.

3. Que versão do sistema executa a extremidade que aceita? Para os Mac essa pergunta tem uma resposta dura. A Apple lista a VPN como removida do macOS Server 5.7.1, e a própria aplicação macOS Server foi descontinuada a 21 de abril de 2022; o aviso do histórico do serviço é a página a ler quando um tutorial antigo o leva por uma caixa de serviço VPN que já não existe.

Quando a primeira resposta é “alguém de fora inicia”, deixe de procurar um interruptor no painel de cliente do Mac e vá escolher o anfitrião que vai terminar o túnel.

Onde o gateway pode viver em vez disso

Quatro disposições cobrem a maioria dos casos domésticos e de pequeno escritório. Um router com um modo servidor genuíno, em vez de um modo cliente com outra etiqueta, termina o túnel na margem e mantém baixo o número de anfitriões, ao custo de ficar preso ao suporte de protocolos desse firmware. Um NAS ou um mini PC sempre ligado corre o pacote de servidor do fabricante e deixa-lhe registos que pode ler. Uma pequena VM na nuvem dá-lhe um endereço público que controla e chega a casa por um segundo túnel. Uma camada mesh construída sobre WireGuard, ou um serviço gerido que retransmite entre pares, evita o reencaminhamento de portas de entrada fazendo ambos os extremos marcar para fora.

A fronteira entre essas opções é normalmente a sua ligação à internet, não o software. Se o ISP o colocar atrás de NAT de nível de operadora, nenhuma quantidade de reencaminhamento de portas no router produz um ponto de entrada alcançável, e uma disposição com relay ou mesh é a resposta honesta. Compare o endereço WAN que o router reporta com o endereço que o mundo exterior vê; se diferirem e o valor do router estiver num intervalo privado ou partilhado, planeie o caso do relay.

Qualquer anfitrião que escolher, reencaminhe um protocolo numa porta em vez de um intervalo, e mantenha o Mac fora do caminho de entrada a menos que esse produto específico documente um papel de servidor para a versão de macOS que executa.

Confirme o papel antes de distribuir perfis

No gateway candidato, prove que existe um ouvinte em vez de confiar que o instalador criou um. No macOS isso significa sudo lsof -nP -iUDP filtrado para as portas acima, mais sudo pfctl -s nat se as regras de filtro de pacotes fizerem parte do desenho. No Linux, ss -lunp mostra os mesmos factos sem ambiguidade.

Depois teste de fora da rede, usando o próprio protocolo. O ping prova pouco: o ICMP é muitas vezes filtrado e não diz nada sobre UDP 51820. Um handshake de cliente com registo detalhado, executado a partir de um telefone em dados móveis, é o teste real mais barato porque percorre o mesmo caminho que um colega remoto vai percorrer.

Só depois toca nos perfis de cliente. No Mac, scutil --nc list imprime os serviços VPN que o sistema conhece; se o gateway que acabou de construir não estiver entre eles, está a configurar uma máquina diferente da que testou. Se o handshake funcionar na LAN mas falhar de fora, a falha está no caminho de entrada: regra NAT, CGNAT do fornecedor ou firewall no gateway, por essa ordem.

Antes de construir seja o que for, resolva quatro pontos:

• Que lado inicia a ligação, o seu Mac ou um dispositivo remoto.
• Se a versão do sistema e o produto do anfitrião que aceita suportam mesmo um papel de servidor.
• Se o seu ISP lhe dá sequer um endereço público alcançável.
• Que única porta e protocolo o gateway aceitará, e que serviço por trás responde.

O passo seguinte é concreto: escolha o anfitrião do gateway, confirme o ouvinte de fora, e só então crie no Mac a entrada de cliente que aponta para ele.