La lliçó anterior va acabar amb una constatació incòmoda: tot el que ha desplegat Contoso Airlines fins ara —les VM del motor heretat, el conjunt d'escalat de l'API, les aplicacions d'App Service i el compte d'emmagatzematge de targetes— es comunica per internet. Funciona, però cap arquitectura seriosa no es queda així. I arreglar-ho després és molt més car que fer-ho bé des del principi, perquè l'espai d'adreces d'una xarxa virtual condiciona tot el que s'hi connecti durant anys.

Per això tota arquitectura seriosa comença per la xarxa. Canviar la mida d'una VM costa dos minuts; canviar el rang d'adreces d'una xarxa virtual amb cent recursos a dins i una VPN contra dues oficines és un projecte amb tall de servei.

En aquesta lliçó dissenyaràs i desplegaràs la xarxa completa de Contoso: l'espai d'adreces de vnet-contoso-pro amb l'aritmètica CIDR explicada des de zero, les seves quatre subxarxes, els grups de seguretat de xarxa que obren només l'imprescindible, la resolució DNS privada, l'aparellament entre xarxes amb el patró hub-and-spoke, la diferència decisiva entre punts de connexió de servei i Azure Private Link, com es connecta App Service a la xarxa i per què ningú no hauria d'exposar SSH a internet tenint Azure Bastion.

Avís de cost: les xarxes virtuals, les subxarxes i els NSG no costen res. Sí que costen els punts de connexió privats (per hora i per dades processades), les IP públiques estàtiques i, sobretot, Azure Bastion, que es factura per hora des del moment en què existeix. Al final tens la neteja.

1. Per què la xarxa va primer
2. Xarxes virtuals i espai d'adreces
3. Aritmètica CIDR sense dolor
4. Disseny de subxarxes de vnet-contoso-pro
5. Adreces reservades per Azure a cada subxarxa
6. Grups de seguretat de xarxa (NSG)
7. Etiquetes de servei i grups de seguretat d'aplicació
8. IP públiques i privades, estàtiques i dinàmiques
9. DNS a Azure i zones DNS privades
10. Aparellament de xarxes virtuals i hub-and-spoke
11. Punts de connexió de servei davant d'Azure Private Link
12. Integració d'App Service amb la xarxa virtual
13. Azure Bastion davant d'exposar SSH i RDP
14. Verificació amb Network Watcher
15. Topologia completa i neteja
16. Errors Comuns i Consells
17. Exercicis
18. Conclusió

Una xarxa virtual (VNet) és la teva xarxa privada dins d'Azure: un espai d'adreces IP aïllat i controlat per tu, on col·loques recursos que es veuen entre ells i pel qual decideixes què entra i què surt.

El que la xarxa determina, i per això va primer:

I un avís sobre el que no pots fer: dues xarxes amb espais d'adreces encavalcats no es poden aparellar ni unir per VPN. Si tries 10.0.0.0/16 perquè és l'exemple de tots els tutorials, i la teva oficina de Barcelona fa servir 10.0.0.0/16, has creat un problema que només s'arregla renumerant una de les dues.

Una VNet té un o diversos espais d'adreces en notació CIDR, presos dels rangs privats de l'RFC 1918:

Pla d'adreçament de Contoso Airlines, decidit per la Marta Ríos amb la vista posada en la VPN amb les oficines (lliçó 02-06):

Observa la disciplina: blocs /16 separats i res encavalcat, amb forat reservat entre ells per créixer. Això no costa res ara i evita una migració dolorosa d'aquí a tres anys.

Recorda per què la xarxa viu a rg-contoso-red-pro i no al costat de les aplicacions: el criteri d'agrupació de la lliçó 01-05 era cicle de vida + entorn, i la xarxa sobreviu a moltes generacions d'aplicacions.

Si CIDR ja et resulta natural, salta a l'apartat següent. Si no, aquest és el mínim imprescindible i n'hi ha prou d'entendre tres idees.

Idea 1: el número després de la barra són els bits fixos. Una adreça IPv4 té 32 bits. A 10.20.1.0/24, els 24 primers bits són la xarxa (fixos) i els 8 restants identifiquen l'equip (variables).

