Undecoded packets

Только что сам это сделал (сниффинг с использованием правила маникуляции на интерфейсе GRE, который также является IP-only), и значение ethertype правильное. В твоем случае, на самом деле, оно не отсутствует, просто неверно (0x0 вместо 0x800, извини, я пропустил это, когда смотрел изначально). Так что, если эта ошибка не является особенностью твоей архитектуры, возможно, это не ошибка сниффинга, а действительно ошибка в создании этих пакетов. В любом случае, если тебе нужно просто декодировать содержимое, ты можешь экспортировать инкапсулированные данные в Wireshark (начиная с 45 c0) в шестнадцатеричный дамп и использовать "Импорт из шестнадцатеричного дампа", указав тип инкапсуляции как "Raw IP". Если тебе нужно понять, был ли пакет фактически сопоставлен с политикой IPsec и доставлен к месту назначения, боюсь, тебе придется настроить свой собственный узел IPsec вместо публичного VPN, который ты используешь. РЕДАКЦИЯ: есть намного более простой способ декодировать эти пакеты в Wireshark. Когда выбран пакет с неправильным значением ethertype в списке пакетов, щелкни правой кнопкой мыши и выбери "Декодировать как..." из выпадающего меню. Добавь строку в таблицу и установи Поле на Ethertype, Значение на 0 и Текущий на IPv4.

У нас есть давняя традиция — я не понимаю, что ты на самом деле имеешь в виду в своих сообщениях. Неизвестно, является ли этот эффект двусторонним. Так в этом случае ты говоришь, что эти пакеты появляются, когда ты browse’ишь форум, но тем не менее просмотр работает даже при отключенном правиле изменения MSS? Потому что обычно обнаружение Path MTU работает с одним ICMP-отзывом для каждого узкого места: когда пакет с установленным битом Don’t Fragment приходит на маршрутизатор, где он не подходит под MTU выходного маршрута, этот маршрутизатор отправляет обратно ICMP сообщение типа 3 код 4, указывая доступный MTU, и стек сети отправителя или приложение предпринимает необходимые действия (что в случае TCP-стека — отправить меньшую часть входного буфера в пакете, который только что соответствует MTU, сообщенному ICMP типом 3 код 4, снова с установленным флагом DF, чтобы в конечном итоге выявить еще более узкое место в дальнейшем направлении к назначению). В случае TCP главная цель заключается в том, чтобы разрезать входящий поток данных на достаточно маленькие TCP-пакеты уже на источнике, вместо того чтобы позволять им фрагментироваться в процессе передачи, потому что фрагментация во время передачи использует больше дополнительных данных, чем отправка меньших пакетов на источнике. Поэтому я могу представить, что отправитель забрасывает назначение повторными передачами слишком больших для передачи пакетов с установленным DF, но никогда не получает ICMP сообщения типа 3 код 4 в ответ, и не могу представить, как в итоге это соединение когда-либо могло бы быть установлено. Именно поэтому я дважды проверяю, правильно ли я тебя понял на этот раз. И здесь мы, возможно, подходим к причине, почему PMTUD не работает хорошо в этом направлении. Я помню, у тебя была очень специфическая настройка из двух маршрутизаторов с наложением, но с тех пор это могло измениться. В любом случае, эти ICMP сообщения типа 3 код 4 не напрямую соответствуют отслеживаемому соединению, к которому они имеют отношение. Поэтому модуль отслеживания соединений брандмауэра определяет их как относящиеся к уже существующему отслеживаемому соединению и помечает их как connection-state=related, проверяя содержимое их полезной нагрузки (где копируются IP и TCP заголовки триггерного пакета). Следовательно, должно существовать правило фильтрации action=accept connection-state=…,related,…, чтобы эти ICMP-пакеты могли проходить через брандмауэр. Это так на всем пути от маршрутизатора, генерирующего эти пакеты, до клиентского ПК? Эти ICMP-пакеты к клиенту (то есть вызванные слишком большими для передачи пакетами, отправленными в направлении клиент->сервер) генерируются маршрутизатором, выполняющим IPsec инкапсуляцию. IPsec транспортный пакет больше, чем пакет полезной нагрузки, который он транспортирует, на размер заголовков инкапсуляции, поэтому если результирующий транспортный пакет не подходит под MTU его выходного интерфейса, маршрутизатор, выполняющий инкапсуляцию, отправляет ICMP сообщение типа 3 код 4 обратно на адрес клиента со своего собственного адреса — поэтому ты можешь увидеть этот пакет в цепочке postrouting и/или output на этом маршрутизаторе. Поэтому, прежде всего, я бы послушал эти пакеты на физическом интерфейсе маршрутизатора, создающего их, используя функцию "sniff to file" (чтобы ты мог отличить те, которые пойманы правилом mangle, от тех, что пойманы при прослушивании на интерфейсе, если делать оба одновременно). Если они пойманы правилами mangle sniff-tzsp, но не видны в прослушивании на физическом интерфейсе, они генерируются или маршрутизируются неправильно.

