Зошто целосното блокирање на ICMP ја крши работната VPN патека

Тунел што ќе помине автентикација, ќе пренесе ping и потоа ќе заглави на првиот голем пренос е класичен знак за исчезната ICMP порака, а не за расипан VPN. Испраќачот никогаш не дознава дека пакетот бил преголем, го повторува истиот размер, а апликацијата чека. Поправањето е одлука за политиката на огнениот ѕид, не преинсталација на клиентот. Редоследот е важен: измерете каде е границата на големината, потоа стеснете го правилото што го проголта извештајот.

Што ICMP навистина пренесува на оваа патека

Откривање на MTU на патеката IPv4 се потпира на тоа рутерот да пријави дека пакет со поставен don't-fragment бит не можел да се препрати. Тој извештај е ICMP Fragmentation Needed порака, а без неа испраќачот нема причина да ја намали големината на сегментот. IPv6 е построг: рутерите не фрагментираат во транзит, затоа ICMPv6 Packet Too Big пораката е единствениот сигнал што го тера испраќачот да се намали.

Двете пораки се повратна информација од контролната рамнина и ниту една не е дијагностичко ехо. Политиката што блокира ping и политиката што блокира цел ICMP изгледаат слично во списокот правила, но на мрежата се однесуваат многу различно. Втората може да претвори правилно димензиониран тунел во еднонасочна патека за сè што е поголемо од најмалата алка во синџирот.

Некои транспорти го спроведуваат сопственото откривање со сондажни пакети, како што опишува RFC 4821, и тие помалку зависат од оваа повратна информација. Тоа е аргумент да проверите кој транспорт го вртите, не да претпоставите дека секој тунел е имун.

Дефектот зависи од големината

Прашајте дали дефектот корелира со големината на пакетот. Страницата за најава, DNS барањето и краткиот API повик поминуваат, додека прикачувањето датотека, големиот одговор или преземањето слика заглавуваат. Овој образец укажува на ограничување на големината некаде меѓу двата краја, а не на автентикација или рутирање. Успешен мал ping речиси ништо не кажува за тоа каде е таа граница.

Внатре во тунелот треба да се земат предвид два слоја: пакетот со носив товар и надворешниот инкапсулиран пакет. Внатрешниот испраќач може да се однесува правилно додека надворешната патека е помала отколку што претпоставува тунелот, затоа се важни и сопственото MTU поставување на тунелот и физичката алка под него.

Измерете пред да уредувате правила

Проверете со don't-fragment битот и со големина на носивиот товар што самите ја избирате, од дефектниот клиент кон заштитена адреса:

ping -M do -s 1472 10.20.5.7
ping -M do -s 1300 10.20.5.7

Носив товар од 1472 бајти плус 28 бајти заглавија е пакет од 1500 бајти. Ако големата сонда не успее со грешка при фрагментација, а помалата помине, ја најдовте границата; прилагодете за дополнителниот товар на тунелот и повторувајте додека работната големина не се стабилизира.

Потоа потврдете дека јазот е самиот извештај. Ако сондата не успее тивко, без грешка и без одговор, пораката веројатно се отфрла наместо да се доставува, а сомнителното е правилото.

Стеснете го правилото, потоа повторно тестирајте ја задачата

Исправката треба да ги дозволи конкретните контролни пораки, не целиот протокол. На домаќин со iptables формата е дозвола за конкретен тип; прилагодете ја синтаксата на она што го управува огнениот ѕид на вашата платформа:

iptables -I INPUT -p icmp --icmp-type fragmentation-needed -j ACCEPT
ip6tables -I INPUT -p icmpv6 --icmpv6-type packet-too-big -j ACCEPT

Оставете ги ехо одговорите блокирани ако тоа е локалната политика, бидејќи на патеката не ѝ се потребни. Потоа повторно тестирајте го преносот што првично не успеа, од нова врска, и потврдете дека бројачите на правилото покажуваат пристигнување на пораките.

Ако големиот пренос сè уште заглавува откако пораките се дозволени, преостанатото ограничување е на друго место: превисоко поставен MTU на тунелот, прокси што пакетите ги препишува или средно уред што отфрла наместо да пријави. ICMP правилото беше неопходно, но не доволно.