forum.opennet.ru - "openvpn net-to-net" (10)

форумы

помощь

поиск

регистрация

майллист

вход/выход

слежка

"openvpn net-to-net"

Форум Открытые системы на сервере (VPN / FreeBSD)
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"openvpn net-to-net"	+/–
Сообщение от dile (ok) on 13-Дек-11, 14:35
Имеется две машины Freebsd в двух точках. openvpn между ними настроен(по крайней мере связывается). То что относится к делу: server1 tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500 options=80000<LINKSTATE> inet 192.168.1.161 --> 192.168.1.162 netmask 0xffffffff Opened by PID 12986 Destination Gateway Flags Refs Use Netif Expire 192.168.1.160/28 192.168.1.162 UGS 0 681 tun0 192.168.1.161 link#5 UHS 0 5 lo0 192.168.1.162 link#5 UH 0 6 tun0 192.168.12.0/22 192.168.1.162 UGS 0 121 tun0 # ipnat -l List of active MAP/Redirect filters: map tun0 from 192.168.1.0/24 to 192.168.12.0/22 -> 192.168.1.161/32 proxy port ftp ftp/tcp map tun0 from 192.168.1.0/24 to 192.168.12.0/22 -> 192.168.1.161/32 portmap tcp/udp auto map tun0 192.168.1.0/24 -> 192.168.1.161/32 icmpidmap icmp 64000:65535 client1 tun0: flags=8151<UP,POINTOPOINT,RUNNING,PROMISC,MULTICAST> metric 0 mtu 1500 options=80000<LINKSTATE> inet 192.168.1.166 --> 192.168.1.165 netmask 0xffffffff Opened by PID 55557 Internet: Destination Gateway Flags Refs Use Netif Expire 127.0.0.1 link#4 UH 0 6598267 lo0 192.168.1.0/24 192.168.1.165 UGS 0 1342 tun0 192.168.1.161/32 192.168.1.165 UGS 0 94 tun0 192.168.1.165 link#8 UH 0 0 tun0 192.168.1.166 link#8 UHS 0 0 lo0 # ipnat -l map tun0 from 192.168.12.0/22 to 192.168.1.0/24 -> 192.168.1.166/32 proxy port ftp ftp/tcp map tun0 from 192.168.12.0/22 to 192.168.1.0/24 -> 192.168.1.166/32 portmap tcp/udp auto map tun0 192.168.12.0/22 -> 192.168.1.166/32 icmpidmap icmp 64000:65535 Из сети в сеть не ходит(фаервол не причем). loopbak vpn интерфейсы пингуются оба из сети. А в целом получилось полная абра-кадабра. С клиента: # ping 192.168.1.19 PING 192.168.1.19 (192.168.1.19): 56 data bytes 64 bytes from 192.168.1.161: icmp_seq=0 ttl=64 time=4.328 ms # tcpdump -i tun0 14:26:10.721636 IP 192.168.1.166 > 192.168.1.9: ICMP echo request, id 49376, seq 13, length 64 14:26:10.724423 IP 192.168.1.161 > 192.168.1.166: ICMP echo reply, id 49376, seq 13, length 64 С сервера на клиент не пингует. Вопрос: как правильно настроить сеть-сеть через openvpn по науке и по уму
Ответить \| Правка \| Cообщить модератору

Оглавление

openvpn net-to-net, reader, 16:08 , 13-Дек-11, (1)

openvpn net-to-net, dile, 14:10 , 14-Дек-11, (2)

openvpn net-to-net, dile, 15:13 , 15-Дек-11, (3)

openvpn net-to-net, reader, 16:00 , 15-Дек-11, (4)

openvpn net-to-net, dile, 10:21 , 16-Дек-11, (5)

openvpn net-to-net, reader, 11:12 , 16-Дек-11, (6)

openvpn net-to-net, dile, 11:53 , 16-Дек-11, (7)

openvpn net-to-net, dile, 17:01 , 20-Дек-11, (8)

openvpn net-to-net, reader, 17:32 , 20-Дек-11, (9)

openvpn net-to-net, dile, 15:48 , 10-Апр-12, (10)

Сообщения по теме [Сортировка по времени | RSS]

1. "openvpn net-to-net" +/–

Сообщение от reader (ok) on 13-Дек-11, 16:08

http://www.opennet.me/openforum/vsluhforumID1/91287.html?n=r...

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "openvpn net-to-net" +/–

Сообщение от dile (ok) on 14-Дек-11, 14:10

> http://www.opennet.me/openforum/vsluhforumID1/91287.html?n=r...
с tap заработал, спасибо за наводку

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

3. "openvpn net-to-net" +/–

Сообщение от dile (ok) on 15-Дек-11, 15:13

Теперь так:
Сервер:
tap0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=80000<LINKSTATE>
        ether 00:bd:40:a3:64:00
        inet 192.168.1.161 netmask 0xfffffff0 broadcast 192.168.1.175
        Opened by PID 56033
192.168.1.160/28   link#5             U           1      210   tap0
192.168.1.161      link#5             UHS         0        0    lo0
192.168.12.0/22    192.168.1.164      UGS         0    16113   tap0
#ipnat -l
map tap0 from 192.168.1.0/24 to 192.168.12.0/22 -> 192.168.1.161/32 proxy port ftp ftp/tcp
map tap0 from 192.168.1.0/24 to 192.168.12.0/22 -> 192.168.1.161/32 portmap tcp/udp auto
map tap0 192.168.1.0/24 -> 192.168.1.161/32 icmpidmap icmp 64000:65535
ipnat.rules
map tap0 from 192.168.12.0/22 to 192.168.1.0/24 -> 192.168.1.164/32 proxy port ftp ftp/tcp
map tap0 from 192.168.12.0/22 to 192.168.1.0/24 -> 192.168.1.164/32 portmap tcp/udp auto
map tap0 from 192.168.12.0/22 to 192.168.1.0/24 -> 192.168.1.164/32 icmpidmap icmp 64000:65535

Клиент:
tap0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=80000<LINKSTATE>
        ether 00:bd:d2:e0:a1:00
        inet 192.168.1.164 netmask 0xfffffff0 broadcast 192.168.1.175
        Opened by PID 76938
