Dous IP públicas nunha soa VM VPN de Azure: que fai cada unha

Dous IP públicas nunha soa VM VPN de Azure crean unha expectativa que raramente se cumpre: o enderezo ao que se conectan os clientes será tamén o enderezo que ven os sitios web. Tres decisións independentes producen ese resultado, e só a primeira trata do escoitador do túnel. A segunda é a orixe do convidado usada para o tráfico de cliente reenviado, e a terceira é o método de saída de Azure que se aplica a esa orixe. Cambie unha e as outras dúas quedan onde estaban, así que decida cada unha explicitamente.

Decisión 1: onde remata o túnel

Un IP público de Azure asóciase a unha configuración de IP privada na NIC; non é un enderezo que engada dentro do sistema operativo convidado. Lea a correspondencia en lugar de supoñela: az network nic show --ids /subscriptions/.../networkInterfaces/vpn-nic --query 'ipConfigurations[].{private:privateIPAddress,public:publicIPAddress.id}'. Calquera enderezo privado que devolva esa consulta é o que o convidado debe ter realmente.

Unha NIC pode levar varias configuracións de IP, así que dous enderezos públicos non requiren dúas NIC. Se o deseño si usa dúas NIC, cada unha achega as súas propias rutas de convidado e saltos seguintes, e engadiu unha decisión de encamiñamento en lugar de simplificala.

Para un servizo cunha vinculación local explícita, vincúleo ao enderezo privado real do convidado, nunca ao marcador público. Un escoitador que acepta todos os enderezos recibe tráfico por cada configuración de IP que o alcanza, así que restrinxa a entrada co grupo de seguridade de rede e a devasa do host en lugar de esperar que o decida a orde de vinculación.

Decisión 2: que orixe usa o cliente reenviado

Despois de que a pasarela descifre unha solicitude do cliente, o paquete que reenvía é distinto do que chegou ao escoitador VPN. O convidado necesita o reenvío activado, unha política de devasa que permita o fluxo e un enderezo de orixe que o deseño da nube permita. Se traduce o enderezo interno do cliente, esa orixe traducida é a que Azure avaliará, non o enderezo interno do cliente.

Unha regra SNAT estreita pode escoller unha orixe privada do convidado, pero non pode impoñerse a unha tradución posterior de Azure. Escolla SNAT cando necesite responsabilidade por cliente dentro da VM; omítao cando o deseño de saída da subrede xa proporcione unha orixe pública estable e unha segunda tradución só engadiría estado.

Decisión 3: que método de saída de Azure gaña

Microsoft documentaa orde de precedencia de saída: unha ruta aplicable cara a un dispositivo ou pasarela ten prioridade, e a conectividade da subrede mediante NAT Gateway ten prioridade sobre un IP público a nivel de instancia na ruta correspondente. Esa orde é a razón pola que traducir a 10.20.0.5 non demostra que un sitio web vaia ver 198.51.100.20. Lea a táboa de rutas efectiva, a asociación de NAT Gateway e o IP público da NIC xuntas antes de aceptar o deseño de saída.

Manteñao axuste de reenvío da NIC de Azureseparado do reenvío de Linux. O indicador da nube permite paquetes cuxa orixe ou destino non está asignado á NIC; non habilita net.ipv4.ip_forward, e o axuste do convidado non concede o permiso da nube.

O socket do túnel ten a súa propia decisión de orixe

Address de WireGuard en wg-quick asigna un enderezo á interface WireGuard; non é unha instrución de vinculación UDP externa. A orixe do socket cifrado segue a táboa de encamiñamento, así que unha ruta de política ou unha segunda ruta predeterminada pode movela sen tocar o enderezo da interface.OpenVPN: a opción local e UDP multihome compórtanse igual: afectan o escoitador e as súas respostas, non a orixe de internet de cada cliente reenviado.

Conserve a ruta da capa inferior que transporta o túnel e confirme que o cliente segue recibindo respostas autenticadas desde a disposición de entrada esperada. Non confíe na orde da lista de enderezos como política permanente de selección de orixe, porque o seguinte enderezo engadido á NIC pode cambiar cal gaña.

Que aceptar e en que orde

Acepte tres resultados por separado. Primeiro, un cliente externo alcanza a entrada VPN prevista. Segundo, unha solicitude nova permitida dese cliente VPN sae pola saída de internet documentada. Terceiro, as rutas non desexadas de escoita e reenvío seguen denegadas. Rexistre as correspondencias de público a privado e os responsables de convidado e de nube de cada decisión no mesmo lugar.

Un túnel correcto só demostra a primeira parte. Probe a saída cun fluxo novo, porque unha conexión en caché pode seguir usando a orixe antiga moito despois de que cambie a ruta.