а в OpenVPN нет таких функций?
может тогда такой вариант - добавить интрерфейс tun0 в мосту br0 и вашей сетке поменять адресацию на 192.168.161.0 или наоборот в OpenVPN сменить на 192.168.1.0
brctl addif br0 tun0
????????????????
Forum Guru
OpenVPN клиент
а в OpenVPN нет таких функций?
может тогда такой вариант - добавить интрерфейс tun0 в мосту br0 и вашей сетке поменять адресацию на 192.168.161.0 или наоборот в OpenVPN сменить на 192.168.1.0
brctl addif br0 tun0
????????????????
Junior Member
$ brctl addif br0 tun0
br_add_interface: Invalid argument
странно
вообще, похоже, что всё не так просто, как кажется
Forum Guru
OpenVPN клиент
попробуйтеOriginally Posted by petras
$ brctl addif br0 tun0
br_add_interface: Invalid argument
странно
ifconfig tun0 up
brctl addif br0 tun0
это не 100%, что поможет. просто по аналогии прикручивания bluetooth и поднятия интерфейса там - я вам и советую.
и кстати, вы на сервере VPN прописали маршрутизацию своей сети, как сказано здесь:
First, you must advertise the 10.66.0.0/24 subnet to VPN clients as being accessible through the VPN. This can easily be done with the following server-side config file directive:
в этом же HOWTO сказано, что надо проследить за IP forwarding и TUN/TAP на VPN сервере - так что изучайте!
но думаю вам лучше не routed VPN настроить, а bridging VPN - в HOWTO есть рекомендации и поэтому поводу.
Last edited by AndreyPopov; 12-04-2008 at 18:39.
Junior Member
нет, этот вариант тоже не прошел.
в принципе, в howto всё логично и понятно расписано, просто тут уже решение задачи выходит за пределы моей личной досягаемости. посмотрим, если админу с серверной стороны будет не лень и будет на это время, может и сделаем. видимо, решения чисто с клиентской стороны нет. ну да и ладно
спасибо за помощь!
если удастся сделать, обязательно напишу подробно.
Member
Доброй ночи, уважаемые форумчане!
Задался вопросом о поднятии OenVPN-сервера в режиме tap (преследовал цель подключить нескольких пользователей из инета к ресурсам внутреннией локалки). Раньше доблся работы сей софтины в режиме tun - т.е. в ржиме "роутера" (работало но только с одним подключённым клиентом.)
Делал всё изучив следующие мануалы:
Несколько клиентов по OpenVPN - http://wl500g.info/showthread.php?t=9784
Помогите объяснить поведение OpenVPN - http://wl500g.info/showthread.php?t=...hlight=openvpn
Установка openvpn в основную память для НОВИЧКОВ - http://wl500g.info/showthread.php?t=8880&page=6
FAQ: OpenVPN (было - Помогите настроить OpenVPN) ! - http://forum.ixbt.com/topic.cgi?id=14:40906
После долгих мучений и сервер и клиент перестали ругаться на конфиги, сервер запустился.
Конфиги следующие:
server.conf
client.ovpnCode:dev tap0 proto tcp-server server-bridge 10.0.0.1 255.255.255.0 10.0.0.50 10.0.0.60 client-to-client tls-server dh /opt/etc/openvpn/keys/dh1024.pem ca /opt/etc/openvpn/keys/ca.crt cert /opt/etc/openvpn/keys/server.crt key /opt/etc/openvpn/keys/server.key port 1194 keepalive 10 120 persist-tun persist-key verb 3
НО!!Code:ca ca.crt cert client.crt key client.key dev tap0 tls-client remote 192.168.1.1:1194 port 1194 proto udp persist-tun persist-key verb 3 route-delay 10 route-gateway 10.8.0.2
При запуске клиентского соединеия лог постепенно заполняется сообщениями следующего характера:
Thu May 08 00:15:17 2008 read UDPv4: Connection reset by peer (WSAECONNRESET) (code=10054)
Погуглив вопрос нашёл инфу что эти ошибки - ошибки работы с сокетом - и выдаёт их винда.
Лезем в фаервол:
На мой взгляд блокировать ничего не должно. Причём при попытке подключения в таблице INPUT увеличиваются кол-во пакетов и объём данных в правиле №2Code:[admin@(none) /]$ iptables -L -nv --line-numbers Chain INPUT (policy ACCEPT 860 packets, 111K bytes) num pkts bytes target prot opt in out source destination 1 0 0 ACCEPT all -- tun0 * 0.0.0.0/0 0.0.0.0/0 2 84 3528 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:1194 3 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:1194 4 0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID 5 5122 745K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 6 293 17580 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0 state NEW 7 2454 766K ACCEPT all -- br0 * 0.0.0.0/0 0.0.0.0/0 state NEW 8 3 156 ACCEPT tcp -- * * 0.0.0.0/0 192.168.1.1 tcp dpt:80 9 0 0 ACCEPT tcp -- * * 0.0.0.0/0 192.168.1.1 tcp dpt:8081 10 4 244 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 11 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:81 12 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 13 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22000 14 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:23 15 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:21 16 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:59970 17 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:64255 18 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:39309 Chain FORWARD (policy ACCEPT 52 packets, 2664 bytes) num pkts bytes target prot opt in out source destination 1 0 0 ACCEPT all -- * tun0 0.0.0.0/0 0.0.0.0/0 2 0 0 ACCEPT all -- tun0 * 0.0.0.0/0 0.0.0.0/0 3 0 0 ACCEPT all -- * * 192.168.210.10 192.168.1.10 4 0 0 ACCEPT all -- * * 192.168.213.76 192.168.1.10 5 0 0 ACCEPT all -- * * 192.168.211.14 192.168.1.10 6 0 0 ACCEPT all -- * * 192.168.217.3 192.168.1.10 7 0 0 ACCEPT all -- br0 br0 0.0.0.0/0 0.0.0.0/0 8 0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID 9 80 3992 TCPMSS tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x16/0x02 TCPMSS clamp to PMTU 10 2351 1438K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 11 51 2624 MAC_IP all -- * !br0 0.0.0.0/0 0.0.0.0/0 12 0 0 DROP all -- !br0 ppp0 0.0.0.0/0 0.0.0.0/0 13 0 0 DROP all -- !br0 vlan1 0.0.0.0/0 0.0.0.0/0 14 31 1488 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate DNAT 15 0 0 DROP all -- * br0 0.0.0.0/0 0.0.0.0/0 Chain OUTPUT (policy ACCEPT 7723 packets, 1428K bytes) num pkts bytes target prot opt in out source destination 1 0 0 ACCEPT all -- * tun0 0.0.0.0/0 0.0.0.0/0 Chain MACS (0 references) num pkts bytes target prot opt in out source destination Chain MAC_IP (1 references) num pkts bytes target prot opt in out source destination 1 9 432 RETURN all -- * * 192.168.1.3 0.0.0.0/0 MAC 00:80:48:3F:7A:9F 2 0 0 RETURN all -- * * 192.168.1.4 0.0.0.0/0 MAC 00:E0:4C:DD:0D:90 3 39 2036 RETURN all -- * * 192.168.1.5 0.0.0.0/0 MAC 00:1C:23:0B:1C:A4 4 0 0 RETURN all -- * * 192.168.1.10 0.0.0.0/0 MAC 00:17:31:96:6E:F4 5 0 0 RETURN all -- * * 192.168.1.124 0.0.0.0/0 MAC 00:02:78:89:82:13 6 3 156 RETURN all -- * * 192.168.1.190 0.0.0.0/0 MAC 00:1B:77:B6:55:BB 7 0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 Chain SECURITY (0 references) num pkts bytes target prot opt in out source destination 1 0 0 RETURN tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x16/0x02 limit: avg 1/sec burst 5 2 0 0 RETURN tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x17/0x04 limit: avg 1/sec burst 5 3 0 0 RETURN udp -- * * 0.0.0.0/0 0.0.0.0/0 limit: avg 5/sec burst 5 4 0 0 RETURN icmp -- * * 0.0.0.0/0 0.0.0.0/0 limit: avg 5/sec burst 5 5 0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 Chain logaccept (0 references) num pkts bytes target prot opt in out source destination 1 0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 state NEW LOG flags 7 level 4 prefix `ACCEPT ' 2 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 Chain logdrop (0 references) num pkts bytes target prot opt in out source destination 1 0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 state NEW LOG flags 7 level 4 prefix `DROP ' 2 0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0
Может кто сталкивался с подобной ситуацией? Подскажит пожалуйсто, где накосячили мои кривые ручёнки!
Пробовал и с вот этими правилами из одного мануала
И с вот этими правилами из другого мануала:Code:#!/bin/sh iptables -D INPUT -j DROP # enable access from WAN iptables -t nat -I PREROUTING -p udp --dport 1194 -j ACCEPT iptables -I INPUT -p udp --dport 1194 -j ACCEPT iptables -I INPUT -i tap0 -j ACCEPT iptables -I FORWARD -i tap0 -j ACCEPT
P.S. На компе с которого пытаюсь подключиться фаерволов нет. Виндовый брандмауэр отключён. Винда -XP SP2.Code:iptables -A INPUT -i tap0 -j ACCEPT
Зарание благодарен всем откликнувшимся!
Member
Поменял в пост-фаерволл правила:
наCode:iptables -D INPUT -j DROP iptables -I INPUT -p tcp --dport 1194 -j ACCEPT iptables -I INPUT -p udp --dport 1194 -j ACCEPT iptables -t nat -I PREROUTING -i eth1 -p udp --dport 1194 -j DNAT --to-destination $4:1194 iptables -t nat -I PREROUTING -i eth1 -p tcp --dport 1194 -j DNAT --to-destination $4:1194 echo "post-firewall: TCP/UDP ports for OpenVPN OPENED OK ! " >> /tmp/syslog.log iptables -I INPUT -i tun0 -j ACCEPT iptables -I FORWARD -i tun0 -j ACCEPT iptables -I FORWARD -o tun0 -j ACCEPT iptables -I OUTPUT -o tun0 -j ACCEPT echo "post-firewall: Connections from tap0 OPENED OK ! " >> /tmp/syslog.log
Ошибки с в таком бешеном количестве (WSAECONNRESET) (code=10054) прекратились. Теперь лог соединения выглядит так:Code:iptables -D INPUT -j DROP iptables -I INPUT -p tcp --dport 1194 -j ACCEPT iptables -I INPUT -p udp --dport 1194 -j ACCEPT iptables -t nat -I PREROUTING -i eth1 -p udp --dport 1194 -j DNAT --to-destination $4:1194 iptables -t nat -I PREROUTING -i eth1 -p tcp --dport 1194 -j DNAT --to-destination $4:1194 echo "post-firewall: TCP/UDP ports for OpenVPN OPENED OK ! " >> /tmp/syslog.log iptables -I INPUT -i tap0 -j ACCEPT iptables -I FORWARD -i tap0 -j ACCEPT iptables -I FORWARD -o tap0 -j ACCEPT iptables -I OUTPUT -o tap0 -j ACCEPT echo "post-firewall: Connections from tap0 OPENED OK ! " >> /tmp/syslog.log
в чём я накосячил? подскажите подалуйсто!Code:Thu May 08 00:51:17 2008 OpenVPN 2.0.9 Win32-MinGW [SSL] [LZO] built on Oct 1 2006 Thu May 08 00:51:17 2008 WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info. Thu May 08 00:51:17 2008 Control Channel MTU parms [ L:1573 D:138 EF:38 EB:0 ET:0 EL:0 ] Thu May 08 00:51:17 2008 TAP-WIN32 device [Подключение по локальной сети 4] opened: \\.\Global\{3801AE01-AD71-435A-9B1C-62E3F802F5C8}.tap Thu May 08 00:51:17 2008 TAP-Win32 Driver Version 8.4 Thu May 08 00:51:17 2008 TAP-Win32 MTU=1500 Thu May 08 00:51:17 2008 Successful ARP Flush on interface [19] {3801AE01-AD71-435A-9B1C-62E3F802F5C8} Thu May 08 00:51:17 2008 Data Channel MTU parms [ L:1573 D:1450 EF:41 EB:4 ET:32 EL:0 ] Thu May 08 00:51:17 2008 Local Options hash (VER=V4): '2c50bd2c' Thu May 08 00:51:17 2008 Expected Remote Options hash (VER=V4): '0ddbb6e3' Thu May 08 00:51:17 2008 UDPv4 link local (bound): [undef]:1194 Thu May 08 00:51:17 2008 UDPv4 link remote: 62.140.252.29:1194 тут соедиение как-бы подвисает на 60 секунд и выдаётся следующая ошибка: Thu May 08 00:51:21 2008 read UDPv4: Connection reset by peer (WSAECONNRESET) (code=10054) Thu May 08 00:52:18 2008 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity) Thu May 08 00:52:18 2008 TLS Error: TLS handshake failed Thu May 08 00:52:18 2008 TCP/UDP: Closing socket Thu May 08 00:52:18 2008 SIGUSR1[soft,tls-error] received, process restarting Thu May 08 00:52:18 2008 Restart pause, 2 second(s)
Last edited by Romeo9128; 07-05-2008 at 21:55.
Member
Сделал по вашим конфигам. Ип получается из той подсети, которую задали в конфиге сервера. В данном случае - 10.8.0.50 - 10.8.0.60...
Так что не вполне ясно почему у Вас ip был выдан DHCP-роутера..
Кстати, с Вашего позволения один небольшой вопросик: как Вы генерировали сертификаты и ключи? на роутере или на ПК, и какой софт использовали для этого?
Member
openvpn: help needed
Пытаюсь поднять дома простейший openvpn на asus wl500w. По вот этой рассказке: http://wl500g.info/showthread.php?t=5312 Все запускается, ошибок нет. Далее, пытаюсь тестировать. В качестве клиента - openvpn на n810, которая через синезуб вяжется с мабилой и выходит в интернет. Интерфейс tun0 подымается как родной (точнее, 2 интерфейса - на роутере и на таблетке соотв.). Но пинг с 10.8.0.1 на 10.8.0.2 не проходит ваще. И обратно, что характерно, тоже. Где б покопать? В логах рапортуют об удачно установленном соединении...
Спасибо.
Registered User
Приветствую!
WL520GC + AKADO (бывшый провайдер TC-EXE в Марьино). Для использования внешнего адреса необходимо установить PPTP соединение. Короче, все рабоает прекрасно, но до перезагрузки устройства - PPTP он сразу не всегда поднимает, может много раз пытаться, а может и сразу установить. Стоит нажать в в статусе Disconnect - снова будет соединяться неопределенное время. Но когда соединился - держит по несколько дней без проблем. Т.е. имеем какую-то нестабильную работу pppd. Прошивка родная 2011. Включение дебага и т.д. понимания не добавляет - Modem Hangup исе тут. При этом если устанавливать VPN с винды - всегда мгновенно.
Ладно, можно списать на кривизу родной прошивки, но косяк в том, что заменить я ее не могу. Никак. Ни стандартными средствами через закладку Firmware Update, ни c использованием Firmware Restoration Utility - не находит устройство (интерфейс маршрутизатора вообще не пингуется). Т.е. просто никак, хотя один раз это было успешно проделано - куплен он был с 2010, я заменил на 2010 через вебморду.
Что делать? Ну можно забить, конечно - ведь через сколько-то времени он поднимает pptp и далее стабильно работает, но я так не привык. Алтернатива - поднять pptp до провайдера на rrase виндовом, все равно сервер стоит дома, но тоже лишнее это...
Поэтому основной вопрос - как прошить 0016 прошивку?
Спасибо.
Forum Guru
Так не пробовали?
http://wl500g.info/showpost.php?p=33445&postcount=16
Registered User
Не, так не пробовал - меня останавливает тот шаг, что интерфейс не пигуется. Т.е. тфтп можно уже и не пробовать. Я допускаю конечно, что в стандартном загрузчике запрещен ICMP и разрешен только tftp, но сомнительно. Да и в той теме интерфейс пингуется. Хотя это много времени не требует - вечером проверю, конечно - щас реальный адрес пока нужен
Да, без установки VPN (когда на WAN интерфейсе адрес из внутреннего диапазона провайдер) все летает и всегда. Т.е. проблема только с PPTP.
Junior Member
Есть еще один момент с PoPToP.
Если провайдер использует raduis-сервер в аутентификации (а так скорее всего и есть), может быть небольшой ньюанс.
В случае непредвиденного разрыва вашего соединения сервер доступа (vpn-сервер) не всегда может понять что сессия разорвалась, ну нет пакетов в туннеле и нет, мож вы покурить вышли. Соответственно, когда вы тут же пытаетесь зацепиться снова, сервер доступа спрашивает у raduis-сервера, можно ли вам цепляться. raduis в свою очередь видит, что вы уже единожды подключены, а второй раз - фиг, о чем и говорит впн серверу. При этом, сервер доступа на транспортном для впн уровне (на уровне ip сетевых карт) видит что от вас всетки идут пакеты, выж на впн-порт стучитесь, gre пакеты ходят, а потому, когда идет промежуточный эккаунтинг (который и призван ложить ненормально завершенные сессии) не видит причин ложить зависшую vpn сессию - и говорит радиусу что все в этом туннеле в норме, юзер работает. Получается замкнутый круг - твоя железяка пытается с упорством маньяка дозвониться раз в 30 сек, чем и лишает всякого шанса соединиться. И как только вы переткнули кабель из wan-порта железки в комп, другую железку, или выдернув кабель из wan минут 5 обжимали его отверткой заново - все магическим образом проходит...
По идее все, что нужно - минут от 1 до 10 просто не пытаться соединяться, в зависимости от прова.
Бывший пров.
Registered User
О! Это полностью подверждает мои подозрения. Вот смотрю по логу - вчера вечером он час соединялся. Но, опять же - когда говоришь ему disconnect, то по логу он завершет соединение корректно (ни разу не очевидно, что с точки зрения vpn сервера это так). Да и запуск vpn с винды всегда проходит успешно.
Я для себя вот что заметил - если он после перезапуска нормально соединяется, то в логе срвзу все хорошо. А вот если сразу не соединялся. то лог начинается так:
Jan 1 03:00:03 pppd[57]: pppd 2.4.2 started by (unknown), uid 0
Jan 1 03:00:04 pppd[57]: Serial connection established.
Jan 1 03:00:04 pppd[57]: Using interface ppp0
Jan 1 03:00:04 pppd[57]: Connect: ppp0 <--> /dev/pts/0
Jan 1 03:00:07 pptp[69]: connect: No route to host
Jan 1 03:00:07 pptp[69]: Could not open control connection to 10.10.10.10
Jan 1 03:00:07 pptp[63]: Call manager exited with error 256
Jan 1 03:00:07 pppd[57]: Modem hangup
Jan 1 03:00:07 pppd[57]: Connection terminated.
Sep 21 22:56:57 ntp client: time is synchronized to time.nist.gov pool.ntp.org
Дальше постоянно повторяется:
Sep 21 22:57:00 pppd[57]: Serial connection established.
Sep 21 22:57:00 pppd[57]: Using interface ppp0
Sep 21 22:57:00 pppd[57]: Connect: ppp0 <--> /dev/pts/0
Sep 21 22:57:03 pppd[57]: Modem hangup
Sep 21 22:57:03 pppd[57]: Connection terminated.
Ну и когда наконец соединился:
Sep 22 00:03:54 pppd[57]: Serial connection established.
Sep 22 00:03:54 pppd[57]: Using interface ppp0
Sep 22 00:03:54 pppd[57]: Connect: ppp0 <--> /dev/pts/0
Sep 22 00:03:55 pppd[57]: CHAP authentication succeeded
Sep 22 00:03:55 pppd[57]: local IP address 89.19.171.68
Sep 22 00:03:55 pppd[57]: remote IP address 89.19.162.1
Sep 22 00:03:56 PPTP: connect to ISP
Осталось понять для проверки, как бы минут на 5 отложить старт pppd после стартапа маршрутизатора.
Registered User
По поводу невозможности прошивки через веб-интерфейс на сайте openwrt нашел вот что:
Web interface from ASUS Firmware 2.0.1.0 and newer doesn't allow to upload DD-WRT firmware, it reports corrupted file. You have to downgrade to 2.0.0.8 ASUS firmware in order to flash DD-WRT firmware.
There also could be unable to downgrade to 2.0.0.8 ASUS firmware from newer version through web interface, easily soulution could be rename in order to flash DD-WRT firmware. Easy solution could be to rename a old firmware file (up to 2.0.0.8) for example to "newer" WL520gc_2.0.1.2_EN.trx
Прикольно. Вечером прошью 0016 прошивкой и будем посмотреть. Кстати, где-нибудь опубликован полный список отличий данной прошивки от родной и вносились ли каки-нибудь изменения в части pppd?
Junior Member
pppd, как и poptop - весьма консервативные проекты, ввиду возраста и отлаженности. Вряд ли стоит ждать чего-то нового.
Posting Permissions
Reply With Quote
