Delen via

Uw Azure API Management-exemplaar implementeren in een virtueel netwerk - interne modus

  • Artikel

VAN TOEPASSING OP: Ontwikkelaar | Premie

Azure API Management kan worden geïmplementeerd (geïnjecteerd) in een virtueel Azure-netwerk (VNet) voor toegang tot back-endservices binnen het netwerk. Zie voor VNet-connectiviteitsopties, vereisten en overwegingen:

In dit artikel wordt uitgelegd hoe u VNet-connectiviteit instelt voor uw API Management-exemplaar in de interne modus. In deze modus hebt u alleen toegang tot de volgende API Management-eindpunten binnen een VNet waarvan u de toegang beheert.

  • De API-gateway
  • De ontwikkelaarsportal
  • Direct beheer
  • Git

Notitie

  • Geen van de API Management-eindpunten wordt geregistreerd op de openbare DNS. De eindpunten blijven niet toegankelijk totdat u DNS voor het VNet configureert.
  • Als u de zelf-hostende gateway in deze modus wilt gebruiken, moet u ook privéconnectiviteit met het zelf-hostende gatewayconfiguratie-eindpunt inschakelen.

GEBRUIK API Management in de interne modus om:

  • Maak API's die worden gehost in uw privé-datacenter veilig toegankelijk voor derden buiten het datacenter met behulp van Azure VPN-verbindingen of Azure ExpressRoute.
  • Schakel hybride cloudscenario's in door uw cloud-API's en on-premises API's beschikbaar te maken via een gemeenschappelijke gateway.
  • Beheer uw API's die worden gehost op meerdere geografische locaties, met behulp van één gateway-eindpunt.

Verbinding maken met intern VNet

Voor configuraties die specifiek zijn voor de externe modus, waarbij de API Management-eindpunten toegankelijk zijn vanaf het openbare internet en back-endservices zich in het netwerk bevinden, raadpleegt u Uw Azure API Management-exemplaar implementeren in een virtueel netwerk - externe modus.

Notitie

Het wordt aanbevolen de Azure Az PowerShell-module te gebruiken om te communiceren met Azure. Zie Azure PowerShell installeren om aan de slag te gaan. Raadpleeg Azure PowerShell migreren van AzureRM naar Az om te leren hoe u naar de Azure PowerShell-module migreert.

Vereisten

Controleer de netwerkresourcevereisten voor API Management-injectie in een virtueel netwerk voordat u begint.

Sommige vereisten verschillen, afhankelijk van de versie (stv2 of stv1) van het rekenplatform dat als host fungeert voor uw API Management-exemplaar.

Tip

Wanneer u de portal gebruikt om de netwerkverbinding van een bestaand API Management-exemplaar te maken of bij te werken, wordt het exemplaar gehost op het stv2 rekenplatform.

  • Een virtueel netwerk en subnet in dezelfde regio en hetzelfde abonnement als uw API Management-exemplaar.

    • Het subnet dat wordt gebruikt om verbinding te maken met het API Management-exemplaar kan andere Azure-resourcetypen bevatten.
    • Het subnet mag geen delegaties hebben ingeschakeld. Het subnet Delegeren naar een service-instelling voor het subnet moet worden ingesteld op Geen.

  • Een netwerkbeveiligingsgroep die is gekoppeld aan het bovenstaande subnet. Een netwerkbeveiligingsgroep (NSG) is vereist om binnenkomende connectiviteit expliciet toe te staan, omdat de load balancer die intern door API Management wordt gebruikt, standaard beveiligd is en al het binnenkomende verkeer weigert. Zie NSG-regels configureren verderop in dit artikel voor specifieke configuratie.

  • Schakel voor bepaalde scenario's service-eindpunten in het subnet in op afhankelijke services, zoals Azure Storage of Azure SQL. Zie Tunnelverkeer geforceerd naar een on-premises firewall met behulp van ExpressRoute of virtueel netwerkapparaat, verderop in dit artikel voor meer informatie.

  • (Optioneel) Een openbaar IPv4-adres voor een standaard-SKU.

    Belangrijk

    • Vanaf mei 2024 is een openbare IP-adresresource niet meer nodig bij het implementeren (injecteren) van een API Management-exemplaar in een VNet in de interne modus of het migreren van de interne VNet-configuratie naar een nieuw subnet. In de externe VNet-modus is het opgeven van een openbaar IP-adres optioneel. Als u er geen opgeeft, wordt automatisch een door Azure beheerd openbaar IP-adres geconfigureerd en gebruikt voor runtime-API-verkeer. Geef alleen het openbare IP-adres op als u de eigenaar wilt zijn van het openbare IP-adres dat wordt gebruikt voor inkomende of uitgaande communicatie met internet.

    • Indien opgegeven, moet het IP-adres zich in dezelfde regio en hetzelfde abonnement bevinden als het API Management-exemplaar en het virtuele netwerk.

    • Wanneer u een openbare IP-adresresource maakt, moet u ervoor zorgen dat u er een DNS-naamlabel aan toewijst. Over het algemeen moet u dezelfde DNS-naam gebruiken als uw API Management-exemplaar. Als u dit wijzigt, implementeert u uw exemplaar opnieuw zodat het nieuwe DNS-label wordt toegepast.

    • Voor de beste netwerkprestaties is het raadzaam om de standaardvoorkeur routering te gebruiken: Microsoft-netwerk.

    • Wanneer u een openbaar IP-adres maakt in een regio waar u zoneredundantie wilt inschakelen voor uw API Management-exemplaar, configureert u de zone-redundante instelling.

    • De waarde van het IP-adres wordt toegewezen als het virtuele openbare IPv4-adres van het API Management-exemplaar in die regio.

  • Configureer voor API Management-implementaties met meerdere regio's afzonderlijk resources voor virtuele netwerken voor elke locatie.

