VPN MTU аңыздары: пакеттеріңіз неге кішірееді және орын қайда кетеді
Инкапсуляция мен PPPoE пакет орнын жейді, бірақ төмен MTU — диагноз емес. Санды өзгерту алдында ішкі және сыртқы өлшемдерді бөліңіз.
Біреу сізге VPN "MTU салдарынан пакет жоғалтып жатыр" дейді, сіз туннельді 1400-ге қоясыз, және тасымалдау қайта жұмыс істейді. Бұл нәтиже диагноз сияқты сезіледі. Әдетте бұл арифметикалық кездейсоқтық: сіз ешқашан анықтамаған шектен төмен сыю үшін жеткілікті кішкентай санды таңдадыңыз, және келесі желіде басқа бюджетпен сол шекке қайта кездесесіз.
Мұның көбін екі аңыз тудырады. Біріншісі — туннель интерфейсінің MTU-ы жолдың MTU-ы. Екіншісі — инкапсуляция "бір тақырыпша" тұрады, ал PPPoE санауға тұрарлық ештеңе тұрмайды. Екеуі де таңдаған саныңыз ерікті болып көрінетіндей, ал шын мәнінде ол анықталған.
Бірінші аңыз: туннельдің MTU-ы жолдың MTU-ы
Туннель интерфейсінде қоятын мән ең үлкен ішкі пакет туралы жергілікті уәде, оны іске асыру төменге береді. Жолдың нақты сыйымдылығы сіз бен алыс шет арасындағы әрбір буынның қасиеті, және ол маршрут өзгергенде, ұялы байланыс тапсырылғанда немесе трафик басқа peering алғанда өзгеруі мүмкін. Орнатылған 1500 сіздің хостыңыз не құрастыратынын айтады, желі не таситынын емес.
Жол MTU-ын анықтау осы екеуін үйлестіру үшін бар және кері байланысқа тәуелді. IPv4-те толық өлшемді пакетті жібере алмайтын маршрутизатор ICMP "fragmentation needed" хабарламасын жіберуі керек, ал жіберуші өз бағасын төмендетеді. IPv6-да баламасы Packet Too Big хабарламасы, ал маршрутизаторлар транзитте мүлдем фрагменттемейді. Бұл кері байланыс сүзілсе, жіберуші жол таси алмайтын пакеттерді шығара береді, және ешнәрсе оған себебін айтпайды.
Екінші аңыз: инкапсуляция бір тақырыпша тұрады
Сыртқы қабаттарды адал санаңыз. Сыртқы IP тақырыпшасы IPv4-те 20 байт немесе IPv6-да 40 байт. NAT-тан өту үшін UDP инкапсуляциясы 8 қосады. Туннель протоколы өз тақырыпшасын, инициализация векторын немесе nonce, шифрдің блок немесе туралау шекарасына дейінгі толтыруды, аяқтаушы бөлікті және тұтастықты тексеру мәнін қосады. Протокол мен шифрге байланысты қосынды ішкі пакет басталмай тұрып-ақ ондаған байтқа жетеді.
Содан кейін ішкі пакеттің өз тақырыпшалары үшін қайта шегеріңіз. Туннель ішіндегі TCP сегменті өзінің 20 байттық IP тақырыпшасы мен 20 байттық TCP тақырыпшасын тасиды, ал TCP-ның MSS-і MTU-дан шығады, туннельдің номиналды пайдалы жүктемесінен емес. Сондықтан ping кішірек жүктемемен сәтті болуы мүмкін, ал файл тасымалдау тұрып қалады: құралдар әртүрлі нәрселерді тексереді және олардың тек біреуі толық өлшемді TCP сегментін қолданады.
ip link show tun0
ping -M do -s 1472 192.0.2.10
ping -M do -s 1400 192.0.2.10
Бірінші пәрмен орнатылған туннель MTU-ын хабарлайды. Екі сынақ 1472 байттық жүктеме жібереді, ол IPv4 және ICMP тақырыпшаларының 28 байтымен 1500 байттық пакет, содан кейін кішірек. Егер үлкен сынақ мүлдем сәтсіз болып, кішісі сәтті болса, сізде өлшемге тәуелді ақау бар, жалпы маршруттау мәселесі емес.
Үшінші аңыз: PPPoE әлі де таза 1500 береді
Кәдімгі PPPoE қатынау буыны 1500 байттық IP пакетін тасымайды. PPPoE тақырыпшасы мен PPP протокол өрісі Ethernet кадрының ішінде 8 байт алады, бұл IP пакетіне 1492 қалдырады. Бұл RFC 2516-да сипатталған дәстүрлі шек. Егер осындай буын үстінде VPN жүргізсеңіз, туннельдің қосымша шығыны 1500-ден емес, сол 1492-ден шығады.
RFC 4638 үлкенірек PPP жүктемесі туралы келісу жолын анықтайды, егер қатынау концентраторы да, клиент жабдығы да қолдаса, сондықтан "бұл қосылым PPPoE қолданады" деген сөз өзі қандай да бір нақты санды дәлелдемейді. Жергілікті параметр аралық құрылғыны ол үшін ешқашан конфигурацияланбаған пакетті қабылдауға мәжбүрлей алмайды, сондықтан пайдалы сұрақ — белгі не дейтіні емес, буын нақты нені келісті.
Неге ақау таңдамалы көрінеді
Кіші сұраныстардың сәтті болуы мен үлкен тасымалдаулардың тұрып қалуы жол MTU-ының қара құрдымының классикалық белгісі. Қол алысу, DNS сұранысы және API шақыруы бәрі сыяды; жаппай тасымалдау бір буында өлетін толық өлшемді сегменттерді тудырады, ал мәселені хабарлауы тиіс ICMP хабарламасы ешқашан жетпейді. Қосылым дұрыс көрінеді, жүктеу ілініп қалады, бұл адамдарды жолға емес серверге қарауға жібереді.
Екінші, оған қатысты қате — үш санды шатастыру: интерфейс MTU-ы, TCP-ның MSS-і және протоколдың өз фрагментация немесе толтыру параметрі. Маршрутизатордағы MSS қысуы жарияланған MSS-ті қайта жазады, сонда жіберуші кішірек сегменттер құрастырады; ол туннель MTU-ын өзгертпейді және UDP трафигіне көмектеспейді. Үшеуіне бірдей сан беру, өйткені олар байланысты болып көрінеді, — жақсы ниетті өзгерістің жұмыс істеп тұрған конфигурацияны бұзу тәсілі.
Нені және қандай ретпен өзгерту керек
Дәлелден бастаңыз. Жоғарыдағы сынақтармен ақаудың өлшемге тәуелді екенін растаңыз, содан кейін өтетін ең кіші өлшемді және сәтсіз болатын ең үлкенді табыңыз. Туннельді кінәламас бұрын қатынау буынының нақты MTU-ын тексеріңіз; PPPoE буыны VPN оған тимей тұрып бюджетті шектейді. Өзгерісті кері қайтару үшін бастапқы мәндерді жазып алыңыз.
Содан кейін клиент құжаттайтын ең кішкентай түзетуді қолданыңыз. Көптеген клиенттер туннель MTU-ын және MSS түзету опциясын ұсынады, ал MSS опциясы TCP үшін жиі жақсы тұтқа, өйткені әр пакетті кішірейтпей жіберушіге жетеді. Сол мақсатты және сол тасымалдауды қайта тексеріңіз және тоқтаған сандарыңызды жазыңыз. Бір қатынау желісінде жұмыс істейтін туннель мәні әмбебап тұрақты емес, келесі орынның өз бюджеті болады.