Чаму старонкі OpenConnect завісаюць, пакуль вы не паменшыце MTU тунеля

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

Аддзяліце праблему памеру ад праблемы палітыкі

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

Механізм — інкапсуляцыя. Кожны ўнутраны пакет атрымлівае загалоўкі тунеля, таму карысная нагрузка, якая змяшчаецца ў фізічным канале, становіцца знешнім пакетам, які ўжо не змяшчаецца, і ўсё, што нясе біт do-not-fragment, адкідаецца без адказу, які браўзер можа інтэрпрэтаваць.

Вымерайце столю DF-пробамі

Вымерайце столю замест здагадак. Дасылайце пробы, якія адмаўляюцца ад фрагментацыі, і зніжайце нагрузку крок за крокам, пакуль не вернецца адказ. Пачніце з такой каманды, як ping -M do -s 1472 host. Калі адказ скардзіцца, што патрэбна фрагментацыя, а DF усталяваны, значэнне ўсё яшчэ занадта вялікае. Паўтарыце на 1462, затым на 1452, і спыніцеся на першым памеры, які верне адказ. Запішыце лік разам з хастом, які вы правяралі, бо адказ належыць гэтаму шляху, а не пратаколу наогул.

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

Прымяніце значэнне да прылады тунеля

Прымяніце вынік да інтэрфейса, створанага кліентам, а не да адаптара Wi-Fi. На кліенце Linux гэта ip link set dev tun0 mtu 1300 , а затым ip link show tun0 , каб пацвердзіць, што значэнне ўжылося. Выкарыстоўвайце тое імя прылады, якое паведамляе кліент, бо яно залежыць ад рэалізацыі і ад таго, як пабудаваны тунель.

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

Спачатку выкарыстоўвайце ўласныя запыты MTU кліента

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

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

Праверце той перадачай, якая правалілася, затым зрабіце значэнне пастаянным

Лакальная змена ip link дзейнічае, пакуль кліент не перабудуе тунель, што адбываецца пры наступным перападключэнні або аднаўленні. Размясціце значэнне там, дзе пачынаецца злучэнне: абгортка, якая запускае кліент і затым наладжвае прыладу, модуль systemd з крокам ExecStartPost або опцыя кліента, калі шлюз яе прымае. Трымайце яго побач з профілем у сістэме кантролю версій, каб наступны чалавек бачыў, чаму лік там.

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

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