VNet-verbinding inschakelen

VNet-connectiviteit inschakelen met behulp van Azure Portal (stv2 platform)

  1. Ga naar Azure Portal om uw API Management-exemplaar te vinden. Zoek en selecteer API Management-services.

  2. Kies uw API Management-exemplaar.

  3. Selecteer Virtueel>netwerk netwerk.

  4. Selecteer het type interne toegang.

  5. In de lijst met locaties (regio's) waar uw API Management-service wordt ingericht:

    1. Kies een Locatie.
    2. Selecteer Virtueel netwerk en subnet.
      • De VNet-lijst wordt gevuld met Resource Manager-VNets die beschikbaar zijn in uw Azure-abonnementen, die zijn ingesteld in de regio die u configureert.

  6. Selecteer Toepassen. De pagina Virtueel netwerk van uw API Management-exemplaar wordt bijgewerkt met uw nieuwe VNet- en subnetkeuzen. Intern VNet instellen in Azure Portal

  7. Ga door met het configureren van VNet-instellingen voor de resterende locaties van uw API Management-exemplaar.

  8. Selecteer Opslaan in de bovenste navigatiebalk.

    Het kan 15 tot 45 minuten duren voordat het API Management-exemplaar is bijgewerkt. De developer-laag heeft downtime tijdens het proces. De Basic- en hogere SKU's hebben geen downtime tijdens het proces.

Na een geslaagde implementatie ziet u het privé-IP-adres van uw API Management-service en het openbare virtuele IP-adres op de blade Overzicht. Zie Routering in dit artikel voor meer informatie over de IP-adressen.

Openbaar en privé-IP-adres dat is geadresseerd in Azure Portal

Notitie

Omdat de gateway-URL niet is geregistreerd op de openbare DNS, werkt de testconsole die beschikbaar is in Azure Portal niet voor een interne VNet-geïmplementeerde service. Gebruik in plaats daarvan de testconsole die is opgegeven in de ontwikkelaarsportal.

Connectiviteit inschakelen met behulp van een Resource Manager-sjabloon (stv2 platform)

  • Azure Resource Manager-sjabloon (API-versie 2021-08-01)

    Knop voor het implementeren van de Resource Manager-sjabloon in Azure.

Connectiviteit inschakelen met behulp van Azure PowerShell-cmdlets (stv1 platform)

Een API Management-exemplaar maken of bijwerken in een VNet.

NSG-regels configureren

Configureer aangepaste netwerkregels in het API Management-subnet om verkeer naar en van uw API Management-exemplaar te filteren. We raden de volgende minimale NSG-regels aan om de juiste werking en toegang tot uw exemplaar te garanderen. Controleer uw omgeving zorgvuldig om meer regels te bepalen die mogelijk nodig zijn.

Belangrijk

Afhankelijk van uw gebruik van caching en andere functies, moet u mogelijk aanvullende NSG-regels configureren buiten de minimale regels in de volgende tabel. Zie de naslaginformatie over de configuratie van virtuele netwerken voor gedetailleerde instellingen.

  • Gebruik voor de meeste scenario's de aangegeven servicetags in plaats van service-IP-adressen om netwerkbronnen en bestemmingen op te geven.
  • Stel de prioriteit van deze regels hoger in dan die van de standaardregels.
Bron-/doelpoort(en) Richting Transportprotocol Servicetags
Bron/doel		 Doel VNet-type
* / [80], 443 Inkomend TCP Internet/VirtualNetwork Clientcommunicatie met API Management Alleen extern
* / 3443 Inkomend TCP ApiManagement /VirtualNetwork Beheereindpunt voor Azure Portal en PowerShell Extern en intern
* / 6390 Inkomend TCP AzureLoadBalancer/VirtualNetwork Load balancer voor Azure-infrastructuur Extern en intern
* / 443 Inkomend TCP AzureTrafficManager/VirtualNetwork Azure Traffic Manager-routering voor implementatie met meerdere regio's Alleen extern
* / 443 Uitgaand TCP VirtualNetwork / Storage Afhankelijkheid van Azure Storage voor kernservicefunctionaliteit Extern en intern
* / 1433 Uitgaand TCP VirtualNetwork / SQL Toegang tot Azure SQL-eindpunten voor kernservicefunctionaliteit Extern en intern
* / 443 Uitgaand TCP VirtualNetwork/AzureKeyVault Toegang tot Azure Key Vault voor kernservicefunctionaliteit Extern en intern
* / 1886, 443 Uitgaand TCP VirtualNetwork/AzureMonitor Diagnostische logboeken en metrische gegevens, Resource Health en Application Insights publiceren Extern en intern

DNS-configuratie

In de interne VNet-modus moet u uw eigen DNS beheren om binnenkomende toegang tot uw API Management-eindpunten in te schakelen.

We raden het volgende aan:

  1. Configureer een privézone van Azure DNS.
  2. Koppel de Azure DNS-privézone aan het VNet waarin u uw API Management-service hebt geïmplementeerd.

Meer informatie over het instellen van een privézone in Azure DNS.

Notitie

De API Management-service luistert niet naar aanvragen op de IP-adressen. Het reageert alleen op aanvragen naar de hostnaam die is geconfigureerd op de eindpunten. Deze eindpunten zijn onder andere:

  • API-gateway
  • Azure Portal
  • De ontwikkelaarsportal
  • Eindpunt voor direct beheer
  • Git

Toegang op standaardhostnamen

Wanneer u een API Management-service maakt (contosointernalvnetbijvoorbeeld), worden de volgende eindpunten standaard geconfigureerd:

Eindpunt Eindpuntconfiguratie
API-gateway contosointernalvnet.azure-api.net
ontwikkelaarsportal contosointernalvnet.portal.azure-api.net
De nieuwe ontwikkelaarsportal contosointernalvnet.developer.azure-api.net
Eindpunt voor direct beheer contosointernalvnet.management.azure-api.net
Git contosointernalvnet.scm.azure-api.net

Toegang tot aangepaste domeinnamen

Als u geen toegang wilt krijgen tot de API Management-service met de standaardhostnamen, stelt u aangepaste domeinnamen in voor al uw eindpunten, zoals wordt weergegeven in de volgende afbeelding:

Aangepaste domeinnaam instellen

DNS-records configureren

Maak records op uw DNS-server om toegang te krijgen tot de eindpunten die toegankelijk zijn vanuit uw VNet. Wijs de eindpuntrecords toe aan het privé-VIRTUELE IP-adres voor uw service.

Voor testdoeleinden kunt u het hosts-bestand bijwerken op een virtuele machine in een subnet dat is verbonden met het VNet waarin API Management wordt geïmplementeerd. Ervan uitgaande dat het privé-VIRTUELE IP-adres voor uw service 10.1.0.5 is, kunt u het hosts-bestand als volgt toewijzen. Het toewijzingsbestand voor hosts bevindt zich in %SystemDrive%\drivers\etc\hosts (Windows) of /etc/hosts (Linux, macOS).

Intern virtueel IP-adres Eindpuntconfiguratie
10.1.0.5 contosointernalvnet.azure-api.net
10.1.0.5 contosointernalvnet.portal.azure-api.net
10.1.0.5 contosointernalvnet.developer.azure-api.net
10.1.0.5 contosointernalvnet.management.azure-api.net
10.1.0.5 contosointernalvnet.scm.azure-api.net

Vervolgens hebt u toegang tot alle API Management-eindpunten vanaf de virtuele machine die u hebt gemaakt.

Routering

De volgende virtuele IP-adressen zijn geconfigureerd voor een API Management-exemplaar in een intern virtueel netwerk.

Virtueel IP-adres Beschrijving
Privé virtueel IP-adres Een IP-adres met gelijke taakverdeling binnen het subnetbereik van het API Management-exemplaar (DIP), waarmee u toegang hebt tot de API-gateway, de ontwikkelaarsportal, het beheer en Git-eindpunten.

Registreer dit adres bij de DNS-servers die door het VNet worden gebruikt.
Openbaar virtueel IP-adres Alleen gebruikt voor besturingsvlakverkeer naar het beheereindpunt via poort 3443. Kan worden vergrendeld naar de ApiManagement-servicetag .

De openbare en privé-IP-adressen met gelijke taakverdeling vindt u op de blade Overzicht in Azure Portal.

Zie IP-adressen van Azure API Management voor meer informatie en overwegingen.

VIP- en DIP-adressen

Dynamische IP-adressen (DIP) worden toegewezen aan elke onderliggende virtuele machine in de service en gebruikt voor toegang tot eindpunten en resources in het VNet en in gekoppelde VNet's. Het OPENBARE IP-adres (VIP) van de API Management-service wordt gebruikt voor toegang tot openbare resources.

Als met IP-beperking beveiligde resources in het VNet of gekoppelde VNet's worden vermeld, raden we u aan het hele subnetbereik op te geven waarin de API Management-service wordt geïmplementeerd om toegang van de service te verlenen of te beperken.

Meer informatie over de aanbevolen subnetgrootte.

Opmerking

Als u 1 capaciteitseenheid van API Management implementeert in de Premium-laag in een intern VNet, worden 3 IP-adressen gebruikt: 1 voor het privé-VIP en één voor de DIPs voor twee VM's. Als u uitschaalt naar 4 eenheden, worden er meer IP-adressen gebruikt voor extra DIPs uit het subnet.

Als het doeleindpunt alleen een vaste set DIPs bevat, worden verbindingsfouten veroorzaakt als u in de toekomst nieuwe eenheden toevoegt. Daarom en omdat het subnet volledig in uw beheer is, raden we u aan het hele subnet in de back-end op te geven.

Tunnelverkeer naar een on-premises firewall afdwingen met behulp van ExpressRoute of virtueel netwerkapparaat

Met geforceerde tunneling kunt u al het internetverkeer van uw subnet terug naar on-premises omleiden of 'forceren' voor inspectie en controle. Doorgaans configureert en definieert u uw eigen standaardroute (0.0.0.0/0), waardoor al het verkeer van het API Management-subnet wordt geforceerd door een on-premises firewall of naar een virtueel netwerkapparaat. Deze verkeersstroom breekt de connectiviteit met API Management, omdat uitgaand verkeer on-premises wordt geblokkeerd of NAT naar een onherkenbare set adressen die niet meer werken met verschillende Azure-eindpunten. U kunt dit probleem oplossen via de volgende methoden:

  • Schakel service-eindpunten in op het subnet waarin de API Management-service is geïmplementeerd voor:

    • Azure SQL (alleen vereist in de primaire regio als de API Management-service wordt geïmplementeerd in meerdere regio's)
    • Azure Storage
    • Azure Event Hubs
    • Azure Key Vault (vereist wanneer API Management op het stv2 platform wordt geïmplementeerd)

    Door eindpunten rechtstreeks vanuit het API Management-subnet naar deze services in te schakelen, kunt u het Backbone-netwerk van Microsoft Azure gebruiken en optimale routering bieden voor serviceverkeer. Als u service-eindpunten gebruikt met een geforceerde TUNNELed API Management, wordt verkeer voor de voorgaande Azure-services niet geforceerd geforceerd getunneld. Het andere verkeer van de API Management-serviceafhankelijkheid blijft echter geforceerd getunneld. Zorg ervoor dat uw firewall of virtueel apparaat dit verkeer niet blokkeert of dat de API Management-service mogelijk niet goed werkt.

    Notitie

    We raden u ten zeerste aan service-eindpunten rechtstreeks vanuit het API Management-subnet in te schakelen naar afhankelijke services, zoals Azure SQL en Azure Storage die deze ondersteunen. Sommige organisaties hebben echter mogelijk vereisten om al het verkeer van het API Management-subnet af te dwingen. In dit geval moet u ervoor zorgen dat u uw firewall of virtueel apparaat zo configureert dat dit verkeer wordt toegestaan. U moet het volledige IP-adresbereik van elke afhankelijke service toestaan en deze configuratie up-to-date houden wanneer de Azure-infrastructuur wordt gewijzigd. Uw API Management-service kan ook latentie of onverwachte time-outs ondervinden vanwege de geforceerde tunneling van dit netwerkverkeer.

  • Al het verkeer van het besturingsvlak van internet naar het beheereindpunt van uw API Management-service wordt gerouteerd via een specifieke set binnenkomende IP-adressen, gehost door API Management, die wordt beheerd door de ApiManagement-servicetag. Wanneer het verkeer geforceerd wordt getunneld, worden de antwoorden niet symmetrisch toegewezen aan deze binnenkomende bron-IP-adressen en gaat de connectiviteit met het beheereindpunt verloren. Om deze beperking te overwinnen, configureert u een door de gebruiker gedefinieerde route (UDR) voor de ApiManagement-servicetag met het volgende hoptype ingesteld op 'Internet', om verkeer terug te sturen naar Azure.

    Notitie

    Het toestaan van API Management-beheerverkeer om een on-premises firewall of virtueel netwerkapparaat te omzeilen, wordt niet beschouwd als een aanzienlijk beveiligingsrisico. De aanbevolen configuratie voor uw API Management-subnet staat inkomend beheerverkeer alleen toe op poort 3443 van de set Azure IP-adressen die zijn opgenomen in de ApiManagement-servicetag. De aanbevolen UDR-configuratie is alleen voor het retourpad van dit Azure-verkeer.

  • (Externe VNet-modus) Gegevensvlakverkeer voor clients die de API Management-gateway en de ontwikkelaarsportal van internet proberen te bereiken, worden ook standaard verwijderd vanwege asymmetrische routering die wordt geïntroduceerd door geforceerde tunneling. Voor elke client waarvoor toegang is vereist, configureert u een expliciete UDR met het volgende hoptype 'Internet' om de firewall of het virtuele netwerkapparaat te omzeilen.

  • Voor andere geforceerde API Management-serviceafhankelijkheden moet u de hostnaam oplossen en contact opnemen met het eindpunt. Deze omvatten:

    • Metrische gegevens en statuscontrole
    • Diagnostische gegevens van Azure Portal
    • SMTP-relay
    • CAPTCHA voor ontwikkelaarsportal
    • Azure KMS-server

Zie de naslaginformatie over de configuratie van virtuele netwerken voor meer informatie.

Veelvoorkomende problemen met netwerkconfiguratie

Deze sectie is verplaatst. Zie naslaginformatie over de configuratie van virtuele netwerken.

Probleemoplossing

Mislukte initiële implementatie van API Management-service in een subnet

  • Implementeer een virtuele machine in hetzelfde subnet.
  • Maak verbinding met de virtuele machine en valideer de connectiviteit met een van de volgende resources in uw Azure-abonnement:
    • Azure Storage-blob
    • Azure SQL-database
    • Azure Storage-tabel
    • Azure Key Vault (voor een API Management-exemplaar dat wordt gehost op het stv2 platform)

Belangrijk

Nadat u de connectiviteit hebt geverifieerd, verwijdert u alle resources in het subnet voordat u API Management implementeert in het subnet (vereist wanneer API Management op het stv1 platform wordt gehost).

Netwerkstatus controleren

  • Nadat u API Management in het subnet hebt geïmplementeerd, gebruikt u de portal om de connectiviteit van uw exemplaar te controleren op afhankelijkheden, zoals Azure Storage.

  • Selecteer >in de portal in het linkermenu onder Implementatie en infrastructuur de netwerkstatus.

    Schermopname van de status van de netwerkverbinding controleren in de portal.

Filteren Beschrijving
Vereist Selecteer deze optie om de vereiste Azure-servicesconnectiviteit voor API Management te controleren. Fout geeft aan dat het exemplaar geen kernbewerkingen kan uitvoeren om API's te beheren.
Optioneel Selecteer deze optie om de optionele servicesconnectiviteit te controleren. Fout geeft alleen aan dat de specifieke functionaliteit niet werkt (bijvoorbeeld SMTP). Fout kan leiden tot een afname in het gebruik en bewaken van het API Management-exemplaar en het leveren van de vastgelegde SLA.

Als u verbindingsproblemen wilt oplossen, selecteert u:

  • Metrische gegevens: metrische gegevens over de netwerkverbindingsstatus controleren

  • Diagnose : een virtuele netwerkverificator uitvoeren gedurende een opgegeven periode

Als u verbindingsproblemen wilt oplossen, controleert u de netwerkconfiguratie-instellingen en lost u de vereiste netwerkinstellingen op.

Incrementele updates

Wanneer u wijzigingen aanbrengt in uw netwerk, raadpleegt u de NetworkStatus-API om te controleren of de API Management-service geen toegang heeft verloren tot kritieke resources. De connectiviteitsstatus moet elke 15 minuten worden bijgewerkt.

Een netwerkconfiguratiewijziging toepassen op het API Management-exemplaar met behulp van de portal:

  1. Selecteer in het linkermenu voor uw exemplaar, onder Implementatie en infrastructuur, het>virtuele netwerk van het netwerk.
  2. Selecteer Netwerkconfiguratie toepassen.

Een API Management-exemplaar dat wordt gehost op het stv1 rekenplatform, wanneer deze wordt geïmplementeerd in een VNet-subnet van Resource Manager, reserveert het subnet door een koppeling voor resourcenavigatie te maken. Als het subnet al een resource van een andere provider bevat, mislukt de implementatie. Als u een API Management-service verwijdert of naar een ander subnet verplaatst, wordt de koppeling naar de resourcenavigatie verwijderd.

Problemen met het opnieuw toewijzen van API Management-exemplaar aan het vorige subnet

  • VNet-vergrendeling : wanneer u een API Management-exemplaar weer naar het oorspronkelijke subnet verplaatst, is het mogelijk dat het opnieuw toewijzen niet mogelijk is vanwege de VNet-vergrendeling. Dit duurt maximaal één uur om te worden verwijderd. Als het oorspronkelijke subnet andere stv1 platformgebaseerde API Management-services (op basis van cloudservices) heeft, is het verwijderen en wachten nodig voor het implementeren van een stv2 platformservice in hetzelfde subnet.
  • Vergrendeling van resourcegroepen: een ander scenario dat u moet overwegen, is de aanwezigheid van een bereikvergrendeling op het niveau van de resourcegroep of hoger, waardoor het verwijderingsproces van de koppeling voor resourcenavigatie wordt belemmerd. U kunt dit oplossen door de bereikvergrendeling te verwijderen en een vertraging van ongeveer 4-6 uur toe te staan voordat de API Management-service de koppeling van het oorspronkelijke subnet ongedaan maakt voordat de vergrendeling wordt verwijderd, waardoor de implementatie naar het gewenste subnet wordt ingeschakeld.

Verbinding met Microsoft Graph oplossen vanuit een VNet

Netwerkconnectiviteit met Microsoft Graph is nodig voor functies zoals gebruikersaanmelding bij de ontwikkelaarsportal met behulp van de Microsoft Entra-id-provider.

Verbindingsproblemen met Microsoft Graph oplossen vanuit een VNet:

  • Zorg ervoor dat NSG en andere netwerkregels zijn geconfigureerd voor uitgaande connectiviteit van uw API Management-exemplaar naar Microsoft Graph (met behulp van de AzureActiveDirectory-servicetag ).

  • Zorg ervoor dat dns-resolutie en netwerktoegang vanuit graph.microsoft.com het VNet. Richt bijvoorbeeld een nieuwe VIRTUELE machine in het VNet in, maak er verbinding mee en probeer vanuit GET https://graph.microsoft.com/v1.0/$metadata een browser of met cURL, PowerShell of andere hulpprogramma's.

Volgende stappen

Meer informatie over: