PDA

Bekijk de volledige versie : Dial-in Server


Vofik
09-02-2008, 10:32
Раскажите как на базе нашего роутера + встроенного com-порта (можно и переходник USB-COM) + модема организовать Dial-in Server с обратным дозвоном (это когда ты звониш с удалённой машины на сервер (при этом на удалённой машине должна быть включена опция обратного дозвона) логинишся, а затем сервер тебя сбрасывает с линии и перезванивает. Это нужно к примеру если у сервер телефон бесплатный, а у клиента платный с поминутной тариффикацией. Все схемы и способы подключения есть на форуме! Теперь дело лишь за програмной частью ;)

Желательно, чтоб модем брал трубку только после определённого времяни звонка, чтоб убедиться, что никого нет дома и dial-in никому не помешает трепаться по всякой ярунде;)

Вот нашел материал, осталось только, чтоб кто-нибуть его разжевал ;)

http://www.opennet.ru/prog/sml/54.shtml

http://www.homepc.ru/2002/72/18591/ (надо найти первую часть)

http://i2r.ru/static/486/out_12889.shtml

http://gazette.linux.ru.net/lg77/articles/rus-sunil.html

http://www.howtoforge.com/linux_dialin_server

http://www.opennet.ru/base/modem/dialin_simple_bill.txt.html
Mapseam
22-01-2010, 20:05
Возможно, на тему dial-in уже неактуально для многих, но мне пока это необходимо использовать. Поэтому внесу свои "пять копеек".

Мигрировал на прошивку Oleg++ (она же - "от энтузиастов", 1.9.2.7-d-r1000). Пара доп. модулей ядра из соотв. архива (http://wl500g.googlecode.com/files/modules-1.9.2.7-d-r1000.tgz) мне пригодились - удалось реализовать dial-in с помощью идущих с прошивкой pppd и chat.

Остался лишь вопрос с передачей клиенту адресов DNS. Вариант с указанием опции ms-dns в файле опций pppd (в моем случае - в /tmp/ppp/options.usb.acm.0) - тривиален. Такой вариант - работает, но адреса DNS могут быть изменены провайдером и не хотелось бы их указывать явно.
Если вместо опции ms-dns указать опцию usepeerdns, то клиент не получает инфы по адресам DNS.

Вот тут (http://www.wl500g.info/showpost.php?...1&postcount=18) прочитал, что pppd ищет resolv.conf в /tmp/ppp/, тогда как его оригинал лежит в /tmp/. (Там, правда, вместо tmp упоминается etc, но, возможно, это особенность прошивки DD-WRT, тогда как у меня - не она).
Я так и сделал: ln -fs /tmp/resolv.conf /tmp/ppp/resolv.conf
Однако, ожидаемого эффекта это не дало.

Кто-нибудь может сказать точнее, решаемо ли, чтобы pppd брал адреса DNS из /tmp/resolv.conf (или его симлинка)?
Mapseam
04-02-2010, 09:15
Столкнулся с проблемой "отваливания" коннекта. Суть такова.
К роутеру присоединен USB-модем, он опознан и настроен на прием входящих соединений (используются pppd и chat). При вх. звонке с др. модема образуется соединение на интерфейсе ppp1. В св-х соединения указано, что адрес интерфейса ppp1 - 192.168.2.1, а адрес звонящего - 192.168.2.2 (т.е. адрес - фиксированный, хотя есть задумка каждому звонящему выдавать свой IP, но это "на потом"). Звонящему сообщаются 2 адреса DNS. Гейт для него - 192.168.2.1 (хотя, если на клиенте (WinXP) смотреть вывод ipconfig /all, то гейтом значится 192.168.2.2).
Одним словом, интерфейсу ppp1 выделен диапазон IP 192.168.2.0/24
У роутера внут. адрес - 192.168.1.1 и инт-с br0, а внеш. адрес - "белый" на интерфейсе ppp0. Провайдер предоставляет коннект по PPPoE.

Задача такова: для начала дать возможность дозвонившемуся пользоваться всеми сервисами Инета (как будто это хост из моей дом. локалки). Для решения задачи, я так понял, необходимо лишь безусловно пробрасывать трафик между ppp1 и ppp0.

Но... При установлении dial-in соединения со стороны клиента поначалу пингуется адрес gw (гейта), но не пингуются ни один из двух адресов DNS, которые передаются клиенту при установлении соединения. Причем в команде, например, ping www.ru FQDN разрешается в IP-адрес, но пинга нет. Получается, что ответ от DNS-ов клиент получает, но ICMP-трафик "режется" iptables.

Через несколько минут перестает пинговаться гейт и перестают разрешаться FQDN. Кто бы сказал, в чем причина этого явления и как решить возникающую проблему?

В post-firewall для этого направления прописаны такие правила:
iptabels -t -I FORWARD -i $1 -o ppp1 -j ACCEPT
iptabels -t -I FORWARD -i ppp1 -o $1 -j ACCEPT
iptables -t nat -A POSTROUTING -o ppp1 -j MASQUERADE

Подозреваю, что пропущено правило на предмет PREROUTING. Как оно должно выглядеть? И что еще не дописано, чтобы решить задачу?
Basile
04-02-2010, 10:15
Что дают пинги и трассировки?
Mapseam
04-02-2010, 15:33
Со стороны дозвонившегося клиента поначалу пингуется только адрес гейта (192.168.2.1), но через несколько минут гейт уже не пингуется.
Со стороны роутера, после установления соединения, клиент (его адрес 192.168.2.2) - не пингуется вообще никогда.

Под трассировкой понимается запуск tcpdump -i ppp1? Пока не трассировал. Спасибо за наводку - надо будет попробовать.
Basile
04-02-2010, 16:18
Под трассировкой понимается запуск tcpdump -i ppp1?traceroute ya.ru ;)
Power
04-02-2010, 16:44
Надо смотреть ваши текущие правила iptables при поднятых всех соединениях


iptables-save

Еще хорошо бы увидеть IP-адреса тех dns, которые выдаются клиенту.
И таблицу маршрутизации на роутере (а то мало ли, куда пакеты направляются...)


route -n
Mapseam
04-02-2010, 19:59
traceroute ya.ru ;)

Результат неутешительный:



C:\Documents and Settings\user>tracert ya.ru

Трассировка маршрута к ya.ru [213.180.204.8]
с максимальным числом прыжков 30:

1 * * * Превышен интервал ожидания для запроса.
2 * * * Превышен интервал ожидания для запроса.
3 * * * Превышен интервал ожидания для запроса.
4 * * * Превышен интервал ожидания для запроса.
5 * * * Превышен интервал ожидания для запроса.
6 ^C
C:\Documents and Settings\user>


Хотя из шелла роутера трассировка работает:


traceroute to ya.ru (213.180.204.8), 30 hops max, 38 byte packets
1 bsr01.volgograd.ertelecom.ru (88.87.65.92) 2.225 ms 4.024 ms 1.588 ms
2 te-2-0-0-48.bsr02.volgograd.ertelecom.ru (88.87.65.194) 4.112 ms 1.945 ms 3.563 ms
3 vgd15.transtelecom.net (217.150.50.122) 30.456 ms 30.097 ms 30.052 ms
4 xe120-197.RT.TNR.HKI.FI.retn.net (87.245.248.17) 46.002 ms 46.135 ms 45.955 ms
5 ae2-9.RT.V10.MSK.RU.retn.net (87.245.233.13) 47.362 ms 46.123 ms 95.766 ms
6 ya.ru (213.180.204.8) 46.031 ms 45.993 ms 45.966 ms
Basile
04-02-2010, 20:16
Еще бы таблицу маршрутизации с компа, с которого производилась трассировка.
Mapseam
04-02-2010, 20:46
iptables-save


# Generated by iptables-save v1.3.8 on Thu Feb 4 21:53:15 2010
*nat
:PREROUTING ACCEPT [674:81919]
:POSTROUTING ACCEPT [653:39801]
:OUTPUT ACCEPT [656:40373]
:VSERVER - [0:0]
-A PREROUTING -d 188.187.23.236 -j VSERVER
-A POSTROUTING -s ! 188.187.23.236 -o ppp0 -j MASQUERADE
-A POSTROUTING -s 192.168.1.0/255.255.255.0 -d 192.168.1.0/255.255.255.0 -o br0 -j SNAT --to-source 192.168.1.1
-A POSTROUTING -o ppp1 -j MASQUERADE
-A VSERVER -p tcp -m tcp --dport 51413:51419 -j DNAT --to-destination 192.168.1.1:51413
-A VSERVER -p udp -m udp --dport 51413:51419 -j DNAT --to-destination 192.168.1.1:51413
-A VSERVER -p tcp -m tcp --dport 2222 -j DNAT --to-destination 192.168.1.1:2222
-A VSERVER -p tcp -m tcp --dport 443 -j DNAT --to-destination 192.168.1.1:2222
-A VSERVER -p tcp -m tcp --dport 17643:17649 -j DNAT --to-destination 192.168.1.2:17643
-A VSERVER -p udp -m udp --dport 17643:17649 -j DNAT --to-destination 192.168.1.2:17643
-A VSERVER -p tcp -m tcp --dport 30002 -j DNAT --to-destination 192.168.1.2:30002
-A VSERVER -p udp -m udp --dport 30002 -j DNAT --to-destination 192.168.1.2:30002
-A VSERVER -p tcp -m tcp --dport 20:21 -j DNAT --to-destination 192.168.1.1:8821
COMMIT
# Completed on Thu Feb 4 21:53:15 2010
# Generated by iptables-save v1.3.8 on Thu Feb 4 21:53:15 2010
*mangle
:PREROUTING ACCEPT [5741:4268096]
:INPUT ACCEPT [5183:4067105]
:FORWARD ACCEPT [554:199215]
:OUTPUT ACCEPT [6783:1650864]
:POSTROUTING ACCEPT [7384:1856511]
COMMIT
# Completed on Thu Feb 4 21:53:15 2010
# Generated by iptables-save v1.3.8 on Thu Feb 4 21:53:15 2010
*filter
:INPUT DROP [74:4239]
:FORWARD ACCEPT [54:3125]
:OUTPUT ACCEPT [6783:1650864]
:BRUTE - [0:0]
:MACS - [0:0]
:SECURITY - [0:0]
:logaccept - [0:0]
:logdrop - [0:0]
-A INPUT -i ppp1 -m state --state NEW -j ACCEPT
-A INPUT -p udp -m udp --dport 30002 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 30002 -j ACCEPT
-A INPUT -p udp -m udp --dport 51413 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 51413 -j ACCEPT
-A INPUT -m state --state INVALID -j logdrop
-A INPUT -i br0 -j MACS
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -m state --state NEW -j ACCEPT
-A INPUT -i br0 -m state --state NEW -j ACCEPT
-A INPUT -p udp -m udp --sport 67 --dport 68 -j ACCEPT
-A INPUT -d 192.168.1.1 -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -p tcp -m tcp --dport 2222 -j ACCEPT
-A FORWARD -i ppp1 -o ppp0 -j ACCEPT
-A FORWARD -i ppp0 -o ppp1 -j ACCEPT
-A FORWARD -i br0 -j MACS
-A FORWARD -i br0 -o br0 -j ACCEPT
-A FORWARD -m state --state INVALID -j DROP
-A FORWARD -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -j TCPMSS --clamp-mss-to-pmtu
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i ! br0 -o ppp0 -j DROP
-A FORWARD -i ! br0 -o vlan1 -j DROP
-A FORWARD -m conntrack --ctstate DNAT -j ACCEPT
-A FORWARD -o br0 -j DROP
-A FORWARD -o ppp0 -p tcp -m tcp --dport 411 -j DROP
...
<цепочка MACS - поскипана>
...
-A SECURITY -p udp -m udp --dport 30002:30254 -j RETURN
-A SECURITY -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m limit --limit 1/sec -j RETURN
-A SECURITY -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK RST -m limit --limit 1/sec -j RETURN
-A SECURITY -p udp -m limit --limit 5/sec -j RETURN
-A SECURITY -p icmp -m limit --limit 5/sec -j RETURN
-A SECURITY -j DROP
-A logaccept -m state --state NEW -j LOG --log-prefix "ACCEPT " --log-tcp-sequence --log-tcp-options --log-ip-options
-A logaccept -j ACCEPT
-A logdrop -j LOG --log-prefix "DROP " --log-tcp-sequence --log-tcp-options --log-ip-options
-A logdrop -j DROP
COMMIT
# Completed on Thu Feb 4 21:53:15 2010




