Мрежа само со IPv6 го крши VPN-от пред да почне тунелот

Лаптопот се поврзува со конференциски Wi-Fi што дели само IPv6, VPN клиентот се врти и паѓа, а истиот профил работел во хотел еден час порано. Во акредитивите ништо не се сменило. Она што се сменило е дека клиентот сега мора да стигне до дестинација IPv4 преку мрежа што носи само IPv6, и не секој клиент знае како да го направи тоа.

Поминете ги истите пет чекори што ги поминуваат пакетите.

Чекор 1: набљудувајте го барањето име

Ако профилот користи име на домаќин, првото прашање е што враќа резолверот. dig AAAA vpn.example.com во мрежа само со IPv6 враќа вистински AAAA запис, синтетизиран од DNS64 или ништо. Синтетизираниот одговор ја кодира дестинацијата IPv4 во префикс за превод, и само тогаш клиент без дестинација IPv6 може да ја достигне. Профил со тврдо впишана адреса IPv4 никогаш не стигнува дотука, бидејќи нема име за синтетизирање.

Таа единствена разлика ги објаснува повеќето извештаи „работи таму, паѓа тука“, а за да се види е потребна една наредба.

Чекор 2: видете кое семејство го повикал клиентот

Набљудувајте го сокетот, а не лентата за напредок. Клиентот што отвора сокет IPv4 кон адреса IPv4 на врска само со IPv6 нема каде да го испрати, а дефектот се појавува како истекување на време, а не како грешка во името. ss -tanp додека клиентот се поврзува ги покажува далечната адреса и семејството што го проба. Споредете го тоа со ip -6 route за да потврдите дека стандардната рута е вистински следен скок IPv6.

Семејството адреси во табелата со сокети е фактот. Лентата за напредок е резиме што го напишал некој друг.

Чекор 3: одвојте го преводот од тунелот

NAT64 и DNS64 се начинот на кој пристапната мрежа стигнува до дестинации IPv4, и тие не прават ништо за тунелот откако ќе се подигне. Тунел воспоставен преку преведен пат сепак преговара за своето внатрешно адресирање, а внатрешната покриеност IPv4 или IPv6 е одделно прашање на политика. Ако клиентот се поврзе и потоа не стигне до ништо, веќе сте го поминале преводот и сте во рутирањето, што е друга истрага со други докази.

Неуспехот на преводот изгледа како никогаш да не се поврзе. Неуспехот на внатрешната покриеност изгледа како да се поврзе и да не стигне до ништо.

Чекор 4: тестирајте го истиот профил во друга мрежа

Однесете го истиот профил, верзијата на клиентот и акредитивите во мрежа со двоен стек и повторете. Ако таму работи, а паѓа на патот само со IPv6, променливата е пристапната мрежа, а не профилот. Забележете ја верзијата на клиентот и состојбата на мрежата во тикетот, бидејќи конечното решение е ажурирање на клиентот или друга дестинација.

Извештај што вели дека VPN-от е скршен не може да се спроведе. Извештај што вели дека паѓа само при пристап само со IPv6 е извештај за грешка.

Чекор 5: поправете го патот, а не безбедносните поставки

Сите примамливи поправки ја влошуваат состојбата. Исклучувањето на IPv6 го отстранува единствениот пат што мрежата го нуди. Насочувањето на клиентот кон јавен резолвер ја крши синтезата на DNS64, бидејќи таа синтеза мора да доаѓа од резолверот зад преведувачот. Исклучувањето на проверката на сертификатот ви дава врска со нешто што не можете да го идентификувате. Ниту едно од тие не е поправка, а две од нив се безбедносни регресии што ќе го надживеат инцидентот.

Вистинските опции се клиент што го поддржува моделот на мрежен превод, или дестинација со достапна адреса IPv6. Побарајте една од нив.