Lista kontrolna gotowości IPv6 dla domowego serwera self-hosted
Bezpieczne podejście polega na traktowaniu przeglądu gotowości do obsługi dwóch stosów, który niezależnie weryfikuje adresowanie, filtrowanie, DNS, tożsamość aplikacji i dostępność z zewnątrz, jako sekwencji obserwowalnych bramek, a nie pojedynczego polecenia.
W przypadku samoobsługowego domowego serwera i routera z obsługą dwóch stosów praktyczne ryzyko polega na tym, że włączenie IPv6 może utworzyć działającą ścieżkę wychodzącą, podczas gdy DNS, filtrowanie ruchu przychodzącego i działanie aplikacji zdalnej pozostaną nieweryfikowane. Zapisz bieżącą tożsamość i punkt odzyskiwania, zacznij od najmniej inwazyjnego testu rozróżniającego, zinterpretuj wyniki pozytywne i negatywne przed zmianą kolejnej zmiennej oraz przerwij, gdy pamięć masowa stanie się niestabilna lub jedyna możliwa do odzyskania kopia byłaby narażona. Poniższa procedura kończy się dopiero wtedy, gdy pierwotne obciążenie zakończy się powodzeniem albo dowody osiągną granicę eskalacji.
Spisz adresy, prefiksy i powiązania usług
Zapisz prefiks przydzielony przez dostawcę internetu, prefiksy sieci LAN routera, globalne i lokalne adresy serwera, czasy ważności adresów, trasę domyślną, resolvery DNS oraz informację, czy używane jest adresowanie prywatne lub stabilne. Ustal, który adres pozostanie odpowiedni dla serwera po odnowieniu dzierżawy, zamiast publikować tymczasowy adres klienta.
Sprawdź nasłuchujące gniazda osobno dla IPv4 i IPv6. Usługa powiązana z :: może akceptować IPv6 na interfejsach, do których nigdy nie można było dotrzeć przez przekierowanie portów IPv4, natomiast powiązanie wyłącznie z IPv4 może sprawić, że prawidłowo działająca trasa IPv6 będzie wyglądać jak awaria aplikacji.
Skorzystaj z procedury sprawdzania ekspozycji ZimaSpace na stronie sprawdzania ekspozycji domowego serwera jako dodatkowej bramki bezpieczeństwa. Nie publikuj rekordów AAAA ani nie otwieraj reguł ruchu przychodzącego, dopóki każdy proces nasłuchujący, trasa proxy, nazwa certyfikatu i granica uwierzytelniania nie będą miały właściciela.
Zweryfikuj zgodność zapór routera i hosta
Przejrzyj stanowe zasady ruchu przychodzącego na routerze, hoście, hipernadzorcy i w warstwie publikowania kontenerów. Zacznij od blokowania niezamówionego ruchu przychodzącego, a następnie twórz wąskie wyjątki określające źródło, miejsce docelowe, protokół i port wyłącznie dla usług, które muszą być publiczne lub dostępne z zaufanego prefiksu VPN.
Adresowanie globalne nie oznacza globalnej dostępności. Organizacja Internet Society w informacjach o stanowej zaporze IPv6 wskazuje, że zapora IPv6 może zezwalać na komunikację wychodzącą, jednocześnie filtrując niezamówiony ruch przychodzący. Jest to granica, którą wielu użytkowników błędnie przypisuje samej translacji NAT.
Testuj z zewnętrznej sieci IPv6, a nie z tej samej sieci LAN. Potwierdź, że zamierzony HTTPS działa, a porty administracyjne, baz danych, SMB i nieużywane pozostają zamknięte lub filtrowane; powtórz test zarówno dla adresu serwera, jak i każdego publicznego adresu proxy.
Zweryfikuj DNS, TLS, routing i rozmiar pakietów
Odpytaj rekordy A i AAAA z klientów wewnętrznych, zewnętrznych i VPN, a następnie zapisz, którego adresu faktycznie używa aplikacja. Upewnij się, że miejsce docelowe AAAA przedstawia właściwy certyfikat i kieruje nazwę hosta do tej samej tożsamości aplikacji co IPv4.
Przetestuj zwykłe żądania i większy transfer przez IPv6. Komunikaty ICMPv6 Packet Too Big są częścią działania ścieżki, dlatego szerokie blokowanie ICMPv6 może utworzyć czarną dziurę MTU ścieżki, nawet gdy małe strony się ładują; zezwalaj na wymagany ruch sterujący zamiast traktować cały ICMP jako opcjonalny.
Porównaj logi i zachowanie według rodziny adresów. Jeśli IPv6 nie działa, a IPv4 działa, pozostaw rekord AAAA nieopublikowany lub ogranicz jego zakres do czasu, aż dowody dotyczące routingu, zapory, DNS i proxy wskażą różnicę.
Przeprowadź testy awarii i trwałości przed uruchomieniem
Uruchom ponownie połączenie routera lub odnów prefiks w oknie serwisowym, a następnie potwierdź, że adresowanie serwera, dynamiczny DNS (jeśli jest używany), obiekty zapory i powiązania proxy aktualizują się zgodnie z założeniami. Uruchom ponownie serwer i sprawdź, czy reguły zostaną załadowane przed uruchomieniem usług publicznych.
Przetestuj utratę IPv6 przy zachowaniu IPv4 oraz utratę IPv4 przy zachowaniu IPv6. Klienci powinni przełączać się w przewidywalny sposób albo jasno ujawniać zależność; etykieta „dwa stosy” jest bezużyteczna, jeśli jedna rodzina adresów po cichu dociera do innej usługi lub nieaktualnego adresu.
Ogłoś gotowość dopiero wtedy, gdy zamierzone usługi działają z zewnątrz przez IPv6, niezamierzone porty pozostają zablokowane, DNS i TLS są zgodne, a zmiana prefiksu nie omija zasad. Najpierw wycofaj publikację AAAA, gdy wyniki się rozbieżne, a następnie zachowaj dowody w postaci pakietów i konfiguracji zapory do dalszej korekty.
Polecane produkty
Wsparcie i wskazówki
Więcej do przeczytania
Przewodnik po pamięci masowej nagrywania telewizji na żywo: pojemność, przechowywanie i czyszczenie
Zmierz rzeczywiste nagrania, zarezerwuj zapas, połącz limity wieku i pojemności oraz potwierdź, że najstarszy kwalifikujący się program zostanie usunięty, zanim pamięć się zapełni.
Proces odzyskiwania metadanych multimediów domowych po przywróceniu bazy danych
Zabezpiecz przywrócony stan, zweryfikuj tożsamość multimediów i ścieżki, a następnie napraw brakujące grafiki lub dopasowania w pilotażowej bibliotece przed wprowadzeniem szeroko zakrojonych zmian metadanych.
Lista zgodności klientów Jellyfin z dźwiękiem, obrazem i napisami
Testuj reprezentatywne pliki, zmieniając jedną zmienną naraz, i rejestruj dla każdego klienta: bezpośrednie odtwarzanie, remultipleksowanie, konwersję dźwięku, transkodowanie wideo lub niepowodzenie.
