

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

# Netzwerkkonfiguration und Porteinstellungen
<a name="dotnet-migrating-applications-network"></a>

In diesem Abschnitt werden Netzwerkkonfigurationsoptionen für IIS-Migrationen behandelt, einschließlich VPC-Einstellungen, Portkonfigurationen und Bereitstellungen an mehreren Standorten.

## VPC-Konfiguration
<a name="dotnet-migrating-applications-network-vpc"></a>

Der **eb migrate** Befehl bietet flexible VPC-Konfigurationsoptionen für Ihre Elastic Beanstalk Beanstalk-Umgebung. Das Tool kann entweder VPC-Einstellungen von einer EC2-Quellinstanz erkennen oder benutzerdefinierte VPC-Konfigurationen über Befehlszeilenparameter akzeptieren. Lesen Sie[Verwenden von Elastic Beanstalk mit Amazon VPC](vpc.md), um zu erfahren, wie Elastic Beanstalk mit VPC konfiguriert wird.

### Automatische VPC-Erkennung
<a name="dotnet-migrating-applications-network-vpc-auto"></a>

Wenn sie auf einer EC2-Instance **eb migrate** ausgeführt wird, erkennt und verwendet sie automatisch die VPC-Konfiguration aus den EC2-Instances der Quellumgebung. Die folgende Beispielausgabe veranschaulicht die von ihr erkannten Konfigurationsinformationen:

```
PS C:\migrations_workspace > eb migrate
Identifying VPC configuration of this EC2 instance (i-0123456789abcdef0):
  id: vpc-1234567890abcdef0
  publicip: true
  elbscheme: public
  ec2subnets: subnet-123,subnet-456,subnet-789
  securitygroups: sg-123,sg-456
  elbsubnets: subnet-123,subnet-456,subnet-789
...
```

Die erkannte Konfiguration umfasst:
+ VPC-ID
+ Einstellungen für die öffentliche IP-Zuweisung
+ Load Balancer-Schema (öffentlich/privat)
+ Subnetzzuweisungen für EC2-Instances
+ Zuordnungen von Sicherheitsgruppen
+ Subnetzzuweisungen für den Load Balancer

### Lokale oder nicht in der Cloud befindliche Hosts AWS
<a name="dotnet-migrating-applications-network-vpc-onprem"></a>

Wenn der Elastic Beanstalk-Service auf einem lokalen Server oder einem AWS Nicht-Cloud-Host **eb migrate** ausgeführt wird, verwendet er die Standard-VPC in Ihrem Konto. AWS Die folgende Liste zeigt ein Beispiel für einen Befehl und eine Ausgabe:

```
PS C:\migrations_worspace> eb migrate `
      -k windows-test-pem `
      --region us-east-1 `
      -a EBMigratedEnv `
      -e EBMigratedEnv-test2 `
      --copy-firewall-config
