Формирование пакетов утилитой PING

http://ru.wikipedia.org/wiki/ICMP

Я не совсем правильно выразился. Мне нужно знать какая последовательность формирования пакета на линухе через конкретный интерфейс, для того что-бы не писать -I tun0. Или другими словами как заставить выпускать пакеты через конкретный интерфейс

таблицы маршрутизации

Или другими словами как заставить выпускать пакеты через конкретный интерфейс

Это маршрутизацией делается обычно. Если направление КУДА всегда одно, то тупо route add -host IP dev tun0, например.

пробовал, не помогает. может как-то через ip forward?

когда я ставлю такую маршрутизацию то пакеты доходят но почему-то не распознаются ядром. Другими словами если пинговать эту машину то она не отвечает

чето может я неправильно понял

когда я ставлю такую маршрутизацию то пакеты доходят но почему-то не распознаются ядром. Другими словами если пинговать эту машину то она не отвечает

С другой стороны тоже должно быть настроено. Если у тебя там тоже tun (то есть впн), то кури маршрутизацию на двух провов.
http://www.lartc.org/howto/lartc.rpdb.multiple-links.html

нет это не впн - это ipip, проходя по сети первая шапка снимается на роутере и до получателя доходит чистый пакет, он же в свою очередь отвечает но без инкапсуляции, тоесть доходит не ipip, а просто ip

нет это не впн - это ipip, проходя по сети первая шапка снимается на роутере и до получателя доходит чистый пакет, он же в свою очередь отвечает но без инкапсуляции, тоесть доходит не ipip, а просто ip

Да, скорее всего банальная настройка на двух провайдеров.
Кури доку выше.

Да но пакет то доходит до меня обратно, но система его почемуто не распозгает. В чем тогда причина?

в доке использовали 2 физических интерфейса, у меня же весь траффик всеравно будет выходить через один интерфейс. Просто нужно указать что для некоторого пула нужно на пакеты одевать ip шапки

а пакет приходит на тот же интерфейс откуда улетает??

Мне нужно знать какая последовательность формирования пакета на линухе через конкретный интерфейс, для того что-бы не писать -I tun0. Или другими словами как заставить выпускать пакеты через конкретный интерфейс

При указании интерфейса, исходящему пакету задаётся IP адрес этого интерфейса, в качестве адреса-источника пакета.

Да пакет приходит, но дальше наверно не пересылается на туннельный интерфейс. Если писать route add -host 10.10.10.10 dev tun0 ping 10.10.10.10 PING 10.10.10.10 (10.10.10.10) 56(84) bytes of data пустая строка tcpdump: IP 1.1.1.1 --> 2.2.2.2 IP 5.5.5.5 --> 10.10.10.10 - запрос IP 10.10.10.10 --> 5.5.5.5 -ответ При этом пинг тупо молчит

Если пинговать 5.5.5.5 с 10.10.10.10 то tcpdump на 5.5.5.5 IP 10.10.10.10 --> 5.5.5.5 IP 10.10.10.10 --> 5.5.5.5 и не отвечает Если убрать эту маршрутизацию и писать Ping 10.10.10.10 -I tun0 то все нормально. Естественно писать -I tun0 в реальной работе не получится

Чето я не вкурил, в чем смысл?

Возможно когда приходит пакет на линух он как-то недоходит до тунельного интерфейса? Это вобще возможно и как это понимать?

очень сумбурно написано, я не понимаю. Лучше создай ещё один топик где ты укажешь конфигурацию сети, фаервола, роуты и sysctl.

Есть сеть состоящая из компа К1, роутера Р1, компа К2.

-----------------------------------------------------

Роутер

eth0 10.20.200.2/24 eth1 10.10.10.1/24

tun1 Ip 5.5.5.1 src 10.10.10.1 dst 10.20.200.1

------------------------------------------------------

Комп 2

eth0 10.10.10.21

------------------------------------------------------

Конфигурация К1:

sysctl -a | grep forward | grep v4

