| 0
- 22.12.2013 - 10:16
|
Приветствую! Речь о редиректах по портам. Задачи: пробрасывать подключения извне (WAN-asterisk) пробрасывать подключения внутри (LAN-asterisk) пробрасывать подключения внутри, но с dst WAN на asterisk (цель - сохранить в настройках клиентов внешнее dns-имя хоста, чтобы не перенастраивать клиентов при подключениях внутри/снаружи) Картинке: [URL=http://piccy.info/view3/5631492/dcada1009a3045c15f7fe8662054c05f/][IMG]http://i.piccy.info/i9/b18df46c3c85e42529580f01f9aa3625/1387696503/7557/668216/1_500.jpg[/IMG][/URL][URL=http://i.piccy.info/a3c/2013-12-22-07-15/i9-5631492/500x281-r][IMG]http://i.piccy.info/a3/2013-12-22-07-15/i9-5631492/500x281-r/i.gif[/IMG][/URL] [URL=http://piccy.info/view3/5631494/53547293b4ee806ddd79dcaa2c86b367/][IMG]http://i.piccy.info/i9/7c0cf58102f4a67c708b275c4a0749b8/1387696525/17096/668216/2_500.jpg[/IMG][/URL][URL=http://i.piccy.info/a3c/2013-12-22-07-15/i9-5631494/500x216-r][IMG]http://i.piccy.info/a3/2013-12-22-07-15/i9-5631494/500x216-r/i.gif[/IMG][/URL] Проблема: при использовании UDP-транспорта все четко работает, при использовании TCP - изнутри (lan), при dst=WAN (dns-имя внешнего интерфейса) request timeout. ПО - zoiper, на андроидах.     | |
| 1
- 22.12.2013 - 19:04
|
не совсем понял... [quote=Фанат NASCAR;33433666]пробрасывать подключения извне (WAN-asterisk)[/quote] при пробросе извне правило на внешнем интерфейсе разрешить на внутр адрес должно быть в rules, он делает сам при создании rdr с keep-state поэтому больше нигде ничего добавлять не надо [quote=Фанат NASCAR;33433666]пробрасывать подключения внутри (LAN-asterisk)[/quote] не понял фразы [quote=Фанат NASCAR;33433666]пробрасывать подключения внутри, но с dst WAN на asterisk (цель - сохранить в настройках клиентов внешнее dns-имя хоста, чтобы не перенастраивать клиентов при подключениях внутри/снаружи)[/quote] nat reflection в advanced по-моему т.е. если dns астера висит на wan pf-а, а клиент натится наружу через этот же pf то его перекинет согласно правилам reirect-а когда он обратится на wan алрес изнутри и в догонку на pf-е есть freeswitch можно на нем попробовать организовать стык с астером, на крайняк а так уточни, что именно не получается | |
| 2
- 22.12.2013 - 19:10
| и да , может астер сам по себе только с udp работает ? в принципе для rtp траффика это нормально или имеется в виду sip ? вобщем я б смотрел на настройки астера впервую очередь, с pf-м проблем по-дефолту обычно не бывает редиректы делает корректно, nat reflection включен, на крайняк можно посмотреть tcpdump-ом на внутр\внешнем интерфейсе что куда влетает и откуда вылетает(ли) | |
| 3
- 22.12.2013 - 19:13
| а есть у него ещё пара интересных галок это reply-to чтоб отвечать через тот интерфейс откуда прилетело в принципе нужно только при двух и более каналах наружу, в остальных случаях мешает, и разрешить роутить в тот же интерфес откуда прилетело, все это где-то в advanced, эти галки я б поправил, но опятьже вначале tcpdump, чтоб понять что откуда и куда недолетает | |
| 4
- 22.12.2013 - 19:27
|
плин отвлекают.... внутри лучше вообще в dns прописать на внутр адрес | |
| 5
- 22.12.2013 - 19:37
| в смысде добавить A запись одного узла asterisk.domain.com на local.ip , на томже pf-е если он для LAN-клиентов dns это делается как за здрасте и не нужны никакие редиректы изнутри. | |
| 6
- 22.12.2013 - 20:06
|
[quote=701054;33439650]при пробросе извне правило на внешнем интерфейсе разрешить на внутр адрес должно быть в rules, он делает сам при создании rdr с keep-state поэтому больше нигде ничего добавлять не над[/quote] не понял фразы)) что не надо добавлять было? все строчки нужны, всем есть объяснение. [quote=701054;33439650]не понял фразы[/quote] клиенты внутри сети ломятся на шлюз (192.168.0.1) от отправляет на sip-сервер (192.168.0.5) [quote=701054;33439650]nat reflection в advanced по-моему т.е. если dns астера висит на wan pf-а, а клиент натится наружу через этот же pf то его перекинет согласно правилам reirect-а когда он обратится на wan алрес изнутри[/quote] dns на другом сервере, для других задач, поэтому решил вот обойтись другими средствами. С udp же работает? [quote=701054;33439726]и да , может астер сам по себе только с udp работает ?[/quote] нет, снаружи по обоим подрубается, как и изнутри если напрямую к серверу (0.5) [quote=701054;33439760] вначале tcpdump, чтоб понять что откуда и куда недолетает[/quote] да время на него не было, думал на лету подскажет кто про днс понятно, но он на другом сервере, там он автоматичен.. по своим движениям)) лезть ручками неохота, думал на шлюзе правилами поправлю Цель: изнутри сети (0.12) прилетает пакет на sip.company.ru:sip/10000-20000 tcp/udp, где адрес есть внешний интерфейс (wan) этого же шлюза. По этим совпадениям пакет отправляется на 0.5 (астериск). Повторю - с UDP работает. Нужно, чтобы в настройках зойперов было написано sip.company.ru и пздтс, и хочется tcp | |
| 7
- 22.12.2013 - 20:26
|
[quote=Фанат NASCAR;33440537]клиенты внутри сети ломятся на шлюз (192.168.0.1) от отправляет на sip-сервер (192.168.0.5)[/quote] если я правильно понимаю, то клиенты ломятся не на 192.168.0.1, а на wan адрес через шлюз 192.168.0.1 должен отработать nat reflection и redirect и т.д.(redirect wan->192.168.0.5) по-идее, если же они ломятся именно на 192.168.0.1 то надо создать перенаправление на LAN интерфесе(192.168.0.1 протокол\порты->192.168.0.5 протокол\порты) , кстати можно попробовать ,если и не отрабатывает nat reflection тоже самое залепить именно на LAN интерфейсе только wanip->192.168.0.5 тут не уверен, надо проверять. и ещё с tcp имхо надо смотреть tcpdump-ом очень возможна ситуация, что клиент шлет на wan.ip, пакет заворачивается на pf-е, но ответ ему летит от 192.168.0.5 или 192.168.0.1 и tcp сессия рассыпается. | |
| 8
- 22.12.2013 - 20:49
|
из мануала [quote] Диапазон портов содержащий более 500 портов не будет включаться в зеркальный NAT, а 1:1 NAT не поддерживается. Разделение DNS является единственным средством размещения больших диапазонов портов и 1:1 NAT. [/quote] | |
| 9
- 22.12.2013 - 20:54
| Хотя учитывая что rtp трафф это udp, то 10000:20000 порты не нужны tcpшные, только sip-вый 5060 , но судя из описалово могут полезть грабли, они ниче не гарантируют свыше 500 портов, в общем pf не так гибок как хотелось бы, я б для избежания геммора всетаки разделил dns это и проще и лучше | |
| 10
- 22.12.2013 - 21:08
|
[quote=701054;33440802] 192.168.0.1, а на wan адрес через шлюз 192.168.0.1 должен отработать nat reflection и redirect и т.д.[/quote] с этим все в порядке как раз, и tcp и udp работает. Я говорю о ситуации когда они с гостиницы приезжают в офис, смартфон ловит местный wifi, они оказываются в одной локальной сети с астериском и шлюзом. Зойпер ломится на sip.company.ru, шлюз принимает запрос на LAN, обнаруживает правило - редирект если на LAN и dst=WAN_Addr (sip.company.ru=WAN_Addr) и редиректит на астериск. UDP так работает. TCP нет, и с логах астериска намека нет. [quote=701054;33441094]но ответ ему летит от 192.168.0.5 или 192.168.0.1 и tcp сессия рассыпается[/quote] да, буду смотреть как попаду туда. Через неделю ) | |
| 11
- 22.12.2013 - 21:10
|
[quote=701054;33441159] rtp трафф это udp, то 10000:20000 порты не нужны tcpшные[/quote] ну, вообще как я понял rtp как раз по tcp и работает, то есть умеет. И за счет "встроенной" поддержки tcp ядром ондроеда, происходит оптимизация и наблюдаецо долгоживучесть батареек. Но суть даже не в батарейках - удп оказался заблочен в первой же гостинице, откуда сотрудних пытался выйти на связь) | |
| 12
- 22.12.2013 - 21:36
|
дык это оно и есть ))) когда они в офисе то пакет летит от 192.168.0.x(для sip.company.ru)->192.168.0.1-> тут отрабатывает nat reflection он с lan интерфейса заворачивает на 127.0.0.1 (таких правил он рожает сам глядя на то что прописано в редиректе, и это как раз и есть nat reflection оно же зеркалирование оно же с ограничением до 500 портов - один порт - одно правило), а оттуда уже ->по идее дальше пакет летит от 192.168.0.1(для 192.168.0.5) , но вся эта кривая чихарда не совсем для меня понятна именно на pfsense , вообще я такое делал руками один раз на чистом packet filter-е, после чего очень полюбил iptables и уже не вспомню всю эту порнографию в подробностях ))) прелесть pf-a в том, что там это одна галочка, а внутри черти роятся, дык вот с чертями этими лучше не связываться ))) | |
| 13
- 22.12.2013 - 21:38
| tcp - это совсем не кайф для траффика реального времени особо на загруженных каналах, может и работает не буду спорить т.к. просто не знаю, но везде где встречалось - все на udp | |
| 14
- 22.12.2013 - 21:58
| а ну да работает...гугл знает все....про pf загадка, сча слазил, вижу как он reflect-м наделал на 127.0.0.1 на порты начиная с 19000 , а чем он оттуда двигает в LAN не пойму. кто знает расскажите | |
| 15
- 22.12.2013 - 22:15
|
а плин...нашел /var/etc/inetd.conf 19000 stream tcp nowait/0 nobody /usr/bin/nc nc -w 2000 ip.ad.re.s port говорю же порнография, лучше не связываться ) | |
| 16
- 22.12.2013 - 22:27
| а трафф сиповый имхо лучше прятать в vpn ну или играться хотяб с шифрованием SIPS\SRTP и т.д., т.к. никогда мобильными клиентами не игрался, то vpn... | |
| 17
- 22.12.2013 - 22:37
| если вкратце, то красиво и легко похоже не выйдет, pfsense не даст штатными средствами сделать зеркалирование 10000 портов, можно конечно руками набить inetd и накидать redirect-в или ещё как-нить извратится, загляни в /var/etc/inetd.conf и сделай pfctl -sa | grep PFREFLECT , думаю многое прояснится , скорее всего там не все что прописано в rdr | |
| 18
- 22.12.2013 - 22:38
| вернее даже не 10000, а 20002 портов - 10000 tcp+10000udp+sip tcp/udp | |
| 19
- 22.12.2013 - 23:25
| есть ещё один грязный способ заставить это работать - поднять ещё один любой интерфейс на pfsens скажем opt1 с ip 172.16.1.1/30 на lan сделать rdr то что летит на WAN_Addr на 172.16.1.1 , а на opt1 сделать rdr то что летит на 172.16.1.1 на 192.168.0.5 , минус в том что opt1 должен быть в up-е , я такое проделывал на фряхе, вместо opt1 использовал lo0, но pfsense через веб морду не даст пользовать lo0 | |
| 20
- 22.12.2013 - 23:27
| ну и не факт , что заработает, но что-то такое вспоминается | |
| 21
- 23.12.2013 - 16:53
|
[url]http://forum.pfsense.org/index.php/topic,70628.0.html[/url] Для корректного доступа из сети LAN на портфорвард WAN необходимо включить опцию System: Advanced: Firewall and NAT > Network Address Translation / NAT Reflection mode for port forwards | |
| 22
- 24.12.2013 - 11:11
|
20-701054 >21-No > спасибо парни, попробую вкурить чехарду с чертями) | |
Интернет-форум Краснодарского края и Краснодара |
