...

воскресенье, 6 апреля 2014 г.

Сервер VPN для организации телефонной связи удаленного офиса на базе АТС Panasonic TDE100

Доброе время суток.

Предлагаю еще одно решение, реализованное мной три месяца назад, и показавшее достаточную эффективность.

Эта статья предназначена для описания прикладного решения в выбранных условиях. Кроме того, как такового описания как решить мою проблему в одном месте я не нашел, поэтому решение результат поиска информации в различных источниках. Короче говоря, мало ли кому пригодится.

Итак, имеем:

Удаленный офис в другом городе, провайдер локальный, выделенного IP нет (назначается по DHCP провайдером).

Мини — АТС Panasonic KX-TDE100, с включенными лицензиями на внутренние VOIP Телефоны (16 штук) и SIP телефоны (16 штук). Так же в АТС установлены платы аналоговых телефонов 3*16 и на 16 входящих городских линий.

Телефон KX-NT321, находящийся в удаленном офисе.

Dlink DIR-300, с зашитым в нем DD-WRT, в удаленном офисе, для подключения к моему серверу VPN.

Картинка для привлечения внимания:

image



Сначала было желание реализовать сервер VPN на шлюзе FreeBSD, установив pptpd. Однако, как оказалось, в FreeBSD нужно патчить систему для поддержки mpd, чего на работающей системе делать совершенно не хотелось почему-то не взлетело.

Был установлен Ubuntu сервер 13.10. Далее, по порядку без описания своих метаний, приведу результат настройки:

sudo apt-get update && sudo apt-get upgrade
sudo apt-get install ppp pptpd




Приведу сетевые интерфейсы сервера:

ifconfig
eth0 Link encap:Ethernet HWaddr
inet addr:10.1.1.209 Bcast:10.1.1.255 Mask:255.255.255.0

eth1 Link encap:Ethernet HWaddr
inet addr:10.90.90.9 Bcast:10.90.90.255 Mask:255.255.255.0


eth1 смотрит наружу, eth0 локальная сеть. Адрес Мини-АТС 10.1.1.250.

Конфигурация pptp сервера в файлах:



cat pptpd-options
name pptpd
refuse-pap
refuse-chap
refuse-mschap
require-mschap-v2
require-mppe
ms-dns 8.8.8.8
nodefaultroute
lock
nobsdcomp




Надо сказать, что в конце файла должен быть EOF, иначе служба висит, загружая 99% процессорного времени. EOF это перевод строки и пустота.

cat chap-secrets
# Secrets for authentication using CHAP
# client server secret IP addresses
user1 pptpd mysecret 10.1.1.211
user2 pptpd mysecret 10.1.1.216




В файле жестко указаны IP адреса, однако можно задать назначение адресов автоматом, заменив IP адрес на "*". Кстати, ip-адреса по-незнанию выдал из своей-же сети, однако можно было писать все, что угодно.

Доступ с Windows к серверу я уже получил, используя белый IP-адрес, а вот с маршрутизатора доступа не было. Путем проб и ошибок был понижен релиз DD-WRT до 14896 (Firmware: DD-WRT v24-sp2 (08/07/10) std). На более высоких версиях не цеплялся ppp.

Настройка DIR-300:

1. Закладка Setup — advanced routing — Destination LAN NET 10.1.1.0 Netmask 255.255.255.0 Gateway 10.1.1.209.

Operating mode — router.

2. Закладка Basic Setup — Wan Connection — Automatic DHCP (получаем адрес от роутера провайдера)

3. Network Setup — LAN 192.168.2.1 netmask 255.255.255.0 gateway 192.168.2.1 DNS1 10.1.1.30 (Здесь указан мой сервер DNS в локальной сети моего офиса, в которой установлена мини-АТС). DHCP сервер для подсети 192.168.2.xx настроен на выдачу ip адресов, туда жестко забил привязку 192.168.2.2 к мак-адресу VOIP телефона.