Determining EB platform based on host machine properties
Using .\migrations\latest to contain artifacts for this migration run.
...
```

Lesen Sie [Verwenden von Elastic Beanstalk mit Amazon VPC](vpc.md) weiter, um zu erfahren, wie Elastic Beanstalk die Standard-VPC für Ihre Umgebung konfiguriert.

### Benutzerdefinierte VPC-Konfiguration
<a name="dotnet-migrating-applications-network-vpc-custom"></a>

Stellen Sie für jede Quellumgebung (EC2, lokal oder nicht in der AWS Cloud), in der Sie bestimmte VPC-Einstellungen benötigen, eine VPC-Konfigurationsdatei wie die im folgenden Beispiel bereit:

```
{
    "id": "vpc-12345678",
    "publicip": "true",
    "elbscheme": "public",
    "ec2subnets": ["subnet-a1b2c3d4", "subnet-e5f6g7h8"],
    "securitygroups": "sg-123456,sg-789012",
    "elbsubnets": ["subnet-a1b2c3d4", "subnet-e5f6g7h8"]
}
```

Wenden Sie diese Konfiguration mit dem folgenden Befehl an:

```
PS C:\migrations_workspace> eb migrate --vpc-config vpc-config.json
```

**Anmerkung**  
Die VPC-Konfigurationsdatei erfordert das `id` Feld, das die VPC-ID angibt. Alle anderen Felder sind optional und Elastic Beanstalk verwendet Standardwerte für alle Felder, die Sie nicht angeben.

**Wichtig**  
Bei *der Migration werden alle vorhandenen VPC-Einstellungen aus der Quellumgebung ignoriert, wenn Sie den `--vpc-config` *Parameter* angeben*. Wenn Sie diesen Parameter verwenden, verwendet die Migration nur die VPC-Einstellungen, die in der Konfigurationsdatei angegeben sind, die Sie übergeben. Die Verwendung dieses Parameters setzt das Standardverhalten beim Erkennen der VPC-Konfiguration der Quell-Instance oder beim Verwenden der Standard-VPC außer Kraft.

Verwenden Sie den `--vpc-config` Parameter in diesen Szenarien:
+ Wenn Sie Nicht-EC2-Umgebungen migrieren, die keine erkennbaren VPC-Einstellungen haben
+ Wenn Sie zu einer anderen VPC migrieren als der, die von der Quellumgebung verwendet wird
+ Wenn Sie Subnetzauswahlen oder Sicherheitsgruppenkonfigurationen anpassen müssen
+ Wenn die automatische Erkennung die gewünschten VPC-Einstellungen nicht korrekt identifiziert
+ Wenn Sie von einer lokalen Umgebung migrieren und nicht die Standard-VPC verwenden möchten

### Konfiguration der Netzwerksicherheit
<a name="dotnet-migrating-applications-network-vpc-security"></a>

**eb migrate**Öffnet standardmäßig Port 80 auf Zielinstanzen, kopiert jedoch keine anderen Windows-Firewallregeln vom Quellcomputer. Verwenden Sie den folgenden Befehl, um alle Firewallkonfigurationen einzubeziehen:

```
PS C:\migrations_workspace> eb migrate --copy-firewall-config
```

Dieser Befehl führt die folgenden Aktionen aus:
+ Identifiziert Ports, die von IIS-Site-Bindungen verwendet werden
+ Ruft die entsprechenden Firewallregeln ab
+ Generiert PowerShell Skripts, um Regeln auf Zielinstanzen neu zu erstellen
+ Behält alle DENY-Regeln für Port 80 vom Quellcomputer bei (andernfalls ist Port 80 standardmäßig zulässig)

Stellen Sie sich einen Anwendungsfall vor, bei dem Ihr Quellcomputer über die im folgenden Beispiel angegebenen Firewallregeln verfügt:

```
# Source machine firewall configuration
Get-NetFirewallRule | Where-Object {$_.Enabled -eq 'True'} | Get-NetFirewallPortFilter | Where-Object {$_.LocalPort -eq 80 -or $_.LocalPort -eq 443 -or $_.LocalPort -eq 8081}
# Output shows rules for ports 80, 443, and 8081
```

Bei der Migration wird ein Skript (`modify_firewall_config.ps1`) erstellt, das die folgende Konfiguration enthält:

```
New-NetFirewallRule -DisplayName "Allow Web Traffic" -Direction Inbound -Action Allow -Protocol TCP -LocalPort 80,443
New-NetFirewallRule -DisplayName "Allow API Traffic" -Direction Inbound -Action Allow -Protocol TCP -LocalPort 8081
```

Das Migrationstool führt automatisch die folgenden Aktionen aus:
+ Extrahiert HTTP/HTTPS Ports aus allen IIS-Site-Bindungen
+ Verwendet die Windows-Firewall [INetFwPolicy2-Schnittstelle](https://learn.microsoft.com/en-us/windows/win32/api/netfw/nn-netfw-inetfwpolicy2), um Firewallregeln aufzulisten
+ Filtert Regeln so, dass sie nur Regeln einschließen, die explizit auf die angegebenen Ports verweisen
+ Verarbeitet nur HTTP- und HTTPS-Site-Bindungen und die zugehörigen Firewallregeln
+ Behält die Regeleigenschaften wie Anzeigename, Aktion, Protokoll und Aktivierungsstatus bei
+ Behandelt sowohl einzelne Ports als auch Portbereiche in Firewallregeln
+ Fügt das Firewall-Konfigurationsskript zum Bereitstellungsmanifest hinzu

### Load Balancer-Konfiguration
<a name="dotnet-migrating-applications-network-vpc-lb"></a>

Sie können die Load Balancer Balancer-Konfiguration über das `--vpc-config` Argument angeben. Die folgenden Beispiele veranschaulichen die Parameter.

Auswahl des Schemas  
Wählen Sie zwischen öffentlichen und privaten Load Balancer-Schemata:  

```
{
    "id": "vpc-12345678",
    "elbscheme": "private",
    "elbsubnets": ["subnet-private1", "subnet-private2"]
}
```

Verteilung über Subnetze  
Um eine hohe Verfügbarkeit zu gewährleisten, verteilen Sie die Load Balancer-Subnetze auf die Availability Zones:  

```
{
    "elbsubnets": [
        "subnet-az1", // Availability Zone 1
        "subnet-az2", // Availability Zone 2
        "subnet-az3"  // Availability Zone 3
    ]
}
```

**Anmerkung**  
Elastic Beanstalk unterstützt zwar die Erstellung von Umgebungen mit Application Load Balancers, Network Load Balancers und Classic Load Balancers, der **eb migrate** Befehl unterstützt jedoch nur Application Load Balancers. Weitere Informationen zu Load-Balancer-Typen finden Sie unter [Load Balancer Ihrer Elastic-Beanstalk-Umgebung](using-features.managing.elb.md).

## Bereitstellungen an mehreren Standorten mit Portkonfigurationen
<a name="dotnet-migrating-applications-network-multi"></a>

Der **eb migrate** Befehl verarbeitet komplexe IIS-Bereitstellungen an mehreren Standorten, bei denen Anwendungen möglicherweise Abhängigkeiten gemeinsam haben oder nicht standardmäßige Ports verwenden. Betrachten Sie das folgende Beispiel für eine typische Unternehmenseinrichtung mit mehreren Standorten:

```
<!-- IIS Configuration -->
<sites>
    <site name="Default Web Site" id="1">
        <bindings>
            <binding protocol="http" bindingInformation="*:80:www.example.com" />
        </bindings>
    </site>
    <site name="InternalAPI" id="2">
        <bindings>
            <binding protocol="http" bindingInformation="*:8081:api.internal" />
        </bindings>
    </site>
    <site name="ReportingPortal" id="3">
        <bindings>
            <binding protocol="http" bindingInformation="*:8082:reports.internal" />
        </bindings>
    </site>