192.168.1.0/24     192.168.1.161      UGS         0     2588   tap0
192.168.1.160/28   link#8             U           0    15854   tap0
192.168.1.164      link#8             UHS         0        0    lo0
#ipnat -l
map tap0 from 192.168.12.0/22 to 192.168.1.0/24 -> 192.168.1.164/32 proxy port ftp ftp/tcp
map tap0 from 192.168.12.0/22 to 192.168.1.0/24 -> 192.168.1.164/32 portmap tcp/udp auto
map tap0 192.168.12.0/22 -> 192.168.1.164/32 icmpidmap icmp 64000:65535
#ipnat.rules
map tap0 from 192.168.1.0/24 to 192.168.12.0/22 -> 192.168.1.161/32 proxy port ftp ftp/tcp
map tap0 from 192.168.1.0/24 to 192.168.12.0/22 -> 192.168.1.161/32 portmap tcp/udp auto
map tap0 from 192.168.1.0/24 to 192.168.12.0/22 -> 192.168.1.161/32 icmpidmap icmp 64000:65535

Результат:
с сервера в сеть клиента идет пинг
# ping 192.168.14.100
PING 192.168.14.100 (192.168.14.100): 56 data bytes
64 bytes from 192.168.1.164: icmp_seq=0 ttl=127 time=3.820 ms
Но все что касается tcp соединений(ssh) не проходит.
Выдержка tcpdump с клиента.
15:08:28.551233 IP 192.168.1.161.65042 > 192.168.1.164.ssh: Flags [R], seq 562607220, win 0, length 0
15:08:30.716933 IP 192.168.1.161 > 192.168.14.100: ICMP echo request, id 768, seq 11073, length 40
15:08:30.717257 IP 192.168.1.164 > 192.168.1.161: ICMP echo reply, id 768, seq 11073, length 40
15:08:34.548745 IP 192.168.1.164.ssh > 192.168.1.161.21706: Flags [S.], seq 1512465607, ack 562607220, win 65535, options [mss 1336,nop,wscale 3,sackOK,eol], length 0
15:08:34.552098 IP 192.168.1.161.65042 > 192.168.1.164.ssh: Flags [R], seq 562607220, win 0, length 0
15:08:36.216685 IP 192.168.1.161 > 192.168.14.100: ICMP echo request, id 768, seq 11329, length 40
15:08:36.217010 IP 192.168.1.164 > 192.168.1.161: ICMP echo reply, id 768, seq 11329, length 40
15:08:37.747812 IP 192.168.1.161.21706 > jim.remt.local.ssh: Flags [S], seq 562607219, win 65535, options [mss 1336,sackOK,eol], length 0
15:08:37.747950 IP 192.168.1.164.ssh > 192.168.1.161.21706: Flags [S.], seq 1512465607, ack 562607220, win 65535, options [mss 1336,nop,wscale 3,sackOK,eol], length 0
15:08:37.750972 IP 192.168.1.161.65042 > 192.168.1.164.ssh: Flags [R], seq 562607220, win 0, length 0
15:08:40.747337 IP 192.168.1.164.ssh > 192.168.1.161.21706: Flags [S.], seq 1512465607, ack 562607220, win 65535, options [mss 1336,nop,wscale 3,sackOK,eol], length 0
15:08:40.750862 IP 192.168.1.161.65042 > 192.168.1.164.ssh: Flags [R], seq 562607220, win 0, length 0
15:08:41.716701 IP 192.168.1.161 > 192.168.14.100: ICMP echo request, id 768, seq 11585, length 40
15:08:41.717010 IP 192.168.1.164 > 192.168.1.161: ICMP echo reply, id 768, seq 11585, length 40
15:08:46.747891 IP 192.168.1.164.ssh > 192.168.1.161.21706: Flags [S.], seq 1512465607, ack 562607220, win 65535, options [mss 1336,nop,wscale 3,sackOK,eol], length 0
15:08:46.750733 IP 192.168.1.161.65042 > 192.168.1.164.ssh: Flags [R], seq 562607220, win 0, length 0
15:08:47.216642 IP 192.168.1.161 > 192.168.14.100: ICMP echo request, id 768, seq 11841, length 40
15:08:47.217017 IP 192.168.1.164 > 192.168.1.161: ICMP echo reply, id 768, seq 11841, length 40
15:08:52.716580 IP 192.168.1.161 > 192.168.14.100: ICMP echo request, id 768, seq 12097, length 40
15:08:52.716924 IP 192.168.1.164 > 192.168.1.161: ICMP echo reply, id 768, seq 12097, length 40
15:08:58.216423 IP 192.168.1.161 > 192.168.14.100: ICMP echo request, id 768, seq 12353, length 40
15:08:58.216783 IP 192.168.1.164 > 192.168.1.161: ICMP echo reply, id 768, seq 12353, length 40
15:08:58.749002 IP 192.168.1.164.ssh > 192.168.1.161.21706: Flags [S.], seq 1512465607, ack 562607220, win 65535, options [mss 1336,nop,wscale 3,sackOK,eol], length 0
15:08:58.752068 IP 192.168.1.161.65042 > 192.168.1.164.ssh: Flags [R], seq 562607220, win 0, length 0
Подскажите в чем дело, в каком направлении идти.

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

4. "openvpn net-to-net" +/–

Сообщение от reader (ok) on 15-Дек-11, 16:00

192.168.1.164.ssh > 192.168.1.161.21706: Flags [S.], seq 1512465607, ack 562607220, win 65535, options [mss 1336,nop,wscale 3,sackOK,eol], length 0
несколько раз, похоже пакет не доходит до туда

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

5. "openvpn net-to-net" +/–

Сообщение от dile (ok) on 16-Дек-11, 10:21

