DS-Lite blokuje hosting przychodzący IPv4, a nie wychodzący VPN

Stan tłumaczenia podąża za stroną, która rozpoczyna połączenie. Prześledź żądanie wychodzące przez B4 i AFTR, a potem zobacz, dlaczego hosting zawodzi.

DS-Lite to sposób na danie klientowi łączności IPv4 przez sieć dostępową, która przenosi tylko IPv6. Router domowy nie ma własnego dedykowanego publicznego adresu IPv4, i ten jeden fakt przekonuje ludzi, że VPN IPv4 nie może działać z takiego połączenia. W kierunku wychodzącym zwykle działa dobrze. Połączenie jest tłumaczone przez dostawcę, a drugi koniec widzi zwykłego klienta IPv4. Psuje się kierunek przeciwny: hosting czegoś, co oczekuje nieproszonego przychodzącego IPv4. Różnica polega na tym, która strona zaczyna rozmowę.

Która strona rozpoczyna połączenie

Klient, który inicjuje połączenie, tworzy stan tłumaczenia na bieżąco. Tłumacz dostawcy widzi pierwszy pakiet, przydziela mapowanie i przekazuje go dalej. Ruch powrotny pasuje do tego mapowania, ponieważ mapowanie już istnieje.

Serwer, który czeka na połączenia, nie ma takiego stanu do utworzenia. Ktoś z zewnątrz musi dotrzeć do adresu i portu, na których mapowanie dostawca się nie zgodził, a to zupełnie inne żądanie.

Prześledź żądanie wychodzące

Architektura w RFC 6333 nazywa oba końce. Elementem po stronie klienta jest B4, który enkapsuluje IPv4 w IPv6. Elementem po stronie dostawcy jest AFTR, który wykonuje tłumaczenie adresu i przekazuje pakiet jako IPv4.

Client's IPv4 VPN packet
  → Customer B4
  → IPv4 carried over the provider's IPv6 network
  → AFTR address translation
  → IPv4 VPN server

Serwer VPN otrzymuje normalne połączenie IPv4 z przetłumaczonego adresu dostawcy. Nie potrzebuje trybu DS-Lite, specjalnego portu ani świadomości, że sieć dostępowa klienta to tylko IPv6. To jest ta część, którą ludzie pomijają: drugi koniec nie może tego rozpoznać.

Konfiguracja samego klienta jest równie zwyczajna. Potrzebuje działającej ścieżki IPv4 do serwera, którą zapewniają B4 i AFTR, oraz tego, by nazwa hosta serwera rozwiązywała się na adres IPv4.

Dlaczego hosting przychodzący to ten przypadek, który zawodzi

Uruchamianie serwera VPN IPv4 w domu to projekt, który zderza się ze współdzielonym adresowaniem dostawcy. Tłumacz dostawcy posiada publiczny adres i tablicę mapowań, i nie ma powodu tworzyć trwałego mapowania przychodzącego dla jednego abonenta.

Reguła przekierowania portu na routerze domowym nie może skonfigurować AFTR. Reguła jest realna i poprawna na urządzeniu lokalnym i niczego nie zmienia wyżej, dlatego objaw wygląda jak problem z zaporą ogniową, który nie znika.

Tu także tłumaczenie na poziomie operatora różni się od jednego publicznego adresu: nawet poprawne przekierowanie lokalne może trafić na adres współdzielony przez wielu abonentów.

Zdiagnozuj, zanim zmienisz plan dostępu

Najpierw potwierdź tryb, który został uruchomiony. Natywny podwójny stos, DS-Lite i sieć tylko IPv6 korzystająca z innego mechanizmu tłumaczenia to trzy różne układy, a nazwy marketingowe dostawcy nie zawsze odpowiadają technicznym.

Potem ustal cztery obserwacje dla awarii wychodzącej. Czy klient rozwiązuje nazwę hosta VPN na cel IPv4? Czy działa zwykła łączność IPv4, a nie żądanie przeglądarki, które mogło po cichu użyć IPv6? Jakiego transportu i portu próbuje klient i czy logi punktu końcowego w ogóle widzą tę próbę? Czy awaria występuje podczas początkowej wymiany, po okresie bezczynności, czy tylko przy większych transferach?

Te cztery odpowiedzi wskazują na filtrowanie, wygaśnięcie stanu tłumaczenia, zły punkt końcowy lub obsługę rozmiaru pakietu. Żadnej z nich nie ustala się, widząc DS-Lite na stronie konta.

Czytaj zmiany dostawcy uważnie

Zmiana konta może zbiec się z działającym połączeniem, a jednocześnie zmienić kilka właściwości naraz. Zapisz, która właściwość się zmieniła, bo nowa nazwa pakietu nie jest wyjaśnieniem technicznym.

Polecenie włączenia podwójnego stosu jest niejednoznaczne, dopóki ktoś nie potwierdzi, co dostawca faktycznie uruchamia. Traktowanie go jako uniwersalnego wymogu dla klientów VPN IPv4 zamienia przypuszczenie w politykę.

Jeśli prawdziwym wymogiem jest hosting przychodzący IPv4, omów z dostawcą obsługiwany układ przychodzący, adresowanie natywne lub inny projekt dostępu. Jeśli wymogiem jest laptop docierający do zdalnego serwera, zapytaj zamiast tego o dokładnie ten ruch wychodzący. Kolejność pracy: nazwij kierunek, potwierdź uruchomiony tryb, przetestuj zwykły IPv4 i jeden transport, a plan dostępu zmień tylko wtedy, gdy kierunek naprawdę tego wymaga.

Powiązane artykuły