Еще хорошо бы увидеть IP-адреса тех dns, которые выдаются клиенту.


PPP адаптер:

DNS-суффикс этого подключения . . :
Описание . . . . . . . . . . . . : WAN (PPP/SLIP) Interface
Физический адрес. . . . . . . . . : 00-53-45-00-00-00
DHCP включен. . . . . . . . . . . : нет
IP-адрес . . . . . . . . . . . . : 192.168.2.2
Маска подсети . . . . . . . . . . : 255.255.255.255
Основной шлюз . . . . . . . . . . : 192.168.2.2
DNS-серверы . . . . . . . . . . . : 88.87.64.6
88.87.65.3
NetBIOS через TCP/IP. . . . . . . : отключен



route -n


Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
88.87.65.92 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
192.168.2.2 0.0.0.0 255.255.255.255 UH 0 0 0 ppp1
192.168.2.0 192.168.2.1 255.255.255.0 UG 0 0 0 ppp1
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 br0
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
0.0.0.0 88.87.65.92 0.0.0.0 UG 0 0 0 ppp0


Если это что-то даст, приведу листинг файла опций для соединения ppp1:


[admin@mapseam root]$ cat /tmp/ppp/options.usb.acm.0
115200
#nolog
debug
lock
silent
persist
maxfail 0
modem
crtscts
mru 296
login
auth
show-password
-chap
+pap
192.168.2.1:192.168.2.2
netmask 255.255.255.0
ms-dns 88.87.64.6
ms-dns 88.87.65.3
nodefaultroute
unit 1
init "/usr/sbin/chat -s -V -t 10 -f /tmp/ppp/peers/init.chat"
connect "/usr/sbin/chat -s -V -t 10 -f /tmp/ppp/peers/conn.chat"
disconnect "/usr/sbin/chat -s -V -t 20 -f /tmp/ppp/peers/disconn.chat"
ip-up-script /tmp/ppp/peers/ip-up.sh
ip-down-script /tmp/ppp/peers/ip-down.sh
nomppe nomppc
noaccomp
nopcomp


По тексту видно, какие IP-адреса я задаю интерфейсу и клиенту, как сообщаю клиенту адреса DNS. Кстати, странно, что у клиента гейтом является он сам (см. листинг "PPP адаптер"), да и маска у него не та, что я ему передаю: 255.255.255.255, а не 255.255.255.0

P.S. Маршрут для 192.168.2.0/24 я добавляю автоматически через скрипт /tmp/ppp/peers/ip-up.sh, а удаляю - тоже автоматом через /tmp/ppp/peers/ip-down.sh
Mapseam
04-02-2010, 21:04
Еще бы таблицу маршрутизации с компа, с которого производилась трассировка.

Не вопрос:


C:\Documents and Settings\user>route print

