IPv6 пакеті тым үлкен: үлкен VPN тасымалдары неге тоқтайды
Шағын жауаптар келеді, ал үлкен тасымалдар сол туннель арқылы ілініп қалады. Жіберуші жол өлшемін ешқашан білмеген, және сүзілген басқару хабарламасы мұны түсіндіреді.
Ping жұмыс істейді, браузер шағын бетті жүктейді, ал файл тасымалы тоқтайды — бәрі де бір туннель арқылы IPv6-да. Мұндай үлгі әдетте туннель баяу дегенді емес, жіберуші жолдың нақты өлшемін ешқашан білмегенін білдіреді. IPv6 маршрутизаторлар мәселені Packet Too Big хабарламасымен хабарлайды деп күтеді, ал инкапсуляция пакет сыртқы желіге жетпей тұрып қосымша шығын қосады. Егер бұл хабарлама сүзілсе, жіберуші өте алмайтын өлшемді қайталай береді.
Шағын сұраулар, үлкен тоқтаулар
Туннель әр пакетті тағы бір тақырыпшаға орайды, сондықтан ішіндегі пайдаланылатын өлшем сырттағы өлшемнен кіші. Инкапсуляцияға дейін физикалық буынға өлшенген пакет кейін тым үлкен болады. IPv4 маршрутизаторлары жолда бөлшектей алады, ал IPv6 маршрутизаторлары мұны жіберушінің орнына жасамайды, сондықтан жіберуші өзі бейімделуі керек. Және бұл бейімделу кері байланысты алуға толық тәуелді.
Бір жоғалған хабарлама классикалық белгіні тудыруға жеткілікті: қол алысулар мен шағын жауаптар сәтті өтеді, ал каталог тізімі немесе жүктеу әр жолы сол жерде тоқтайды. Пайдаланушылар мұны VPN баяу деп сипаттайды, ал журналдар аутентификацияда ештеңе дұрыс емес екенін көрсетпейді. Екі байқау да дәл және ешқайсысы ақаудың орнын таппайды.
Packet Too Big — кері байланыс, трафик емес
ICMPv6 Packet Too Big хабарламасы келесі секіріс қабылдай алатын өлшемді тасымалдайды, ал жіберуші оны өз бағасын төмендету үшін пайдаланады. Оны сүзу жол белгісін алып тастап, кейін жүргізушілерді кінәлаумен пара-пар. Барлық ICMPv6-ны тастайтын ереже қатал көрінеді, бірақ оған мұқтаж әр буында жолды табуды бұзады. Хабарлама жол туралы басқару ақпараты, қолданбаның пайдалы жүктемесі емес.
Таңдамалы сүзу әлі де орынды. Эхо сұраулары мен көршілерді табу қате хабарламаларынан өзге рөл атқарады, ал саясат оларға басқаша қарауы мүмкін. Бүкіл протоколды қабылдаудың немесе жоққа шығарудың орнына платформаның құжатталған сүзу нұсқаулығын орындаңыз, өйткені RFC 8201 бұл кері байланыстың табуды қалай басқаратынын анықтайды.
Екі мекенжай тобын бөлек тексеріңіз
IPv6-ны жеке тексеріңіз, өйткені сәтті IPv4 тасымалы IPv6 жолы туралы ештеңені дәлелдемейді. Содан кейін үлкен тасымал тоқтап тұрғанда басқару хабарламаларын түсіріңіз. Екі жазба бірге кері байланыстың шығып жатқанын көрсетеді немесе оның ешқашан жетпегенін дәлелдейді.
ping -6 -M do -s 1400 host.internal
ip -6 route get 2001:db8:2::10
sudo tcpdump -ni any 'icmp6 and ip6[40] == 2'
Зонд do-not-fragment битін орнатып пакет жібереді және ол сәтсіз аяқталатын өлшемді хабарлайды — бұл туннель сыйдыруы тиіс сан. Маршрут сұрауы межеліні тасымалдайтын интерфейсті атайды, сондықтан қай буынның MTU-ы қолданылатынын білесіз. Түсірілім ICMPv6 2-түрін, яғни Packet Too Big хабарламасын сүзеді және оның осы хостқа жететінін көрсетеді. Хабарлама түсірілімде көрініп, тасымал әлі тоқтап тұрса, жіберуші оны елемейді, бұл тексеруді желіден стекке ауыстырады.
Туннель өлшемін тек дәлелдерден кейін өзгертіңіз
Туннель MTU-ын төмендету сүзілген хабарламаны жасырып, белгіні жоюы мүмкін, бірақ әр пакетке қосымша шығынмен. Бұл шешім емес, айналып өту, және түсірілімнен кейін жүруі керек, оны алмастырмауы керек. Ерікті төмен мән де көрінетін ештеңені бұзбайды, сондықтан ол конфигурацияларда жылдар бойы өмір сүреді. Оны әдейі өзгертіңіз, мәнді жазып алыңыз және қай өлшеу оны ақтағанын белгілеңіз.
Қақпаны өзіңіз басқарсаңыз, өртқабырғаны өшірудің орнына хабарламаны тастайтын ережені тексеріңіз. Бір түзетілген ереже саясаттағы ерекшеліктен тар және кейін оны қорғау әлдеқайда оңай. Дәл осы логика тайм-ауттарға да қатысты: әр тоқтау өлшем мәселесі емес, ал екеуін ажырататын нәрсе — түсірілім.