IPv6-gereedheidschecklist voor een zelfgehoste thuisserver

De veilige aanpak is om een gereedheidscontrole voor dual-stack, waarbij adressering, filtering, DNS, applicatie-identiteit en externe bereikbaarheid afzonderlijk worden geverifieerd, te behandelen als een reeks waarneembare controlepunten en niet als één opdracht.

Op een dual-stack zelfgehoste thuisserver en router bestaat het praktische risico dat het inschakelen van IPv6 een werkend uitgaand pad creëert, terwijl DNS, inkomende filtering en het gedrag van externe applicaties nog niet zijn gecontroleerd. Leg de huidige identiteit en het herstelpunt vast, begin met de minst ingrijpende onderscheidende test, interpreteer geslaagde en mislukte resultaten voordat je een andere variabele wijzigt, en stop wanneer de opslag instabiel wordt of de enige herstelbare kopie zou worden blootgesteld. De onderstaande workflow eindigt pas nadat de oorspronkelijke workload succesvol werkt of het bewijsmateriaal een escalatiegrens bereikt.

Inventariseer adressen, prefixen en servicebindingen

Leg het door de ISP gedelegeerde prefix, de LAN-prefixen van de router, de globale en link-local adressen van de server, de geldigheidsduur van adressen, de standaardroute, de DNS-resolvers en het gebruik van privacy- of stabiele adressering vast. Bepaal welk adres geschikt blijft voor een server tijdens vernieuwingen, in plaats van een tijdelijk clientadres te publiceren.

Inspecteer afzonderlijk de luisterende sockets voor IPv4 en IPv6. Een service die aan :: is gebonden, kan IPv6 accepteren op interfaces die via IPv4 nooit bereikbaar waren, terwijl een binding die alleen IPv4 ondersteunt een gezonde IPv6-route kan laten lijken op een applicatiefout.

Gebruik de ZimaSpace-workflow voor blootstelling op de controle van blootstelling van de thuisserver als aangrenzend veiligheidscontrolepunt. Publiceer geen AAAA-records en open geen inkomende regels totdat voor elk luisterend proces, elke proxyroute, certificaatnaam en authenticatiegrens een eigenaar is aangewezen.

Controleer de gelijkheid van router- en hostfirewall

Controleer het stateful inkomende beleid op de router, host, hypervisor en containerpublicatielaag. Begin met het weigeren van ongevraagd inkomend verkeer en maak vervolgens alleen nauwe uitzonderingen voor bron, bestemming, protocol en poort voor services die openbaar moeten zijn of bereikbaar moeten zijn vanaf een vertrouwd VPN-prefix.

Globale adressering vereist geen wereldwijde bereikbaarheid. De stateful IPv6-firewallgrens van de Internet Society vermeldt dat een IPv6-firewall uitgaande communicatie kan toestaan en tegelijk ongevraagd inkomend verkeer kan filteren. Dat is de grens die veel gebruikers ten onrechte aan NAT zelf toeschrijven.

Test vanaf een extern IPv6-netwerk en niet vanaf hetzelfde LAN. Bevestig dat het bedoelde HTTPS werkt en dat administratieve, database-, SMB- en ongebruikte poorten gesloten of gefilterd blijven; herhaal dit voor zowel het serveradres als elk openbaar proxyadres.

Valideer DNS, TLS, routing en pakketgrootte

Raadpleeg A- en AAAA-records vanaf interne, externe en VPN-clients en leg vervolgens vast welk adres de applicatie daadwerkelijk gebruikt. Zorg dat de AAAA-bestemming het juiste certificaat presenteert en de hostnaam naar dezelfde applicatie-identiteit routeert als IPv4.

Test gewone verzoeken en een grotere overdracht via IPv6. ICMPv6-berichten van het type Packet Too Big maken deel uit van de werking van het pad. Het breed blokkeren van ICMPv6 kan daarom een black hole voor de pad-MTU veroorzaken, zelfs wanneer kleine pagina's laden; sta vereist controleverkeer toe in plaats van alle ICMP als optioneel te behandelen.

Vergelijk logs en gedrag per adresfamilie. Als IPv6 faalt terwijl IPv4 werkt, houd het AAAA-record dan ongepubliceerd of beperk het bereik totdat routing-, firewall-, DNS- en proxygegevens het verschil verklaren.

Featured

ZimaCube 2 Persoonlijke Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Voer fout- en persistentietests uit vóór vrijgave

Herstart de routerverbinding of vernieuw het prefix binnen een onderhoudsvenster en bevestig vervolgens dat serveradressering, dynamische DNS indien gebruikt, firewallobjecten en proxybindingen worden bijgewerkt zoals bedoeld. Herstart de server en controleer of de regels worden geladen voordat openbare services starten.

Test het wegvallen van IPv6 terwijl IPv4 actief blijft, en het wegvallen van IPv4 terwijl IPv6 actief blijft. Clients moeten voorspelbaar overschakelen of een duidelijke afhankelijkheid tonen; een dual-stacklabel is niet nuttig als de ene familie stilletjes een andere service of verouderd adres bereikt.

Verklaar de omgeving pas gereed wanneer de bedoelde services extern via IPv6 werken, ongewenste poorten geblokkeerd blijven, DNS en TLS overeenkomen en een prefixwijziging het beleid niet kan omzeilen. Draai eerst de publicatie van AAAA terug wanneer resultaten uiteenlopen en bewaar vervolgens de pakket- en firewallgegevens voor correctie.