IPv4 таблица маршрута
================================================== =========================
Список интерфейсов
0x1 ........................... MS TCP Loopback interface
0x10003 ...08 00 27 00 88 a9 ...... VirtualBox Host-Only Ethernet Adapter - Virtual Machine Network Services Driver
0x80005 ...00 53 45 00 00 00 ...... WAN (PPP/SLIP) Interface
================================================== =========================
================================================== =========================
Активные маршруты:
Сетевой адрес Маска сети Адрес шлюза Интерфейс Метрика
0.0.0.0 0.0.0.0 192.168.2.2 192.168.2.2 1
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
192.168.2.1 255.255.255.255 192.168.2.2 192.168.2.2 1
192.168.2.2 255.255.255.255 127.0.0.1 127.0.0.1 50
192.168.2.255 255.255.255.255 192.168.2.2 192.168.2.2 50
192.168.56.0 255.255.255.0 192.168.56.1 192.168.56.1 20
192.168.56.1 255.255.255.255 127.0.0.1 127.0.0.1 20
192.168.56.255 255.255.255.255 192.168.56.1 192.168.56.1 20
224.0.0.0 240.0.0.0 192.168.56.1 192.168.56.1 20
224.0.0.0 240.0.0.0 192.168.2.2 192.168.2.2 1
255.255.255.255 255.255.255.255 192.168.2.2 192.168.2.2 1
255.255.255.255 255.255.255.255 192.168.56.1 192.168.56.1 1
Основной шлюз: 192.168.2.2
================================================== =========================
Постоянные маршруты:
Отсутствует
Power
04-02-2010, 21:47
По поводу iptables:
1. Верхушка вывода обрезана, а там тоже интересно.
2. Можно попробовать переместить правила


FORWARD -i ppp1 -o ppp0 -j ACCEPT
FORWARD -i ppp0 -o ppp1 -j ACCEPT

куда-нибудь после правил


FORWARD -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -j TCPMSS --clamp-mss-to-pmtu
FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT

чтобы уменьшить вероятность проблем с MTU. Код примерно такой:


index=`iptables -L FORWARD -n --line-numbers | awk '/ESTABLISHED|TCPMSS/ {print($1)}' | tail -1`

iptables -I FORWARD $((index + 1)) -i ppp1 -o ppp0 -j ACCEPT
iptables -I FORWARD $((index + 2)) -i ppp0 -o ppp1 -j ACCEPT


В остальном вроде ничего подозрительного.

Ну и ещё на всякий случай покажите сведения об интерфейсе ppp1:


ifconfig ppp1


И кстати, в случаях, когда со стороны клиента пингуется адрес гейта и когда (через некоторое время) гейт уже не пингуется, различаются ли результаты "route -n" на роутере?
Mapseam
05-02-2010, 07:40
По поводу iptables:
1. Верхушка вывода обрезана, а там тоже интересно.

Верхушку вывода поправил по месту. Прошу Вас взглянуть еще раз.



2. Можно попробовать переместить правила ... , чтобы уменьшить вероятность проблем с MTU.

Предложенный Вами код поместил в post-firewall.

Показания "ifconfig ppp1" и "route -n" на роутере (до и после) - представлю чуть позднее, когда доберусь до него.


Подскажите, пожалуйста, в правиле вроде "iptables -I FORWARD ...", если явно не указываю номер строки, в которую вставить правило, правило вставляется на 1-е место, в самый верх цепочки?

Кстати, когда искал примеры реализации dial-in для своего роутера, наткнулся на эту тему - http://www.wl500g.info/showthread.php?t=9628&highlight=com-%EF%EE%F0%F2
Один из участников (некто BELPAV) тоже столкнулся с "отваливанием" модемного соединения (не сразу, а через некоторое время).
Power
05-02-2010, 17:23
Верхушку вывода поправил по месту. Прошу Вас взглянуть еще раз.