net.ipv4.conf.all.forwarding = 1

net.ipv4.conf.all.mc_forwarding = 0

net.ipv4.conf.default.forwarding = 1

net.ipv4.conf.default.mc_forwarding = 0

net.ipv4.conf.lo.forwarding = 1

net.ipv4.conf.lo.mc_forwarding = 0

net.ipv4.conf.eth0.forwarding = 1

net.ipv4.conf.eth0.mc_forwarding = 0

net.ipv4.conf.gre0.forwarding = 1

net.ipv4.conf.gre0.mc_forwarding = 0

net.ipv4.conf.tun0.forwarding = 1

net.ipv4.conf.tun0.mc_forwarding = 0

net.ipv4.ip_forward = 1

++++++++++++++++++++++++++++++++++++++++++++++++++++

ifconfig

eth0 10.20.200.1 255.255.255.0

tun0 5.5.5.5 255.255.255.0

++++++++++++++++++++++++++++++++++++++++++++++++++++

ip tunnel show tun0

tun0: ip/ip remote 10.10.10.1 local 10.20.200.1 ttl 255

++++++++++++++++++++++++++++++++++++++++++++++++++++

route

Kernel IP routing table

Destination Gateway Genmask Flags Metric Ref Use Iface

5.5.5.0 * 255.255.255.0 U 0 0 0 tun0

10.20.200.0 * 255.255.255.0 U 0 0 0 eth0

default 10.20.200.2 0.0.0.0 UG 0 0 0 eth0

+++++++++++++++++++++++++++++++++++++++++++++++++++++

ping 10.10.10.21 -I tun0

PING 10.10.10.21 (10.10.10.21) from 5.5.5.5 tun0: 56(84) bytes of data.

64 bytes from 10.10.10.21: icmp_seq=1 ttl=62 time=0.499 ms

tcpdump

IP 10.20.200.1 > 10.10.10.1: IP 5.5.5.5 > 10.10.10.21: ICMP echo request, id 48401, seq 1, length 64

IP 10.10.10.21 > 5.5.5.5: ICMP echo reply, id 48401, seq 1, length 64

Тут все нормально

******************************************************

если дописать route add -host 10.10.10.21 dev tun0 то будет все тоже самое но в графе пинга:

PING 10.10.10.21 (10.10.10.21) 56(84) bytes of data.

просто пустая строка

Если теперь пропинговать 5.5.5.5 c 10.10.10.21 то будет следующий tcpdump

IP 10.10.10.21 > 5.5.5.5: ICMP echo request, id 5449, seq 25, length 64

IP 10.10.10.21 > 5.5.5.5: ICMP echo request, id 5449, seq 25, length 64

Громоздко получилось, но уж как есть iptables выключил