4. Services — VPN — PPTP-Client включен, указан ip адрес моего сервера, remote subnet 10.1.1.0 netmask 255.255.255.0, и строка инициализации ppp

mppe required,no40,no56,stateless




5. Services — VPN — PPTP-Client: NAT выключен, вбиты user2 и пароль (то есть при коннекте роутер получает ip-адрес 10.1.1.216.

В итоге получилось следующее: роутер зацепился к серверу, получил IP-адрес и успешно пинговал 10.1.1.209 ( то есть адрес eth1 сервера). Но дальше дело не шло, а мне необходимо достучаться к 10.1.1.250. Делаем вывод, что проблема в настройке роутинга + некоторых правилах firewall.

После длительных исследований получился стартовый скрипт (при взлете интерфейса), который я приведу ниже. Ради него эта статья и затевалась:



cd /etc/ppp/ip-up.d
cat /etc/ppp/ip-up.d/pppup

#!/bin/bash
iptables -L -t nat
iptables -F
iptables -X
#Пробросы портов VPN (47 и 1723)
iptables -A INPUT -i eth1 -p tcp --dport 47 -j ACCEPT
iptables -A INPUT -i eth1 -p udp --dport 47 -j ACCEPT
iptables -A INPUT -i eth1 -p tcp --dport 1723 -j ACCEPT
iptables -A INPUT -i eth1 -p udp --dport 1723 -j ACCEPT
#Разрешаем траффик на интерфейсах
iptables -A FORWARD -o eth0 -p tcp -j ACCEPT
iptables -A FORWARD -o eth0 -p udp -j ACCEPT
iptables -A FORWARD -o eth1 -p tcp -j ACCEPT
iptables -A FORWARD -o eth1 -p udp -j ACCEPT
iptables -A FORWARD -o ppp0 -p tcp -j ACCEPT
iptables -A FORWARD -o ppp0 -p udp -j ACCEPT
iptables -A FORWARD -o ppp1 -p tcp -j ACCEPT
iptables -A FORWARD -o ppp1 -p udp -j ACCEPT
iptables -A FORWARD -o ppp2 -p tcp -j ACCEPT
iptables -A FORWARD -o ppp2 -p tcp -j ACCEPT
iptables -A FORWARD -o ppp3 -p udp -j ACCEPT
iptables -A FORWARD -o ppp3 -p tcp -j ACCEPT
iptables -A FORWARD -o ppp4 -p udp -j ACCEPT
iptables -A FORWARD -o ppp5 -p udp -j ACCEPT
#Разрешаем VOIP
iptables -t mangle -A FORWARD -p tcp -m tcp --tcp-flags RST,SYN SYN -j TCPMSS --clamp-mss-to-pmtu

#Грохаем устаревший роутинг
/sbin/route del -net 192.168.0.0 netmask 255.255.255.0
/sbin/route del -net 192.168.2.0 netmask 255.255.255.0
/sbin/route del default gw 10.90.90.1

#Восстанавливаем роутинг. (Это для мини-АТС, у которой шлюзом прописан мой сервер 10.1.1.209, чтобы она видела 192.168.2.2).
/sbin/route add -net 192.168.2.0 netmask 255.255.255.0 gw 10.1.1.212
/sbin/route add -net 192.168.0.0 netmask 255.255.255.0 gw 10.1.1.216
/sbin/route add default gw 10.90.90.1



Что касается строчки «Разрешаем VOIP» в стартовом скрипте, то я могу сказать так: нашел ее в выдаче далеко за первой сотней поисковика, в одном из форумов, с пометкой «попробуй, вдруг заработает». До ее введения в конфиг ходил любой траффик за исключением голоса со стороны АТС. Голос из удаленного офиса приходил.

Спасибо за внимание. Буду рад, если данное решение может помочь быстро взлететь VPN между удаленными офисами.


This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.


Комментариев нет:

Отправить комментарий