Dues IP públiques en una sola VM VPN d'Azure: què fa cada una

Dues IP públiques en una sola VM VPN d'Azure creen una expectativa que rares vegades es compleix: l'adreça a què es connecten els clients serà també l'adreça que veuen els llocs web. Tres decisions independents produeixen aquest resultat, i només la primera és sobre l'oient del túnel. La segona és l'origen del convidat utilitzat per al trànsit reenviat del client, i la tercera és el mètode de sortida d'Azure que s'aplica a aquest origen. Canvieu-ne una i les altres dues es queden on eren, així que decidiu cada una explícitament.

Decisió 1: on acaba el túnel

Una IP pública d'Azure s'associa a una configuració d'IP privada a la NIC; no és una adreça que afegiu dins del sistema operatiu convidat. Llegiu la correspondència en lloc de suposar-la: az network nic show --ids /subscriptions/.../networkInterfaces/vpn-nic --query 'ipConfigurations[].{private:privateIPAddress,public:publicIPAddress.id}'. L'adreça privada que retorni aquesta consulta és la que el convidat ha de tenir realment.

Una NIC pot portar diverses configuracions d'IP, així que dues adreces públiques no requereixen dues NIC. Si el disseny sí que utilitza dues NIC, cada una aporta les seves rutes de convidat i salts següents, i heu afegit una decisió d'encaminament en lloc de simplificar-ne una.

Per a un servei amb una vinculació local explícita, vinculeu-vos a l'adreça privada real del convidat, mai al marcador públic. Un oient comodí accepta trànsit per cada configuració d'IP que l'arriba, així que limiteu l'entrada amb el grup de seguretat de xarxa i el tallafoc de l'amfitrió en lloc d'esperar que ho decideixi l'ordre de vinculació.

Decisió 2: quin origen utilitza el client reenviat

Després que la passarel·la desxifri una sol·licitud del client, el paquet que reenvia és un paquet diferent del que va arribar a l'oient VPN. El convidat necessita el reenviament activat, una política de tallafoc que permeti el flux i una adreça d'origen que el disseny del núvol permeti. Si traduïu l'adreça interna del client, aquest origen traduït és el que Azure avaluarà, no l'adreça interna del client.

Una regla SNAT estreta pot triar un origen privat del convidat, però no pot imposar-se a una traducció posterior d'Azure. Trieu SNAT quan necessiteu responsabilitat per client dins de la VM; ometeu-lo quan el disseny de sortida de la subxarxa ja proporcioni un origen públic estable i una segona traducció només afegiria estat.

Decisió 3: quin mètode de sortida d'Azure guanya

Microsoft documental'ordre de precedència de sortida: una ruta aplicable cap a un dispositiu o passarel·la té prioritat, i la connectivitat de la subxarxa a través de NAT Gateway té prioritat sobre una IP pública a nivell d'instància en el camí corresponent. Aquest ordre és la raó per la qual traduir a 10.20.0.5 no demostra que un lloc web vegi 198.51.100.20. Llegiu la taula de rutes efectiva, l'associació de NAT Gateway i la IP pública de la NIC alhora abans d'acceptar el disseny de sortida.

Manteniuel paràmetre de reenviament de la NIC d'Azureseparat del reenviament de Linux. L'indicador del núvol permet paquets l'origen o la destinació dels quals no està assignat a la NIC; no habilita net.ipv4.ip_forward, i el paràmetre del convidat no atorga el permís del núvol.

El sòcol del túnel té la seva pròpia decisió d'origen

Address de WireGuard sota wg-quick assigna una adreça a la interfície WireGuard; no és una instrucció de vinculació UDP externa. L'origen del sòcol xifrat segueix la taula d'encaminament, així que una ruta de política o una segona ruta per defecte el pot moure sense tocar l'adreça de la interfície.OpenVPN: l'opció local i UDP multihome es comporten igual: afecten l'oient i les seves respostes, no l'origen d'internet de cada client reenviat.

Preserveu la ruta de la capa inferior que transporta el túnel i confirmeu que el client encara rep respostes autenticades des de la disposició d'entrada esperada. No confieu en l'ordre de la llista d'adreces com a política permanent de selecció d'origen, perquè la propera adreça afegida a la NIC pot canviar quina guanya.

Què cal acceptar, i en quin ordre

Accepteu tres resultats per separat. Primer, un client extern arriba a l'entrada VPN prevista. Segon, una sol·licitud nova permesa d'aquell client VPN surt per la sortida d'internet documentada. Tercer, els camins no volguts d'oient i de reenviament romanen denegats. Enregistreu les correspondències de públic a privat i els propietaris de convidat i de núvol de cada decisió en el mateix lloc.

Un túnel correcte només demostra la primera part. Proveu la sortida amb un flux nou, perquè una connexió en memòria cau pot continuar utilitzant l'origen antic molt després que la ruta canviï.