</sites>
```

Verwenden Sie den folgenden Beispielbefehl und die folgenden Parameter, um diese Konfiguration zu migrieren:

```
PS C:\migrations_workspace> eb migrate `
    --sites "Default Web Site,InternalAPI,ReportingPortal" `
    --copy-firewall-config `
    --instance-type "c5.large"
```

Der **eb migrate** Befehl erstellt ein Bereitstellungspaket, das die Identität und Konfiguration der einzelnen Standorte beibehält. Der Befehl generiert eine`aws-windows-deployment-manifest.json`, die definiert, wie diese Sites bereitgestellt werden sollen. Das folgende Beispiel zeigt eine generierte JSON-Datei:

```
{
    "manifestVersion": 1,
    "deployments": {
        "msDeploy": [
            {
                "name": "DefaultWebSite",
                "parameters": {
                    "appBundle": "DefaultWebSite.zip",
                    "iisPath": "/",
                    "iisWebSite": "Default Web Site"
                }
            }
        ],
        "custom": [
            {
                "name": "InternalAPI",
                "scripts": {
                    "install": {
                        "file": "ebmigrateScripts\\install_site_InternalAPI.ps1"
                    },
                    "restart": {
                        "file": "ebmigrateScripts\\restart_site_InternalAPI.ps1"
                    },
                    "uninstall": {
                        "file": "ebmigrateScripts\\uninstall_site_InternalAPI.ps1"
                    }
                }
            },
            {
                "name": "ReportingPortal",
                "scripts": {
                    "install": {
                        "file": "ebmigrateScripts\\install_site_ReportingPortal.ps1"
                    },
                    "restart": {
                        "file": "ebmigrateScripts\\restart_site_ReportingPortal.ps1"
                    },
                    "uninstall": {
                        "file": "ebmigrateScripts\\uninstall_site_ReportingPortal.ps1"
                    }
                }
            }
        ]
    }
}
```

