Por que o NAT doméstico não protege a sua interface VPN

Os portáteis atrás de um router doméstico sem reencaminhamento de portas continuam a aceitar ligações SSH que chegam pela VPN. Não é uma contradição, porque dois dispositivos diferentes julgam dois pacotes diferentes. O router reencaminha o transporte cifrado, e o host decide o que fazer com o pacote desencriptado que chega à sua interface de túnel. Manter essas duas decisões separadas é todo o exercício.

O router reencaminha o túnel, o host julga o pacote

Desenhe o caminho da origem remota até ao serviço antes de olhar para uma única regra. O troço exterior é o transporte VPN, tratado pelo router e pela gateway. O troço interior começa quando o ponto final retira a camada do túnel e o host recebe um pacote endereçado ao seu endereço VPN.

Junte esses dois troços e o router fica com o mérito de uma decisão que o host toma. Uma página de reencaminhamento de portas ou um registo do router descrevem apenas conversas exteriores, e nenhum diz que tráfego desencriptado o host aceitará. O host aplica a sua própria política de entrada ao pacote interior, tal como a qualquer pacote que chegue a uma interface. É nessa política que a questão da exposição fica realmente resolvida.

Um ouvinte wildcard não é um serviço público

No Linux, ligar a INADDR_ANY significa todos os endereços locais, pelo que um serviço pode responder numa interface de túnel que nunca nomeou. A referência de sockets IP descreve essa ligação, e vale a pena lê-la antes de tirar conclusões de uma lista de ouvintes. Uma entrada wildcard é um facto sobre o socket, não uma afirmação sobre a alcançabilidade.

As duas linhas abaixo são o mesmo serviço em duas ligações diferentes, e a diferença é toda a resposta à questão de saber se a interface importa. Leia em que endereço está o socket antes de qualquer outra coisa.

ss -lntp "sport = :22"
LISTEN 0 4096 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=812,fd=3))
LISTEN 0 4096 10.8.0.6:22 0.0.0.0:* users:(("sshd",pid=812,fd=4))

Nomeie a disposição que poderia alcançar a porta

Três disposições colocam um pacote nessa interface, e têm donos diferentes. Nomear a correta decide quem tem de mudar uma política.

Um resultado do navegador que mostra um endereço de saída público não diz nada sobre nenhuma das três, porque descreve como o tráfego de saída sai e não o que é permitido ao tráfego de entrada. Trabalhe de trás para a frente a partir do ouvinte e do endereço de origem no registo do serviço. Se a origem for outro par do túnel, a política da gateway é o documento interessante. Se for um endereço traduzido, encontre a tradução antes de mudar uma regra.

Limite o serviço ao caminho que pretendia

Se o SSH só for necessário a partir de um caminho de gestão, escreva esse caminho como um intervalo de origem mais uma interface. Depois limite as regras de entrada do host por interface, destino e origem em vez de por nome de rede, já que um nome que parece privado pode representar qualquer endereço. Deixe uma rota para a pessoa que resolverá o próximo problema.

nft add rule inet filter input iifname "tun0" ip saddr 10.8.0.0/24 tcp dport 22 accept
nft list chain inet filter input

Uma regra que nomeia a interface do túnel e o intervalo de gestão declara a intenção num só lugar. Compare-a com uma regra escrita para a rede Wi-Fi, que não diz nada sobre tráfego de túnel desencriptado. Quando as duas camadas não concordam, a política do host é a que o pacote encontra.

Deixe os inícios de sessão e as correções exatamente onde estão; alcançar uma porta nunca foi o mesmo que ter permissão para a usar. Registe a família de endereços e a hora de qualquer origem desconhecida, e investigue antes de culpar uma funcionalidade ou uma vulnerabilidade. Uma regra que admite todos os pares do túnel é um desenho diferente de uma que admite uma sub-rede de gestão, e nenhuma linha de registo dirá qual era pretendida.

Aceite a correção com um sucesso e uma recusa

Prove as duas metades: uma ligação aprovada tem sucesso e um caminho excluído é recusado. A recusa é a metade que as pessoas saltam, e é a que mostra que a regra está a trabalhar em vez de estar ao lado de um valor predefinido permissivo. Teste a partir do lado excluído em vez de raciocinar sobre isso.

Repita o par depois de uma reconexão, porque um túnel que volta com outro nome de interface pode contornar silenciosamente uma regra limitada ao antigo. A fronteira que importa é a que o host aplica aos pacotes que recebe realmente.