IPv6-Bereitschaftscheckliste für einen selbst gehosteten Heimserver

Der sichere Ansatz besteht darin, eine Dual-Stack-Bereitschaftsprüfung, die Adressierung, Filterung, DNS, Anwendungsidentität und externe Erreichbarkeit unabhängig voneinander verifiziert, als eine Abfolge beobachtbarer Prüfungen zu behandeln und nicht als einen einzelnen Befehl.

Auf einem selbst gehosteten Dual-Stack-Heimserver und Router besteht das praktische Risiko darin, dass die Aktivierung von IPv6 einen funktionierenden ausgehenden Pfad schafft, während DNS, eingehende Filterung und das Verhalten der Anwendung aus der Ferne weiterhin ungeprüft sind. Erfassen Sie die aktuelle Identität und den Wiederherstellungspunkt, beginnen Sie mit dem am wenigsten invasiven Unterscheidungstest, werten Sie erfolgreiche und fehlgeschlagene Ergebnisse aus, bevor Sie eine weitere Variable ändern, und brechen Sie ab, sobald der Speicher instabil wird oder die einzige wiederherstellbare Kopie offengelegt werden müsste. Der folgende Ablauf endet erst, wenn die ursprüngliche Arbeitslast erfolgreich ist oder die Beweislage eine Eskalationsgrenze erreicht.

Adressen, Präfixe und Dienstbindungen erfassen

Erfassen Sie das vom ISP delegierte Präfix, die LAN-Präfixe des Routers, die globalen und link-lokalen Adressen des Servers, Gültigkeitsdauern der Adressen, die Standardroute, DNS-Resolver sowie die Information, ob temporäre oder stabile Adressierung verwendet wird. Ermitteln Sie, welche Adresse für einen Server auch nach Erneuerungen geeignet bleibt, statt eine temporäre Client-Adresse zu veröffentlichen.

Prüfen Sie die lauschenden Sockets getrennt für IPv4 und IPv6. Ein Dienst, der an :: gebunden ist, kann IPv6 auf Schnittstellen akzeptieren, die über IPv4 nie durch Portweiterleitung erreichbar waren, während eine reine IPv4-Bindung eine funktionierende IPv6-Route wie einen Anwendungsfehler erscheinen lassen kann.

Verwenden Sie den ZimaSpace-Ablauf zur Prüfung der Erreichbarkeit unter Prüfung der Erreichbarkeit des Heimservers als angrenzende Sicherheitsprüfung. Veröffentlichen Sie keine AAAA-Einträge und öffnen Sie keine eingehenden Regeln, bevor jeder lauschende Prozess, jede Proxy-Route, jeder Zertifikatsname und jede Authentifizierungsgrenze einem Verantwortlichen zugeordnet ist.

Parität zwischen Router- und Host-Firewall prüfen

Überprüfen Sie die zustandsbehaftete Richtlinie für eingehenden Datenverkehr auf Router, Host, Hypervisor und der Ebene für die Veröffentlichung von Containern. Blockieren Sie zunächst unaufgeforderten eingehenden Datenverkehr und erstellen Sie dann nur für Dienste, die öffentlich oder aus einem vertrauenswürdigen VPN-Präfix erreichbar sein müssen, eng gefasste Ausnahmen für Quelle, Ziel, Protokoll und Port.

Eine globale Adressierung erfordert keine globale Erreichbarkeit. Die zustandsbehaftete IPv6-Firewall-Grenze der Internet Society weist darauf hin, dass eine IPv6-Firewall ausgehende Kommunikation erlauben und gleichzeitig unaufgeforderten eingehenden Datenverkehr filtern kann - eine Grenze, die viele Nutzer fälschlicherweise NAT selbst zuschreiben.

Testen Sie von einem externen IPv6-Netzwerk aus, nicht aus demselben LAN. Bestätigen Sie, dass das gewünschte HTTPS funktioniert und administrative, Datenbank-, SMB- sowie ungenutzte Ports geschlossen bleiben oder gefiltert werden; wiederholen Sie den Test für die Serveradresse und jede öffentliche Proxy-Adresse.

DNS, TLS, Routing und Paketgröße validieren

Fragen Sie A- und AAAA-Einträge von internen, externen und VPN-Clients ab und protokollieren Sie anschließend, welche Adresse die Anwendung tatsächlich verwendet. Stellen Sie sicher, dass das AAAA-Ziel das richtige Zertifikat präsentiert und den Hostnamen auf dieselbe Anwendungsidentität wie bei IPv4 weiterleitet.

Testen Sie gewöhnliche Anfragen und eine größere Übertragung über IPv6. ICMPv6-Nachrichten vom Typ „Packet Too Big“ sind Bestandteil des Netzwerkpfads. Eine umfassende Blockierung von ICMPv6 kann daher ein Path-MTU-Schwarzes Loch erzeugen, selbst wenn kleine Seiten geladen werden. Erlauben Sie den erforderlichen Steuerverkehr, statt sämtliches ICMP als optional zu behandeln.

Vergleichen Sie Protokolle und Verhalten nach Adressfamilie. Wenn IPv6 fehlschlägt, während IPv4 funktioniert, lassen Sie den AAAA-Eintrag unveröffentlicht oder begrenzen Sie seinen Geltungsbereich, bis Routing, Firewall, DNS und Proxy-Daten den Unterschied erkennen lassen.

Featured

ZimaCube 2 Persönliche Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Fehler- und Persistenztests vor der Freigabe durchführen

Starten Sie die Routerverbindung neu oder erneuern Sie das Präfix innerhalb eines Wartungsfensters. Bestätigen Sie anschließend, dass sich Serveradressierung, dynamisches DNS, sofern verwendet, Firewall-Objekte und Proxy-Bindungen wie vorgesehen aktualisieren. Starten Sie den Server neu und überprüfen Sie, dass die Regeln geladen werden, bevor öffentliche Dienste starten.

Testen Sie den Ausfall von IPv6 bei weiterhin verfügbarem IPv4 sowie den Ausfall von IPv4 bei weiterhin verfügbarem IPv6. Clients sollten vorhersehbar auf die jeweils andere Verbindung ausweichen oder eine klare Abhängigkeit anzeigen. Eine Dual-Stack-Kennzeichnung ist nicht hilfreich, wenn eine Adressfamilie unbemerkt einen anderen Dienst oder eine veraltete Adresse erreicht.

Erklären Sie die Bereitschaft erst dann für gegeben, wenn die vorgesehenen Dienste extern über IPv6 funktionieren, nicht vorgesehene Ports weiterhin blockiert sind, DNS und TLS übereinstimmen und eine Präfixänderung die Richtlinie nicht umgehen kann. Machen Sie bei abweichenden Ergebnissen zuerst die Veröffentlichung des AAAA-Eintrags rückgängig und bewahren Sie anschließend Paket- und Firewall-Daten zur Korrektur auf.