Пінг праз VPN працуе, а сайт завісае: праверце памер

Адказы рэха прыходзяць, аддалены працоўны стол працуе, а браўзер стаіць на пустой старонцы, пакуль не здасца. Гэтаму ўзору адпавядаюць два тлумачэнні, і яны не варыянты адной праблемы: палітыка, якая ніколі не дазваляла сэрвіс, або пакеты, якія перастаюць умяшчацца, калі перадача расце. Адказ рэха не выключае ні аднаго з іх.

Ідзіце ад самага малога пытання да самага вялікага і запісвайце, што кожны крок насамрэч даказаў.

Адказ рэха адказвае на значна меншае пытанне

Адказ рэха кажа, што IP-стэк прызначэння адказаў на запыт ICMP ад вашай крыніцы. Ён нічога не кажа пра тое, ці існуе TCP-слухач на патрэбным вам порце, ці дазваляе палітыка гэты порт, ці фільтруе хост прызначэння трафік незалежна ад шлюза. Шлюз, які дазваляе адзін сэрвіс, можа скінуць іншы, пакуль абодва адрасы адказваюць на ping. Чытайце адказ як адзін факт пра адзін пакет і адзін кірунак.

Пацвердзіце прызначэнне і порт сэрвісу, перш чым тлумачыць што-небудзь яшчэ. Адрас, які вы правяралі, і адрас, які выкарыстоўвае праграма, часам розныя запісы, і імя, якое разрозніваецца ў два адрасы, робіць гэта верагодным.

Высветліце, ці пачалося злучэнне

Злучэнне, адразу адхіленае, — гэта адказ слухача або палітыкі: нешта адказала і сказала не. Злучэнне, якое адкрываецца, а затым затынаецца, калі даныя пачынаюць рухацца, паказвае на памер. Злучэнне, якое ўвогуле не завяршае рукацісканне, звычайна звязана з палітыкай або маршрутызацыяй і выглядае як тайм-аўт, а не як адмова.

curl -v --max-time 10 https://internal.example/ -o /dev/null
ss -tn state established '( dport = :443 )'

Запішыце, якое з гэтых трох вы назіралі, перш чым кранаць налады MTU. Змена памеру тунеля, каб выправіць адхіленае злучэнне, марнуе змену і на нейкі час хавае сапраўдную прычыну.

Мерка памеру з названым лікам

Калі затынка з'яўляецца пад нагрузкай, праверце адзін памер пакета з усталяваным бітам забароны фрагментацыі і назвіце арыфметыку, каб вынік нешта значыў. У Linux з iputils карысная нагрузка ў 1392 байты плюс 8-байтавы загаловак ICMP і 20-байтавы загаловак IPv4 даюць унутраны пакет роўна ў 1420 байтаў. Назавіце гэтую арыфметыку ў заяўцы, бо голы ping, які даходзіць да шлюза, нічога не даказвае пра праграму.

ping -4 -M do -s 1392 10.44.0.10
ping -4 -M do -s 1372 10.44.0.10

Абодва замеры — гэта пункты вымярэння, а не рэкамендацыі памеру тунеля. Калі ICMP фільтруецца дзе-небудзь на шляху, тайм-аўт нічога не кажа пра памер, бо фільтрацыя і занадта вялікі пакет выглядаюць для кліента аднолькава. Поспех таксама нічога не кажа пра зваротны кірунак або іншае прызначэнне.

Улічыце знешні шлях

Інкапсуляцыя дадае свае загалоўкі, таму пакет на провадзе большы за пакет, які вы вымералі ўнутры тунеля. Менавіта розніца паміж імі робіць магчымымі адначасова працоўны малы запыт і збойны вялікі.

Выяўленне MTU шляху ў IPv4 залежыць ад зваротнай сувязі пра пакеты, якія нельга перадаць без фрагментацыі, а IPv6 выкарыстоўвае паведамленні Packet Too Big. Спецыфікацыя IPv4 апісвае гэты механізм. Фільтраванне зваротнай сувязі ламае здольнасць адпраўніка вучыцца, і ён працягвае паўторна адпраўляць пакеты, якія ніколі не змесцяцца. Менавіта таму працоўны малы запыт і збойны вялікі так камфортна суіснуюць.

Змяніце адзін лік і пераправерце праграму

Зменшыце MTU тунеля або абмяжуйце максімальны памер сегмента для TCP, затым паўтарыце першапачатковы тэст праграмы, а не замер. Замер, які ўдаецца пасля змены, і праграма, якая ўсё яшчэ завісае, — гэта іншая праблема падобнай формы, і толькі тэст праграмы адрознівае іх.

Трымайце арыфметыку ў запісе пра змену: вымераны памер, накладныя выдаткі, якія вы меркавалі, і значэнне, якое вы ўсталявалі. Той, хто будзе гэта пераглядаць, зможа праверыць здагадку замест таго, каб выводзіць яе зноў са здымка экрана ping.

Калі праграма працуе пры любым памеры, які вы паспрабавалі, спыніцеся правіць лікі і паглядзіце на палітыку, якая аддзяляе працоўны сэрвіс ад збойнага.