Пинг през VPN: защо правилата за ехо-отговор не виждат обратния път

Пуснете ping към хост през VPN и заявката излиза с един тип ICMP, а се връща с друг — това е достатъчно да обърка всяко правило, написано в термини на портове. В ехо-обмена няма порт на услугата по местоназначение, който да се копира в правилото за връщане, а филтър, който очаква симетрия, ще изхвърли отговора, докато заявката минава свободно. Поправката започва с прочитане на пакета такъв, какъвто е, и след това с решение коя граница по пътя взема решението. Обикновено работят два слоя, докато третият безшумно изхвърля отговора. Разделите по-долу ги разделят в реда, в който пакетът ги среща.

Пакетът сменя типа, не порта

Ехо-заявката е ICMP тип 8, код 0, и носи идентификатор и пореден номер. Отговорът е тип 0, код 0, със същите идентификатор и пореден номер и с разменени IP крайни точки. RFC 792 дефинира тези полета и именно идентификаторът позволява на подателя да съпоставя отговорите със своите заявки.

Отсъствието е също толкова важно: няма TCP или UDP заглавка, следователно няма порт, който да се разрешава. Правило, което посочва порт за ехо-отговор, описва пакет, който никога няма да съществува. Това е най-честата грешка в заявките за ping през VPN. Правилото изглежда конкретно, не важи за нищо и оставя повредата точно там, където беше.

Три контекста решават съдбата на пакета

Ако ping е насочен към хост в отдалечената LAN, заявката трябва да бъде препратена от шлюза. Ако е насочен към адрес, който принадлежи на самия шлюз, тя завършва във локалния входен път. Ако шлюзът сам инициира ping, пакетът започва в собствения му изходен път и изобщо не преминава през решението за препращане.

Тези три контекста имат различни вериги от правила и различни броячи и точно смесването им в едно е причината „защитната стена разрешава ICMP“ да дава неуспешен ping. Външният тунел е четвърти контекст: разрешаването на VPN слушателя не разрешава автоматично декапсулираната вътрешна заявка, а вътрешното разрешение не казва нищо за това дали външният тунел е вдигнат.

Филтрите със и без състояние обработват отговора различно

Защитна стена със състояние, която е видяла заявката да излиза, може да свърже отговора с този поток и да го пропусне без второ правило. Филтър без състояние няма такава памет, затова обратната посока се нуждае от собствено изрично разрешение, с разменени източник и местоназначение.

Проверете кой модел продуктът наистина прилага, преди да пишете каквото и да е. Правило за ехо-заявка не покрива непременно ехо-отговор, а продукт, който следи ICMP заявки, може да прилага различна политика към отговори, пристигащи на друг интерфейс.

Ограничете това, което разрешавате. Разрешаването на всеки ехо-отговор отвсякъде не е същото като завършване на връзка със състояние, а номерът на типа не удостоверява подателя.

Транслацията променя и идентификатора

Ако транслацията на източника е умишлена, кортежът в далечния край не съвпада с този, който клиентът е изпратил. NAT може да транслира идентификатора на ICMP заявката заедно с адресите, така че настояването един и същ номер да се появи от двете страни създава фалшиво несъответствие.

Вместо това се ориентирайте по съответствието, което транслаторът докладва. Транслатор, който пренаписва идентификатора, няма да запази номера, който клиентът ви е записал, затова третирайте съответствието като идентичност, а не номера. След това проследете една разпознаваема заявка по пътя: потвърдете, че достига до местоназначението с очаквания източник, потвърдете, че местоназначението е издало отговор, проследете маршрута на този отговор обратно, и потвърдете, че клиентът го е получил, вместо само да гледате как брояч на шлюза расте.

Не сливайте ICMP грешките в ехо политиката

Съобщението „необходима е фрагментация“, използвано от откриването на MTU по пътя, не е ехо-отговор и полезният му товар цитира пакета, който го е предизвикал. Разрешение само за ехо, което тихо изхвърля тези грешки, превръща проблем с размера в закачена връзка, което е точно обратното на полезното.

Същото внимание важи и за семействата адреси. ICMPv6 използва различни типове съобщения и носи съществени функции, които IPv4 няма, така че копирането на тези номера в правило за IPv6 е просто грешно.

Когато ехо-обменът работи, тествайте истинското приложение отделно. Успешният ping доказва двупосочно пътуване на един протокол, с един размер, до едно местоназначение и не е лиценз да предполагате, че HTTPS, SMB или всеки друг поток е разрешен.