Мрежа само с 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 адрес. Поискайте едно от двете.