Зашто се странице 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-у није доказана. Снимите саобраћај на тунелу и проверите која страна престаје да шаље пре него што поново промените број, и држите претходну вредност забележену да би враћање остало једна наредба.