Есть сеть состоящая из компа К1, роутера Р1, компа К2.
----------------------------------------------------------------------------------------------------------------------------
Роутер
eth0 10.20.200.2/24
eth1 10.10.10.1/24
tun1 Ip 5.5.5.1
src 10.10.10.1
dst 10.20.200.1
----------------------------------------------------------------------------------------------------------------------------
Комп 2
eth0 10.10.10.21
----------------------------------------------------------------------------------------------------------------------------
Конфигурация К1:
sysctl -a | grep forward | grep v4
net.ipv4.conf.all.forwarding = 1
net.ipv4.conf.all.mc_forwarding = 0
net.ipv4.conf.default.forwarding = 1
net.ipv4.conf.default.mc_forwarding = 0
net.ipv4.conf.lo.forwarding = 1
net.ipv4.conf.lo.mc_forwarding = 0
net.ipv4.conf.eth0.forwarding = 1
net.ipv4.conf.eth0.mc_forwarding = 0
net.ipv4.conf.gre0.forwarding = 1
net.ipv4.conf.gre0.mc_forwarding = 0
net.ipv4.conf.tun0.forwarding = 1
net.ipv4.conf.tun0.mc_forwarding = 0
net.ipv4.ip_forward = 1
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
ifconfig
eth0 10.20.200.1 255.255.255.0
tun0 5.5.5.5 255.255.255.0
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
ip tunnel show tun0
tun0: ip/ip remote 10.10.10.1 local 10.20.200.1 ttl 255
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
5.5.5.0 * 255.255.255.0 U 0 0 0 tun0
10.20.200.0 * 255.255.255.0 U 0 0 0 eth0
default 10.20.200.2 0.0.0.0 UG 0 0 0 eth0
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
ping 10.10.10.21 -I tun0
PING 10.10.10.21 (10.10.10.21) from 5.5.5.5 tun0: 56(84) bytes of data.
64 bytes from 10.10.10.21: icmp_seq=1 ttl=62 time=0.499 ms
tcpdump
IP 10.20.200.1 > 10.10.10.1: IP 5.5.5.5 > 10.10.10.21: ICMP echo request, id 48401, seq 1, length 64
IP 10.10.10.21 > 5.5.5.5: ICMP echo reply, id 48401, seq 1, length 64
Тут все нормально
****************************************************************************************************************************
если дописать route add -host 10.10.10.21 dev tun0 то будет все тоже самое но в графе пинга:
PING 10.10.10.21 (10.10.10.21) 56(84) bytes of data.
просто пустая строка
Если теперь пропинговать 5.5.5.5 c 10.10.10.21 то будет следующий tcpdump
IP 10.10.10.21 > 5.5.5.5: ICMP echo request, id 5449, seq 25, length 64
IP 10.10.10.21 > 5.5.5.5: ICMP echo request, id 5449, seq 25, length 64

А разве тунель не должен с двух концов настраиваться? На K2 не поднят тунель.

Туннель настроен между роутером и К1, на К2 приходят уже чистые пакеты без второй шапки Ip. Незнаю, возможно не обязательно на К2 туннель. В любом случае если писать
ping 10.10.10.21 -I tun0
то все нормально работает. Значит наверно на К2 не нужен тунельный интерфейс

Откройте для себя тэг [code] и www.linux.org.ru/wiki/en/Lorcode

Какието идеи есть?

Сорри, времени нет в это въезжать. Могу только задавать наводящие вопросы.

Туннель работает когда ты пингуешь с одного конца туннеля другой?

Пакеты приходят но пинг пустой.
ping 5.5.5.1
PING 5.5.5.1 (5.5.5.1) 56(84) bytes of data
пустая строка типа висит
tcpdump
IP 10.20.200.1 > 10.10.10.1: IP 5.5.5.5 > 5.5.5.1: ICMP echo request, id 16909, seq 1, length 64
IP 5.5.5.1 > 5.5.5.5: ICMP echo reply, id 16909, seq 1, length 64

Давай хотя бы через наводящие вопросы.
Слышал еще про такназываемый rt_filter

Может приходящий пакет тупо отбрасывается? Поэтому пинг и молчит

У тебя обратно пинги приходят неэнкапсулированные в туннель (видишь это в дампе?). Т.е. туннель настроен неправильно.

То что приходят не инкапсулированые мне подходит, здесь проблем нет, я так понял что они по какой либо причине отбрасываются? А вобще тунельный интерфейс будет выпускать инкапсулированные пакеты если на вход приходят без инкапсуляции?

То что приходят не инкапсулированые мне подходит

Мужик, у тебя туннель криво работает (отсюда и все беды), а ты «мне подходит» :).

А вобще тунельный интерфейс будет выпускать инкапсулированные пакеты если на вход приходят без инкапсуляции?

Первое правило сетевика: делай всё грамотно, иначе никогда не знаешь когда возникнут проблемы. Вот тебе сейчас трахацца не надоело с сетью?

Формально так можно сделать, но только если ты абсолютно знаешь что делаешь.

И как же это формально зделать. Ситуация сложная нужно что б приходили пакеты именно не инкапсулированные. Это вобще реально оформить?

Пришло время рассказать о том что ты хочешь получить. Т.е. об изначальной задаче которая стоит.