The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"openvpn net-to-net"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Открытые системы на сервере (VPN / FreeBSD)
Изначальное сообщение [ Отслеживать ]

"openvpn net-to-net"  +/
Сообщение от dile email(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ообщить модератору

Оглавление

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


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

2. "openvpn net-to-net"  +/
Сообщение от dile email(ok) on 14-Дек-11, 14:10 
> http://www.opennet.ru/openforum/vsluhforumID1/91287.html?n=r...

с tap заработал, спасибо за наводку

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

3. "openvpn net-to-net"  +/
Сообщение от dile email(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 email(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 email(ok) on 16-Дек-11, 11:53 
> с ipnat не ковырялся, поэтому по нему не скажу ничего. А в
> целом для чего вы его решили использовать? По моему там нужна
> только маршрутизация.

Отключил и все заработало. С tun-ом вроде как нужен был.

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

8. "openvpn net-to-net"  +/
Сообщение от dile email(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 | Индекс форумов | Темы | Пред. тема | След. тема




Спонсоры:
MIRhosting
Inferno Solutions
Hosting by Ihor
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2019 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру