Jak zapisać punkt końcowy IPv6 w konfiguracji VPN

Adres IPv6 jest pełen dwukropków, a pole punktu końcowego, które niesie też port, potrzebuje sposobu oznaczenia, gdzie adres się kończy. Jeśli zrobisz to źle, klient albo odmówi analizy profilu, albo po cichu połączy się z niewłaściwą rzeczą. Poprawna forma nie jest uniwersalna: zależy od tego, czy pole zawiera adres z portem, sam adres, czy nazwę hosta. Przejdź przez instrukcję po kolei, bo poprawka składni i poprawka osiągalności wyglądają zupełnie inaczej, gdy zaczniesz czytać wyjście klienta.

Sprawdź typ pola, zanim wpiszesz adres

Na przykład, WireGuard Endpoint pole z portem używa nawiasów kwadratowych wokół adresu, jak w [2001:db8::10]:51820. Prefiks dokumentacyjny w tym przykładzie nie jest publicznym serwerem, a nawiasy są częścią składni, nie adresu.

Inne formaty mają własne zasady. URI może nieść literał IPv6 w nawiasach, ale konfiguracja VPN niekoniecznie jest URI. Klient z osobnymi polami adresu i portu może oczekiwać w jednym polu tylko literału, a w drugim liczby, i dodawanie tam nawiasów jest tak samo błędne, jak pomijanie ich w polu łączonym.

Umieść literał w nawiasach, gdy port dzieli to samo pole

Zasada, którą warto zapamiętać, jest prosta: nawiasy pojawiają się, gdy w tym samym ciągu następuje port. Nie pojawiają się, gdy adres stoi sam w polu bez portu.

Kopiowanie całego ciągu punktu końcowego jednego protokołu do każdego klienta jest zwykłą przyczyną tego błędu. OpenVPN, profile IPsec i interfejsy aplikacji dokumentują każdy własną składnię, a ciąg poprawny dla jednego może zostać odrzucony lub błędnie zinterpretowany przez inny. Czytaj dokumentację samego klienta dla pola, które edytujesz, i trzymaj prefiks dokumentacyjny lub przykładowy adres w komentarzu, żeby nikt nie wysłał go jako prawdziwego hosta. Gdy instrukcja podaje dwie formy, użyj tej, która pasuje do typu pola przed tobą.

Oddziel pola adresu i portu

Gdy klient daje dwa pola, umieść adres w jednym, a port w drugim. Forma łączona wklejona w pole adresu daje błąd analizy albo, co gorsza, adres, który rozwiązuje się na coś niezamierzonego.

Sprawdź końcowe spacje i niewidoczne znaki, gdy wartość wygląda poprawnie. Skopiowany adres często niesie twardą spację lub znak o zerowej szerokości, którego klient nie potrafi przeanalizować, a ekran nie pokazuje. Wpisz wartość ponownie zamiast wklejać, gdy błąd nie ma sensu.

Ostrożnie obchodź się z identyfikatorami strefy

Literał łącza lokalnego może wymagać identyfikatora strefy powiązanego z interfejsem, zapisanego znakiem procentu i nazwą interfejsu. Ta forma jest ważna na hoście, do którego należy interfejs, i nie zastępuje ogólnie osiągalnego zdalnego punktu końcowego.

Zakres i trasowanie nadal mają znaczenie po udanej analizie. Adres IPv6 kwalifikowany strefą, który klient akceptuje, może nie mieć żadnej trasy z maszyny, a zdalny punkt końcowy osiągany przez internet nie powinien w ogóle zależeć od lokalnej strefy. Zdecyduj, przez który interfejs pakiet ma wyjść, zanim wpiszesz strefę, a nie po tym, jak uścisk dłoni się nie powiedzie.

Sprawdź analizę, potem osiągalność

Wyraźnie rozdziel oba błędy. Zniekształcony adres daje błąd analizy lub natychmiastowe odrzucenie, podczas gdy poprawnie zbudowany punkt końcowy, który odrzuca uwierzytelnianie albo nigdy nie odpowiada, to inny problem z innym rozwiązaniem.

Po obsługiwanej poprawce potwierdź, że tunel negocjuje i że zamierzona aplikacja działa. Sam uścisk dłoni nie dowodzi ścieżki, a ping do punktu końcowego nie dowodzi tunelu. Gdy operator podaje nazwę hosta, zachowaj obsługiwaną nazwę i jej kontrole tożsamości, zamiast zastępować ją adresem numerycznym znalezionym gdzie indziej.

Zapisz dokładne pole, użyta wartość i odpowiedź klienta w notatce o zmianie. Inaczej następna osoba edytująca profil powtórzy eksperyment z nawiasami, a odpowiedź już jest w Twoim zgłoszeniu.