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 носят списък с разрешени IP адреси, а запис за 0.0.0.0/0 не казва нищо за IPv6. Ако списъкът на пиъра няма IPv6 префикс, клиентът няма причина да изпраща AAAA трафик в тунела и пакетът излиза по това, което хостът иначе би направил.

Правилата на защитната стена и политиката на NAT заслужават същата проверка за всяко семейство. Правило, написано за IPv4, не покрива IPv6 на нито една платформа, и това е най-честата причина едно семейство да работи, а другото не.

Не изключвайте IPv6, за да опростите екранната снимка

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

Решете какво да прави клиентът със семейството и го конфигурирайте изрично: прекарайте го през тунела или го блокирайте по поддържан начин, така че изборът никога да не предлага недостижим кандидат. И двете са законни решения. Глобалното изключване не е нито едно от тях, защото изобщо не е решение.

Какво да впишете в тикета

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

Правилата за избор на адрес по RFC 6724 обясняват защо клиентът е предпочел кандидата, който е предпочел, а RFC 8305 обяснява надпреварващото се поведение, което скри забавянето. Нито едно от тях няма да маршрутизира пакет вместо вас, а точно това трябва да направи тунелът.

Подобни статии