Ну ка расскажи мне как ты собрался определять с помощью icmp доступность клиента за NAT?

Я тут шлагбаумный шлюз мастерю, сверху схематоз обработки одного датчика (d1 & d2) который, снизу механика и расстановка. Нижних картинок две должно быть, из них составляется шлюз...

Ты как-то странно ставишь резюки

никак. ответ не будет получен при разорваном соединении. если соединение живое то ответ придет на эхо запрос. т.е. доступность определить не получиться только факт открытого подключения или его отсутствие. Как я понял задача именно так и стояла

поэтому и спрашиваю, как расставить правильно?

Все хватит. Это эффект даннинга крюгера в действии. Читай устройств tcp, как он работает и какую роль играет там icmp

Перед анндом же, чтоб диод не сжечь

А нахера там две резюка то

По резюкам уже подзабыл, чё там на выходе и как надо делать...

Все хватит. Это эффект даннинга крюгера в действии. Читай устройств tcp, как он работает и какую роль играет там icmp

Мне даже любопытно стало как ты себе объясняешь механизм работы TCP и с помощью какой магии по твоему мировозрению он ( TCP) узнает о разрыве соединений?

Читай книжки. Там все написано и про это в том числе

Мое мировозрение говорит что TCP работает поверх IP который использует ICMP о чем я довольно подробно написал выше

Дело твое. Но этим бредом ни с кем не делись а то и правда люд будет думать что icmp используется для детекции мертвых tcp сессий. Интересно даже как он в твоем "мировозрении" то через наты бегает.

Нат. это пристройка сбоку к протоколу IP и все завязано на идентификатор подключения. т.е. буквально строиться таблица где идет подмена адресов в сообщении приходящих с одного (внешнего) интерфейса и отправляемых на (внутренний) интерфейс.

Дело твое. Но этим бредом ни с кем не делись а то и правда люд будет думать что icmp используется для детекции мертвых tcp сессий. Интересно даже как он в твоем "мировозрении" то через наты бегает.

Оптопара на 4 гига?

Это 4 ядерная

Дело твое. Но этим бредом ни с кем не делись а то и правда люд будет думать что icmp используется для детекции мертвых tcp сессий. Интересно даже как он в твоем "мировозрении" то через наты бегает.

Насколько я помню ICMP является неотъемлемой частью TCP/IP и без него в принципе невозможно использовать TCP/IP

Попробую совсем на пальцах. Есть определенная модель сети . В ней реализован стек сетевых протоколов. На данный момент следует остановиться на двух TCP/IP. К примеру клиент за натом открывает подключение к серверу. Для этого он формирует буфер из байт и специальную структуру данных с информацией для IP протокола(адрес получателя). после чего отправляет данные. Начинает работать IP протокол который с помощью таблицы маршрутизации выбирает интерфейс на который он отправляет IP пакет(к серверу). На сервер приходит пакет и передается драйверу протокола TCP сервер понимает что подключение открыто и в буфер получены байты. (грубо говоря). Случается ситуация когда когда связь оборвана и ни клиент ни сервер об этом не знают. В таком случае связь пытается работать аналогично. Приложение на сервере формирует буфер с данными заполняет структуру информации для IP протокола и передает в сеть. Но на одном из узлов сети в таблицы маршрутизаци ну или NAT который ее симулирует возникает ошибка невозможно связаться с открывшим подключение адресом. Вот в этот самый момент и происходит магия ICMP узел сети в ответ на IP пакет отправляет обратно свой служебный IP пакет (ICMP 3.1 узел не достижим) этот пакет добирается до сервера и драйвер IP сообщает драйверу TCP о том что соединение разорвано.

Пинговать клиента это вообще лютая дичь чтоб определить жива ли tcp сессия. Ну ответ он тебе на пинг, а сессия мертва и че?

Попробую совсем на пальцах. Есть определенная модель сети . В ней реализован стек сетевых протоколов. На данный момент следует остановиться на двух TCP/IP. К примеру клиент за натом открывает подключение к серверу. Для этого он формирует буфер из байт и специальную структуру данных с информацией для IP протокола(адрес получателя). после чего отправляет данные. Начинает работать IP протокол который с помощью таблицы маршрутизации выбирает интерфейс на который он отправляет IP пакет(к серверу). На сервер приходит пакет и передается драйверу протокола TCP сервер понимает что подключение открыто и в буфер получены байты. (грубо говоря). Случается ситуация когда когда связь оборвана и ни клиент ни сервер об этом не знают. В таком случае связь пытается работать аналогично. Приложение на сервере формирует буфер с данными заполняет структуру информации для IP протокола и передает в сеть. Но на одном из узлов сети в таблицы маршрутизаци ну или NAT который ее симулирует возникает ошибка невозможно связаться с открывшим подключение адресом. Вот в этот самый момент и происходит магия ICMP узел сети в ответ на IP пакет отправляет обратно свой служебный IP пакет (ICMP 3.1 узел не достижим) этот пакет добирается до сервера и драйвер IP сообщает драйверу TCP о том что соединение разорвано.

Никто не определяет мертвую сессию tcp с помощью icmp

В теории клиент должен ответить с помощью того же icmp 3.3 что такого подключения нет

Для таких задач есть такие технологии как nat traversal, stun, turn и тд и тп. Механизмы проверки сессий есть

ваще норм. ещё и нмап на клиента прогнать -- а чего он просто так пришёл

нах. неактивное соединение просто закрывает сервер если в кипэлеайве. или вообще сразу закрывает после отправки ответа

Если есть проверка keepalive, то на той стороне соединения в conntrack обычно обновляются и не рвутся

Правда он так и не ответил как он собрался пинговать клиента за натом

речь была про веб. читал?

Правда он так и не ответил как он собрался пинговать клиента за натом

Если честно, то начал с темы объяснения на пальцах))

Да это как бы из другой оперы

ваще, есть такой звон -- пинг встроен в вебсокеты. но это не так звенит

Куда пинг встроен?

Тут ничего не сказано про icmp