Имею непонятку с openVPN. А именно:
1. Есть два шлюза (для центра и удаленной площадки). Оси - RFR-12 (на интернет-шлюзе) и RFR-15 (шлюз нового офиса).
2. Поднимаю openVPN, Версия 2.2.0. Взята с офсайта.
3. Настраиваю конфигурацию как сказано в статье: http://mannix.ru/debian-linux/%D0%B1%D0%B5%D0%B7%D0%BE%D0%BF%D0%B0%D1%81%D0%BD%D0%BE%D1%81%D1%82%D1%8C/ustanovska-i-nastrojka-openvpn-na-linux.html
Ну, в рехиме связи двух оффисов.
Что имею:
1. интерфейсы tun1 перекрестно пингуются.
2. интерфейсы хостов, на которых поднят openVPM пингуются.
3. пропинговать иные хосты, размещенные в тех же IP-сетях, что и интерфейсы хостов - не получается.
Форвардинг в iptables задан.
$IPT -A FORWARD -i $OPENVPN_IFACE -j ACCEPT
$IPT -A FORWARD -o $OPENVPN_IFACE -j ACCEPT
Но... tcpdump показывает, что на интерфейс tun1 приходят "издалека" ICMP эхо-реквесты. Но вот на нём они и умирают, если не к локальным интерфейсам адресованы... Подскажите, где собака зарылась?
===================
Собака зарылась в том, что я запихнул маршрут на 41-ю сеть в туннель. А на моем стенде 41я сеть изодбражет интернет. Как только вытащил этот маршрут из туннеля - все пинги (на прямой связке, скриптом) заработали.
попробуй добавить маршрут на шлюзе RFR-15
/sbin/route add -net (сеть RFR-15) netmask 255.255.255.0 gw (тенельный ip RFR-12)
и попингуй с сети RFR-15 шлюз RFR-12 и сеть за RFR-12
Очень мудрый совет. Неужели я произвожу впечатление настолько тупого ламера, что не знает ничего о маршрутах?
Итак, сегодня немного поигрался с conf-файлами, чтобы организовать сервер с многоклиентским подключением. После этого стало еще хуже. Пинговаться оно совсем отказалось. Конфиги припрятал, но... В прежний вид (когда пинговались только локальные интерфейсы) openVPN не вернулся.
Итак - запускаю на сервере openVPN следующим скриптом:
соответсвенно - лог
[console]# cat /var/log/vpn.log
Thu Jul 7 12:27:22 2011 OpenVPN 2.2.0 i686-pc-linux-gnu [SSL] [LZO2] [EPOLL] [PKCS11] [eurephia] built on Jul 6 2011
Thu Jul 7 12:27:22 2011 IMPORTANT: OpenVPN's default port number is now 1194, based on an official port number assignment by IANA. OpenVPN 2.0-beta16 and earlier used 5000 as the default port.
Thu Jul 7 12:27:22 2011 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Thu Jul 7 12:27:22 2011 ******* WARNING *******: all encryption and authentication features disabled -- all data will be tunnelled as cleartext
Thu Jul 7 12:27:22 2011 Socket Buffers: R=[114688->131072] S=[114688->131072]
Thu Jul 7 12:27:22 2011 TUN/TAP device tun1 opened
Thu Jul 7 12:27:22 2011 TUN/TAP TX queue length set to 100
Thu Jul 7 12:27:22 2011 /sbin/ifconfig tun1 192.168.254.2 pointopoint 192.168.254.1 mtu 1500
Thu Jul 7 12:27:22 2011 Data Channel MTU parms [ L:1500 D:1450 EF:0 EB:4 ET:0 EL:0 ]
Thu Jul 7 12:27:22 2011 Local Options hash (VER=V4): 'cdaa4ef8'
Thu Jul 7 12:27:22 2011 Expected Remote Options hash (VER=V4): 'f031d33b'
Thu Jul 7 12:27:22 2011 UDPv4 link local (bound): [undef]:1194
Thu Jul 7 12:27:22 2011 UDPv4 link remote: 192.168.41.2:1194
[/console]
маршруты:
[console]# route | grep tun
192.168.254.1 * 255.255.255.255 UH 0 0 0 tun1
192.168.43.0 192.168.254.1 255.255.255.0 UG 0 0 0 tun1
192.168.41.0 192.168.254.1 255.255.255.0 UG 0 0 0 tun1
[/console]
МЭ:
[console]
-A INPUT -p tcp -m tcp --dport 1194 -j ACCEPT
-A INPUT -p udp -m udp --dport 1194 -j ACCEPT
-A INPUT -i tun1 -j ACCEPT
-A FORWARD -d 192.168.43.0/24 -i tun1 -j ACCEPT
-A FORWARD -d 192.168.43.0/24 -o tun1 -j ACCEPT
[/console]
то есть - есть всё. Но пинги не ходят. Я вижу tcpdump'ом, как ICMP реквесты уходят с одого хоста, но на интерфейсе другого - полная тишина.
У меня нет никаких идей. Более того - пытался сделать не TUN-соединение, а TAP... Сервер на RFR12 итерфейс TAP поднимает, а вот клиент на RFR-15 - обламывается.
Самое смешное, что если всё делать (на TUN) с конфигами, с ключами и так далее - то клиент к серверу подключается, авторизуется, получает необходимую конфиграционную иформацию, те же маршруты... Но всё равно - через туннель ничего не идет...
tcpdump видит icmp на интерфейсе который "смотрит" в локалку? и какой icmp приходит в ответ?
на обоих хостах tcpdump -n -i tun1. На хосте отправителе - я отправляемые реквесты вижу. На хосте получателе - мертвая тишина. До локалки еще не добрались...
Более того - на клиенте идет в tun1 постоянная долбежка по udp-протоколу в адрес сервера (192.168.41.2). Но на "сервере" - мертвая тишина. Ничего не понимаю...
пардон, но я запутался...
насколько я понял:
есть 1 севак и 1 клиент. между ними есть попытка пробросить тунель
сервер: tun1 ip: 192.168.41.101
клиент: tun1 ip: 192.168.41.2
подразумевается что iptablas, роуты и т.д и т.п бла-бла-бла настроены верно.
но если c сервера (192.168.41.101) делать
[console]ping 192.168.41.2[/console]
то на получателе (192.168.41.2) тишь и гладь. т.е другими словами icmp тупо не доходят. я правильно понял?
а то:
tcpdump показывает, что на интерфейс tun1 приходят "издалека" ICMP эхо-реквесты. Но вот на нём они и умирают, если не к локальным интерфейсам адресованы
и
Я вижу tcpdump'ом, как ICMP реквесты уходят с одого хоста, но на интерфейсе другого - полная тишина.
пардон, но я запутался...
насколько я понял:
есть 1 севак и 1 клиент. между ними есть попытка пробросить тунель
сервер: tun1 ip: 192.168.41.101
клиент: tun1 ip: 192.168.41.2
подразумевается что iptablas, роуты и т.д и т.п бла-бла-бла настроены верно.
но если c сервера (192.168.41.101) делать
[console]ping 192.168.41.2[/console]
то на получателе (192.168.41.2) тишь и гладь. т.е другими словами icmp тупо не доходят. я правильно понял?
Понято почти правильно. Только сервер и клиент местами перепутаны - сервер имеет адрес 41.2, клиент - 41.101. Собака зарылась в том, что 41-я сеть у меня, хоть и рабочая (и в неё тоже нужно будет пробрасывать туннели), в данном конкретном случае она изображает из себя сеть интернет. По которому и должны быть проброшены жти туннели. Я же клиенту приказал (в конфигурационном файле) задвигать весь трафик на 41-ю сеть в туннель. Что и было на данном этапе работ критической ошибкой. Как только я этот маршрут на клиенте убрал - всё заработало. Правда, пока не проверил - поднимается ли в RFR-15 интерфейс tap (c пробросом езернетовских фреймов), но я пока и не знаю - нужно ли мне это или нет. А на TUN - всё заработало.
