Қос стекті 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 кідірісті жасырған жарыс мінезін түсіндіреді. Олардың ешқайсысы сіз үшін пакетті маршруттамайды, және дәл осы бөлікті туннель орындауы керек.