“без интерфейса и с выбранным конкретным портом Ethernet” для меня не имеет особого смысла. В RouterOS много путаницы с терминами “интерфейс” и “порт”, потому что если IP-конфигурация привязана напрямую к etherX, то etherX является L3 интерфейсом. Однако если etherX является членом моста, то L3 конфигурация должна быть привязана к мосту, и, следовательно, L3 интерфейсом является мост. Но это точка зрения файервола; при настройке сниффера все обозначается как интерфейсы. Так что если вы сказали снифферу захватить трафик с Ethernet-интерфейса, через который должны быть направлены пакеты к клиентскому ПК, не имеет значения, был ли это фактический L3 интерфейс или просто член моста. Так что вы можете действительно начать захват, вообще не указывая интерфейс, а просто указать ip-protocol=icmp, чтобы проверить, не маршрутизируются ли пакеты типа 3 код 4 куда-то еще, кроме ожидаемого. И есть большая вероятность, что политики маршрутизации (т.е. использование connection-mark и routing-mark) приводят к неправильной маршрутизации этих локально сгенерированных ICMP пакетов типа 3 код 4, или что политика IPsec соответствуют им и перенаправляет их, потому что правило NAT, соответствующее connection-mark, на NAT-ит их к исходному адресу, на который и соответствует политика IPsec (поскольку пакеты, связанные с соединением, наследуют его connection-mark). В основном, если первое правило в цепочке forward принимает связанные трафики без каких-либо ограничивающих условий, не имеет значения, что делают последующие правила, так как трафик к ним просто не доходит. Так что самый быстрый способ проверить, является ли причиной блокировка “связанных” трафиков, просто добавьте правило chain=forward action=accept connection-state=related в самом начале цепочки chain=forward на любом маршрутизаторе между тем, который генерирует пакеты, и клиентом. На маршрутизаторе-генераторе эти пакеты могут быть отброшены файерволом только если у вас есть какие-то специфические правила в цепочке output, которая, как правило, пуста. Так что я скорее склоняюсь к тому, что они неправильно маршрутизируются, чем к тому, что блокируются файерволом. Что касается OP - я провел несколько тестов и мой вывод заключается в том, что неправильное заполнение поля ethertype в заголовке Ethernet 0x0 вместо надлежащего 0x800 является специфическим поведением действия action=sniff-tzsp в цепочке output /ip firewall mangle. Это не зависит от IP-протокола, который переносится пакетом, который захватывается (пакеты TCP также подвержены этому), тем менее от конкретного типа ICMP. С другой стороны, action=sniff-tzsp в цепочке postrouting /ip firewall mangle не страдает от этой проблемы, даже для пакетов ICMP типа 3 код 4, генерируемых самим маршрутизатором. Так что пакеты ICMP типа 3 код 4 сами по себе не являются поврежденными (как покажет захват с использованием цепочки postrouting), это исключительно проблема захвата в цепочке output в mangle. Возможно, стоит уведомить support@mikrotik.com об этой проблеме.