Idea 2: com més bits fixos, més petita és la xarxa. Una /24 és més petita que una /16. El compte és directe: 2^(32 - prefix) adreces.

Idea 3: per trossejar, s'avança de bloc en bloc. Una /24 cobreix 256 adreces, així que dins de 10.20.0.0/16 les subxarxes /24 van saltant d'una en una al tercer octet:

I si una subxarxa necessita menys, es trosseja amb prefixos més grans. Dins de 10.20.250.0/24:

Regla mental que resol el 90 % dels casos del dia a dia: /24 és "un bloc de 256 amb el mateix tercer octet". Planifica amb /24 llevat que sàpigues que necessites una altra cosa, i deixa forats entre subxarxes per créixer.

Una subxarxa és una porció de l'espai d'adreces de la xarxa virtual on es col·loquen realment els recursos. Se segmenta per funció, perquè la segmentació és el que permet aplicar regles diferents a cada capa.

Noms reservats que cal respectar al peu de la lletra, perquè Azure els busca literalment:

I una restricció amb conseqüències: una subxarxa es pot ampliar, però no si hi ha recursos que ho impedeixin, i no es pot reduir amb recursos a dins. Dimensiona amb marge.

En una subxarxa /24 no disposes de 256 adreces ni de 254, sinó de 251. Azure en reserva cinc a cada subxarxa:

Per tant, la primera adreça assignable de snet-web és 10.20.1.4. Això importa quan dimensiones al límit: una subxarxa /29 té 8 adreces i només 3 utilitzables. Si has planificat «vuit servidors en una /29», no hi caben.

Un grup de seguretat de xarxa és una llista de regles de filtratge amb estat que s'aplica a una subxarxa o a una NIC. Amb estat vol dir que si permets una connexió d'entrada, la resposta de sortida es permet automàticament; no cal escriure la regla inversa.

Cada regla té:

Tot NSG porta regles invisibles que no es poden esborrar, només sobreescriure amb prioritats més baixes:

Dues conseqüències que cal interioritzar:

1. Per defecte, tot el trànsit dins de la VNet està permès, encara que siguin subxarxes diferents. La segmentació no és automàtica: cal escriure-la.
2. Per defecte, tot pot sortir a internet. Si ho vols impedir, cal denegar-ho explícitament.

La regla denegar-resto-vnet amb prioritat 4000 és la peça clau de la segmentació: s'avalua abans que la regla per defecte 65000 que permetia tot el trànsit intern, però després que la regla 100 que autoritza la capa web. El resultat és exactament el que buscàvem: snet-app només escolta snet-web.

Comprovació de les regles efectives, incloses les invisibles:

Escriure rangs d'IP a mà envelleix malament: les IP dels serveis d'Azure canvien i les de les teves màquines també. Azure ofereix dues abstraccions per no dependre'n.

Una etiqueta de servei representa un conjunt de prefixos d'IP que Microsoft manté actualitzat per tu.

Un ASG és una etiqueta lògica que agrupa NIC. En lloc d'escriure regles per rang d'IP, escrius regles entre grups: «el que sigui a asg-web pot parlar amb el que sigui a asg-api». Quan afegeixes una màquina al grup, hereta les regles sense tocar el NSG.

És la manera de mantenir regles llegibles quan la xarxa creix: es llegeixen com a frases del negoci, no com a llistes d'octets.

Sobre les SKU d'IP pública: Standard és l'actual (estàtica sempre, tancada per defecte —necessita un NSG que permeti el trànsit explícitament— i compatible amb zones). La SKU Basic està retirada. Fes servir sempre Standard.

Un matís de sortida a internet que confon molta gent: una VM sense IP pública pot continuar sortint a internet mitjançant l'accés sortint predeterminat d'Azure, amb una IP que no controles i que Microsoft està retirant per a les xarxes noves. Per a una sortida predictible i auditable es fa servir un NAT Gateway, que dona a tota la subxarxa una IP de sortida fixa i evita l'esgotament de ports SNAT.

