Partilhe uma ligação VPN com todos os dispositivos da sua LAN

Um portátil mantém o túnel, o resto da casa quer o mesmo acesso, e a primeira tentativa é apontar tudo para a máquina ligada. Falha por razões que nada têm que ver com a VPN: o host recetor tem de encaminhar o pacote, reescrever a origem e garantir que as respostas encontram o caminho de volta. Falhe um dos três e o portátil ligado continua a funcionar enquanto todos os outros dispositivos ficam sem resposta. A solução é um desenho de encaminhamento, não uma definição do cliente.

Porque falha apontar os dispositivos para o host

Um host que recebe um pacote endereçado a uma rede remota torna-se um router nesse momento, quer alguém o tenha configurado como tal, quer não. O encaminhamento está desativado por predefinição no Linux e no Windows, a menos que uma funcionalidade o ative. A tradução de endereços importa porque o lado remoto tem de saber para onde enviar as respostas, e um endereço LAN privado não significa nada para ele. A rota de retorno é a terceira peça, e é aquela de que as pessoas se esquecem quando o primeiro ping parece ter êxito.

Diagnostique por essa ordem em vez de ligar e desligar definições ao acaso. Cada peça em falta produz um sintoma ligeiramente diferente.

Ative o encaminhamento e a tradução de endereços no host

Duas alterações no host ligado cobrem as duas primeiras peças: ativar o encaminhamento IPv4 e traduzir o tráfego da LAN para a interface do túnel.

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

Guarde o valor sysctl num ficheiro em /etc/sysctl.d e verifique novamente a regra de masquerade após um reinício, porque as interfaces das firewalls podem limpar cadeias personalizadas. No Windows, a funcionalidade de partilha executa os dois passos, mas também reendereça o adaptador LAN para uma sub-rede fixa e limpa o seu gateway, o que quebra o endereçamento estático e o redirecionamento de portas. Restaure o caminho do router para o host no novo endereço antes de concluir que a partilha falhou. Depois observe os contadores da regra a aumentar enquanto um segundo dispositivo envia tráfego.

Dê à LAN um caminho que sobreviva a reinícios

Os outros dispositivos precisam de uma rota para o prefixo remoto, e as duas formas de a fornecer diferem no alcance do impacto.

ip route add 10.8.0.0/24 via 192.168.1.20 dev eth0

Apontar o gateway predefinido de um cliente para o host envia todo o seu tráfego através do host, incluindo impressão local e partilha de ficheiros, pelo que coisas não relacionadas param quando o host suspende. Adicionar uma rota específica no router para o prefixo remoto é mais estreito: só os destinos atrás do túnel vão para a máquina ligada, e o resto da LAN continua a funcionar. As sub-redes acima são exemplos, por isso substitua-as pelos seus próprios intervalos de LAN e de túnel. De qualquer forma, teste a partir de um segundo dispositivo com o túnel ativo e depois inativo.

Verifique o MTU antes de culpar o túnel

Os túneis reduzem o tamanho útil do pacote, e o segundo dispositivo não faz ideia. Transferências grandes e handshakes TLS bloqueiam enquanto os pedidos pequenos têm êxito.

ping -M do -s 1400 10.8.0.5

Uma resposta prova que esse tamanho atravessa o caminho sem fragmentação; um tempo limite significa que o custo da encapsulação empurrou o pacote para além do MTU do túnel. Baixe o MTU na interface de partilha ou limite o tamanho máximo do segmento no dispositivo que encaminha, e depois repita o mesmo teste. Teste primeiro o mesmo tamanho do lado da LAN, porque uma falha local aponta para a LAN e não para o túnel. Registe o tamanho que funciona, pois uma alteração posterior do fornecedor ou do túnel pode alterá-lo.

Para um único dispositivo adicional, a partilha a partir do host chega. Para uma casa, ponha a rota no router. Quando o acesso tiver de sobreviver à saída do portátil consigo, o próprio túnel pertence a um gateway dedicado.