> 192.168.1.164.ssh > 192.168.1.161.21706: Flags [S.], seq 1512465607, ack 562607220, win
> 65535, options [mss 1336,nop,wscale 3,sackOK,eol], length 0
> несколько раз, похоже пакет не доходит до туда
15:08:28.551233 IP 192.168.1.161.65042 > 192.168.1.164.ssh: Flags [R], seq 562607220, win 0, length 0
15:08:30.716933 IP 192.168.1.161 > 192.168.14.100: ICMP echo request, id 768, seq 11073, length 40
15:08:30.717257 IP 192.168.1.164 > 192.168.1.161: ICMP echo reply, id 768, seq 11073, length 40
15:08:34.548745 IP 192.168.1.164.ssh > 192.168.1.161.21706: Flags [S.], seq 1512465607, ack 562607220, win 65535, options [mss 1336,nop,wscale 3,sackOK,eol], length 0
161>164.ssh , потом 164.ssh>161 значит доходит на машине в клиентской сети
Просто похоже ipnat как-то не отрабатывает
С сервера vpn:
# ssh 192.168.14.2
ssh: connect to host 192.168.14.2 port 22: Operation timed out
На машине, к которой обращаюсь в сети клиента:
# tcpdump -n port 22 | grep 192.168.1.161
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on re0, link-type EN10MB (Ethernet), capture size 96 bytes
09:33:12.375897 IP 192.168.1.161.32561 > 192.168.14.2.22: Flags [S], seq 1748667508, win 65535, options [mss 1336,nop,wscale 3,sackOK,TS val 3340007363 ecr 0], length 0
09:33:12.375921 IP 192.168.14.2.22 > 192.168.1.161.32561: Flags [S.], seq 1397778113, ack 1748667509, win 65535, options [mss 1336,nop,wscale 3,sackOK,TS val 3034815067 ecr 3340007363], length 0
09:33:15.374689 IP 192.168.1.161.32561 > 192.168.14.2.22: Flags [S], seq 1748667508, win 65535, options [mss 1336,nop,wscale 3,sackOK,TS val 3340010363 ecr 0], length 0
09:33:15.374708 IP 192.168.14.2.22 > 192.168.1.161.32561: Flags [S.], seq 1397778113, ack 1748667509, win 65535, options [mss 1336,nop,wscale 3,sackOK,TS val 3034815067 ecr 3340010363], length 0
09:33:18.374169 IP 192.168.14.2.22 > 192.168.1.161.32561: Flags [S.], seq 1397778113, ack 1748667509, win 65535, options [mss 1336,nop,wscale 3,sackOK,TS val 3034815067 ecr 3340010363], length 0
09:33:18.574448 IP 192.168.1.161.32561 > 192.168.14.2.22: Flags [S], seq 1748667508, win 65535, options [mss 1336,nop,wscale 3,sackOK,TS val 3340013563 ecr 0], length 0
09:33:18.574468 IP 192.168.14.2.22 > 192.168.1.161.32561: Flags [S.], seq 1397778113, ack 1748667509, win 65535, options [mss 1336,nop,wscale 3,sackOK,TS val 3034815067 ecr 3340013563], length 0
09:33:21.574470 IP 192.168.14.2.22 > 192.168.1.161.32561: Flags [S.], seq 1397778113, ack 1748667509, win 65535, options [mss 1336,nop,wscale 3,sackOK,TS val 3034815067 ecr 3340013563], length 0
09:33:21.774626 IP 192.168.1.161.32561 > 192.168.14.2.22: Flags [S], seq 1748667508, win 65535, options [mss 1336,sackOK,eol], length 0
09:33:21.774645 IP 192.168.14.2.22 > 192.168.1.161.32561: Flags [S.], seq 1397778113, ack 1748667509, win 65535, options [mss 1336,nop,wscale 3,sackOK,eol], length 0
09:33:24.774761 IP 192.168.14.2.22 > 192.168.1.161.32561: Flags [S.], seq 1397778113, ack 1748667509, win 65535, options [mss 1336,nop,wscale 3,sackOK,eol], length 0
09:33:24.974610 IP 192.168.1.161.32561 > 192.168.14.2.22: Flags [S], seq 1748667508, win 65535, options [mss 1336,sackOK,eol], length 0
09:33:24.974629 IP 192.168.14.2.22 > 192.168.1.161.32561: Flags [S.], seq 1397778113, ack 1748667509, win 65535, options [mss 1336,nop,wscale 3,sackOK,eol], length 0
09:33:27.974064 IP 192.168.14.2.22 > 192.168.1.161.32561: Flags [S.], seq 1397778113, ack 1748667509, win 65535, options [mss 1336,nop,wscale 3,sackOK,eol], length 0
09:33:28.174574 IP 192.168.1.161.32561 > 192.168.14.2.22: Flags [S], seq 1748667508, win 65535, options [mss 1336,sackOK,eol], length 0
09:33:28.174592 IP 192.168.14.2.22 > 192.168.1.161.32561: Flags [S.], seq 1397778113, ack 1748667509, win 65535, options [mss 1336,nop,wscale 3,sackOK,eol], length 0
09:33:31.174354 IP 192.168.14.2.22 > 192.168.1.161.32561: Flags [S.], seq 1397778113, ack 1748667509, win 65535, options [mss 1336,nop,wscale 3,sackOK,eol], length 0
09:33:34.375826 IP 192.168.1.161.32561 > 192.168.14.2.22: Flags [S], seq 1748667508, win 65535, options [mss 1336,sackOK,eol], length 0
09:33:34.375845 IP 192.168.14.2.22 > 192.168.1.161.32561: Flags [S.], seq 1397778113, ack 1748667509, win 65535, options [mss 1336,nop,wscale 3,sackOK,eol], length 0
09:33:37.375937 IP 192.168.14.2.22 > 192.168.1.161.32561: Flags [S.], seq 1397778113, ack 1748667509, win 65535, options [mss 1336,nop,wscale 3,sackOK,eol], length 0
09:33:43.376487 IP 192.168.14.2.22 > 192.168.1.161.32561: Flags [S.], seq 1397778113, ack 1748667509, win 65535, options [mss 1336,nop,wscale 3,sackOK,eol], length 0
09:33:46.574383 IP 192.168.1.161.32561 > 192.168.14.2.22: Flags [S], seq 1748667508, win 65535, options [mss 1336,sackOK,eol], length 0
09:33:46.574401 IP 192.168.14.2.22 > 192.168.1.161.32561: Flags [S.], seq 1397778113, ack 1748667509, win 65535, options [mss 1336,nop,wscale 3,sackOK,eol], length 0
ipnat на сервере:
# cat ipnat.ssh.connect
List of active MAP/Redirect filters:
map tap0 from 192.168.1.0/24 to 192.168.12.0/22 -> 192.168.1.161/32 proxy port ftp ftp/tcp
map tap0 from 192.168.1.0/24 to 192.168.12.0/22 -> 192.168.1.161/32 portmap tcp/udp auto
map tap0 192.168.1.0/24 -> 192.168.1.161/32 icmpidmap icmp 64000:65535
List of active sessions:
MAP 192.168.1.161   32561 <- -> 192.168.1.161   64083 [192.168.1.164 22]
MAP 192.168.1.161   32561 <- -> 192.168.1.161   32561 [192.168.14.2 22]
        proxy ftp/6 use 1 flags 0
                proto 6 flags 0 bytes 420 pkts 8 data YES size 312
        FTP Proxy:
                passok: 1
        Client:
                seq 0 (ack 0) len 0 junk 0 cmds 0
                buf [\000]
        Server:
                seq 0 (ack 0) len 0 junk 0 cmds 0
                buf [\000]
