Поставување TCP MSS на Linux IPsec портал: што поправа

Ping работи, SSH работи, мала страница се вчитува, а потоа секој голем одговор заглавува додека не истече времето. Класичната шема укажува на големината на пакетот, а не на достапноста: патеката го носи ракувањето и првите неколку килобајти, потоа сегмент со полна големина исчезнува. На Linux IPsec портал, правилото TCP MSS често е решението, но само ако разбирате што менува и каде всушност се наоѓа пакетот што го допира. Редоследот подолу го следи пакетот од симптомот до поставувањето на правилото, така што можете да застанете штом објаснувањето престане да одговара.

Симптомот што укажува на MSS

TCP преговара максимална големина на сегмент при ракувањето. Ако таа вредност е поголема од она што патеката може да го пренесе по инкапсулацијата, испраќачот продолжува да создава сегменти што никогаш не пристигнуваат, и врската заглавува по првиот круг. Малите одговори поминуваат; големите не.

Повратната информација од ICMP може да ја спаси врската преку откривање на MTU на патеката, а огнениот ѕид што ги отфрла тие пораки го претвора заглавувањето во тивка црна дупка. Затоа истиот тунел работи за една апликација, а не успева за друга без никаква очигледна разлика во конфигурацијата.

Што прави правилото TCPMSS, а што не прави

Правилото ја препишува опцијата MSS во пакетите за ракување на TCP додека поминуваат. Тоа не го поставува MTU на тунелскиот интерфејс, не ја менува политиката на IPsec, и на современите јадра само ја намалува објавената вредност наместо да ја зголеми веќе помалата. Исто така допира само TCP; UDP товарите, однесувањето на DNS и преговараните селектори на сообраќај се надвор од неговиот дофат.

Бидејќи промената се случува за време на ракувањето, постојната врска воспоставена пред правилото ја задржува старата вредност. Тестирајте со нова врска и очекувајте првиот обид по промената да биде тој што ќе ви каже нешто. Ништо во правилото не допира до врска што е веќе отворена. Затоа исправка применета среде инцидент може да изгледа како да не направила ништо.

Ставете го правилото на внатрешната TCP патека

На Linux портал заснован на политика, препратениот пакет сѐ уште изгледа како обичен TCP кога огнениот ѕид го гледа. Политиката на IPsec одлучува дека пакетот ќе биде заштитен; огнениот ѕид не гледа ESP заглавие за внатрешниот тек, па совпаѓањето со ESP овде опишува сосема друг пакет. Токму тоа несовпаѓање е причината зошто некои правила изгледаат точни и никогаш не се совпаѓаат.

Во термини на iptables, правилото припаѓа на табелата mangle на патеката на препраќање, ограничено на пакетите за ракување: iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1270. Бројот е пример, а не универзална константа; изведете го од трошокот за инкапсулација и од вистинскиот MTU на патеката. Еквивалент на nftables ја поставува максималната големина на сегмент во синџир forward или postrouting.

Држете ги надворешните правила за слушање на IKE и ESP одвоени од внатрешните правила за препраќање. Едно правило што се обидува да овласти и текот на апликацијата и надворешниот протокол, на крајот не се совпаѓа сигурно со ниту едно од двете.

Почитувајте го сопственикот на огнениот ѕид и редоследот на NAT

Ако UFW го поседува огнениот ѕид на домаќинот, додајте ги промените на mangle и препраќањето преку неговата поддржана постојана конфигурација, наместо со впишување команда што исчезнува при следното вчитување. Правило вметнато во погрешна табела или по терминално правило нема ефект, а активната табела тоа ви го крие.

Преводот на изворот е одделна одлука што често взаимодействува со оваа. Исклучок поставен пред општо правило за masquerade спречува заштитениот сообраќај да го загуби изворот што го бара неговата политика; тоа не поправа проблем со големина, а правило за големина не поправа проблем со превод.

Проверете тесно, потоа застанете

Отворете нова врска до услугата што не успева и набљудувајте и апликацијата и бројачите на правилото. Ако заглавувањето исчезне, имате доказ за таа TCP патека со таа инкапсулација. Немате доказ дека одговара секој VPN протокол, дека се поправени сите UDP апликации или дека одредена услуга повисоко било првобитната причина.

Дозволете повратната информација за големина од ICMP да работи таму каде што политиката дозволува, и внимателно третирајте го автоматското ограничување засновано на MTU на маршрутата кога надворешната IPsec патека не е претставена од внатрешната маршрута. Колку е потесен заклучокот, толку е полесно да се дијагностицира следниот инцидент.