Porto de orixe do cliente fronte ao listener do servidor nun fluxo VPN
Compare os dous números de porto nun túnel: o listener fixo do servidor e a orixe efémera do cliente, e como a tradución do router queda entre ambos.
Nunha mesma conversa aparecen dous números e ningún dos dous está mal. O rexistro do servidor mostra o listener que ofrece o servizo, o portátil mostra o socket que enviou o datagrama, e un router intermedio pode reescribir o segundo á saída. Comparar os extremos da conversa é máis útil que comparar os díxitos. A comparación de abaixo mantén separados o listener, o socket do cliente e a orixe traducida, porque responden a preguntas distintas.
Dous números que describen extremos opostos
O porto configurado do servidor é o destino ao que marca o cliente. Fíxao a política, aparece no perfil e ten que estar aberto no lado do servidor. O porto de orixe do cliente elíxese localmente, normalmente do rango efémero, e existe para que a resposta teña onde aterrar. Pode cambiar en cada reconexión, e nada do deseño depende de que sexa estable.
Un router intermedio pode reescribir esa orixe na súa propia asignación 'NAT'. Por iso o número que se observa no servidor a miúdo non ten relación co que escolleu o portátil.
Onde cambia o número de orixe á saída
Tome un exemplo inventado de IPv4: un cliente detrás dun router que traduce, un servidor cun só listener 'UDP' e un único datagrama que cruza ambos. A táboa nomea cada extremo e o que lle ocorre, en lugar de reproducir o paquete en tres puntos de observación.
| 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 en cada fila, e só cambia a identidade da orixe. Requisitos de UDP NAT distinguen un enderezo e un porto internos da asignación externa, que é exactamente a diferenza entre a segunda e a terceira fila. Un router pode conservar o porto de orixe do cliente ou escoller outro; conservalo non é algo que unha aplicación deba supoñer.
Lea os tres extremos nos propios hosts
As listas de abaixo veñen de tres máquinas distintas e, xuntas, mostran toda a conversa. Execute a primeira no servidor, a segunda no cliente e a terceira onde exista a asignación. Unha soa liña de rexistro nunca mostra as tres.
ss -lunp 'sport = :1194'
ss -unp | grep 1194
conntrack -L -p udp | grep 1194A primeira lista demostra que o servidor está ligado ao porto do servizo e mostra que proceso o posúe. A segunda mostra o socket local do cliente e o destino ao que marcou. A terceira mostra a asignación que creou o router, e é o único lugar onde aparece a orixe traducida. Léaas nesa orde e os dous números deixan de parecer contraditorios.
Que cambia unha reconexión e que non
Algúns routers conservan o porto de orixe do cliente cando está libre, e outros asignan un distinto cada vez. Ambos os comportamentos son normais, e unha aplicación que esixa o primeiro romperá co segundo. Un cambio de asignación tras unha reconexión ou un cambio de rede non é un fallo do servidor: o cliente abre un socket novo, o router asigna o que ten e o servidor ve unha orixe nova no mesmo listener. O que sería un fallo é esperar que o servidor acepte tráfico dirixido a un porto de cliente arbitrario.
Os clientes OpenVPN da comunidade obteñen este comportamento mediante nobind, que deixa que o sistema operativo escolla o porto local; o porto remoto segue vindo do perfil. Ligalo explicitamente é unha decisión deliberada, non un requisito do protocolo. O servidor segue ofrecendo un extremo mentres os clientes escollen as súas propias identidades locais.
Etiquete as capas por separado no rexistro
Dentro do túnel hai unha segunda conversa con portos propios. Unha petición HTTPS transportada polo túnel ten destino TCP 443, mentres que a conexión cifrada exterior usa UDP 1194, así que cambiar o porto de orixe exterior non cambia nada do servizo interior.
Incluso na capa exterior, o protocolo importa. UDP 1194 e TCP 1194 son extremos distintos, e un listener 'TCP' nunca recibirá un datagrama UDP porque o número coincida. Ao documentar un despregamento, etiquete o listener do servidor, o socket do cliente e a orixe traducida como tres cousas distintas, e engada o transporte a cada unha.
Despois deixe que a política siga os roles. O servidor abre o transporte previsto no seu listener e segue autenticando o par; a devasa do cliente admite as respostas ao seu propio intercambio saínte sen publicar un servizo entrante. Un filtro sen estado necesita a dirección de retorno escrita explicitamente, e esa é a razón práctica pola que a distinción importa máis alá dos diagramas ordenados.