VPN са двоструким стеком: породицу адреса бира клијент, не ви

Тунел је подигнут, IPv4 странице се учитавају, а једно име хоста истиче. Непосредан закључак је да је VPN покварен или су подаци за пријаву погрешни, а обично није тачно ни једно. Име је вратило и IPv4 и IPv6 адресу, апликација је изабрала једну, а само је један од тих кандидата имао радни пут. Одлуку о избору донео је клијент; тунел једноставно није покривао оно што је изабрао.

Избор није обећање покривености

Подразумевани избор адресе, описан у RFC 6724, одређује који пар извора и одредишта хост преферира кад их је доступно неколико. Happy Eyeballs додаје поврх тога стратегију повезивања: започиње покушаје на обе породице и задржава онај који први одговори, па корисник не чека да покварена породица истекне.

Ниједан механизам не ствара руту. Ако ваш тунел носи само IPv4, AAAA кандидат је и даље легитиман циљ који клијент може покушати, а неуспех се појављује као споро учитавање, а не као грешка, јер је прегледач пао на резерву. Корисник пријављује спору страницу, а не покварену, и тикет за подршку наслеђује ту неодређеност. Репродукујте то с фиксном породицом и извештај постаје конкретан.

Због тог повратка симптом је недоследан међу апликацијама. Прегледач скрива кашњење; клијент командне линије с фиксном породицом одмах вам покаже прави неуспех.

Пронађите породицу коју је захтев заиста користио

Почните с именом, не с тунелом. Проверите оба типа записа и забележите шта се вратило:

dig +short A example.com
dig +short AAAA example.com
curl -4 -sS -o /dev/null -w '%{http_code}\n' https://example.com
curl -6 -sS -o /dev/null -w '%{http_code}\n' https://example.com

Ако v4 захтев успе, а v6 захтев не успе, репродуковали сте проблем у облику који можете отклањати. Ако оба успеју из љуске, а прегледач и даље не успева, погледајте властити разрешивач апликације или кеширани одговор пре него што дирате тунел.

Држите породицу и одредиште у својим белешкама. Тикет који каже да се страница не учитава преко VPN-а не може проверити нико, док тикет који каже да AAAA не успева, а A ради, указује на конкретну руту.

Проверите руту за ту породицу

За породицу која не успева, питајте кернел који би пут користио и упоредите га с конфигурисаним адресама тунела. На Linux-у ip -6 route get за одредиште приказује интерфејс и извор који би били изабрани.

Затим проверите сам тунел. WireGuard peer-ови носе листу дозвољених IP адреса, а унос за 0.0.0.0/0 не говори ништа о IPv6. Ако листа peer-а нема IPv6 префикс, клијент нема разлога да шаље AAAA саобраћај у тунел, а пакет излази кроз оно што би хост иначе урадио.

Правила firewall-а и NAT политика заслужују исту проверу по породици. Правило написано за IPv4 не покрива IPv6 ни на једној платформи, и то је најчешћи разлог зашто једна породица ради, а друга не.

Не искључујте IPv6 да бисте поједноставили снимак екрана

Искључивање IPv6 на нивоу система учиниће да симптом нестане и оставити вас без дијагнозе. Оно такође квари свако одредиште које је само IPv6, и скрива исту грешку за следећу апликацију. Ако нека машина заиста не треба да користи IPv6, то је намерна политика с власником и тестом. Искључивање током инцидента није ни једно ни друго.

Одлучите шта клијент треба да ради с породицом и конфигуришите то експлицитно: проведите је кроз тунел или је блокирајте на подржан начин тако да избор никада не нуди недоступног кандидата. Оба су легитимна дизајна. Глобално искључивање није ни једно од тога, јер уопште није дизајн.

Шта ставити у тикет

Забележите четири ствари: име хоста, породицу која није успела, руту коју је кернел изабрао и резултат захтева специфичног за породицу. Тај скуп је довољан да неко други репродукује неуспех без нагађања који од два пута сте мислили.

Правила избора адресе RFC 6724 објашњавају зашто је клијент преферирао кандидата којег јесте, а RFC 8305 објашњава тркачко понашање које је сакрило кашњење. Ниједно од њих неће рутирати пакет уместо вас, а то је део који тунел мора да одради.