Com una aplicació web Azure arriba a les instal·lacions mitjançant una VPN

La sol·licitud de sortida de l'aplicació web deixa un treballador que no veieu mai, d'una font que no heu escollit, i el tallafoc de l'oficina l'ha d'acceptar. Aquest és tot el problema en una frase. La integració de la xarxa virtual regional proporciona a la sol·licitud un camí cap a una xarxa virtual i la VPN de lloc a lloc la porta des d'allà. Tot el que va malament després és sobre quin rang d'origen i quina ruta va utilitzar realment el paquet.

El que realment envia el treballador

App Service executa el vostre codi als treballadors que es troben fora de la vista de xarxa de la vostra subscripció. Amb la integració regional activada, el trànsit de sortida es lliura a una subxarxa delegada d'una xarxa virtual de la mateixa regió i el paquet hi apareix abans de continuar. La integració no mou l'aplicació a la xarxa virtual i no canvia la seva adreça d'entrada. Només dóna als fluxos de sortida un primer salt diferent.

De manera predeterminada, només l'espai d'adreces privades pren aquest camí, de manera que les destinacions habituals d'Internet encara surten directament del treballador. L'encaminament de tot a través de la xarxa virtual és una configuració independent i una decisió independent, perquè també envia les vostres dependències públiques a través del túnel.

El trànsit de configuració, com ara l'extracció d'imatge del contenidor a l'inici, segueix les seves pròpies regles d'encaminament i pot fallar mentre les trucades a l'API es fan bé.

La subxarxa d'integració és la font que heu de permetre

L'oficina veu l'interval d'adreces de la subxarxa d'integració o el que el tradueixi el vostre dispositiu, no les adreces públiques de sortida de l'aplicació. Col·loqueu aquest rang als selectors de trànsit de la VPN del lloc i a la regla del tallafoc local. Si el túnel està basat en polítiques, els selectors que l'ometen deixen anar el paquet fins i tot quan existeix una ruta.

No permetis que una sola adreça de treballador hagis observat. Les instàncies canvien amb l'escala i el manteniment de la plataforma, i una regla fixada a una adreça es trenca en el pitjor moment.

Mantingueu el costat de la destinació estret: un servei, un port, una direcció, amb la ruta de retorn permesa explícitament.

El peering i el trànsit de passarel·la són explícits

Si la passarel·la VPN es troba en una xarxa virtual de concentrador i la subxarxa d'integració en un ràdio, el camí necessita que el trànsit de la passarel·la es permeti al peering del concentrador i l'ús remot de la passarel·la activat al peering del ràdio. El peering per si mateix porta trànsit entre les dues xarxes virtuals i res més. Les rutes efectives de la subxarxa d'integració són on confirmeu que la passarel·la següent salt hi és realment.

Un disseny de hub-and-spoke la taula de ruta del qual envia 0.0.0.0/0 a un tallafoc és una variant habitual, i aquest tallafoc necessita la seva pròpia regla per al prefix local.

Dibuixa el camí en paper abans d'obrir un bitllet amb l'equip de la xarxa, perquè estalvia un dia d'endevinar. Inclou la direcció de retorn al dibuix, ja que aquesta és la meitat que la gent oblida.

El punt final privat d'entrada és l'altra direcció

Un punt final privat fa que l'aplicació sigui accessible des d'una xarxa virtual. No fa res per a la trucada de sortida de l'aplicació a l'oficina i els equips en configuren una periòdicament mentre que el requisit real era el contrari.

La documentació antiga descriu la integració necessària per a la passarel·la basada en una VPN punt a lloc, una característica diferent amb els seus propis requisits. Microsoft programa la retirada d'aquesta funció per al 31 de març de 2027 i recomana la integració regional.

No copieu una configuració de punt a lloc heretada només perquè l'utilitzi un exemple antic.

Verificar amb el propi context de l'aplicació

Proveu des de l'aplicació desplegada, no des del vostre ordinador portàtil ni des d'una màquina virtual de la mateixa xarxa virtual. Registreu l'adreça resolta, el resultat de la connexió i la resposta a nivell d'aplicació per separat, perquè un error de DNS, un temps d'espera TCP i un punt de rebuig d'autenticació en tres propietaris diferents. Si la resolució de noms falla, arregleu el DNS privat per a la xarxa virtual abans de tocar el túnel.

Un estat de túnel verd només demostra que la passarel·la està activada. No diu res sobre selectors, regles de tallafoc o DNS.

Quan la sol·licitud finalment funcioni, escriviu l'interval d'origen, el port de destinació i la zona DNS al runbook de l'aplicació. La següent persona que depuri això començarà des de la vostra nota en lloc de des de la pàgina d'estat de la passarel·la.