Dins d'una VNet, Azure ofereix resolució DNS automàtica: les màquines de la mateixa xarxa es resolen pel seu nom d'amfitrió sense que configuris res, a través del servidor virtual 168.63.129.16 (una adreça que apareix a tots els diagnòstics d'Azure i convé reconèixer).

Aquesta resolució automàtica té límits: no funciona entre xarxes aparellades ni resol noms de serveis privats. Per a això hi ha les zones DNS privades.

Ara qualsevol recurs de la xarxa resol motor.interno.contosoairlines.example a 10.20.4.10. Amb --registration-enabled true, a més, les VM es registren soles en crear-se.

Les zones privades són imprescindibles per a Private Link: són el mecanisme pel qual sql-contoso-reservas-pro.database.windows.net deixa de resoldre's a una IP pública i passa a resoldre's a una IP de la teva subxarxa. Ho veiem ara.

El DNS públic (registrar contosoairlines.example i publicar-ne els registres al món) és Azure DNS, i es tracta a la lliçó 02-06.

L'aparellament (peering) connecta dues xarxes virtuals perquè es vegin com si fossin una de sola: trànsit privat per la xarxa troncal de Microsoft, latència baixa, sense portes d'enllaç ni internet pel mig.

Característiques que cal conèixer:

• Funciona dins d'una regió i entre regions (aparellament global).
• No és transitiu: si A s'aparella amb B i B amb C, A no veu C. Aquest és el punt que més sorprèn i el que dona forma a la topologia hub-and-spoke.
• Els espais d'adreces no es poden encavalcar.
• Es factura per dades transferides en tots dos sentits.
• Cal crear-lo en els dos sentits: dues ordres, una per xarxa.

Les dues opcions importants: --allow-gateway-transit al concentrador vol dir «pots fer servir la meva porta d'enllaç VPN», i --use-remote-gateways al radi vol dir «la faré servir». Gràcies a aquesta parella, una sola porta d'enllaç VPN al concentrador dona connectivitat a tots els radis, en lloc de pagar-ne una per xarxa. És l'argument econòmic principal del patró.

Com que l'aparellament no és transitiu, producció i desenvolupament no es veuen entre ells encara que tots dos vegin el concentrador. Això no és una limitació: és exactament la propietat d'aïllament que volem, i surt de franc.

Aquí hi ha la decisió més important de la lliçó, i la que resol el problema amb què obríem: la base de dades i el compte d'emmagatzematge de Contoso són accessibles des d'internet.

La diferència pràctica que decideix: amb un punt de connexió de servei, algú amb la clau del compte d'emmagatzematge pot continuar accedint-hi des de qualsevol lloc autoritzat pel tallafoc; i les oficines connectades per VPN no el poden fer servir. Amb un punt de connexió privat, el recurs té una IP dins de la teva xarxa, es pot tancar del tot al món i les oficines hi arriben per la VPN.

Contoso tria punts de connexió privats per a la base de dades sql-contoso-reservas-pro i per al compte sttarjetascontosopro. El cost afegit és petit comparat amb exposar les dades dels passatgers.

El pas 3 és el que més gent oblida i el que provoca la fallada clàssica: crees el punt de connexió privat, tanques l'accés públic i l'aplicació deixa de funcionar, perquè continua resolent el nom a la IP pública que ja està tancada. Sense la zona DNS privada vinculada, Private Link no serveix de res.

Comprovació des d'una VM de la xarxa:

Les zones privades dels serveis que Contoso farà servir: privatelink.blob.core.windows.net (Storage), privatelink.database.windows.net (SQL, mòdul 3), privatelink.vaultcore.azure.net (Key Vault, 04-03) i privatelink.azurewebsites.net (App Service).

Amb App Service cal distingir dues direccions, i confondre-les és font d'hores perdudes.

Detalls pràctics: la integració de sortida requereix nivell Basic o superior, la subxarxa delegada és d'ús exclusiu d'aquell pla, i per defecte només s'encamina cap a adreces privades (per forçar tot el trànsit de sortida per la xarxa s'activa WEBSITE_VNET_ROUTE_ALL=1, que és el que Contoso fa en producció perquè la sortida sigui auditable).

A la lliçó 02-01 vam obrir el port 22 a internet amb --nsg-rule SSH i vam avisar que era temporal. Ha arribat el moment de fer-ho bé.

