Overzicht van de netwerkarchitectuur van App Service-omgevingen

App Service-omgevingen worden altijd gemaakt in een subnet van een virtueel netwerk . Apps die worden uitgevoerd in een App Service-omgeving kunnen communiceren met privé-eindpunten binnen dezelfde topologie van het virtuele netwerk. Omdat klanten delen van hun virtuele netwerkinfrastructuur kunnen vergrendelen, is het belangrijk om inzicht te hebben in de typen netwerkcommunicatiestromen die zich voordoen met een App Service-omgeving.

Algemene netwerkstroom

Wanneer een App Service Environment (ASE) een openbaar VIRTUEEL IP-adres (VIP) gebruikt voor apps, komt al het binnenkomende verkeer binnen op dat openbare VIP. Dit omvat HTTP- en HTTPS-verkeer voor apps en ander verkeer voor FTP, functionaliteit voor externe foutopsporing en Azure-beheerbewerkingen. Zie het artikel over het beheren van inkomend verkeer naar een App Service-omgeving voor een volledige lijst met specifieke poorten (zowel vereist als optioneel) die beschikbaar zijn op het openbare VIP.

App Service Environments biedt ook ondersteuning voor het uitvoeren van apps die alleen zijn gebonden aan een intern adres van een virtueel netwerk, ook wel een ILB-adres (interne load balancer) genoemd. Op een ASE met ILB, HTTP- en HTTPS-verkeer voor apps en externe foutopsporingsaanroepen, arriveert u op het ILB-adres. Voor de meest voorkomende ILB-ASE-configuraties komt FTP-/FTPS-verkeer ook aan op het ILB-adres. Azure-beheerbewerkingen stromen echter nog steeds naar poorten 454/455 op het openbare VIP van een as-omgeving met ILB-functionaliteit.

In het onderstaande diagram ziet u een overzicht van de verschillende binnenkomende en uitgaande netwerkstromen voor een App Service-omgeving waarin de apps zijn gebonden aan een openbaar virtueel IP-adres:

Een App Service-omgeving kan communiceren met privé-klanteindpunten. Apps die in de App Service Environment worden uitgevoerd, kunnen bijvoorbeeld verbinding maken met databaseservers die worden uitgevoerd op virtuele IaaS-machines in dezelfde topologie van het virtuele netwerk.

App Service-omgevingen communiceren ook met Sql DB- en Azure Storage-resources die nodig zijn voor het beheren en uitvoeren van een App Service-omgeving. Sommige sql- en opslagbronnen waarmee een App Service-omgeving communiceert, bevinden zich in dezelfde regio als de App Service Environment, terwijl andere zich in externe Azure-regio's bevinden. Als gevolg hiervan is uitgaande verbinding met internet altijd vereist om een App Service-omgeving goed te laten functioneren.

Omdat een App Service-omgeving wordt geïmplementeerd in een subnet, kunnen netwerkbeveiligingsgroepen worden gebruikt om inkomend verkeer naar het subnet te beheren. Zie het volgende artikel voor meer informatie over het beheren van inkomend verkeer naar een App Service-omgeving.

Zie het volgende artikel over het werken met Express Route voor meer informatie over het toestaan van uitgaande internetverbinding vanuit een App Service Environment. Dezelfde benadering die in het artikel wordt beschreven, geldt voor het werken met site-naar-site-connectiviteit en het gebruik van geforceerde tunneling.

Uitgaande netwerkadressen

Wanneer een App Service Environment uitgaande aanroepen doet, wordt er altijd een IP-adres gekoppeld aan de uitgaande aanroepen. Het specifieke IP-adres dat wordt gebruikt, is afhankelijk van of het eindpunt dat wordt aangeroepen zich in de topologie van het virtuele netwerk of buiten de topologie van het virtuele netwerk bevindt.

Als het eindpunt dat wordt aangeroepen zich buiten de topologie van het virtuele netwerk bevindt, is het uitgaande adres (ook wel het uitgaande NAT-adres genoemd) dat wordt gebruikt het openbare VIP van de App Service-omgeving. Dit adres vindt u in de gebruikersinterface van de portal voor de App Service-omgeving in de sectie Eigenschappen.

