форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форум Открытые системы на сервере (Маршрутизация, NAT)
Изначальное сообщение		[ Отслеживать ]

"Перенаправление UDP траффика"	+/–
Сообщение от H1ghlander (ok) on 05-Окт-11, 23:38
есть: - клиент - шлюз - сервер Нужно, чтобы клиент посылал udp пакеты к шлюзу, а он перенаправлял эти пакеты серверу. Обмен udp пакетами должен происходить в обе стороны: от клиента к серверу и от сервера к клиенту. Все эти три ПК находятся в разных подсетях: клиент в инете, шлюз имеет реал ip (к которому обращается клиент) и vpn соединение с локалкой в которой находится сервер. Вот такая сложная схема. Сейчас мне удалось организовать перенаправление траффика от клиент к серверу, а обратно никак не выходит. Как это лучше осуществить.
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "Перенаправление UDP траффика"	+/–
Сообщение от reader (ok) on 06-Окт-11, 10:54
>[оверквотинг удален] > Нужно, чтобы клиент посылал udp пакеты к шлюзу, а он перенаправлял эти > пакеты серверу. Обмен udp пакетами должен происходить в обе стороны: от > клиента к серверу и от сервера к клиенту. Все эти три > ПК находятся в разных подсетях: клиент в инете, шлюз имеет реал > ip (к которому обращается клиент) и vpn соединение с локалкой в > которой находится сервер. > Вот такая сложная схема. > Сейчас мне удалось организовать перенаправление траффика от клиент к серверу, а обратно > никак не выходит. > Как это лучше осуществить. если сервер в серой сети, то помимо перенапровления nat нужен в целом вопрос не совсем понятен, серевер - это машина или демон?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	2. "Перенаправление UDP траффика"	+/–
	Сообщение от H1ghlander (ok) on 06-Окт-11, 12:08
	>[оверквотинг удален] >> клиента к серверу и от сервера к клиенту. Все эти три >> ПК находятся в разных подсетях: клиент в инете, шлюз имеет реал >> ip (к которому обращается клиент) и vpn соединение с локалкой в >> которой находится сервер. >> Вот такая сложная схема. >> Сейчас мне удалось организовать перенаправление траффика от клиент к серверу, а обратно >> никак не выходит. >> Как это лучше осуществить. > если сервер в серой сети, то помимо перенапровления nat нужен > в целом вопрос не совсем понятен, серевер - это машина или демон? да я догадываюсь, что он нужен. Вопрос в том, как делать нат, только тогда, когда мне срабатывает условие, что определенный ip идет на определенный порт. И какая последовательность действий, я просто не до конца могу понять как все эту будет происходить. И как вообще лучше осуществлять перенаправление траффика? Сервер - это железка, на которой крутиться сервис, через который нужно гонять звук по протоколу udp, в оба направления.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	3. "Перенаправление UDP траффика"	+/–
	Сообщение от YuryD (??) on 06-Окт-11, 13:13
	> Сервер - это железка, на которой крутиться сервис, через который нужно гонять > звук по протоколу udp, в оба направления. Гуглите по словам rtp proxy, или ищите sip/h.323 сервера с полным проксированием...
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	4. "Перенаправление UDP траффика"	+/–
	Сообщение от H1ghlander (ok) on 06-Окт-11, 14:58
	>> Сервер - это железка, на которой крутиться сервис, через который нужно гонять >> звук по протоколу udp, в оба направления. >  Гуглите по словам rtp proxy, или ищите sip/h.323 сервера с полным > проксированием... Я посмотрел на счет rtp proxy и не понял, как мне это поможет?? Я пробовал экспериментировать с этой программой http://linux.die.net/man/8/rtpproxy. Объясни хотя бы принципы работы rtp proxy и как он мне может помочь в моем случае. И у звук ходит не по сиповскому протоколу.
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	5. "Перенаправление UDP траффика"	+/–
	Сообщение от YuryD (??) on 06-Окт-11, 15:19
	> Объясни хотя бы принципы работы rtp proxy и как он мне может > помочь в моем случае. > И у звук ходит не по сиповскому протоколу. В протоколах sip/h323 оконченые устройства обмениваются ip и портами, по которым будет идти речевой траффик. В приличных устройствах можно указывать прокси-сервер для речи, или использовать промежуточный сервер для полного проксирования сигнального и речевого траффика.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	6. "Перенаправление UDP траффика"	+/–
	Сообщение от H1ghlander (ok) on 06-Окт-11, 15:27
	>> Объясни хотя бы принципы работы rtp proxy и как он мне может >> помочь в моем случае. >> И у звук ходит не по сиповскому протоколу. >  В протоколах sip/h323 оконченые устройства обмениваются ip и портами, по которым > будет идти речевой траффик. В приличных устройствах можно указывать прокси-сервер для > речи, или использовать промежуточный сервер для полного проксирования сигнального и речевого > траффика. я же говорю у меня не сип, и нету никаких устройств в которых можно прописать прокси сервер.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	7. "Перенаправление UDP траффика"	+/–
	Сообщение от reader (ok) on 06-Окт-11, 15:42
	>>> Объясни хотя бы принципы работы rtp proxy и как он мне может >>> помочь в моем случае. >>> И у звук ходит не по сиповскому протоколу. >>  В протоколах sip/h323 оконченые устройства обмениваются ip и портами, по которым >> будет идти речевой траффик. В приличных устройствах можно указывать прокси-сервер для >> речи, или использовать промежуточный сервер для полного проксирования сигнального и речевого >> траффика. > я же говорю у меня не сип, и нету никаких устройств в > которых можно прописать прокси сервер. какая ОС? сервер будет инициировать соединение или только отвечать на запросы клиента? Multicast?
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	8. "Перенаправление UDP траффика"	+/–
	Сообщение от H1ghlander (ok) on 06-Окт-11, 16:18
	>[оверквотинг удален] >>>> И у звук ходит не по сиповскому протоколу. >>>  В протоколах sip/h323 оконченые устройства обмениваются ip и портами, по которым >>> будет идти речевой траффик. В приличных устройствах можно указывать прокси-сервер для >>> речи, или использовать промежуточный сервер для полного проксирования сигнального и речевого >>> траффика. >> я же говорю у меня не сип, и нету никаких устройств в >> которых можно прописать прокси сервер. > какая ОС? > сервер будет инициировать соединение или только отвечать на запросы клиента? > Multicast? На сервере fedora На шлюзе debian Сервер отвечает на запросы.
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	9. "Перенаправление UDP траффика"	+/–
	Сообщение от reader (ok) on 06-Окт-11, 16:53
	>[оверквотинг удален] >>>> речи, или использовать промежуточный сервер для полного проксирования сигнального и речевого >>>> траффика. >>> я же говорю у меня не сип, и нету никаких устройств в >>> которых можно прописать прокси сервер. >> какая ОС? >> сервер будет инициировать соединение или только отвечать на запросы клиента? >> Multicast? > На сервере fedora > На шлюзе debian > Сервер отвечает на запросы. тогда перенаправляются только пакеты идущие от клиента из инета, ответы автоматом пройдут обратное преобразование на шлюзе, но это если unicast
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	10. "Перенаправление UDP траффика"	+/–
	Сообщение от H1ghlander (ok) on 06-Окт-11, 17:05
	>[оверквотинг удален] >>>> я же говорю у меня не сип, и нету никаких устройств в >>>> которых можно прописать прокси сервер. >>> какая ОС? >>> сервер будет инициировать соединение или только отвечать на запросы клиента? >>> Multicast? >> На сервере fedora >> На шлюзе debian >> Сервер отвечает на запросы. > тогда перенаправляются только пакеты идущие от клиента из инета, ответы автоматом пройдут > обратное преобразование на шлюзе, но это если unicast это я понимаю. Но как правильнее нужно перенапрявлять. Можно привести примеры необходимых правил .
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	11. "Перенаправление UDP траффика"	+/–
	Сообщение от reader (ok) on 06-Окт-11, 17:11
	>[оверквотинг удален] >>>> какая ОС? >>>> сервер будет инициировать соединение или только отвечать на запросы клиента? >>>> Multicast? >>> На сервере fedora >>> На шлюзе debian >>> Сервер отвечает на запросы. >> тогда перенаправляются только пакеты идущие от клиента из инета, ответы автоматом пройдут >> обратное преобразование на шлюзе, но это если unicast > это я понимаю. Но как правильнее нужно перенапрявлять. > Можно привести примеры необходимых правил . https://www.opennet.ru/docs/RUS/iptables/#DNATTARGET там же показано, не понял в чем трудность, ну и правила в таблице фильтров
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	12. "Перенаправление UDP траффика"	+/–
	Сообщение от reader (ok) on 06-Окт-11, 17:14
	>[оверквотинг удален] >>>> На сервере fedora >>>> На шлюзе debian >>>> Сервер отвечает на запросы. >>> тогда перенаправляются только пакеты идущие от клиента из инета, ответы автоматом пройдут >>> обратное преобразование на шлюзе, но это если unicast >> это я понимаю. Но как правильнее нужно перенапрявлять. >> Можно привести примеры необходимых правил . > https://www.opennet.ru/docs/RUS/iptables/#DNATTARGET > там же показано, не понял в чем трудность, ну и правила в > таблице фильтров вывод iptables-save, адреса, порты и условия озвучте
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	13. "Перенаправление UDP траффика"	+/–
	Сообщение от H1ghlander (ok) on 06-Окт-11, 17:56
	>[оверквотинг удален] >>>>> На шлюзе debian >>>>> Сервер отвечает на запросы. >>>> тогда перенаправляются только пакеты идущие от клиента из инета, ответы автоматом пройдут >>>> обратное преобразование на шлюзе, но это если unicast >>> это я понимаю. Но как правильнее нужно перенапрявлять. >>> Можно привести примеры необходимых правил . >> https://www.opennet.ru/docs/RUS/iptables/#DNATTARGET >> там же показано, не понял в чем трудность, ну и правила в >> таблице фильтров > вывод iptables-save, адреса, порты и условия озвучте Сейчас никаких особых правил не установлено, так как я делал перенаправлнение с помощью различных утилит. адрес роутера - некий real ip адрес шлюза который висит за роутером в dmz имеет адрес внутренний сети 192.168.1.7 и адрес vpn подключения 10.10.10.2 адрес сервера имеет один интерфейс 192.168.254.44 условие такое, когда на шлюз приходит udp трафик с портом назначения в диапазоне 1000:2000, перенапрявлять его на сервер.
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	14. "Перенаправление UDP траффика"	+/–
	Сообщение от reader (ok) on 06-Окт-11, 20:12
	>[оверквотинг удален] >>> таблице фильтров >> вывод iptables-save, адреса, порты и условия озвучте > Сейчас никаких особых правил не установлено, так как я делал перенаправлнение с > помощью различных утилит. > адрес роутера - некий real ip > адрес шлюза который висит за роутером в dmz имеет адрес внутренний сети > 192.168.1.7 и адрес vpn подключения 10.10.10.2 > адрес сервера имеет один интерфейс 192.168.254.44 > условие такое, когда на шлюз приходит udp трафик с портом назначения в > диапазоне 1000:2000, перенапрявлять его на сервер. какую роль тут vpn выполняет? на 192.168.1.7 маршрут к 192.168.254.44 должен быть прописан. 192.168.254.44 в инет должен идти через 192.168.1.7, если это не так - предупреждайте. iptables -t nat -I PREROUTING -p udp -d real_ip --sport 1000:2000 -j DNAT --to-destination 192.168.254.44 iptables -I FORWARD -p udp -d 192.168.254.44 --sport 1000:2000 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT iptables -I FORWARD -p udp -s 192.168.254.44 --dport 1000:2000 -m state --state ESTABLISHED,RELATED -j ACCEPT
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	15. "Перенаправление UDP траффика"	+/–
	Сообщение от reader (ok) on 06-Окт-11, 20:22
	>[оверквотинг удален] > какую роль тут vpn выполняет? > на 192.168.1.7 маршрут к 192.168.254.44 должен быть прописан. > 192.168.254.44 в инет должен идти через 192.168.1.7, если это не так - > предупреждайте. > iptables -t nat -I PREROUTING -p udp -d real_ip --sport 1000:2000 -j > DNAT --to-destination 192.168.254.44 > iptables -I FORWARD -p udp -d 192.168.254.44 --sport 1000:2000 -m state --state > NEW,ESTABLISHED,RELATED -j ACCEPT > iptables -I FORWARD -p udp -s 192.168.254.44 --dport 1000:2000 -m state --state > ESTABLISHED,RELATED -j ACCEPT и в /proc/sys/net/ipv4/ip_forward  должна быть 1
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	16. "Перенаправление UDP траффика"	+/–
	Сообщение от H1ghlander (ok) on 06-Окт-11, 20:51
	>[оверквотинг удален] > какую роль тут vpn выполняет? > на 192.168.1.7 маршрут к 192.168.254.44 должен быть прописан. > 192.168.254.44 в инет должен идти через 192.168.1.7, если это не так - > предупреждайте. > iptables -t nat -I PREROUTING -p udp -d real_ip --sport 1000:2000 -j > DNAT --to-destination 192.168.254.44 > iptables -I FORWARD -p udp -d 192.168.254.44 --sport 1000:2000 -m state --state > NEW,ESTABLISHED,RELATED -j ACCEPT > iptables -I FORWARD -p udp -s 192.168.254.44 --dport 1000:2000 -m state --state > ESTABLISHED,RELATED -j ACCEPT Видимо я немного не понятно объяснил. Сейчас попробую немного прояснить. 192.168.1.7 и 192.168.254.44 находятся в разных сетях 192.168.1.0/24 - это сеть в городе №1. 192.168.254.0/24 - это сеть в города №2. эти две сети связаны между собой с помощью pptp соединения, поднятого на шлюзе. VPN сервер находится в городе №2, подсеть для vpn сети 10.10.10.0/24, с помощью каких-то маршрутизаторов она линкуется с сетью 192.168.254.0/24. на 192.168.1.7 маршрут к 192.168.254.44 - маршрут конечно прописан
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	17. "Перенаправление UDP траффика"	+/–
	Сообщение от reader (ok) on 06-Окт-11, 21:06
	>[оверквотинг удален] >> iptables -I FORWARD -p udp -s 192.168.254.44 --dport 1000:2000 -m state --state >> ESTABLISHED,RELATED -j ACCEPT > Видимо я немного не понятно объяснил. Сейчас попробую немного прояснить. > 192.168.1.7 и 192.168.254.44 находятся в разных сетях > 192.168.1.0/24 - это сеть в городе №1. > 192.168.254.0/24 - это сеть в города №2. > эти две сети связаны между собой с помощью pptp соединения, поднятого на > шлюзе. VPN сервер находится в городе №2, подсеть для vpn сети > 10.10.10.0/24, с помощью каких-то маршрутизаторов она линкуется с сетью 192.168.254.0/24. > на 192.168.1.7 маршрут к 192.168.254.44 - маршрут конечно прописан а на vpn-сервере маршрут к 192.168.1.7 есть? с 192.168.254.44 есть соединение с 192.168.1.7?
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	18. "Перенаправление UDP траффика"	+/–
	Сообщение от H1ghlander (ok) on 06-Окт-11, 21:20
	>[оверквотинг удален] >> Видимо я немного не понятно объяснил. Сейчас попробую немного прояснить. >> 192.168.1.7 и 192.168.254.44 находятся в разных сетях >> 192.168.1.0/24 - это сеть в городе №1. >> 192.168.254.0/24 - это сеть в города №2. >> эти две сети связаны между собой с помощью pptp соединения, поднятого на >> шлюзе. VPN сервер находится в городе №2, подсеть для vpn сети >> 10.10.10.0/24, с помощью каких-то маршрутизаторов она линкуется с сетью 192.168.254.0/24. >> на 192.168.1.7 маршрут к 192.168.254.44 - маршрут конечно прописан > а на vpn-сервере маршрут к 192.168.1.7 есть? с 192.168.254.44 есть соединение с > 192.168.1.7? нету. они соединяются через интернет.
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	19. "Перенаправление UDP траффика"	+/–
	Сообщение от reader (ok) on 06-Окт-11, 21:49
	>[оверквотинг удален] >>> 192.168.1.7 и 192.168.254.44 находятся в разных сетях >>> 192.168.1.0/24 - это сеть в городе №1. >>> 192.168.254.0/24 - это сеть в города №2. >>> эти две сети связаны между собой с помощью pptp соединения, поднятого на >>> шлюзе. VPN сервер находится в городе №2, подсеть для vpn сети >>> 10.10.10.0/24, с помощью каких-то маршрутизаторов она линкуется с сетью 192.168.254.0/24. >>> на 192.168.1.7 маршрут к 192.168.254.44 - маршрут конечно прописан >> а на vpn-сервере маршрут к 192.168.1.7 есть? с 192.168.254.44 есть соединение с >> 192.168.1.7? > нету. они соединяются через интернет. к выше сказанному добавляете snat и разрешаем gre протокол. iptables -t nat -I POSTROUTING -o ppp+ -d 192.168.254.44 --sport 1000:2000 -j SNAT --to-source 10.10.10.2 iptables -I FORWARD -p 47 -j ACCEPT так же наверно понадобится подгрузить модули ip_nat_pptp ip_conntrack_pptp https://www.opennet.ru/openforum/vsluhforumID10/4246.html https://www.opennet.ru/base/net/gre_over_nat.txt.html
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	20. "Перенаправление UDP траффика"	+/–
	Сообщение от H1ghlander (ok) on 07-Окт-11, 09:59
	>[оверквотинг удален] >> нету. они соединяются через интернет. > к выше сказанному добавляете snat и разрешаем gre протокол. > iptables -t nat -I POSTROUTING -o ppp+ -d 192.168.254.44 --sport 1000:2000 -j > SNAT --to-source 10.10.10.2 > iptables -I FORWARD -p 47 -j ACCEPT > так же наверно понадобится подгрузить модули > ip_nat_pptp > ip_conntrack_pptp > https://www.opennet.ru/openforum/vsluhforumID10/4246.html > https://www.opennet.ru/base/net/gre_over_nat.txt.html Что-то не работает. вот вывод iptables-save # Generated by iptables-save v1.4.10 on Fri Oct  7 09:28:58 2011 *nat :PREROUTING ACCEPT [659:40607] :POSTROUTING ACCEPT [515:31482] :OUTPUT ACCEPT [515:31482] -A PREROUTING -d 192.168.1.7/32 -p udp -m udp --sport 1000:2000 -j DNAT --to-destination 192.168.254.44 -A POSTROUTING -d 192.168.254.44/32 -o ppp0 -p udp -m udp --sport 1000:2000 -j SNAT --to-source 10.10.10.2 COMMIT # Completed on Fri Oct  7 09:28:58 2011 # Generated by iptables-save v1.4.10 on Fri Oct  7 09:28:58 2011 *filter :INPUT ACCEPT [15266:1880466] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [13096:861996] -A FORWARD -p gre -j ACCEPT -A FORWARD -s 192.168.254.44/32 -p udp -m udp --dport 1000:2000 -m state --state RELATED,ESTABLISHED -j ACCEPT -A FORWARD -d 192.168.254.44/32 -p udp -m udp --sport 1000:2000 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT COMMIT # Completed on Fri Oct  7 09:28:58 2011 До сервера не доходят udp c тем портом назначения который ушел от клиента. Судя по показаниям счетчиков, некоторые правила срабатывают. В этом правиле iptables -t nat -I PREROUTING -p udp -d real_ip --sport 1000:2000 -j DNAT --to-destination 192.168.254.44 вместо real_ip что нужно прописывать, реальный ip который на роуторе или все-таки адрес шлюза во внутренний сети??
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	21. "Перенаправление UDP траффика"	+/–
	Сообщение от H1ghlander (ok) on 07-Окт-11, 11:30
	>[оверквотинг удален] > --state NEW,RELATED,ESTABLISHED -j ACCEPT > COMMIT > # Completed on Fri Oct  7 09:28:58 2011 > До сервера не доходят udp c тем портом назначения который ушел от > клиента. > Судя по показаниям счетчиков, некоторые правила срабатывают. > В этом правиле iptables -t nat -I PREROUTING -p udp -d real_ip > --sport 1000:2000 -j DNAT --to-destination 192.168.254.44 > вместо real_ip что нужно прописывать, реальный ip который на роуторе или все-таки > адрес шлюза во внутренний сети?? Вот так выглядит обмен когда клиент находится в одной локальной сети с сервером 10:59:27.159389 IP 192.168.254.44.57215 > 192.168.249.44.3889: UDP, length 74 10:59:27.166265 IP 192.168.249.44.3890 > 192.168.254.44.1217: UDP, length 74 10:59:27.179431 IP 192.168.254.44.57215 > 192.168.249.44.3889: UDP, length 74 10:59:27.185880 IP 192.168.249.44.3890 > 192.168.254.44.1217: UDP, length 74 10:59:27.199451 IP 192.168.254.44.57215 > 192.168.249.44.3889: UDP, length 74 10:59:27.206691 IP 192.168.249.44.3890 > 192.168.254.44.1217: UDP, length 74 10:59:27.219432 IP 192.168.254.44.57215 > 192.168.249.44.3889: UDP, length 74 10:59:27.225963 IP 192.168.249.44.3890 > 192.168.254.44.1217: UDP, length 74 10:59:27.239414 IP 192.168.254.44.57215 > 192.168.249.44.3889: UDP, length 74 10:59:27.246501 IP 192.168.249.44.3890 > 192.168.254.44.1217: UDP, length 74
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	22. "Перенаправление UDP траффика"	+/–
	Сообщение от H1ghlander (ok) on 07-Окт-11, 13:27
	>[оверквотинг удален] > 10:59:27.159389 IP 192.168.254.44.57215 > 192.168.249.44.3889: UDP, length 74 > 10:59:27.166265 IP 192.168.249.44.3890 > 192.168.254.44.1217: UDP, length 74 > 10:59:27.179431 IP 192.168.254.44.57215 > 192.168.249.44.3889: UDP, length 74 > 10:59:27.185880 IP 192.168.249.44.3890 > 192.168.254.44.1217: UDP, length 74 > 10:59:27.199451 IP 192.168.254.44.57215 > 192.168.249.44.3889: UDP, length 74 > 10:59:27.206691 IP 192.168.249.44.3890 > 192.168.254.44.1217: UDP, length 74 > 10:59:27.219432 IP 192.168.254.44.57215 > 192.168.249.44.3889: UDP, length 74 > 10:59:27.225963 IP 192.168.249.44.3890 > 192.168.254.44.1217: UDP, length 74 > 10:59:27.239414 IP 192.168.254.44.57215 > 192.168.249.44.3889: UDP, length 74 > 10:59:27.246501 IP 192.168.249.44.3890 > 192.168.254.44.1217: UDP, length 74 На шлюзе когда приходит udp пакет, сниффером я вижу такое: 12:44:49.076873 IP 195.96.93.179.61485 > 192.168.1.7.1223: UDP, length 28 12:44:49.076910 IP 192.168.1.7 > 195.96.93.179: ICMP 192.168.1.7 udp port 1223 unreachable, length 64N
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

	23. "Перенаправление UDP траффика"	+/–
	Сообщение от reader (ok) on 07-Окт-11, 21:50
	> вместо real_ip что нужно прописывать, реальный ip который на роуторе или все-таки > адрес шлюза во внутренний сети?? ваш внешний адрес, клиент на него обращается?
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	24. "Перенаправление UDP траффика"	+/–
	Сообщение от H1ghlander (ok) on 07-Окт-11, 23:10
	>> вместо real_ip что нужно прописывать, реальный ip который на роуторе или все-таки >> адрес шлюза во внутренний сети?? > ваш внешний адрес, клиент на него обращается? да, клиент обращается к real ip.
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	25. "Перенаправление UDP траффика"	+/–
	Сообщение от reader (ok) on 07-Окт-11, 23:15
	>>> вместо real_ip что нужно прописывать, реальный ip который на роуторе или все-таки >>> адрес шлюза во внутренний сети?? >> ваш внешний адрес, клиент на него обращается? > да, клиент обращается к real ip. вот и указывайте его в PREROUTING. потом tcpdump на ppp0, делаете обращение с клиента и смотрим что показал tcpdump
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	26. "Перенаправление UDP траффика"	+/–
	Сообщение от H1ghlander (ok) on 10-Окт-11, 09:59
	>>>> вместо real_ip что нужно прописывать, реальный ip который на роуторе или все-таки >>>> адрес шлюза во внутренний сети?? >>> ваш внешний адрес, клиент на него обращается? >> да, клиент обращается к real ip. > вот и указывайте его в PREROUTING. потом tcpdump на ppp0, делаете обращение > с клиента и смотрим что показал tcpdump Сделал, результата не дало. tcpdump -nn -i ppp0 09:54:21.199359 IP 192.168.254.44.37688 > 10.10.10.2.37649: UDP, length 74 09:54:21.221322 IP 192.168.254.44.37688 > 10.10.10.2.37649: UDP, length 74 09:54:21.241321 IP 192.168.254.44.37688 > 10.10.10.2.37649: UDP, length 74 09:54:21.261312 IP 192.168.254.44.37688 > 10.10.10.2.37649: UDP, length 74 09:54:21.261362 IP 10.10.10.2 > 192.168.254.44: ICMP 10.10.10.2 udp port 37649 unreachable, length 110
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	27. "Перенаправление UDP траффика"	+/–
	Сообщение от reader (ok) on 10-Окт-11, 11:26
	>[оверквотинг удален] >> вот и указывайте его в PREROUTING. потом tcpdump на ppp0, делаете обращение >> с клиента и смотрим что показал tcpdump > Сделал, результата не дало. > tcpdump -nn -i ppp0 > 09:54:21.199359 IP 192.168.254.44.37688 > 10.10.10.2.37649: UDP, length 74 > 09:54:21.221322 IP 192.168.254.44.37688 > 10.10.10.2.37649: UDP, length 74 > 09:54:21.241321 IP 192.168.254.44.37688 > 10.10.10.2.37649: UDP, length 74 > 09:54:21.261312 IP 192.168.254.44.37688 > 10.10.10.2.37649: UDP, length 74 > 09:54:21.261362 IP 10.10.10.2 > 192.168.254.44: ICMP 10.10.10.2 udp port 37649 unreachable, > length 110 тут нет обращений с клиента с 1000:2000 портов, это вывод с самого начала обращения клиента? если да, то запустите tcpdump на внешнем интерфейсе и смотрите дошли ли до шлюза пакеты клиента. тут есть обращение с сервера , только на шлюзе этих пакетов никто не ждал, что это за пакеты? вы же писали что сервер будет отвечать на запросы, а тут сервер пытается установить соединение, так что же есть.
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	28. "Перенаправление UDP траффика"	+/–
	Сообщение от H1ghlander (ok) on 10-Окт-11, 11:37
	>[оверквотинг удален] >> 09:54:21.261362 IP 10.10.10.2 > 192.168.254.44: ICMP 10.10.10.2 udp port 37649 unreachable, >> length 110 > тут нет обращений с клиента с 1000:2000 портов, это вывод с самого > начала обращения клиента? > если да, то запустите tcpdump на внешнем интерфейсе и смотрите дошли ли > до шлюза пакеты клиента. > тут есть обращение с сервера , только на шлюзе этих пакетов никто > не ждал, что это за пакеты? > вы же писали что сервер будет отвечать на запросы, а тут сервер > пытается установить соединение, так что же есть. до шлюза пакеты доходят (я писал об этом ранее) 12:44:49.076873 IP 195.96.93.179.61485 > 192.168.1.7.1223: UDP, length 28 12:44:49.076910 IP 192.168.1.7 > 195.96.93.179: ICMP 192.168.1.7 udp port 1223 unreachable, length 64 но тут они и останавливаются. тут ситуация такая: что когда клиент обращается к серверу по udp порту 1000:2000 сервер принимает этот пакет, и отвечает на него пакетом с рандомным портом назначения.
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

	29. "Перенаправление UDP траффика"	+/–
	Сообщение от reader (ok) on 10-Окт-11, 12:03
	>[оверквотинг удален] >> если да, то запустите tcpdump на внешнем интерфейсе и смотрите дошли ли >> до шлюза пакеты клиента. >> тут есть обращение с сервера , только на шлюзе этих пакетов никто >> не ждал, что это за пакеты? >> вы же писали что сервер будет отвечать на запросы, а тут сервер >> пытается установить соединение, так что же есть. > до шлюза пакеты доходят (я писал об этом ранее) > 12:44:49.076873 IP 195.96.93.179.61485 > 192.168.1.7.1223: UDP, length 28 > 12:44:49.076910 IP 192.168.1.7 > 195.96.93.179: ICMP 192.168.1.7 udp port 1223 unreachable, > length 64 тут обращения на 1000:2000, а не с 1000:2000 , меняйте в правилах --sport 1000:2000 на --dport 1000:2000 и наоборот. > но тут они и останавливаются. > тут ситуация такая: что когда клиент обращается к серверу по udp порту > 1000:2000 сервер принимает этот пакет, и отвечает на него пакетом с > рандомным портом назначения. это уже не ответы на запросы, это уже сервер начинает соединение и эти пакеты через обратное преобразование автоматом не пойдут. если у клиента постоянный ip то можно для этих пакетов тоже проброс сделать, но это только для одного клиента
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

	30. "Перенаправление UDP траффика"	+/–
	Сообщение от H1ghlander (ok) on 10-Окт-11, 12:51
	>[оверквотинг удален] > тут обращения на 1000:2000, а не с 1000:2000 , меняйте в правилах > --sport 1000:2000 на --dport 1000:2000 и наоборот. >> но тут они и останавливаются. >> тут ситуация такая: что когда клиент обращается к серверу по udp порту >> 1000:2000 сервер принимает этот пакет, и отвечает на него пакетом с >> рандомным портом назначения. > это уже не ответы на запросы, это уже сервер начинает соединение и > эти пакеты через обратное преобразование автоматом не пойдут. > если у клиента постоянный ip то можно для этих пакетов тоже проброс > сделать, но это только для одного клиента поменял вывод tcpdump такой же. сейчас правила такие # Generated by iptables-save v1.4.10 on Mon Oct 10 12:49:06 2011 *nat :PREROUTING ACCEPT [243:14659] :POSTROUTING ACCEPT [126:8156] :OUTPUT ACCEPT [126:8156] -A PREROUTING -d 77.37.162.137/32 -p udp -m udp --dport 1000:2000 -j DNAT --to-destination 192.168.254.44 -A POSTROUTING -d 192.168.254.44/32 -o ppp0 -p udp -m udp --dport 1000:2000 -j SNAT --to-source 10.10.10.2 COMMIT # Completed on Mon Oct 10 12:49:06 2011 # Generated by iptables-save v1.4.10 on Mon Oct 10 12:49:06 2011 *filter :INPUT ACCEPT [90625:4997659] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [71603:194460515] -A FORWARD -d 192.168.254.44/32 -p udp -m udp --dport 1000:2000 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT -A FORWARD -s 192.168.254.44/32 -p udp -m udp --sport 1000:2000 -m state --state RELATED,ESTABLISHED -j ACCEPT COMMIT # Completed on Mon Oct 10 12:49:06 2011
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	31. "Перенаправление UDP траффика"	+/–
	Сообщение от reader (ok) on 10-Окт-11, 13:34
	>[оверквотинг удален] >> --sport 1000:2000 на --dport 1000:2000 и наоборот. >>> но тут они и останавливаются. >>> тут ситуация такая: что когда клиент обращается к серверу по udp порту >>> 1000:2000 сервер принимает этот пакет, и отвечает на него пакетом с >>> рандомным портом назначения. >> это уже не ответы на запросы, это уже сервер начинает соединение и >> эти пакеты через обратное преобразование автоматом не пойдут. >> если у клиента постоянный ip то можно для этих пакетов тоже проброс >> сделать, но это только для одного клиента > поменял вывод tcpdump такой же. всмысле как тут 12:44:49.076873 IP 195.96.93.179.61485 > 192.168.1.7.1223: UDP, length 28 12:44:49.076910 IP 192.168.1.7 > 195.96.93.179: ICMP 192.168.1.7 udp port 1223 кстати почему обращение на 192.168.1.7? tcpdump -n -i any host 192.168.254.44 or host 10.10.10.2 or host 192.168.1.7 or host внешний_ip and portrange 1000-2000 >[оверквотинг удален] > *filter > :INPUT ACCEPT [90625:4997659] > :FORWARD ACCEPT [0:0] > :OUTPUT ACCEPT [71603:194460515] > -A FORWARD -d 192.168.254.44/32 -p udp -m udp --dport 1000:2000 -m state > --state NEW,RELATED,ESTABLISHED -j ACCEPT > -A FORWARD -s 192.168.254.44/32 -p udp -m udp --sport 1000:2000 -m state > --state RELATED,ESTABLISHED -j ACCEPT > COMMIT > # Completed on Mon Oct 10 12:49:06 2011
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

	32. "Перенаправление UDP траффика"	+/–
	Сообщение от H1ghlander (ok) on 10-Окт-11, 15:01
	>[оверквотинг удален] >> *filter >> :INPUT ACCEPT [90625:4997659] >> :FORWARD ACCEPT [0:0] >> :OUTPUT ACCEPT [71603:194460515] >> -A FORWARD -d 192.168.254.44/32 -p udp -m udp --dport 1000:2000 -m state >> --state NEW,RELATED,ESTABLISHED -j ACCEPT >> -A FORWARD -s 192.168.254.44/32 -p udp -m udp --sport 1000:2000 -m state >> --state RELATED,ESTABLISHED -j ACCEPT >> COMMIT >> # Completed on Mon Oct 10 12:49:06 2011 почему обращение на 192.168.1.7 трудно сказать. клиент обращается к реал ip, который на роуторе, а он в свою очередь перенаправляет запрос на шлюз. tcpdump -n -i any host 192.168.254.44 or host 10.10.10.2 or host 192.168.1.7 or host внешний_ip and portrange 1000-2000 куча всяких tcp-шных пакетов, а по делу ничего нету.
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

	33. "Перенаправление UDP траффика"	+/–
	Сообщение от reader (ok) on 10-Окт-11, 15:33
	>[оверквотинг удален] >>> :FORWARD ACCEPT [0:0] >>> :OUTPUT ACCEPT [71603:194460515] >>> -A FORWARD -d 192.168.254.44/32 -p udp -m udp --dport 1000:2000 -m state >>> --state NEW,RELATED,ESTABLISHED -j ACCEPT >>> -A FORWARD -s 192.168.254.44/32 -p udp -m udp --sport 1000:2000 -m state >>> --state RELATED,ESTABLISHED -j ACCEPT >>> COMMIT >>> # Completed on Mon Oct 10 12:49:06 2011 > почему обращение на 192.168.1.7 трудно сказать. клиент обращается к реал ip, который > на роуторе, а он в свою очередь перенаправляет запрос на шлюз. проброс делается на шлюзе, который к инету подключен через роутер и 192.168.1.7 смотрит на роутер? 192.168.1.7 - это внешний адрес шлюза? если да, тогда в роуторе уже сделан проброс и тогда в PREROUTING -d 77.37.162.137/32 меняйте на -d 192.168.1.7 или в роуторе делать проброс не на 192.168.1.7, а сразу на 192.168.254.44 и прописать маршрут к 192.168.254.44 через 192.168.1.7 но это только первая часть. договор клиента и сервера > tcpdump -n -i any host 192.168.254.44 or host 10.10.10.2 or host 192.168.1.7 > or host внешний_ip and portrange 1000-2000 > куча всяких tcp-шных пакетов, а по делу ничего нету.
	Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

	34. "Перенаправление UDP траффика"	+/–
	Сообщение от reader (ok) on 10-Окт-11, 15:41
	>[оверквотинг удален] > проброс делается на шлюзе, который к инету подключен через роутер и 192.168.1.7 > смотрит на роутер? 192.168.1.7 - это внешний адрес шлюза? > если да, тогда в роуторе уже сделан проброс и тогда в PREROUTING > -d 77.37.162.137/32 меняйте на -d 192.168.1.7 > или в роуторе делать проброс не на 192.168.1.7, а сразу на 192.168.254.44 > и прописать маршрут к 192.168.254.44 через 192.168.1.7 > но это только первая часть. договор клиента и сервера >> tcpdump -n -i any host 192.168.254.44 or host 10.10.10.2 or host 192.168.1.7 >> or host внешний_ip and portrange 1000-2000 >> куча всяких tcp-шных пакетов, а по делу ничего нету. не проще ли что бы клиент подключался по vpn к серверу
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

	35. "Перенаправление UDP траффика"	+/–
	Сообщение от H1ghlander (ok) on 10-Окт-11, 15:57
	>[оверквотинг удален] >> смотрит на роутер? 192.168.1.7 - это внешний адрес шлюза? >> если да, тогда в роуторе уже сделан проброс и тогда в PREROUTING >> -d 77.37.162.137/32 меняйте на -d 192.168.1.7 >> или в роуторе делать проброс не на 192.168.1.7, а сразу на 192.168.254.44 >> и прописать маршрут к 192.168.254.44 через 192.168.1.7 >> но это только первая часть. договор клиента и сервера >>> tcpdump -n -i any host 192.168.254.44 or host 10.10.10.2 or host 192.168.1.7 >>> or host внешний_ip and portrange 1000-2000 >>> куча всяких tcp-шных пакетов, а по делу ничего нету. > не проще ли что бы клиент подключался по vpn к серверу на самом деле так сейчас и делается, но некоторым это не нравится, вот и пытаюсь осуществить перенаправления траффика
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	36. "Перенаправление UDP траффика"	+/–
	Сообщение от reader (ok) on 10-Окт-11, 16:12
	>[оверквотинг удален] >>> -d 77.37.162.137/32 меняйте на -d 192.168.1.7 >>> или в роуторе делать проброс не на 192.168.1.7, а сразу на 192.168.254.44 >>> и прописать маршрут к 192.168.254.44 через 192.168.1.7 >>> но это только первая часть. договор клиента и сервера >>>> tcpdump -n -i any host 192.168.254.44 or host 10.10.10.2 or host 192.168.1.7 >>>> or host внешний_ip and portrange 1000-2000 >>>> куча всяких tcp-шных пакетов, а по делу ничего нету. >> не проще ли что бы клиент подключался по vpn к серверу > на самом деле так сейчас и делается, но некоторым это не нравится, > вот и пытаюсь осуществить перенаправления траффика некоторым? то есть клиентов будет несколько? как вы собираетесь определять с кем сервер собирается установить соединение?
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема