VPN арқылы жол MTU-ын анықтау: өлшем және ICMP алшақтығы

Туннель өзінің қол алысуын аяқтайды, шағын сұраныстар қайтады, алғашқы үлкен тасымалдау тоқтайды. Бұл үлгі өткізу қабілетіне қарағанда жол MTU-ына әлдеқайда ерте меңзейді. Маршруттағы әрбір буын пакет өлшемін шектейді, ал инкапсуляция сол рұқсаттың бір бөлігін сыртқы тақырыптарға жұмсайды, сондықтан ішкі пакет қарапайым жол көрсеткеннен кіші болуы керек. Ақау үнсіз, және бұл оны диагностикалауды қымбат етеді.

Жол MTU-ы шын мәнінде нені өлшейді

Жол MTU-ы екі хост арасындағы маршруттағы ең кіші буын MTU-ы, жергілікті интерфейсте басылған MTU емес. Жергілікті мән — бағалау басталатын нүкте, ал жол оның қайда аяқталуын шешеді. Сондықтан бірдей туннель бір қатынау желісінде жұмыс істеп, екіншісінде тоқтауы мүмкін: маршрут өзгерді, конфигурация емес. Бір рет өлшеп, барлық жерде болжау — бұл мәселені тірі ұстайтын қате.

Туннель үшін маңызды сан — ішкі MTU, ол сыртқы жолдың рұқсатынан инкапсуляция жұмсайтынын шегергеннен қалады. WireGuard сыртқы IP тақырыбын және UDP тақырыбын қосады; басқа транспорттар өздерін қосады. Ішкі өлшемді тым жоғары қойсаңыз, толық өлшемді әрбір пакет ешқашан болмайтын фрагментацияны қажет етеді.

Туннель пайдаланылатын пакетті неге кішірейтеді

Егер туннель интерфейсі физикалық буынның MTU-ын сақтаса, әрбір үлкен пакет төмендегі біреудің оны фрагменттеуге дайын болуына тәуелді. IPv4 мұны қағида бойынша рұқсат етеді, бірақ фрагменттемеуге бұйырылған маршрутизатор оның орнына қате қайтарады. IPv6 маршрутизаторлары транзитте мүлдем фрагменттемейді, сондықтан бірдей параметр мекенжай тобына қарай басқаша әрекет етеді. Қалай болғанда да жіберуші бірдеңе қайта хабарламайынша ештеңе білмейді.

Практикалық салдар — қол алысуға сыйып, пайдалы жүктемеге сыймайтын өлшем. TLS ClientHello немесе DNS сұранысы кішірейген жолдан тиіспестен өтуге жеткілікті кіші, ал жаппай тасымалдау олай емес. Сондықтан симптомдар нақты хосттардың емес, нақты операциялардың айналасында жинақталады.

Анықтау тек кері байланыс келгенде жұмыс істейді

IPv4 анықтауы don't-fragment битіне сүйенеді: пакетті әрі жібере алмайтын маршрутизатор келесі секірістің MTU-ымен ICMP fragmentation-needed қайтарады, ал жіберуші өз бағасын төмендетеді. IPv6 оның орнына Packet Too Big хабарламаларын қолданады, өйткені маршрутизаторлар транзитте фрагменттемейді. Екі механизм де хабарламаның жіберушіге қайту жолын табатынын болжайды: туннель арқылы және қайту жолындағы кез келген брандмауэрдің артынан өтіп. Бұл болжам сәтсіз болса, жіберуші жол көтере алмайтын өлшемді қайта-қайта көреді.

echo request пен echo reply-ге рұқсат беретін брандмауэр сол қате түрлеріне рұқсат берген болуы міндетті емес. ICMP — бір отбасы, және мұнда маңызды мүшелер — қателер, эхо жұбы емес. Туннельдің екі ұшындағы және олардың арасындағы жолдағы басқару трафигінің саясатын тексеріңіз, әрі барлық жерде әрбір ICMP түріне рұқсат берудің орнына платформаның қолдайтын нұсқаулығын ұстаныңыз.

Сол сүзгілеу туннельдің ішінде де болуы мүмкін. Егер ішкі жол қатені тастап, сыртқы жол оны тасыса, жіберуші инкапсуляцияланған трафик шын мәнінде ешқашан көрмейтін шекке бейімделуі мүмкін.

Санды болжаудың орнына жолды сынап көріңіз

Межелі орынды, қатынау желісін және туннельді қозғалтпай, тек пакет өлшемін өзгертіңіз. MTU нұсқасымен сәтсіз аяқталатын don't-fragment сынағы сізге келесі секірістің шегін береді; қандай да бір өлшем өткенше қайталаңыз және өлшемді де, мекенжай тобын да жазып алыңыз.

ping -M do -s 1400 10.60.20.10
ping -M do -s 1300 10.60.20.10
ping -6 -M do -s 1300 2001:db8::10

Сыйған ping нақты қолданбаның толық өлшемді сегменттері сыйатынын дәлелдемейді, сондықтан сынақты шын мәнінде сәтсіз болған тасымалдаумен қайталаңыз. Ең үлкен жұмыс істеген сынақты конфигурациялаған туннель MTU-ымен салыстырыңыз және екі санды жазбаларыңызда бөлек ұстаңыз. Егер олар шамамен бір тақырыпқа айырмашылық жасаса, сіз ақауды емес, инкапсуляция қосымшасын таптыңыз.

RFC 4821-де сипатталған PLPMTUD жоғары қарай сынайды және жеткізілген қателерге сенудің орнына транспорттық растауларды пайдаланады. Ол ICMP-ны сүзетін жолдарда көмектеседі, бірақ қолдау стекке және қолданбаға қарай өзгереді. TCP ағыны өздігінен қалпына келуі мүмкін, ал тұрақты датаграмма өлшемі бар UDP қолданбасы сәтсіздікке ұшырай береді.

Мәнді таңдап, дәлелін жазып алыңыз

Туннель MTU-ын төмендету — бұл да диагностика, әрі заңды түзету, жолды білгеннен кейін. Ол қай жол мен қай кері байланыс механизмі қатысқанын білудің орнын баспайды, өйткені ұялы буынға реттелген мән талшықты қосылымда артық кіші болады. Таңдалған өлшемді, оны негіздеген сынақты және кері қайтару қадамын жазыңыз.

IPv4 механизмі RFC 1191-де, ал IPv6 пакеттеу нұсқаулығы RFC 8201-де сипатталған; екеуін де атау келесі инженерге болжамды қайта шығарудан сақтайды. Егер тасымалдау таңдаған өлшемде әлі де тоқтаса, санды төмендетуді доғарып, келесі қабатқа қараңыз. Әрбір өлшемде сәтсіз болатын жол MTU мәселесі емес.