Avís de cost important: Bastion es factura per hora mentre existeixi, més el trànsit de sortida. En un laboratori, crea'l, fes-lo servir i esborra'l el mateix dia. En producció, el seu cost es compara favorablement amb el de gestionar IP públiques i sobreviure a un incident per SSH exposat.

Alternativa més barata per a administració puntual: az ssh vm amb Microsoft Entra ID i l'extensió corresponent, o un simple túnel a través d'una VPN de punt a lloc, que és justament el que la Marta Ríos farà servir des de casa (lliçó 02-06).

Quan alguna cosa no connecta, endevinar és car. Network Watcher et diu exactament quina regla està bloquejant què.

test-ip-flow és l'eina que cal fer servir abans de tocar cap regla: et diu el nom de la regla que decideix, amb la qual cosa deixes de canviar coses a l'atzar. I els registres de flux de NSG, que envien a Log Analytics tot el que es permet i es denega, són la base de l'anàlisi que veuràs a la lliçó 07-02.

Neteja del que factura:

Comprovació de despesa residual: az network public-ip list --query "[?ipConfiguration==null]" -o table i az network private-endpoint list -o table.

• Fer servir 10.0.0.0/16 perquè és l'exemple del tutorial. És el rang que fa servir mitja internet corporativa; el dia que muntis la VPN amb l'oficina, s'encavalcarà. Planifica l'adreçament abans de crear res.
• Dimensionar les subxarxes al límit. Azure reserva 5 adreces per subxarxa i ampliar amb recursos a dins és problemàtic. Deixa marge.
• Oblidar els noms obligatoris. GatewaySubnet i AzureBastionSubnet s'escriuen exactament així; amb qualsevol altre nom, el servei no es desplega.
• Suposar que les subxarxes estan aïllades per defecte. La regla AllowVnetInBound permet tot el trànsit intern. La segmentació cal escriure-la.
• Confondre l'ordre de prioritats. S'avalua de menor a major i la primera coincidència guanya. Una regla Deny amb prioritat 100 anul·la un Allow amb prioritat 200.
• Escriure rangs d'IP on hi cap una etiqueta de servei. Les IP dels serveis d'Azure canvien; les etiquetes s'actualitzen soles.
• Esperar que l'aparellament sigui transitiu. No ho és. En hub-and-spoke, els radis no es veuen entre ells (i normalment això és el que vols).
• Crear l'aparellament en un sol sentit. Queda en estat Initiated i no funciona fins que existeix l'enllaç invers.
• Crear un punt de connexió privat sense la seva zona DNS privada. El nom continua resolent a la IP pública i, en tancar l'accés públic, l'aplicació deixa de funcionar. És l'errada número u de Private Link.
• Deixar Azure Bastion encès en un laboratori. Es factura per hora encara que no el facis servir.
• Depurar connectivitat a força de provar regles. az network watcher test-ip-flow et dona la regla culpable en una ordre.
• Consell: documenta el pla d'adreçament en un fitxer del repositori juntament amb els scripts. La xarxa és la part de l'arquitectura que més gent necessita consultar i menys gent recorda.
• Consell: aplica els NSG a subxarxes, no a NIC individuals, llevat d'excepcions justificades. Les regles per NIC s'obliden i creen forats invisibles.

Contoso obre una tercera oficina a Sevilla i vol a més una xarxa virtual per a proves de càrrega, aïllada de producció.

1. Assigna espais d'adreces a l'oficina de Sevilla i a la nova xarxa vnet-contoso-pruebas, coherents amb el pla existent i sense encavalcaments.
2. Divideix vnet-contoso-pruebas en tres subxarxes /24 amb noms coherents amb la nomenclatura del curs.
3. Quantes adreces utilitzables té cada subxarxa /24? I una /27?
4. Explica per què no pots fer servir 10.20.0.0/16 per a la xarxa de proves.

Escriu les regles de NSG (amb prioritats) que compleixin exactament aquesta política per a vnet-contoso-pro:

1. snet-web accepta 443 des d'internet i res més.
2. snet-app accepta 8080 només des de snet-web; cap altre trànsit intern.
3. snet-datos accepta 1433 només des de snet-app.
4. snet-gestion no accepta res des d'internet; només administració des de Bastion.
5. snet-app pot sortir cap a Azure SQL de West Europe, però no cap a la resta d'internet.

