Тут есть два варианта:
1) Выдавать при подключении к серверу ip из диапазона локалки с соответствующей маской и при этом вкдючить arp proxy на интерфейсе, который смотрит в локалку.
2) Выдавать пофиг какой ip, но при этом у всей локалки должен быть прописан роутин для этого ip через этот сервер.
Ну и не забыть прописать роутинг на клиенте.(или push route на сервере)
через часик-два напишу более конкретно.
Мне помогло решить проблему.
- выдается адрес из внутренней сети
- включается proxy-arp на ВНУТРЕННЕМ интерфейсе
В таком режиме нормально видно локалку.
Симптомы описанные топикстартером (видно сам VPN-сервер, не видно локалку за ним) наблюдались если забывал включить proxy-arp на LAN интерфейсе.
_________________
Trixbox 2.2.x (Asterisk 1.4.11) / FXO шлюзы (Dynamix, OvisLink, Planet, etc) / разные IP-телефоны (OvisLink, Grandstream, Dynamix, Nokia, Cisco ATA-186, etc)
| SolarW писал(а): |
| ...proxy-arp на LAN интерфейсе. |
подробнее можно? желательно в деталях
Что толку что я детально расскажу где надо ткнуть мышом в программе управления роутером которая запущена на винде?
Ключевая часть которую я хотел донести "обязательное включение proxy arp на внутреннем интерфейсе"
А вот как это делается в OpenVPN - я не в курсе, ибо не приходилось его использовать...
_________________
Trixbox 2.2.x (Asterisk 1.4.11) / FXO шлюзы (Dynamix, OvisLink, Planet, etc) / разные IP-телефоны (OvisLink, Grandstream, Dynamix, Nokia, Cisco ATA-186, etc)
eth0 поменяй на интрерфейс который нужен.
FAQ: OpenVPN - топик на 43 страницы на форуме ixbt.com
P.S. anest, ты не забудь сказать это оно было?
_________________
Trixbox 2.2.x (Asterisk 1.4.11) / FXO шлюзы (Dynamix, OvisLink, Planet, etc) / разные IP-телефоны (OvisLink, Grandstream, Dynamix, Nokia, Cisco ATA-186, etc)
| SolarW писал(а): |
| ..топик на 43 страницы на форуме ixbt.com |
издеваешься?
хочешь чтобы я там весь день провел и полночи? может есть ссылка на 300 страниц, чего мелочиться то? я конечно понимаю что ты помочь хотел, спасибо конечно, но в данном случае это будет "медвежья услуга", лучше не надо
Это ссылка вообще не тебе ибо я надеюсь что приведенный совет по включению proxy arp тебе помог.
А ссылка приведена на случай если кто-то еще с подобными вопросами будет этот топик читать...
И ежели у него что-то будет совсем не получаться - то пойдет читать многие страницы.
_________________
Trixbox 2.2.x (Asterisk 1.4.11) / FXO шлюзы (Dynamix, OvisLink, Planet, etc) / разные IP-телефоны (OvisLink, Grandstream, Dynamix, Nokia, Cisco ATA-186, etc)
| [-Alt-] писал(а): |
| sysctl net.ipv4.conf.eth0.proxy_arp = 1 |
| Цитата: |
| #sysctl net.ipv4.conf.eth1.proxy_arp = 1 error: "net.ipv4.conf.eth1.proxy_arp" is an unknown key error: Malformed setting "=" error: "1" is an unknown key |
| Цитата: |
| #sysctl net.ipv4.conf.eth1.proxy_arp=1 error: "net.ipv4.conf.eth1.proxy_arp" is an unknown key |
| Код: |
| echo 1 > /proc/sys/net/ipv4/conf/eth1/proxy_arp |
_________________
Trixbox 2.2.x (Asterisk 1.4.11) / FXO шлюзы (Dynamix, OvisLink, Planet, etc) / разные IP-телефоны (OvisLink, Grandstream, Dynamix, Nokia, Cisco ATA-186, etc)
| Цитата: |
| cat /proc/sys/net/ipv4/conf/eth1/proxy_arp 1 |
Added after 42 seconds:
рутинг так и не пашет
Понадобится поддержка бриджа в ядре: 802.1d Ethernet Bridging(CONFIG_BRIDGE) и, естественно: Universal TUN/TAP device driver support (CONFIG_TUN).
Предположим, что у нас есть eth0 смотрящий в интернет и eth1 в локальную есть. В конфиге OpenVPN с обоих сторон указываем: dev tap.
Создаем бридж:
| Код: |
| brctl addbr br0 |
Добавляем в него интерфейс локальной сети:
| Код: |
| brctl addif br0 eth1 |
На стороне сервера в конфиге указываем скрипт, которые будут выполнятся при соединении клиента:
| Цитата: |
| client-connect /etc/openvpn/uconn.sh |
/etc/openvpn/uconn.sh:
| Код: |
| #!/bin/bash /sbin/brctl addif br0 $1 exit 0 |
И, в общем --- все. Естественно, выдавать клиенту нужно адреса из диапазона адресов локальной сети. Для управления бриджом нужен пакет: net-misc/bridge-utils
Вроде ничего не забыл.
Последний раз редактировалось: xelas (Пт Мар 21, 2008 22:27)
http://openvpn.net/index.php/documentati ... ing-subnet
_________________
Trixbox 2.2.x (Asterisk 1.4.11) / FXO шлюзы (Dynamix, OvisLink, Planet, etc) / разные IP-телефоны (OvisLink, Grandstream, Dynamix, Nokia, Cisco ATA-186, etc)
на стороне сервера:
| Код: |
| asteriskpbx conf.d # nmap -sP 192.168.0.* Starting Nmap 4.53 ( http://insecure.org ) at 2008-03-22 00:00 MSK Host 192.168.0.1 appears to be up. MAC Address: 00:17:9A:9C:AB:EE (D-Link) Host 192.168.0.2 appears to be up. Host 192.168.0.106 appears to be up. MAC Address: 00:1A:4D:9C:96:3E (Gigabyte Technology Co.) Host 192.168.0.119 appears to be up. MAC Address: 00:03:0D:4B:0D:82 (Uniwill Computer) Host 192.168.0.230 appears to be up. MAC Address: 00:0E:08:CD:D9:94 (Sipura Technology) Host 192.168.0.231 appears to be up. MAC Address: 00:1C:10:D0:04:67 (Cisco-Linksys) Host 192.168.0.232 appears to be up. MAC Address: 00:1C:10:CA:5F:38 (Cisco-Linksys) Host 192.168.0.233 appears to be up. MAC Address: 00:1C:10:D0:04:66 (Cisco-Linksys) Host 192.168.0.234 appears to be up. MAC Address: 00:0E:08:DD:87:30 (Sipura Technology) Host 192.168.0.235 appears to be up. MAC Address: 00:0E:08:D0:F9:8F (Sipura Technology) Host 192.168.0.236 appears to be up. MAC Address: 00:0E:08:DD:9C:0F (Sipura Technology) Host 192.168.0.237 appears to be up. MAC Address: 00:0E:08:DD:9C:15 (Sipura Technology) Nmap done: 256 IP addresses (12 hosts up) scanned in 2.686 seconds asteriskpbx conf.d # |
на стороне клиента:
| Код: |
| myhost conf.d # nmap -sP 192.168.0.* Starting Nmap 4.53 ( http://insecure.org ) at 2008-03-21 14:01 PDT Host 192.168.0.2 appears to be up. Host 192.168.0.3 appears to be up. Host 192.168.0.20 appears to be up. Nmap done: 256 IP addresses (3 hosts up) scanned in 27.919 seconds myhost conf.d # |
Added after 16 minutes:
сервер:
| Код: |
| asteriskpbx myhomelan # route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.0.20 0.0.0.0 255.255.255.255 UH 0 0 0 tun0 85.85.85.85 0.0.0.0 255.255.255.248 U 0 0 0 eth0 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 0.0.0.0 85.85.85.86 0.0.0.0 UG 0 0 0 eth0 asteriskpbx myhomelan # |
клиент:
| Код: |
| myhost myhomelan # route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.0.3 0.0.0.0 255.255.255.255 UH 0 0 0 tun0 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth3 192.168.0.0 192.168.0.3 255.255.255.0 UG 0 0 0 tun0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 0.0.0.0 192.168.1.2 0.0.0.0 UG 0 0 0 eth3 myhost myhomelan # |
| anest писал(а): |
| Но доступ есть только на машину на которой установлен vpn. А требуется также видеть и локалку в котрую есть доступ с этой машины. |
Аnest, У меня это работает так- OpenVPN сервак стоит на роутере. На нем же стоит Samba. Под Самбой шарю локалку (то что мне надо). Коннекчусь клиентом (WindowsXP) к серверу и вижу локалку!
А в чем проблемы Сэр?
да и собственно вопрос был не "как обойти" а "как это должно быть".
1. должно и с таким вариантом работать по идее - вижу в гугле что у людей работает. почему не работает у меня - загадка.
2. в настройке на генте довольно сложный вариант так как назначает eth0 пустой ип (а у меня на него завязано много чего) причем в некоторых инструкциях включается зачемто promisc mode на интерфейсе, и потом делает бриджинг с br0, довольно сложная схема получается и мне не совсем понятная. буду пробовать только если с первым вариантом действительно никак.
| xelas писал(а): |
| ...значение /proc/sys/net/ipv4/ip_forward. Дожно быть 1. |
| Код: |
| cat /proc/sys/net/ipv4/ip_forward 1 |
Странно. Приведу свой пример. Система Gentoo. net-misc/openvpn-2.0.7-r2
eth0 --- 195.xxx.xxx.194/30 Смотрит, понятное дело, в интернет.
eth1 --- 10.123.190.2/16 Смотрит в локальную сеть.
openvpn.conf:
| Код: |
| port 1194 proto udp dev tun ca /etc/openvpn/myca.pem cert /etc/openvpn/vpn.cer key /etc/openvpn/vpn.key dh /etc/openvpn/dh1024.pem crl-verify /etc/openvpn/crl.pem mode server tls-server server 10.10.20.0 255.255.255.0 ifconfig-pool-persist ipp.txt push "route 10.123.0.0 255.255.0.0" push "route 10.123.131.0 255.255.255.0" push "dhcp-option DNS 10.123.130.2" push "dhcp-option WINS 10.123.130.2" client-to-client client-config-dir ccd ;duplicate-cn keepalive 10 120 tls-auth ta.key 0 # This file is secret reneg-sec 86400 cipher BF-CBC # Blowfish (default) comp-lzo persist-key persist-tun status openvpn-status.log verb 3 |
После запуска openvpn создет tun интерфейс:
tun0 --- 10.10.20.1/32
и добавляет роут:
| Код: |
| Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 10.10.20.2 0.0.0.0 255.255.255.255 UH 0 0 0 tun0 10.10.20.0 10.10.20.2 255.255.255.0 UG 0 0 0 tun0 |
| Код: |
| openvpn # cat /proc/sys/net/ipv4/ip_forward 1 |
Как видно из приведенного выше --- адреса локальной сети и клиентов подключаемых по OpenVPN не совпадают. Для того что бы клиенты выдели локальную есть, и для того что бы локальная сеть видела клиентов на шлюзе по умолчанию прописан роут до клиентов OpenVPN:
route add -net 10.10.20.0 netmask 255.255.255.0 gw 10.123.190.2
И там же, на этом же шлюзе в iptables проковыряна дырка для этого трафика:
iptables -A FORWARD -s 10.123.0.0/16 -d 10.10.20.0/24 -j ACCEPT
iptables -A FORWARD -s 10.10.20.0/24 -d 10.123.0.0/16 -j ACCEPT
И все работает. Причем без proxy-arp.
при переносе этого примера на свою действительность. но думаю разберусь. просьба показать конфиг на стороне клиента еще. для полноты картины. и ipp.txt
локалка 10.10.30.0/24
адреса для клиентов 172.16.11/24
конфиг на сервере
| Код: |
| port 1194 proto udp dev tun ca ca.crt cert server.crt key server.key dh dh1024.pem server 172.16.11.0 255.255.255.0 ifconfig-pool-persist ipp.txt push "route 10.10.30.0 255.255.255.0" push "dhcp-option DNS 10.10.30.241" push "dhcp-option WINS 10.10.30.2" client-to-client duplicate-cn keepalive 10 120 tls-auth ta.key 0 comp-lzo push comp-lzo daemon max-clients 100 status openvpn-status.log verb 3 |
iptables
| Код: |
| -A INPUT -i tun+ -j ACCEPT -A INPUT -p udp -m udp --dport 1194 -j ACCEPT -A FORWARD -i tun+ -j ACCEPT -A FORWARD -o tun+ -m state --state RELATED,ESTABLISHED -j ACCEPT |
на клиенте
| Код: |
| ca ca.crt cert cache.crt key cache.key dev tun client remote 193.XXX.XXX.XXX 1194 redirect-gateway comp-lzo ns-cert-type server tls-auth ta.key 1 |
ipp.txt
| Код: |
| cache,172.16.11.4 servak,172.16.11.8 houseadmin,172.16.11.12 mariha,172.16.11.16 |
_________________
нанотехнолигии в области Asterisk
| anest писал(а): |
| просьба показать конфиг на стороне клиента еще. для полноты картины. и ipp.txt |
| Код: |
| client dev tun proto udp remote 195.x.x.194 1194 resolv-retry infinite nobind persist-key persist-tun ca ca.crt cert client.crt key client.key tls-auth ta.key 1 tls-remote vpn.x.ru tls-client reneg-sec 86400 cipher BF-CBC comp-lzo verb 3 up /etc/openvpn/up.sh down /etc/openvpn/down.sh |
| Код: |
| sinitsa@home ~ $ sudo cat /etc/openvpn/up.sh #!/bin/bash /sbin/iptables -t nat -A POSTROUTING -o $1 -j MASQUERADE /sbin/iptables -A INPUT -i $1 -j ACCEPT sinitsa@home ~ $ sudo cat /etc/openvpn/down.sh #!/bin/bash /sbin/iptables -t nat -D POSTROUTING -o $1 -j MASQUERADE /sbin/iptables -D INPUT -i $1 -j ACCEPT |
Скприты, поднимающие маскарадинг на стороне клиента нужны для того, что бы локальная сеть клиента могла без проблем попадать в удаленную локальную сеть.
чудеса продолжаются.. а именно, оказывается что всетки вижу другие ip в сетке НО не все а только половину примерно, причем както выборочно
предполагаю что вижу счас только те которые получили с утра ипешники на dhcpd а вот те которые уже давно висят онлайн - адаптеры (и ип вписаны вручную в железках) по vpn не вижу их вообще хотя с сервера очень даже доступны. все ип в одноранговой сети 192.168.0.x. ктонить может обьяснить мне сей феномен?
Added after 3 minutes:
с моей машины:
| Цитата: |
| myhost openvpn # nmap -sP 192.168.0.* Starting Nmap 4.53 ( http://insecure.org ) at 2008-04-02 03:43 PDT Host 192.168.0.2 appears to be up. Host 192.168.0.101 appears to be up. Host 192.168.0.102 appears to be up. Host 192.168.0.104 appears to be up. Host 192.168.0.106 appears to be up. Host 192.168.0.250 appears to be up. Nmap done: 256 IP addresses (6 hosts up) scanned in 261.911 seconds myhost openvpn # |
на сервере:
| Цитата: |
| asteriskpbx openvpn # nmap -sP 192.168.0.* Starting Nmap 4.53 ( http://insecure.org ) at 2008-04-02 14:49 MSD Host 192.168.0.2 appears to be up. Host 192.168.0.100 appears to be up. MAC Address: 00:13:A9:C2:2E:9D (Sony) Host 192.168.0.101 appears to be up. MAC Address: 00:90:F5:54:7A:4B (Clevo CO.) Host 192.168.0.102 appears to be up. MAC Address: 00:1B:FC:30:F9:24 (Asustek Computer) Host 192.168.0.104 appears to be up. MAC Address: 00:1B:38:5E:20:DC (Compal Information (kunshan) CO.) Host 192.168.0.105 appears to be up. MAC Address: 00:1B:38:2C:63:E0 (Compal Information (kunshan) CO.) Host 192.168.0.106 appears to be up. MAC Address: 00:0C:6E:88:0E:E0 (Asustek Computer) Host 192.168.0.107 appears to be up. MAC Address: 00:16:D4:B9:26:50 (Compal Communications) Host 192.168.0.188 appears to be up. MAC Address: 00:1B:38:5E:20:DB (Compal Information (kunshan) CO.) Host 192.168.0.231 appears to be up. MAC Address: 00:1C:10:D0:04:67 (Cisco-Linksys) Host 192.168.0.232 appears to be up. MAC Address: 00:1C:10:CA:5F:38 (Cisco-Linksys) Host 192.168.0.233 appears to be up. MAC Address: 00:1C:10:D0:04:66 (Cisco-Linksys) Host 192.168.0.234 appears to be up. MAC Address: 00:0E:08:DD:87:30 (Sipura Technology) Host 192.168.0.235 appears to be up. MAC Address: 00:0E:08:D0:F9:8F (Sipura Technology) Host 192.168.0.236 appears to be up. MAC Address: 00:0E:08:DD:9C:0F (Sipura Technology) Host 192.168.0.237 appears to be up. MAC Address: 00:0E:08:DD:9C:15 (Sipura Technology) Host 192.168.0.250 appears to be up. MAC Address: 00:1A:4D:9C:96:3E (Gigabyte Technology Co.) Nmap done: 256 IP addresses (17 hosts up) scanned in 2.678 seconds asteriskpbx openvpn # |
| anest писал(а): |
| а вот те которые уже давно висят онлайн - адаптеры (и ип вписаны вручную в железках) по vpn не вижу их вообще хотя с сервера очень даже доступны. все ип в одноранговой сети 192.168.0.x. ктонить может обьяснить мне сей феномен? |
Может быть у этих железок не прописан шлюз по умолчанию или прописан другой?
как такое вообще может быть возможно?
Added after 1 minutes:
шлюз везде один и тот же - eth1 на сервере с 192.168.0.2, на нем же dhcpd - общий для всех.
с клиента VPN, и посмотреть приходят ли на этот интерфейс ответы на эти пинги.
Таким образом поймем хотя бы в каком месте затык
NB: eth1 -- приведен для примера, должен быть указан интерфейс смотрящий в локальную сеть.
| Цитата: |
| asteriskpbx dhcp # tcpdump -ni eth1 proto 1 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth1, link-type EN10MB (Ethernet), capture size 68 bytes 15:29:08.695871 IP 172.16.1.20 > 192.168.0.233: ICMP echo request, id 548, seq 70, length 64 15:29:09.696998 IP 172.16.1.20 > 192.168.0.233: ICMP echo request, id 548, seq 71, length 64 15:29:10.696932 IP 172.16.1.20 > 192.168.0.233: ICMP echo request, id 548, seq 72, length 64 15:29:11.696531 IP 172.16.1.20 > 192.168.0.233: ICMP echo request, id 548, seq 73, length 64 15:29:12.696484 IP 172.16.1.20 > 192.168.0.233: ICMP echo request, id 548, seq 74, length 64 15:29:13.696349 IP 172.16.1.20 > 192.168.0.233: ICMP echo request, id 548, seq 75, length 64 15:29:14.696953 IP 172.16.1.20 > 192.168.0.233: ICMP echo request, id 548, seq 76, length 64 15:29:15.699723 IP 172.16.1.20 > 192.168.0.233: ICMP echo request, id 548, seq 77, length 64 15:29:16.696728 IP 172.16.1.20 > 192.168.0.233: ICMP echo request, id 548, seq 78, length 64 9 packets captured 9 packets received by filter 0 packets dropped by kernel asteriskpbx dhcp # |
Added after 37 seconds:
в тоже время на клиенте ответа нет
Added after 9 minutes:
а если пингую 192.168.0.101
| Цитата: |
| 15:38:57.079792 IP 172.16.1.20 > 192.168.0.101: ICMP echo request, id 53028, seq 1, length 64 15:38:57.080012 IP 192.168.0.101 > 172.16.1.20: ICMP echo reply, id 53028, seq 1, length 64 15:38:58.078709 IP 172.16.1.20 > 192.168.0.101: ICMP echo request, id 53028, seq 2, length 64 15:38:58.078922 IP 192.168.0.101 > 172.16.1.20: ICMP echo reply, id 53028, seq 2, length 64 15:38:59.073736 IP 172.16.1.20 > 192.168.0.101: ICMP echo request, id 53028, seq 3, length 64 15:38:59.073947 IP 192.168.0.101 > 172.16.1.20: ICMP echo reply, id 53028, seq 3, length 64 15:39:00.074290 IP 172.16.1.20 > 192.168.0.101: ICMP echo request, id 53028, seq 4, length 64 15:39:00.074505 IP 192.168.0.101 > 172.16.1.20: ICMP echo reply, id 53028, seq 4, length 64 |
на клиенте получаю ответ, причем nmap его тоже увидел сразу с клиента.
мистика!!
| Код: |
| 15:29:08.695871 IP 172.16.1.20 > 192.168.0.233: ICMP echo request, id 548, seq 70, length 64 |
Ну вот видите, пинги от клиента идут, а вот ответов нет. Отсюда я делаю вывод 192.168.0.233 не знает где находится 172.16.1.20. Учитывая что другие машины видно(значит на шлюзе по умолчанию прописан роут до 172.16.1.20), можно сделать вывод: на 192.168.0.233 не прописан шлюз по умолчанию, либо он там не такой как у тех кого видно, ну или третий и последний вариат: он просто не отвечает на пинги(файрвол в железке?).
Других вариантов мне в голову не приходит.
кстати как сделать ssh тунель на любой ip внутри сети и на любой порт - может комуто еще пригодится:
например нужно попасть из дома на GUI внутренней железки в офисе, делаем так
| Цитата: |
| ssh -L 81:10.0.2.10:80 user@office.net |
где 10.0.2.10 это внутренний ip.
затем открываем у себя в браузере следующую ссылку:
| Цитата: |
| http://localhost:81 |
причем никаких портов на файрволе нигде специально открывать не нужно!
можно сразу на несколько машин(или портов) сделать тунели за раз:
| Цитата: |
| ssh -L 81:10.0.2.10:80 -L 82:10.0.2.20:80 -L 83:10.0.2.30:80 user@office.net |
соответственно будут доступны на локальных портах 81,82 и 83.
большое спасибо всем ответившим мне!
vpn работает замечательно. просто я для проверки все время ломился на пару адаптеров с кривым гатвеем в настройках, как выяснилось. всем еще раз спасибо.