MAP 192.168.1.7     3389  <- -> 192.168.1.161   3389  [192.168.14.113 1047]
        proxy ftp/6 use 1 flags 0
                proto 6 flags 0 bytes 224 pkts 5 data YES size 312
        FTP Proxy:
                passok: 1
        Client:
                seq e7fd7091 (ack 0) len 0 junk 0 cmds 0
                buf [\000]
        Server:
                seq 9fa8bfa1 (ack 0) len 0 junk 0 cmds 0
                buf [\000]

иногда выдает такое:
# ipnat -l
List of active MAP/Redirect filters:
unknown value for in_redir: 0
  0.0.0.0/0 -> 0.0.0.0/0
List of active sessions:
unknown(0000) 0.0.0.0         <- -> 0.0.0.0         [0.0.0.0]

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

6. "openvpn net-to-net" +/–

Сообщение от reader (ok) on 16-Дек-11, 11:12

>> 192.168.1.164.ssh > 192.168.1.161.21706: Flags [S.], seq 1512465607, ack 562607220, win
>> 65535, options [mss 1336,nop,wscale 3,sackOK,eol], length 0
>> несколько раз, похоже пакет не доходит до туда
> 15:08:28.551233 IP 192.168.1.161.65042 > 192.168.1.164.ssh: Flags [R], seq 562607220,
> win 0, length 0
клиент сбрасывает предыдущую сесию ssh (порт 65042)
> 15:08:30.716933 IP 192.168.1.161 > 192.168.14.100: ICMP echo request, id 768, seq 11073,
> length 40
> 15:08:30.717257 IP 192.168.1.164 > 192.168.1.161: ICMP echo reply, id 768, seq 11073,
> length 40
> 15:08:34.548745 IP 192.168.1.164.ssh > 192.168.1.161.21706: Flags [S.], seq 1512465607,
> ack 562607220, win 65535, options [mss 1336,nop,wscale 3,sackOK,eol], length 0
ответ на попытку клиента ssh установить соединение с sshd (это другая сесия , порт 21706), таких пакетов было несколько, а подтверждений со стороны клиента нет
откуда инициируется соединение с sshd, с машины с vpn сервером или из локалки за vpn сервером?
снимите дамп с машины с которой подключаетесь к sshd.

>[оверквотинг удален]
>
>     buf [\000]
> иногда выдает такое:
> # ipnat -l
> List of active MAP/Redirect filters:
> unknown value for in_redir: 0
>   0.0.0.0/0 -> 0.0.0.0/0
> List of active sessions:
> unknown(0000) 0.0.0.0         <- ->
> 0.0.0.0         [0.0.0.0]
с ipnat не ковырялся, поэтому по нему не скажу ничего. А в целом для чего вы его решили использовать? По моему там нужна только маршрутизация.

Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

7. "openvpn net-to-net" +/–

Сообщение от dile (ok) on 16-Дек-11, 11:53

> с ipnat не ковырялся, поэтому по нему не скажу ничего. А в
> целом для чего вы его решили использовать? По моему там нужна
> только маршрутизация.
Отключил и все заработало. С tun-ом вроде как нужен был.

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

8. "openvpn net-to-net" +/–

Сообщение от dile (ok) on 20-Дек-11, 17:01

>> с ipnat не ковырялся, поэтому по нему не скажу ничего. А в
>> целом для чего вы его решили использовать? По моему там нужна
>> только маршрутизация.
> Отключил и все заработало. С tun-ом вроде как нужен был.
Теперь небольшая проблема с настройкой роутинга.
При использовании tap разадча через ccd не работает, если я правильно понял комментарий.
  # This example will only work
  # if you are routing, not bridging, i.e. you are
  # using "dev tun" and "server" directives.
Директива push отдает маршрутом указанные сети в tap интерфейс сервера. Клиент получает роутинг:
192.168.1.0/24     192.168.1.161      UGS         0       22   tap0
192.168.1.160/28   link#8             U           0        0   tap0
192.168.1.164      link#8             UHS         0        0    lo0
192.168.2.0/24     192.168.1.161      UGS         0        0   tap0
А вот сервер ни чего не знает о сети клиента. тлько если в ручную дать route add.
route add -net 192.168.12.0/22 192.168.1.164
Как можно сделать на самом сервере автоматически добавляемую маршрутизацию при коннекте клиента или старте сервиса. И как тогда зафиксировать получаемый ip на стороне клиента.

Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

9. "openvpn net-to-net" +/–

Сообщение от reader (ok) on 20-Дек-11, 17:32

>>> с ipnat не ковырялся, поэтому по нему не скажу ничего. А в
>>> целом для чего вы его решили использовать? По моему там нужна
>>> только маршрутизация.
>> Отключил и все заработало. С tun-ом вроде как нужен был.
> Теперь небольшая проблема с настройкой роутинга.
> При использовании tap разадча через ccd не работает, если я правильно понял
> комментарий.
>   # This example will only work
>   # if you are routing, not bridging, i.e. you are
>   # using "dev tun" and "server" directives.
работает
ifconfig-push 10.1.0.2 255.255.255.0
push "route 10.10.0.0 255.255.255.0"
>[оверквотинг удален]
>   0    lo0
> 192.168.2.0/24     192.168.1.161      UGS
>         0
>      0   tap0
> А вот сервер ни чего не знает о сети клиента. тлько если
> в ручную дать route add.
>  route add -net 192.168.12.0/22 192.168.1.164
> Как можно сделать на самом сервере автоматически добавляемую маршрутизацию при коннекте
> клиента или старте сервиса. И как тогда зафиксировать получаемый ip на
> стороне клиента.
для при старте сервера, поидее в его конфиге route 192.168.4.0 255.255.255.0

Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