Dit adres kan ook worden bepaald voor AS-omgevingen die alleen een openbaar VIP hebben door een app te maken in de App Service Environment en vervolgens een nslookup uit te voeren op het adres van de app. Het resulterende IP-adres is zowel het openbare VIP als het uitgaande NAT-adres van de App Service Environment.

Als het eindpunt dat wordt aangeroepen zich binnen de topologie van het virtuele netwerk bevindt, is het uitgaande adres van de aanroepende app het interne IP-adres van de afzonderlijke rekenresource waarop de app wordt uitgevoerd. Er is echter geen permanente toewijzing van interne IP-adressen van virtuele netwerken aan apps. Apps kunnen navigeren over verschillende rekenresources en de groep beschikbare rekenresources in een App Service-omgeving kan veranderen vanwege schaalbewerkingen.

Omdat een App Service-omgeving zich echter altijd in een subnet bevindt, weet u zeker dat het interne IP-adres van een rekenresource waarop een app wordt uitgevoerd, altijd binnen het CIDR-bereik van het subnet valt. Als er fijnmazige ACL's of netwerkbeveiligingsgroepen worden gebruikt om toegang tot andere eindpunten binnen het virtuele netwerk te beveiligen, moet het subnetbereik met de App Service-omgeving toegang krijgen.

In het volgende diagram ziet u de volgende concepten in meer detail:

In het bovenstaande diagram:

• Omdat het openbare VIP van de App Service Environment 192.23.1.2 is, is dat het uitgaande IP-adres dat wordt gebruikt bij het aanroepen naar interneteindpunten.
• Het CIDR-bereik van het subnet voor de App Service Environment is 10.0.1.0/26. Andere eindpunten binnen dezelfde infrastructuur voor virtuele netwerken zien aanroepen van apps die afkomstig zijn van ergens binnen dit adresbereik.

Aanroepen tussen App Service-omgevingen

Een complexer scenario kan optreden als u meerdere App Service-omgevingen in hetzelfde virtuele netwerk implementeert en uitgaande aanroepen vanuit de ene App Service-omgeving naar een andere App Service-omgeving uitvoert. Deze typen cross App Service Environment-aanroepen worden ook behandeld als 'internet'-aanroepen.

In het volgende diagram ziet u een voorbeeld van een gelaagde architectuur met apps in één App Service Environment (bijvoorbeeld 'Front door'-web-apps) die apps aanroepen in een tweede App Service-omgeving (bijvoorbeeld interne back-end-API-apps die niet zijn bedoeld om toegankelijk te zijn vanaf internet).

In het bovenstaande voorbeeld heeft de App Service Environment 'ASE One' een uitgaand IP-adres van 192.23.1.2. Als een app die wordt uitgevoerd in deze App Service-omgeving een uitgaande aanroep uitvoert naar een app die wordt uitgevoerd in een tweede App Service Environment ('ASE Two') die zich in hetzelfde virtuele netwerk bevindt, wordt de uitgaande aanroep behandeld als een internetaanroep. Als gevolg hiervan wordt het netwerkverkeer dat binnenkomt in de tweede App Service-omgeving weergegeven als afkomstig van 192.23.1.2 (dat wil gezegd, niet het adresbereik van het subnet van de eerste App Service-omgeving).

Hoewel aanroepen tussen verschillende App Service-omgevingen worden behandeld als 'internet'-aanroepen, blijven beide App Service-omgevingen zich in dezelfde Azure-regio bevinden, het netwerkverkeer op het regionale Azure-netwerk en loopt het niet fysiek via het openbare internet. Als gevolg hiervan kunt u een netwerkbeveiligingsgroep in het subnet van de tweede App Service-omgeving gebruiken om alleen binnenkomende aanroepen van de eerste App Service-omgeving toe te staan (waarvan het uitgaande IP-adres 192.23.1.2 is), waardoor veilige communicatie tussen de App Service-omgevingen wordt gegarandeerd.

Aanvullende koppelingen en informatie

Meer informatie over binnenkomende poorten die worden gebruikt door App Service Environments en het gebruik van netwerkbeveiligingsgroepen om inkomend verkeer te beheren, is hier beschikbaar.

Meer informatie over het gebruik van door de gebruiker gedefinieerde routes om uitgaande internettoegang tot App Service Environments te verlenen, is beschikbaar in dit artikel.