| 0
- 04.03.2015 - 19:00
|
Никак не могу объять задачу и решить. Дано: 1) Кабель от поставщика SIP-телефонии заходит в офис. Описание процесса подключения от поставщика: 1. Звонки к нам с Вашего VoIP-шлюза должны приходить с адреса 172.16.209.106, где шлюз будет 172.16.209.105, маска 255.255.255.248 2. Наш Sip сервер на базе Сisco, работает в одноранговом режиме (Peer-to-peer). Используемый протокол h323 или SIP. Адрес VoIP-шлюза с нашей стороны = X1.X6.1X9.X4, порт 5060. Адрес очень похож на внешний. 2) В офисе есть машинка с FreeBSD. Воткнуто три кабеля - локалка (нас не интересует), интернет от другого поставщика (все работает) и кабель из п.1. Цитата:
Цитата:
Также есть клиентское соединение с п.3 3) VDS-сервер на внешнем ресурсе с IPPBX под Centos. Для соединения с сервером 2 используется OpenVPN. Он работает. Цитата:
Как его получить? штобэ пинговалсо     | | |||
| 1
- 04.03.2015 - 19:37
| работает в одноранговом режиме (Peer-to-peer) вот тов. droidman опять навесит на меня ярлык граммар-наци), но одноранговый режим и точка-точка немного из разных опер Мы имеем доступ к машине с freebsd(2) и локальной сети чесслово, не понимаю кто такое мы, и откуда и куда это мы имеет некий доступ | | |||
| 2
- 04.03.2015 - 20:10
|
недопонял ( Цитата:
| | |||
| 3
- 04.03.2015 - 20:30
|
2-701054 >я сам нихрена вникнуть не могу. но надо.. 1-gloomymen >нужно получить доступ с vds-сервера (3) через openvpn -> сервер (2) на фрибзде -> сервер X1.X6.1X9.X4 (1) поставщика услуги, по кабелю. Который воткнут в сервер (2). | | |||
| 4
- 04.03.2015 - 20:33
|
--iroute network [netmask] Generate an internal route to a specific client. The netmask parameter, if omitted, defaults to 255.255.255.255. This directive can be used to route a fixed subnet from the server to a particular client, regardless of where the client is connecting from. Remember that you must also add the route to the system routing table as well (such as by using the --route directive). The reason why two routes are needed is that the --route directive routes the packet from the kernel to OpenVPN. Once in OpenVPN, the --iroute directive routes to the specific client. This option must be specified either in a client instance config file using --client-config-dir or dynamically generated using a --client-connect script. The --iroute directive also has an important interaction with --push "route ...". --iroute essentially defines a subnet which is owned by a particular client (we will call this client A). If you would like other clients to be able to reach A's subnet, you can use --push "route ..." together with --client-to-client to effect this. In order for all clients to see A's subnet, OpenVPN must push this route to all clients EXCEPT for A, since the subnet is already owned by A. OpenVPN accomplishes this by not not pushing a route to a client if it matches one of the client's iroutes. | | |||
| 5
- 04.03.2015 - 20:45
| ну так нарисуйте маршруты, в чем загвоздка-то? | | |||
| 6
- 04.03.2015 - 21:02
|
push "route X1.X6.1X9.X4 255.255.255.255" точно лишний, как и client-to-client , если ток с серва надо попадать, и смотря что в оверрайдах в client-config-dir | | |||
| 7
- 04.03.2015 - 21:08
| кста iroute как раз там и должен в файле конкретного клиента как-то так и не должно быть push route на нем же...можно сбросить там же, для остальных клиентов оставить если надо. | | |||
| 8
- 04.03.2015 - 23:25
|
5-gloomymen >да лень видимо.. 6-701054 >в оверрайдах копия.. Кто возьмется удаленно помочь за пиво? Ну не занимаюсь я таким, блин..  | | |||
| 9
- 05.03.2015 - 10:00
|
push "route X1.X6.1X9.X4 255.255.255.255" убрать отовсюду(можно вместо этого в клиентском конфе написать push-reset сбросит все push мршруты основного конфа), в клентском конфиге добавить iroute X1.X6.1X9.X4 255.255.255.255 всё, ну ещё НАТ на интерфейсе 172.16.209.106 на фре по-идее нужен. Если совсем никак - стукнись в личку, но не факт что время сегодня будет глянуть... | | |||
| 10
- 05.03.2015 - 10:13
| вообще я так понимаю цель притянуть на vds , если vds выделен ток под них и адрес можно ещё один взять из 172.16.209.104/29, лучше было заморочиться с tap и bridge , ещё один адрес для бриджа чтоб проверять линк от vds до фри, а 106 прям на vds воткнуть нет заморочек с sip NAT-ом, думаю ток поставщик SIP-телефонии не слишком рад таким раскладам в любом случае )) | | |||
| 11
- 05.03.2015 - 11:37
|
10-701054 >Между VDS и фрей есть openvpn, он работает. Во фрю воткнут SIP-кабель, его надо заюзать в соответствии с требованиями поставщика услуги. Вот:  Как правильно это сделать? Прошу своими словами, типа алгоритма, описать - как оно правильно должно работать. Цель - понять и научиться, а не быстро сделать и забыть) | | |||
| 12
- 05.03.2015 - 11:38
| SIP очень хорошо работает с натингом. Прямо очень и очень хорошо. | | |||
| 13
- 05.03.2015 - 13:14
| с натом есть сложности на старых устройствах типа древних авай, по кр мере знакомый чет долго мудрил я в туда не лез...и наоборот убрал сип хелперы и сделал нат 1:1 на отдельном ип...насчет схемы есть принципиально 2 варианта или L2(которым можно сбриджевать физич порт от прова с интерфейсом VDS) или L3 соотв-но маршрутизация, как правильно зависит от задачи, т.к. sip то все таки L3 предпочтительнее, его можно фаерволить в каждой точке. | | |||
| 14
- 05.03.2015 - 13:18
|
+13 в случае с L3 SIP поставщик не знает, что 10.8.0.0 за 172.16.209.106 ему оно и не надо, так что тут только натить трафф от vds к сип прову в адрес 172.16.209.106 и наче не добежит в случае с L2 адрес 172.16.209.106 можно посадить на VDS и прозрачно гонять через ovpn как будто он воткнут напрямую к sip поставщику | | |||
| 15
- 05.03.2015 - 13:19
| Цитата:
| | |||
| 16
- 05.03.2015 - 13:25
| Цитата:
| | |||
| 17
- 05.03.2015 - 13:27
| Цитата:
| | |||
| 18
- 05.03.2015 - 21:13
| сейчас случайно наткнулся на SoftEther VPN...это надо увидеть...мож вообще окажитесь от конфов руками... | | |||
| 19
- 06.03.2015 - 14:32
|
Попробовал расписать задачу упрощенно Хост А - сервер на центось с сервером openvpn. На внешке (вдс). Хост Б - сервер на freeBSD, клиент openvpn по отношению к А. В хост Б воткнут допинтерфейс (сетевая карта), в которую воткнут кабель. Вот на этом кабеле находится хост С. Нам нужно с А добраться до С. Начнем с простого - как правильно это сделать схематически? | | |||
| 20
- 06.03.2015 - 14:41
|
я так вижу: с А на Б у нас опенвпн, и роут XX.XX.XX.XX 10.8.0.2 255.255.255.255 UGH 0 0 0 tun0 На Б у нас интерфейс (настроенный) с кабелем провайдера. Нам нужен на Б нат в сторону С? Какой нат? | | |||
| 21
- 06.03.2015 - 16:38
|
Смотря как SIP настроен, вполне возможно что со стороны прова просто кидает на 172.16.209.106:5060 без всяких регистраций и тому подобного, поэтому в общем случае лучше делать проброску того что прилетает(sip port + диапазон rtp) с C на Б пробрасывать на А (dst-nat оноже rdr) и соответственно то что летит с A к С натить(src-nat masquarade оноже во фре nat) в адрес Б. Так вот у фри у pf(packet filter) есть такая штука называется binat по другому называется нат 1:1 это сопоставление внутр адреса внешнему, все что летит с А на С натится в Б порты теже, все что прилетает на Б пробрасывается на А порты теже . + настроить ФВ, и ещё момент, что внутри SIP с А может передаваться ip А - лечится либо настройкой PBX (на астере с этим проблем нет ) или стороним хелпером, который перебирает sip. | | |||
| 22
- 06.03.2015 - 16:57
| +21 а ну то что обычно называется sip helper\sip alg на самом деле позволяет не делать проброски эта штука смотрит sip и динамически открывает rtp, но хз на тиках мне эта штука включеная по-умолчанию только мешала обычно. | | |||
| 23
- 06.03.2015 - 17:16
| 22-701054 >астеру sip helper/alg жутко мешает жить, он все что связано с натом передает сколько нужно в своих сип-пакетах. | |
Интернет-форум Краснодарского края и Краснодара |