10. "openvpn net-to-net" +/–

Сообщение от dile (ok) on 10-Апр-12, 15:48

>[оверквотинг удален]
>>> Отключил и все заработало. С tun-ом вроде как нужен был.
>> Теперь небольшая проблема с настройкой роутинга.
>> При использовании tap разадча через ccd не работает, если я правильно понял
>> комментарий.
>>   # This example will only work
>>   # if you are routing, not bridging, i.e. you are
>>   # using "dev tun" and "server" directives.
> работает
> ifconfig-push 10.1.0.2 255.255.255.0
> push "route 10.10.0.0 255.255.255.0"
нет не работает, перевод куска
[q]
Этот пример будет работать только
# если у вас режим роутера, но не моста, т.е. вы
# используете директивы "dev tun" и "server".
[/q]
причем push на клиент нормально отрабатывает оп всем прописанным сетям
>[оверквотинг удален]
>> 192.168.2.0/24     192.168.1.161      UGS
>>         0
>>      0   tap0
>> А вот сервер ни чего не знает о сети клиента. тлько если
>> в ручную дать route add.
>>  route add -net 192.168.12.0/22 192.168.1.164
>> Как можно сделать на самом сервере автоматически добавляемую маршрутизацию при коннекте
>> клиента или старте сервиса. И как тогда зафиксировать получаемый ip на
>> стороне клиента.
> для при старте сервера, поидее в его конфиге route 192.168.4.0 255.255.255.0
Нет не годится, при запуске нет еще этого IP. Чисто технически это дело сервиса, а не системы.
Тема для обсуждения. Как по технологии openvpn управлять маршрутами на самом сервере c tap интерфейсами без режима server-bridge. learn-address ./script возможно ли применить и как примерно.

Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2025 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "openvpn net-to-net"	+/–
Сообщение от reader (ok) on 13-Дек-11, 16:08
http://www.opennet.me/openforum/vsluhforumID1/91287.html?n=r...
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	2. "openvpn net-to-net"	+/–
	Сообщение от dile (ok) on 14-Дек-11, 14:10
	> http://www.opennet.me/openforum/vsluhforumID1/91287.html?n=r... с tap заработал, спасибо за наводку
	Ответить \| Правка \| ^ к родителю #1 \| Наверх \| Cообщить модератору


	3. "openvpn net-to-net"	+/–
	Сообщение от dile (ok) on 15-Дек-11, 15:13
	Теперь так: Сервер: tap0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=80000<LINKSTATE> ether 00:bd:40:a3:64:00 inet 192.168.1.161 netmask 0xfffffff0 broadcast 192.168.1.175 Opened by PID 56033 192.168.1.160/28 link#5 U 1 210 tap0 192.168.1.161 link#5 UHS 0 0 lo0 192.168.12.0/22 192.168.1.164 UGS 0 16113 tap0 #ipnat -l map tap0 from 192.168.1.0/24 to 192.168.12.0/22 -> 192.168.1.161/32 proxy port ftp ftp/tcp map tap0 from 192.168.1.0/24 to 192.168.12.0/22 -> 192.168.1.161/32 portmap tcp/udp auto map tap0 192.168.1.0/24 -> 192.168.1.161/32 icmpidmap icmp 64000:65535 ipnat.rules map tap0 from 192.168.12.0/22 to 192.168.1.0/24 -> 192.168.1.164/32 proxy port ftp ftp/tcp map tap0 from 192.168.12.0/22 to 192.168.1.0/24 -> 192.168.1.164/32 portmap tcp/udp auto map tap0 from 192.168.12.0/22 to 192.168.1.0/24 -> 192.168.1.164/32 icmpidmap icmp 64000:65535 Клиент: tap0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=80000<LINKSTATE> ether 00:bd:d2:e0:a1:00 inet 192.168.1.164 netmask 0xfffffff0 broadcast 192.168.1.175 Opened by PID 76938 192.168.1.0/24 192.168.1.161 UGS 0 2588 tap0 192.168.1.160/28 link#8 U 0 15854 tap0 192.168.1.164 link#8 UHS 0 0 lo0 #ipnat -l map tap0 from 192.168.12.0/22 to 192.168.1.0/24 -> 192.168.1.164/32 proxy port ftp ftp/tcp map tap0 from 192.168.12.0/22 to 192.168.1.0/24 -> 192.168.1.164/32 portmap tcp/udp auto map tap0 192.168.12.0/22 -> 192.168.1.164/32 icmpidmap icmp 64000:65535 #ipnat.rules map tap0 from 192.168.1.0/24 to 192.168.12.0/22 -> 192.168.1.161/32 proxy port ftp ftp/tcp map tap0 from 192.168.1.0/24 to 192.168.12.0/22 -> 192.168.1.161/32 portmap tcp/udp auto map tap0 from 192.168.1.0/24 to 192.168.12.0/22 -> 192.168.1.161/32 icmpidmap icmp 64000:65535 Результат: с сервера в сеть клиента идет пинг # ping 192.168.14.100 PING 192.168.14.100 (192.168.14.100): 56 data bytes 64 bytes from 192.168.1.164: icmp_seq=0 ttl=127 time=3.820 ms Но все что касается tcp соединений(ssh) не проходит. Выдержка tcpdump с клиента. 15:08:28.551233 IP 192.168.1.161.65042 > 192.168.1.164.ssh: Flags [R], seq 562607220, win 0, length 0 15:08:30.716933 IP 192.168.1.161 > 192.168.14.100: ICMP echo request, id 768, seq 11073, length 40 15:08:30.717257 IP 192.168.1.164 > 192.168.1.161: ICMP echo reply, id 768, seq 11073, length 40 15:08:34.548745 IP 192.168.1.164.ssh > 192.168.1.161.21706: Flags [S.], seq 1512465607, ack 562607220, win 65535, options [mss 1336,nop,wscale 3,sackOK,eol], length 0 15:08:34.552098 IP 192.168.1.161.65042 > 192.168.1.164.ssh: Flags [R], seq 562607220, win 0, length 0 15:08:36.216685 IP 192.168.1.161 > 192.168.14.100: ICMP echo request, id 768, seq 11329, length 40 15:08:36.217010 IP 192.168.1.164 > 192.168.1.161: ICMP echo reply, id 768, seq 11329, length 40 15:08:37.747812 IP 192.168.1.161.21706 > jim.remt.local.ssh: Flags [S], seq 562607219, win 65535, options [mss 1336,sackOK,eol], length 0 15:08:37.747950 IP 192.168.1.164.ssh > 192.168.1.161.21706: Flags [S.], seq 1512465607, ack 562607220, win 65535, options [mss 1336,nop,wscale 3,sackOK,eol], length 0 15:08:37.750972 IP 192.168.1.161.65042 > 192.168.1.164.ssh: Flags [R], seq 562607220, win 0, length 0 15:08:40.747337 IP 192.168.1.164.ssh > 192.168.1.161.21706: Flags [S.], seq 1512465607, ack 562607220, win 65535, options [mss 1336,nop,wscale 3,sackOK,eol], length 0 15:08:40.750862 IP 192.168.1.161.65042 > 192.168.1.164.ssh: Flags [R], seq 562607220, win 0, length 0 15:08:41.716701 IP 192.168.1.161 > 192.168.14.100: ICMP echo request, id 768, seq 11585, length 40 15:08:41.717010 IP 192.168.1.164 > 192.168.1.161: ICMP echo reply, id 768, seq 11585, length 40 15:08:46.747891 IP 192.168.1.164.ssh > 192.168.1.161.21706: Flags [S.], seq 1512465607, ack 562607220, win 65535, options [mss 1336,nop,wscale 3,sackOK,eol], length 0 15:08:46.750733 IP 192.168.1.161.65042 > 192.168.1.164.ssh: Flags [R], seq 562607220, win 0, length 0 15:08:47.216642 IP 192.168.1.161 > 192.168.14.100: ICMP echo request, id 768, seq 11841, length 40 15:08:47.217017 IP 192.168.1.164 > 192.168.1.161: ICMP echo reply, id 768, seq 11841, length 40 15:08:52.716580 IP 192.168.1.161 > 192.168.14.100: ICMP echo request, id 768, seq 12097, length 40 15:08:52.716924 IP 192.168.1.164 > 192.168.1.161: ICMP echo reply, id 768, seq 12097, length 40 15:08:58.216423 IP 192.168.1.161 > 192.168.14.100: ICMP echo request, id 768, seq 12353, length 40 15:08:58.216783 IP 192.168.1.164 > 192.168.1.161: ICMP echo reply, id 768, seq 12353, length 40 15:08:58.749002 IP 192.168.1.164.ssh > 192.168.1.161.21706: Flags [S.], seq 1512465607, ack 562607220, win 65535, options [mss 1336,nop,wscale 3,sackOK,eol], length 0 15:08:58.752068 IP 192.168.1.161.65042 > 192.168.1.164.ssh: Flags [R], seq 562607220, win 0, length 0 Подскажите в чем дело, в каком направлении идти.
	Ответить \| Правка \| ^ к родителю #2 \| Наверх \| Cообщить модератору


	4. "openvpn net-to-net"	+/–
	Сообщение от reader (ok) on 15-Дек-11, 16:00
	192.168.1.164.ssh > 192.168.1.161.21706: Flags [S.], seq 1512465607, ack 562607220, win 65535, options [mss 1336,nop,wscale 3,sackOK,eol], length 0 несколько раз, похоже пакет не доходит до туда
	Ответить \| Правка \| ^ к родителю #3 \| Наверх \| Cообщить модератору


	5. "openvpn net-to-net"	+/–
	Сообщение от dile (ok) on 16-Дек-11, 10:21
	> 192.168.1.164.ssh > 192.168.1.161.21706: Flags [S.], seq 1512465607, ack 562607220, win > 65535, options [mss 1336,nop,wscale 3,sackOK,eol], length 0 > несколько раз, похоже пакет не доходит до туда 15:08:28.551233 IP 192.168.1.161.65042 > 192.168.1.164.ssh: Flags [R], seq 562607220, win 0, length 0 15:08:30.716933 IP 192.168.1.161 > 192.168.14.100: ICMP echo request, id 768, seq 11073, length 40 15:08:30.717257 IP 192.168.1.164 > 192.168.1.161: ICMP echo reply, id 768, seq 11073, length 40 15:08:34.548745 IP 192.168.1.164.ssh > 192.168.1.161.21706: Flags [S.], seq 1512465607, ack 562607220, win 65535, options [mss 1336,nop,wscale 3,sackOK,eol], length 0 161>164.ssh , потом 164.ssh>161 значит доходит на машине в клиентской сети Просто похоже ipnat как-то не отрабатывает С сервера vpn: # ssh 192.168.14.2 ssh: connect to host 192.168.14.2 port 22: Operation timed out На машине, к которой обращаюсь в сети клиента: # tcpdump -n port 22 \| grep 192.168.1.161 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on re0, link-type EN10MB (Ethernet), capture size 96 bytes 09:33:12.375897 IP 192.168.1.161.32561 > 192.168.14.2.22: Flags [S], seq 1748667508, win 65535, options [mss 1336,nop,wscale 3,sackOK,TS val 3340007363 ecr 0], length 0 09:33:12.375921 IP 192.168.14.2.22 > 192.168.1.161.32561: Flags [S.], seq 1397778113, ack 1748667509, win 65535, options [mss 1336,nop,wscale 3,sackOK,TS val 3034815067 ecr 3340007363], length 0 09:33:15.374689 IP 192.168.1.161.32561 > 192.168.14.2.22: Flags [S], seq 1748667508, win 65535, options [mss 1336,nop,wscale 3,sackOK,TS val 3340010363 ecr 0], length 0 09:33:15.374708 IP 192.168.14.2.22 > 192.168.1.161.32561: Flags [S.], seq 1397778113, ack 1748667509, win 65535, options [mss 1336,nop,wscale 3,sackOK,TS val 3034815067 ecr 3340010363], length 0 09:33:18.374169 IP 192.168.14.2.22 > 192.168.1.161.32561: Flags [S.], seq 1397778113, ack 1748667509, win 65535, options [mss 1336,nop,wscale 3,sackOK,TS val 3034815067 ecr 3340010363], length 0 09:33:18.574448 IP 192.168.1.161.32561 > 192.168.14.2.22: Flags [S], seq 1748667508, win 65535, options [mss 1336,nop,wscale 3,sackOK,TS val 3340013563 ecr 0], length 0 09:33:18.574468 IP 192.168.14.2.22 > 192.168.1.161.32561: Flags [S.], seq 1397778113, ack 1748667509, win 65535, options [mss 1336,nop,wscale 3,sackOK,TS val 3034815067 ecr 3340013563], length 0 09:33:21.574470 IP 192.168.14.2.22 > 192.168.1.161.32561: Flags [S.], seq 1397778113, ack 1748667509, win 65535, options [mss 1336,nop,wscale 3,sackOK,TS val 3034815067 ecr 3340013563], length 0 09:33:21.774626 IP 192.168.1.161.32561 > 192.168.14.2.22: Flags [S], seq 1748667508, win 65535, options [mss 1336,sackOK,eol], length 0 09:33:21.774645 IP 192.168.14.2.22 > 192.168.1.161.32561: Flags [S.], seq 1397778113, ack 1748667509, win 65535, options [mss 1336,nop,wscale 3,sackOK,eol], length 0 09:33:24.774761 IP 192.168.14.2.22 > 192.168.1.161.32561: Flags [S.], seq 1397778113, ack 1748667509, win 65535, options [mss 1336,nop,wscale 3,sackOK,eol], length 0 09:33:24.974610 IP 192.168.1.161.32561 > 192.168.14.2.22: Flags [S], seq 1748667508, win 65535, options [mss 1336,sackOK,eol], length 0 09:33:24.974629 IP 192.168.14.2.22 > 192.168.1.161.32561: Flags [S.], seq 1397778113, ack 1748667509, win 65535, options [mss 1336,nop,wscale 3,sackOK,eol], length 0 09:33:27.974064 IP 192.168.14.2.22 > 192.168.1.161.32561: Flags [S.], seq 1397778113, ack 1748667509, win 65535, options [mss 1336,nop,wscale 3,sackOK,eol], length 0 09:33:28.174574 IP 192.168.1.161.32561 > 192.168.14.2.22: Flags [S], seq 1748667508, win 65535, options [mss 1336,sackOK,eol], length 0 09:33:28.174592 IP 192.168.14.2.22 > 192.168.1.161.32561: Flags [S.], seq 1397778113, ack 1748667509, win 65535, options [mss 1336,nop,wscale 3,sackOK,eol], length 0 09:33:31.174354 IP 192.168.14.2.22 > 192.168.1.161.32561: Flags [S.], seq 1397778113, ack 1748667509, win 65535, options [mss 1336,nop,wscale 3,sackOK,eol], length 0 09:33:34.375826 IP 192.168.1.161.32561 > 192.168.14.2.22: Flags [S], seq 1748667508, win 65535, options [mss 1336,sackOK,eol], length 0 09:33:34.375845 IP 192.168.14.2.22 > 192.168.1.161.32561: Flags [S.], seq 1397778113, ack 1748667509, win 65535, options [mss 1336,nop,wscale 3,sackOK,eol], length 0 09:33:37.375937 IP 192.168.14.2.22 > 192.168.1.161.32561: Flags [S.], seq 1397778113, ack 1748667509, win 65535, options [mss 1336,nop,wscale 3,sackOK,eol], length 0 09:33:43.376487 IP 192.168.14.2.22 > 192.168.1.161.32561: Flags [S.], seq 1397778113, ack 1748667509, win 65535, options [mss 1336,nop,wscale 3,sackOK,eol], length 0 09:33:46.574383 IP 192.168.1.161.32561 > 192.168.14.2.22: Flags [S], seq 1748667508, win 65535, options [mss 1336,sackOK,eol], length 0 09:33:46.574401 IP 192.168.14.2.22 > 192.168.1.161.32561: Flags [S.], seq 1397778113, ack 1748667509, win 65535, options [mss 1336,nop,wscale 3,sackOK,eol], length 0 ipnat на сервере: # cat ipnat.ssh.connect List of active MAP/Redirect filters: map tap0 from 192.168.1.0/24 to 192.168.12.0/22 -> 192.168.1.161/32 proxy port ftp ftp/tcp map tap0 from 192.168.1.0/24 to 192.168.12.0/22 -> 192.168.1.161/32 portmap tcp/udp auto map tap0 192.168.1.0/24 -> 192.168.1.161/32 icmpidmap icmp 64000:65535 List of active sessions: MAP 192.168.1.161 32561 <- -> 192.168.1.161 64083 [192.168.1.164 22] MAP 192.168.1.161 32561 <- -> 192.168.1.161 32561 [192.168.14.2 22] proxy ftp/6 use 1 flags 0 proto 6 flags 0 bytes 420 pkts 8 data YES size 312 FTP Proxy: passok: 1 Client: seq 0 (ack 0) len 0 junk 0 cmds 0 buf [\000] Server: seq 0 (ack 0) len 0 junk 0 cmds 0 buf [\000] MAP 192.168.1.7 3389 <- -> 192.168.1.161 3389 [192.168.14.113 1047] proxy ftp/6 use 1 flags 0 proto 6 flags 0 bytes 224 pkts 5 data YES size 312 FTP Proxy: passok: 1 Client: seq e7fd7091 (ack 0) len 0 junk 0 cmds 0 buf [\000] Server: seq 9fa8bfa1 (ack 0) len 0 junk 0 cmds 0 buf [\000] иногда выдает такое: # ipnat -l List of active MAP/Redirect filters: unknown value for in_redir: 0 0.0.0.0/0 -> 0.0.0.0/0 List of active sessions: unknown(0000) 0.0.0.0 <- -> 0.0.0.0 [0.0.0.0]
	Ответить \| Правка \| ^ к родителю #4 \| Наверх \| Cообщить модератору


	6. "openvpn net-to-net"	+/–
	Сообщение от reader (ok) on 16-Дек-11, 11:12
	>> 192.168.1.164.ssh > 192.168.1.161.21706: Flags [S.], seq 1512465607, ack 562607220, win >> 65535, options [mss 1336,nop,wscale 3,sackOK,eol], length 0 >> несколько раз, похоже пакет не доходит до туда > 15:08:28.551233 IP 192.168.1.161.65042 > 192.168.1.164.ssh: Flags [R], seq 562607220, > win 0, length 0 клиент сбрасывает предыдущую сесию ssh (порт 65042) > 15:08:30.716933 IP 192.168.1.161 > 192.168.14.100: ICMP echo request, id 768, seq 11073, > length 40 > 15:08:30.717257 IP 192.168.1.164 > 192.168.1.161: ICMP echo reply, id 768, seq 11073, > length 40 > 15:08:34.548745 IP 192.168.1.164.ssh > 192.168.1.161.21706: Flags [S.], seq 1512465607, > ack 562607220, win 65535, options [mss 1336,nop,wscale 3,sackOK,eol], length 0 ответ на попытку клиента ssh установить соединение с sshd (это другая сесия , порт 21706), таких пакетов было несколько, а подтверждений со стороны клиента нет откуда инициируется соединение с sshd, с машины с vpn сервером или из локалки за vpn сервером? снимите дамп с машины с которой подключаетесь к sshd. >[оверквотинг удален] > > buf [\000] > иногда выдает такое: > # ipnat -l > List of active MAP/Redirect filters: > unknown value for in_redir: 0 > 0.0.0.0/0 -> 0.0.0.0/0 > List of active sessions: > unknown(0000) 0.0.0.0 <- -> > 0.0.0.0 [0.0.0.0] с ipnat не ковырялся, поэтому по нему не скажу ничего. А в целом для чего вы его решили использовать? По моему там нужна только маршрутизация.
	Ответить \| Правка \| ^ к родителю #5 \| Наверх \| Cообщить модератору


	7. "openvpn net-to-net"	+/–
	Сообщение от dile (ok) on 16-Дек-11, 11:53
	> с ipnat не ковырялся, поэтому по нему не скажу ничего. А в > целом для чего вы его решили использовать? По моему там нужна > только маршрутизация. Отключил и все заработало. С tun-ом вроде как нужен был.
	Ответить \| Правка \| ^ к родителю #6 \| Наверх \| Cообщить модератору


	8. "openvpn net-to-net"	+/–
	Сообщение от dile (ok) on 20-Дек-11, 17:01
	>> с ipnat не ковырялся, поэтому по нему не скажу ничего. А в >> целом для чего вы его решили использовать? По моему там нужна >> только маршрутизация. > Отключил и все заработало. С tun-ом вроде как нужен был. Теперь небольшая проблема с настройкой роутинга. При использовании tap разадча через ccd не работает, если я правильно понял комментарий. # This example will only work # if you are routing, not bridging, i.e. you are # using "dev tun" and "server" directives. Директива push отдает маршрутом указанные сети в tap интерфейс сервера. Клиент получает роутинг: 192.168.1.0/24 192.168.1.161 UGS 0 22 tap0 192.168.1.160/28 link#8 U 0 0 tap0 192.168.1.164 link#8 UHS 0 0 lo0 192.168.2.0/24 192.168.1.161 UGS 0 0 tap0 А вот сервер ни чего не знает о сети клиента. тлько если в ручную дать route add. route add -net 192.168.12.0/22 192.168.1.164 Как можно сделать на самом сервере автоматически добавляемую маршрутизацию при коннекте клиента или старте сервиса. И как тогда зафиксировать получаемый ip на стороне клиента.
	Ответить \| Правка \| ^ к родителю #7 \| Наверх \| Cообщить модератору


	9. "openvpn net-to-net"	+/–
	Сообщение от reader (ok) on 20-Дек-11, 17:32
	>>> с ipnat не ковырялся, поэтому по нему не скажу ничего. А в >>> целом для чего вы его решили использовать? По моему там нужна >>> только маршрутизация. >> Отключил и все заработало. С tun-ом вроде как нужен был. > Теперь небольшая проблема с настройкой роутинга. > При использовании tap разадча через ccd не работает, если я правильно понял > комментарий. > # This example will only work > # if you are routing, not bridging, i.e. you are > # using "dev tun" and "server" directives. работает ifconfig-push 10.1.0.2 255.255.255.0 push "route 10.10.0.0 255.255.255.0" >[оверквотинг удален] > 0 lo0 > 192.168.2.0/24 192.168.1.161 UGS > 0 > 0 tap0 > А вот сервер ни чего не знает о сети клиента. тлько если > в ручную дать route add. > route add -net 192.168.12.0/22 192.168.1.164 > Как можно сделать на самом сервере автоматически добавляемую маршрутизацию при коннекте > клиента или старте сервиса. И как тогда зафиксировать получаемый ip на > стороне клиента. для при старте сервера, поидее в его конфиге route 192.168.4.0 255.255.255.0
	Ответить \| Правка \| ^ к родителю #8 \| Наверх \| Cообщить модератору


	10. "openvpn net-to-net"	+/–
	Сообщение от dile (ok) on 10-Апр-12, 15:48
	>[оверквотинг удален] >>> Отключил и все заработало. С tun-ом вроде как нужен был. >> Теперь небольшая проблема с настройкой роутинга. >> При использовании tap разадча через ccd не работает, если я правильно понял >> комментарий. >> # This example will only work >> # if you are routing, not bridging, i.e. you are >> # using "dev tun" and "server" directives. > работает > ifconfig-push 10.1.0.2 255.255.255.0 > push "route 10.10.0.0 255.255.255.0" нет не работает, перевод куска [q] Этот пример будет работать только # если у вас режим роутера, но не моста, т.е. вы # используете директивы "dev tun" и "server". [/q] причем push на клиент нормально отрабатывает оп всем прописанным сетям >[оверквотинг удален] >> 192.168.2.0/24 192.168.1.161 UGS >> 0 >> 0 tap0 >> А вот сервер ни чего не знает о сети клиента. тлько если >> в ручную дать route add. >> route add -net 192.168.12.0/22 192.168.1.164 >> Как можно сделать на самом сервере автоматически добавляемую маршрутизацию при коннекте >> клиента или старте сервиса. И как тогда зафиксировать получаемый ip на >> стороне клиента. > для при старте сервера, поидее в его конфиге route 192.168.4.0 255.255.255.0 Нет не годится, при запуске нет еще этого IP. Чисто технически это дело сервиса, а не системы. Тема для обсуждения. Как по технологии openvpn управлять маршрутами на самом сервере c tap интерфейсами без режима server-bridge. learn-address ./script возможно ли применить и как примерно.
	Ответить \| Правка \| ^ к родителю #9 \| Наверх \| Cообщить модератору