Я работаю над Linux 4.13.x. И я подумываю отправить ответный пакет в ядре.
Рассмотрим эхо-сервер TCP или UDP, работающий в пространстве пользователя, а также другой узел, на котором запущен клиент TCP или UDP. Клиенты отправляют запросы на сервер. Я хочу отправить ответ пакета обратно клиенту без какого-либо участия серверного приложения, работающего в пользовательском пространстве.
Вот мои мысли по поводу этой проблемы:
Я начал думать, как это возможно, и наткнулся на такое решение, как netfilter. Если я могу захватить пакеты в NF_INET_PRE_ROUTING, а затем попытаться поменять местами IP-адреса источника и получателя в заголовке IP, а также поменять местами порты в заголовке TCP, то в соответствии с это ответы и этот предположительно измененный пакет должен быть перенаправлен отправителю через систему маршрутизации .
На самом деле, я попробовал этот сценарий, и кажется, что это невозможно сделать с помощью ловушек netfilter, однако я не уверен в этом. Я думал, что он не работает, так как у него проблемы с контрольными суммами, потому что я манипулирую пакетами, поэтому я провел еще один эксперимент, чтобы выяснить эту проблему. Я просто меняю данные пакета, и все работает хорошо. Я думаю, что с контрольными суммами нет проблем, поскольку они будут проверяться в сетевой карте при получении, а также при отправке такая же ситуация, поэтому промежуточные манипуляции не делают ничего плохого. Я также активирую переадресацию IPv4 на хосте сервера (sysctl.config), но ничего не меняется.
Я не хочу создавать новый пакет, я хочу только изменить этот пакет и отправить его обратно. Есть еще один похожий вопрос, который создает другой пакет. Более того, я просто думаю, почему этот сценарий не работает? Но, судя по архитектуре сетевого фильтра, он должен работать.
Спасибо
skb->pkt_type = PACKET_OTHERHOST
иskb->_skb_refdst = 0
. Я не читал весь код маршрутизации, но это может позаботиться об этом. Это может или не может сломать ваш стек маршрутизации; Не имею представления. - person Joel C   schedule 13.03.2018