2 замечания:
1) правило "-A POSTROUTING -o ppp1 -j MASQUERADE" наверное лучше убрать;
2) [не относится напрямую к теме] когда вы пробрасываете диапазон портов на один порт, это работает так:
проброс (в vitrual servers) 51413:51419 -> 192.168.1.1:51413 равносилен таким:
51413 -> 192.168.1.1:51413
51414 -> 192.168.1.1:51413
51415 -> 192.168.1.1:51413
...
51419 -> 192.168.1.1:51413
Это, скорее всего, не то, что ожидалось.
Если нужно пробросить диапазон без изменения номеров портов, то можно просто 51413:51419 -> 192.168.1.1 (не указывать порт назначения). Если же нужно изменить, то придётся пробрасывать по одному порту за раз:
20 -> 192.168.1.1:8820
21 -> 192.168.1.1:8821



Подскажите, пожалуйста, в правиле вроде "iptables -I FORWARD ...", если явно не указываю номер строки, в которую вставить правило, правило вставляется на 1-е место, в самый верх цепочки?


Да.



Кстати, когда искал примеры реализации dial-in для своего роутера, наткнулся на эту тему - http://www.wl500g.info/showthread.php?t=9628&highlight=com-%EF%EE%F0%F2
Один из участников (некто BELPAV) тоже столкнулся с "отваливанием" модемного соединения (не сразу, а через некоторое время).

Причина оттуда не ясна, но могу предложить дописать в файл опций pppd включение lcp-пинга


lcp-echo-interval 10
lcp-echo-failure 6

Также можно попробовать поотключать разного рода сжатие (хотя вряд ли это влияет на отключение, учитывая, что проходит какое-то время)


novj
nobsdcomp
nodeflate
Mapseam
05-02-2010, 19:37
После задействования lcp-пинга коннект продержался уже несколько минут.

Вот обещанные "route -n"

До:


Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
88.87.65.92 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
192.168.2.2 0.0.0.0 255.255.255.255 UH 0 0 0 ppp1
192.168.2.0 192.168.2.1 255.255.255.0 UG 0 0 0 ppp1
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 br0
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
0.0.0.0 88.87.65.92 0.0.0.0 UG 0 0 0 ppp0


После:


Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
88.87.65.92 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
192.168.2.2 0.0.0.0 255.255.255.255 UH 0 0 0 ppp1
192.168.2.0 192.168.2.1 255.255.255.0 UG 0 0 0 ppp1
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 br0
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
0.0.0.0 88.87.65.92 0.0.0.0 UG 0 0 0 ppp0


Разницы я не вижу. Маршрут для 192.168.2.0/24 создаю при коннекте в /tmp/ppp/peers/ip-up.sh и удаляю в /tmp/ppp/peers/ip-down.sh при дисконнекте (эти скрипты задействованы в options.usb.acm.0 для моего экземпляра pppd).

Вот показания ifconfig ppp1:


[admin@mapseam root]$ ifconfig ppp1
ppp1 Link encap:Point-to-Point Protocol
inet addr:192.168.2.1 P-t-P:192.168.2.2 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:296 Metric:1
RX packets:13 errors:1 dropped:0 overruns:0 frame:0
TX packets:9 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:853 (853.0 B) TX bytes:127 (127.0 B)


Тут смущает errors:1 и txqueuelen:3
И еще: может, MTU:296 неподходящий? Я, правда, задаю там же, в options.usb.acm.0, только MRU=296.
Power
06-02-2010, 00:59
Тут смущает errors:1 и txqueuelen:3
И еще: может, MTU:296 неподходящий? Я, правда, задаю там же, в options.usb.acm.0, только MRU=296.

Ошибки, если они составляют малую долю трафика, можно игнорировать, я думаю (у вас там вообще мало трафика, так что это не показательно).
txqueuelen - я не знаю, что такое. man говорит, что это "length of the transmit queue of the device" - длина очереди на передачу (не текущая, а максимальная).
MTU по хорошему надо выбирать исходя из того, какой используется протокол нижележащего уровня. Но можно и методом тыка.