Тунель узняты, сайты 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 тлумачыць гонкавыя паводзіны, якія схавалі затрымку. Ні адзін з іх не пракладзе пакет за вас, а менавіта гэта тунель і павінен зрабіць.

Падобныя артыкулы