Porta de origem do cliente contra o listener do servidor num fluxo VPN
Compare os dois números de porta num túnel: o listener fixo do servidor e a origem efémera do cliente, e como a tradução do router fica entre eles.
Na mesma conversa aparecem dois números e nenhum dos dois está errado. O registo do servidor mostra o listener que oferece o serviço, o portátil mostra o socket que enviou o datagrama, e um router pelo meio pode reescrever o segundo à saída. Comparar as extremidades da conversa é mais útil do que comparar os dígitos. A comparação abaixo mantém separados o listener, o socket do cliente e a origem traduzida, porque respondem a perguntas diferentes.
Dois números que descrevem extremidades opostas
A porta configurada do servidor é o destino para onde o cliente marca. É fixada pela política, aparece no perfil e tem de estar aberta do lado do servidor. A porta de origem do cliente é escolhida localmente, normalmente a partir do intervalo efémero, e existe para que a resposta tenha onde aterrar. Pode mudar a cada reconexão, e nada do projeto depende de que seja estável.
Um router pelo meio pode reescrever essa origem no seu próprio mapeamento 'NAT'. Por isso o número observado no servidor muitas vezes não tem qualquer relação com o que o portátil escolheu.
Onde o número de origem muda à saída
Tome um exemplo inventado de IPv4: um cliente atrás de um router que traduz, um servidor com um único listener 'UDP' e um único datagrama que atravessa ambos. A tabela nomeia cada extremidade e o que lhe acontece, em vez de reproduzir o pacote em três pontos de observação.
| Endpoint | What stays fixed | What changes on reconnect | Who owns it |
|---|---|---|---|
| Server listener | The service port and the address the profile names | Nothing; the listener does not follow the client | The server operator |
| Client socket | The destination it dials | The local source port, chosen per socket | The client, or its operating system |
| Translated source | Usually the public address of the router | The port, and sometimes the address after a network switch | The NAT device or the upstream carrier |
O destino é constante em cada linha, e só muda a identidade da origem. Requisitos de UDP NAT distinguem um endereço e uma porta internos do mapeamento externo, que é exatamente a diferença entre a segunda e a terceira linha. Um router pode conservar a porta de origem do cliente ou escolher outra; conservá-la não é algo que uma aplicação deva assumir.
Leia as três extremidades nos próprios anfitriões
As listas abaixo vêm de três máquinas diferentes e, em conjunto, mostram toda a conversa. Execute a primeira no servidor, a segunda no cliente e a terceira onde existir o mapeamento. Uma única linha de registo nunca mostra as três.
ss -lunp 'sport = :1194'
ss -unp | grep 1194
conntrack -L -p udp | grep 1194A primeira lista prova que o servidor está ligado à porta do serviço e mostra que processo a detém. A segunda mostra o socket local do cliente e o destino para onde marcou. A terceira mostra o mapeamento criado pelo router, e é o único lugar onde a origem traduzida aparece. Leia-as por essa ordem e os dois números deixam de parecer contraditórios.
O que uma reconexão muda, e o que não muda
Alguns routers conservam a porta de origem do cliente quando está livre, e outros atribuem uma diferente de cada vez. Os dois comportamentos são normais, e uma aplicação que exija o primeiro vai quebrar no segundo. Uma mudança de mapeamento após uma reconexão ou uma mudança de rede não é uma falha do servidor: o cliente abre um novo socket, o router atribui o que tem e o servidor vê uma nova origem no mesmo listener. O que seria falha é esperar que o servidor aceite tráfego endereçado a uma porta de cliente arbitrária.
Os clientes OpenVPN da comunidade obtêm este comportamento através de nobind, que deixa o sistema operativo escolher a porta local; a porta remota continua a vir do perfil. Ligá-la explicitamente é uma decisão deliberada, não um requisito do protocolo. O servidor continua a oferecer uma extremidade enquanto os clientes escolhem as suas próprias identidades locais.
Etiquete as camadas separadamente no registo
Dentro do túnel há uma segunda conversa com portas próprias. Um pedido HTTPS transportado pelo túnel tem destino TCP 443, enquanto a ligação cifrada exterior usa UDP 1194, pelo que mudar a porta de origem exterior não altera nada no serviço interior.
Mesmo na camada exterior, o protocolo importa. UDP 1194 e TCP 1194 são extremidades diferentes, e um listener 'TCP' nunca receberá um datagrama UDP por o número coincidir. Ao documentar uma implantação, etiquete o listener do servidor, o socket do cliente e a origem traduzida como três coisas distintas, e acrescente o transporte a cada uma.
Depois deixe a política seguir os papéis. O servidor abre o transporte previsto no seu listener e continua a autenticar o par; a firewall do cliente admite as respostas ao seu próprio intercâmbio de saída sem publicar um serviço de entrada. Um filtro sem estado precisa da direção de retorno escrita explicitamente, e é essa a razão prática pela qual a distinção importa para além dos diagramas arrumados.