Checklista för IPv6-beredskap för en självhostad hemserver

Eva Wong

IceWhale author

Eva Wong är Teknisk skribent och den boende fixaren på ZimaSpace. En livslång nörd med en passion för hemma-labb och öppen källkod, hon specialiserar sig på att översätta komplexa tekniska koncept till tillgängliga, praktiska guider. Eva tror att självhosting ska vara roligt, inte skrämmande. Genom sina handledningar ger hon gemenskapen verktyg att avmystifiera hårdvaruinstallationer, från att bygga sin första NAS till att bemästra Docker-containrar.

IPv6 Readiness Checklist for a Self-Hosted Home Server - Zima Store Online

Det säkra tillvägagångssättet är att behandla en beredskapsgranskning för dual stack, som oberoende verifierar adressering, filtrering, DNS, applikationsidentitet och extern nåbarhet, som en serie observerbara kontrollpunkter - inte som ett enda kommando.

På en självhostad hemserver och router med dual stack är den praktiska risken att aktivering av IPv6 kan skapa en fungerande utgående väg samtidigt som DNS, inkommande filtrering och fjärrbeteendet hos applikationen förblir overifierade. Dokumentera den aktuella identiteten och återställningspunkten, börja med den minst ingripande särskiljande kontrollen, tolka godkända och underkända resultat innan du ändrar en annan variabel och stoppa när lagringen blir instabil eller den enda återställningsbara kopian skulle exponeras. Arbetsflödet nedan avslutas först när den ursprungliga arbetsbelastningen fungerar eller bevisen når en eskaleringsgräns.

Inventera adresser, prefix och tjänstebindningar

Dokumentera det prefix som ISP:n delegerat, routerns LAN-prefix, serverns globala och länk-lokala adresser, adressernas giltighetstider, standardrutten, DNS-resolverna och om integritets- eller stabil adressering används. Fastställ vilken adress som förblir lämplig för en server vid förnyelser, i stället för att publicera en tillfällig klientadress.

Inspektera lyssnande sockets separat för IPv4 och IPv6. En tjänst som är bunden till :: kan acceptera IPv6 på gränssnitt som aldrig varit nåbara via IPv4-portvidarebefordran, medan en bindning som endast använder IPv4 kan få en fungerande IPv6-rutt att se ut som ett applikationsfel.

Använd ZimaSpaces exponeringsarbetsflöde i kontrollen av hemserverns exponering som en angränsande säkerhetskontroll. Publicera inte AAAA-poster och öppna inte inkommande regler förrän varje lyssnande process, proxyrutt, certifikatnamn och autentiseringsgräns har en ansvarig.

Verifiera överensstämmelse mellan router- och värdbrandvägg

Granska tillståndsbaserade inkommande regler på routern, värden, hypervisorn och lagret för publicering av containrar. Börja med att neka oombedd inkommande trafik och skapa sedan snäva undantag för källa, destination, protokoll och port endast för tjänster som måste vara offentliga eller nåbara från ett betrott VPN-prefix.

Global adressering kräver inte global nåbarhet. Internet Societys tillståndsbaserade IPv6-brandväggsgräns påpekar att en IPv6-brandvägg kan tillåta utgående kommunikation samtidigt som den filtrerar oombedd inkommande trafik, vilket är den gräns många användare felaktigt tillskriver NAT i sig.

Testa från ett externt IPv6-nätverk, inte från samma LAN. Bekräfta att avsedd HTTPS fungerar och att administrativa portar, databasportar, SMB-portar och oanvända portar förblir stängda eller filtrerade. Upprepa testet mot både serveradressen och eventuell offentlig proxyadress.

Validera DNS, TLS, routing och paketstorlek

Fråga efter A- och AAAA-poster från interna, externa och VPN-klienter och dokumentera vilken adress applikationen faktiskt använder. Säkerställ att AAAA-destinationen visar rätt certifikat och dirigerar värdnamnet till samma applikationsidentitet som IPv4.

Testa vanliga förfrågningar och en större överföring över IPv6. ICMPv6-meddelanden av typen Packet Too Big ingår i nätvägens funktion, så en bred blockering av ICMPv6 kan skapa ett svart hål för sökvägens MTU även när små sidor laddas. Tillåt nödvändig kontrolltrafik i stället för att behandla all ICMP som valfri.

Jämför loggar och beteende per adressfamilj. Om IPv6 misslyckas medan IPv4 fungerar, låt AAAA-posten förbli opublicerad eller begränsa dess omfattning tills bevis från routing, brandvägg, DNS och proxy identifierar skillnaden.

Featured

ZimaCube 2 personlig molnhem NAS

ZimaCube2

Kör fel- och beständighetstester före driftsättning

Starta om routeranslutningen eller förnya prefixet under ett underhållsfönster och bekräfta sedan att serverns adressering, dynamisk DNS om den används, brandväggsobjekt och proxybindningar uppdateras enligt plan. Starta om servern och verifiera att reglerna läses in innan offentliga tjänster startar.

Testa bortfall av IPv6 medan IPv4 finns kvar, och bortfall av IPv4 medan IPv6 finns kvar. Klienter bör växla över på ett förutsägbart sätt eller visa ett tydligt beroende. En dual-stack-etikett är inte användbar om den ena familjen i tysthet når en annan tjänst eller en inaktuell adress.

Förklara beredskap först när avsedda tjänster fungerar externt över IPv6, oavsiktliga portar förblir blockerade, DNS och TLS överensstämmer och en prefixändring inte kringgår policyn. Rulla först tillbaka publiceringen av AAAA när resultaten avviker och bevara sedan paket- och brandväggsbevis för korrigering.