Der Migrationsprozess erstellt die folgenden Application Load Balancer Balancer-Listener-Regeln, die Ihre ursprüngliche Routing-Logik beibehalten:
+ Der Verkehr über Port 80 leitet zur Standardwebsite weiter
+ Port 8081 leitet den Verkehr zur InternalAPI weiter
+ Port 8082 Verkehrswege zu ReportingPortal

## Gemeinsame Konfiguration und Abhängigkeiten
<a name="dotnet-migrating-applications-network-shared"></a>

Wenn Websites Konfigurationen oder Abhängigkeiten gemeinsam nutzen, werden diese Beziehungen angemessen **eb migrate** behandelt. Sehen Sie sich das folgende Beispiel an, in dem mehrere Standorte eine gemeinsame Konfiguration verwenden:

```
<!-- Shared configuration in applicationHost.config -->
<location path="Default Web Site">
    <system.webServer>
        <asp enableSessionState="true" />
        <caching enabled="true" enableKernelCache="true" />
    </system.webServer>
</location>
```

Der Migrationsprozess umfasst die folgenden Aufgaben:

1. Identifiziert gemeinsam genutzte Konfigurationen an mehreren Standorten

1. Generiert entsprechende PowerShell Skripts, um diese Einstellungen anzuwenden

1. Behält die Konfigurationshierarchie und Verer

## Best Practices
<a name="dotnet-migrating-applications-network-best"></a>

Wir empfehlen, dass Sie die bewährten Methoden für die Netzwerkkonfiguration Ihrer migrierten Anwendung befolgen. Die folgenden Gruppierungen bieten zusammenfassende Richtlinien.

VPC-Design  
+ Folgen Sie den Best AWS Practices für VPC-Design
+ Verwenden Sie separate Subnetze für Load Balancer und EC2-Instances
+ Implementieren Sie die richtigen Routentabellen und NACLs
+ Ziehen Sie VPC-Endpunkte für Dienste in Betracht AWS 

Hohe Verfügbarkeit  
+ Bereitstellen über mehrere Availability Zones hinweg
+ Verwenden Sie mindestens zwei Subnetze für Load Balancer
+ Konfigurieren Sie die auto-scaling für AZs
+ Implementieren Sie angemessene Gesundheitschecks

Sicherheit  
+ Befolgen Sie die bewährten Sicherheitsmethoden
+ Verwenden Sie Sicherheitsgruppen als primäre Zugriffskontrolle
+ Implementieren Sie Netzwerk-Zugriffskontrolllisten (ACLs) für zusätzliche Sicherheit
+ VPC-Flow-Logs überwachen

## Fehlerbehebung
<a name="dotnet-migrating-applications-network-troubleshooting"></a>

Zu den häufigsten Problemen mit der Netzwerkkonfiguration gehören die folgenden Bereiche. Nach jedem Thema finden Sie Beispielbefehle, mit denen Sie weitere Informationen zur Netzwerkkonfiguration und zum Zustand Ihrer Umgebung erhalten können.

Konfiguration des Subnetzes  

```
# Verify subnet availability
PS C:\migrations_workspace> aws ec2 describe-subnets --subnet-ids subnet-id

# Check available IP addresses
PS C:\migrations_workspace>aws ec2 describe-subnets --subnet-ids subnet-id --query 'Subnets[].AvailableIpAddressCount'
```

Zugriff auf Sicherheitsgruppen  

```
# Verify security group rules
PS C:\migrations_workspace> aws ec2 describe-security-groups --group-ids sg-id

# Test network connectivity
PS C:\migrations_workspace> aws ec2 describe-network-interfaces --filters Name=group-id,Values=sg-id
```

Zustand des Load Balancers  

```
# Check load balancer health
PS C:\migrations_workspace> aws elbv2 describe-target-health --target-group-arn arn:aws:elasticloadbalancing:region:account-id:targetgroup/group-name/group-id
```