Как да тествате IPv6 през VPN със собствен ресурс

Публичната страница за проверка на IP отговаря на един въпрос и обикновено не на този, който сте задали. Тя ви казва адреса на изхода, който страницата е видяла; не ви казва дали маршрутът IPv6 през тунела работи, дали хостът е предпочел IPv6 или се е върнал назад, нито дали изключено приложение е поело друг път. Оторизиран ресурс, който контролирате, отговаря на по-тесния въпрос както трябва, защото виждате двата края. Ръководството по-долу е за получаване на извод, който можете да защитите, а не за зелен резултат.

Стъпка 1: кажете кой път IPv6 тествате

Кажете го с едно изречение. Заявка към собствения адрес IPv6 на сървъра на тунела тества тунела; заявка към хост отвъд изхода тества изходящия IPv6 на изхода; заявка към частен адрес IPv6 тества вътрешен маршрут.

Това са три различни твърдения и една успешна заявка не може да подкрепи и трите. Изберете това, което има значение за решението пред вас, и го запишете, преди да стартирате каквото и да е. Ако притеснението е дали IPv6 изтича около тунела, въпросът е за избора на маршрут от хоста, а не за достижимостта на изхода. Ако притеснението е дали далечната страна може да достигне вътрешна услуга, изходът е без значение.

Стъпка 2: потвърдете, че хостът избира този маршрут

ip -6 route get 2001:db8:1::10 отпечатва маршрута, адреса на източника и интерфейса, който ядрото би използвало, и точно от този факт зависи останалата част от теста.

Съществуването на интерфейс не е същото като избирането му. Хостовете с двоен стек имат таблица за приоритет и /etc/gai.conf в Linux може да промени кое семейство печели за име, което се разрешава до двете.

Стъпка 3: използвайте законна дестинация и име

Ако тествате HTTPS, използвайте името на хоста, за което е издаден сертификатът, и оставете проверката включена; преминаването към буквален адрес, за да мине тестът, изключва точно проверката, която доказва, че сте достигнали предвидения хост. Диагностична услуга, която контролирате и която отговаря на известно име с валиден сертификат, е най-чистата цел. Тя ви дава и ред в журнала от страна на сървъра за съпоставяне, какъвто проверяващ от трета страна никога няма да ви даде.

Стартирайте заявката във форма, която показва използвания адрес: curl -6 -sS -o /dev/null -w '%{remote_ip} %{http_code}\n' https://test6.example.net/. -6 налага семейството и така разделяте „IPv6 не работи“ от „IPv6 не беше предпочетен“.

За чиста проверка на достижимост, където ICMPv6 е разрешен, ping -6 -c 3 2001:db8:1::10 е достатъчна. Тя доказва пътя и нищо над него.

Стъпка 4: съпоставете двата края

Когато имате достъп до двата края, стартирайте tcpdump -ni any ip6 and host 2001:db8:1::10 на клиента и еквивалента на ресурса, с времеви отпечатъци, и потвърдете, че същият поток се появява и на двете. Това превръща правдоподобния резултат в доказателство: гледната точка на клиента сама не може да различи отговор от ресурса от отговор от нещо по средата. Дръжте улавянето тясно до една дестинация, за да остане изходът четим и ничия несвързана сесия да не попадне във файла.

Повторете теста след повторно свързване, ако притеснението е дали политиката оцелява при рестарт. Състоянието на маршрута и защитната стена, приложено веднъж при свързване, може да се различава от състояние, което се прилага отново, и разликата се показва само при второто свързване.

Тествайте случая на отказ отделно, ако ви е нужен. Тунел, който блокира IPv6 при прекъсване, и такъв, който го пропуска, са различни конструкции и само една от тях може да бъде потвърдена с успешна заявка.

Стъпка 5: запишете какво тестът не е доказал

Петата стъпка е да запишете какво тестът не е доказал, и точно тази част се изпуска. Успешен тест на частна крайна точка не доказва публичен изход IPv6, не доказва поведението на DNS и не покрива приложения, които сте изключили от тунела. Всяко от тях има нужда от собствена дестинация и собствено наблюдение. Бележка, която казва, че IPv6 работи след една заявка към един хост, не е находка; това е догадка с времеви отпечатък.

Записът, който си струва да се пази, е кратък: дестинацията, името, адресът на източника, който хостът е избрал, наблюдаваният отдалечен адрес и времето. RFC 7359 обсъжда как да се тества, че съответен път IPv6 е наистина използваем, и това е стандартът, до който това ръководство се доближава с по-прости инструменти. Ако изводът се нуждае от публичен проверяващ, за да е верен, тестът не е бил достатъчно конкретен.