Я с тобой согласен, однако срок реализации может быть «никогда». Так что нам нужно либо решение без VTI, либо демонстрация того, что такое решение невозможно и что только VTI может быть решением. Можешь подтвердить, что ты используешь назначение connection-mark через mode-config, чтобы RouterOS динамически создавал правило в цепочке src-nat? И если да, не мог бы ты вставить вывод команды /ip firewall nat print chain=srcnat, пока подключение IPsec активно (меня интересует только динамическое правило и действительно ли оно добавляется первым в цепочке src-nat, как я и предполагаю)? В любом случае, должно быть какое-то решение — статическое правило IPsec action=none src-address=0.0.0.0/0 dst-address=the.client’s.subnet, которое помещается перед шаблоном политики, используемым для создания динамической политики с адресом IP, предоставленным ответчиком, в качестве src-address. Это правило action=none будет затенять динамически сгенерированное, так что, хотя пакет ICMP код 3 тип 4, вероятно, будет обработан динамическим правилом src-nat, он не достигнет динамической политики (которая направила бы его в тоннель), так что он доберется до клиента. Клиенту не важен адрес источника, так как для него это не имеет значения, поэтому он должен соответственно скорректировать размер повторно отправленного TCP-пакета и всех последующих. Это интересная информация — я сначала поместил правило только в цепочку output и увидел, что пакет TZSP пришел с ошибкой. Затем я добавил то же правило и в цепочку postrouting, и пакеты TZSP начали приходить парами: первый с ошибкой, второй без. Я использую версию 6.45.7 на hAP ac², можешь протестировать то же самое (оба правила присутствуют) и указать свою версию ПО и модель оборудования? Хорошо, похоже, я наконец-то понимаю, как ты проводишь тест. Так что, как только ты отключаешь правило change-mss, ты нажимаешь Preview и смотришь, удастся ли установить новое HTTPS-соединение или нет. Так что ты действительно можешь видеть повторные передачи при нажатии, а не каждое нажатие клавиши в рабочем соединении для отправки одного ICMP-пакета. Хорошо.

Рад помочь. Однако, поскольку заголовок и оригинальное сообщение в этой теме не раскрывают суть проблемы, с которой вы столкнулись, было бы хорошо, если бы вы нашли свою другую тему, которая более ясно связана с ней, и опубликовали там решение (возможно, с ссылкой на подробное объяснение здесь) — если кто-то другой столкнется с такой же проблемой, вряд ли они найдут эту тему (с содержащее решение) по ключевым словам, не говоря уже о заголовке. В большинстве конфигураций, где вы используете VPN для анонимизации доступа в интернет, можно добавить политику action=none "теневого" отражения для каждого из трех диапазонов RFC1918: 10.0.0.0/8, 172.16.0.0/12 и 192.168.0.0/16. Я не думаю, что их следует добавлять автоматически. Еще одна возможность (хотя и аналогично сложная в настройке, как и с политиками action=none) — установить как address-list, так и connection-mark в строке mode-config и добавить несколько диапазонов адресов, исключая LAN-адрес(а) самого роутера в этот address-list (например, 0.0.0.1-192.168.88.0, 192.168.88.2-255.255.255.255, если адрес роутера 192.168.88.1). Таким образом, динамически создаваемое правило NAT не будет соответствовать пакетам, отправленным самим роутером, поэтому они не станут видимыми для динамически сгенерированной политики, и теневые политики не понадобятся.

Я обычно придерживаюсь принципа «пострадавший открывает тикет в поддержку». Мужчины попросят supout.rif и так далее, а у меня и так достаточно открытых тикетов. Да, конечно, я имею в виду, что не думаю, что Mikrotik должен динамически генерировать исключения на основе этой информации, потому что существует больше сценариев VPN, чем просто анонимизация интернет-доступа, а именно «настоящие» VPN, когда вы подключаетесь к сети своей компании или связываете несколько ее офисов, и в таких случаях широкая открытость политик тени будет вредна. Поэтому политики тени должны быть настроены под конкретную конфигурацию, и это просто невозможно сделать автоматически. Ах, я думал, что ты уже открывал один ранее, и я просто пропустил это.

Я забыл добавить одну строку с исходным адресом: 0 D ;;; ipsec mode-config chain=srcnat action=src-nat to-addresses=188.xx.xx.x src-address-list=VPN dst-address-list=!VPN Прямо под этим у меня есть ловушка для случая, когда IKEv2 все еще запускается, а клиент уже начал отправлять пакеты. 1 ;;; Ловит трафик, когда IKEV неактивен chain=srcnat action=src-nat to-addresses=127.0.0.1 src-address=192.168.88.xx log=no log-prefix="No escaping" Для соединения, отмеченного мной, у меня есть отдельная строка "no escaping".

Пост, который я сделал о том, что MTU не был отправлен клиенту. Дайте знать, если что-то нужно изменить.

Как ты получил пакет в Wireshark? Это на 99% ICMP-пакет, но значение ethertype 0x0800 отсутствует между поддельным Ethernet-заголовком, состоящим из одних нулей, и началом IP-заголовка. Так что это либо проблема со шнуром (который добавляет поддельные Ethernet-заголовки к простым IP-пакетам), либо ошибка в том, как ты импортировал шестнадцатеричный дамп в Wireshark.