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

Повезани чланци