Descriu, amb les ordres corresponents, els passos perquè sql-contoso-reservas-pro deixi de ser accessible des d'internet i només s'hi arribi des de snet-app:

1. Preparar la subxarxa.
2. Crear el punt de connexió privat.
3. Configurar la resolució DNS.
4. Tancar l'accés públic.
5. Verificar que la resolució retorna una IP privada.

Explica a més què passaria si et saltessis el pas 3.

Solució 1:

1. Adreçament coherent amb el pla existent:

2. Subxarxes:

3. Una /24 té 256 adreces, menys les 5 que reserva Azure: 251 utilitzables. Una /27 en té 32, menys 5: 27 utilitzables.

4. Perquè 10.20.0.0/16 ja és l'espai de vnet-contoso-pro. Dues xarxes amb rangs encavalcats no es poden aparellar ni connectar per VPN, i l'encaminament seria ambigu. Encara que avui no les aparellessis, reutilitzar el rang tanca aquesta porta per sempre.

Solució 2:

Detall del punt 5: la regla de sortida a SQL ha de tenir prioritat menor (200) que la denegació general (4000), o el trànsit legítim quedaria bloquejat.

Solució 3:

Si et saltes el pas 3, el punt de connexió privat existeix i té la seva IP, però el nom sql-contoso-reservas-pro.database.windows.net continua resolent a la IP pública. Tan bon punt executis el pas 4, l'aplicació intentarà connectar-se a aquesta IP pública ja tancada i fallarà amb un error de connexió esgotada, sense cap pista que apunti al DNS. És l'avaria més freqüent i més desconcertant de Private Link.

Ja tens la tercera pota de la plataforma. Saps per què la xarxa va primer i quines decisions queden congelades durant anys. Manegues els espais d'adreces privats, l'aritmètica CIDR suficient per trossejar una /16 en subxarxes sense encavalcaments, i coneixes les cinc adreces que Azure reserva a cada subxarxa. Has dissenyat i desplegat vnet-contoso-pro amb snet-web, snet-app, snet-datos, snet-gestion i les subxarxes de nom obligatori AzureBastionSubnet i GatewaySubnet. Escrius regles de NSG entenent les prioritats i les regles per defecte —inclosa la més perillosa, AllowVnetInBound, que fa que la segmentació no sigui automàtica—, i fas servir etiquetes de servei i grups de seguretat d'aplicació perquè les regles no depenguin de llistes d'IP. Distingeixes IP públiques i privades, estàtiques i dinàmiques, amb el seu efecte a la factura. Saps com funciona la resolució DNS d'Azure i per a què serveixen les zones DNS privades. Entens l'aparellament i la seva manca de transitivitat, que és just el que dona forma al patró hub-and-spoke i permet pagar una sola porta d'enllaç VPN. I has pres la decisió que més protegeix les dades dels passatgers: punts de connexió privats amb la seva zona DNS per a la base de dades i el compte d'emmagatzematge, en lloc de punts de connexió de servei. A més, has connectat App Service a la xarxa, has substituït l'SSH exposat per Azure Bastion i saps diagnosticar amb Network Watcher en comptes d'endevinar.

Queda una peça per tancar el mòdul, i és la que connecta Azure amb el món real de Contoso Airlines. Les oficines de Barcelona i Palma continuen fora d'aquesta xarxa: el seu personal no arriba als recursos privats que acabes de blindar, el sistema de facturació heretat continua vivint en local, i la Marta Ríos no pot administrar res des de casa sense exposar alguna cosa. Alhora, un client que compra un bitllet des de Sud-amèrica pateix la latència de creuar l'Atlàntic a cada petició fins a West Europe.

A l'última lliçó del mòdul, Connectivitat híbrida i lliurament global, resolem tots dos extrems: VPN de punt a lloc per a la Marta i de lloc a lloc per a les oficines, amb les seves portes d'enllaç i el seu desplegament per CLI; ExpressRoute i quan justifica el seu preu; Azure Virtual WAN com a evolució del hub-and-spoke híbrid; i el lliurament global del lloc amb Azure Front Door, Azure CDN i Traffic Manager, inclòs el cost de la sortida de dades que sorprèn tothom la primera vegada que llegeix una factura.