LINUX.ORG.RU

История изменений

Исправление berrywizard, (текущая версия) :

Ответы:

1) proxy_arp - не в курсе; ip_forward - естественно.

2) смотря как у вас там общение хоста с ВМ'ами настроено.

3) может быть (см. ниже про косяк у меня с /26).

4) должен.

«ccd ?»: да

«про серий ip выдаваемый OpenVPN?»: «туннельный» - «серий ip выдаваемый OpenVPN», «не туннельный» - любой (вменяемый) адрес вне «серий ip выдаваемый OpenVPN».

Объясняю:

- так сказать, «холостое состояние» системы (openvpn поднят, ни один клиент ещё не подключился, в случае с вирт. машинами «eth14.8@eth14» заменить на что-то вроде «xenbr0»): 

# ip addr show
...
4: eth14.12@eth14: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP 
    link/ether 00:0a:5e:75:63:90 brd ff:ff:ff:ff:ff:ff
    inet 11.22.33.46/30 brd 11.22.33.47 scope global eth14.12
       valid_lft forever preferred_lft forever
...
6: eth14.8@eth14: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP 
    link/ether 00:0a:5e:75:63:90 brd ff:ff:ff:ff:ff:ff
    inet 192.168.254.1/24 brd 192.168.254.255 scope global eth14.8
       valid_lft forever preferred_lft forever
...
14: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 100
    link/[65534] 
    inet 192.168.253.1 peer 192.168.253.2/32 scope global tun0
...

#

# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.253.2   0.0.0.0         255.255.255.255 UH    0      0        0 tun0
11.22.33.44     0.0.0.0         255.255.255.252 U     0      0        0 eth14.12
192.168.253.0   192.168.253.2   255.255.255.0   UG    0      0        0 tun0
192.168.254.0   0.0.0.0         255.255.255.0   U     0      0        0 eth14.8
0.0.0.0         11.22.33.45     0.0.0.0         UG    5      0        0 eth14.12

#

- после подключения клиента, таблица маршрутов будет примерно такой (у меня почему-то маска /26, хотя в ccd для клиента указано 255.255.255.255, лень выяснять):

# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
1.1.1.4         192.168.253.2   255.255.255.192 UG    0      0        0 tun0
192.168.253.2   0.0.0.0         255.255.255.255 UH    0      0        0 tun0
11.22.33.44     0.0.0.0         255.255.255.252 U     0      0        0 eth14.12
192.168.253.0   192.168.253.2   255.255.255.0   UG    0      0        0 tun0
192.168.254.0   0.0.0.0         255.255.255.0   U     0      0        0 eth14.8
0.0.0.0         11.22.33.45     0.0.0.0         UG    5      0        0 eth14.12

#
а у клиента примерно такие адреса/маршруты:
# ip addr show
...
3: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:02:b3:d6:08:cb brd ff:ff:ff:ff:ff:ff
    inet 192.168.254.197/24 brd 192.168.254.255 scope global eth0
       valid_lft forever preferred_lft forever
...
10: tun0: <POINTOPOINT,MULTICAST,NOARP,UP> mtu 1500 qdisc pfifo_fast qlen 100
    link/[65534] 
    inet 192.168.253.46 peer 192.168.253.45/32 scope global tun0
    inet 1.1.1.4/32 scope global tun0
# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.253.45  0.0.0.0         255.255.255.255 UH    0      0        0 tun0
192.168.254.0   0.0.0.0         255.255.255.0   U     0      0        0 eth0
192.168.253.0   192.168.253.45  255.255.255.0   UG    0      0        0 tun0
0.0.0.0         192.168.253.45  0.0.0.0         UG    0      0        0 tun0
Ну и вуаля:
# ping -c 2 -R 1.1.1.4
PING 1.1.1.4 (1.1.1.4) 56(124) bytes of data.
64 bytes from 1.1.1.4: icmp_seq=1 ttl=62 time=4.49 ms
RR:     11.22.30.33
        11.22.33.43
        192.168.253.1
        1.1.1.4
        1.1.1.4
        11.22.33.44
        11.22.30.17
        11.22.30.33

64 bytes from 1.1.1.4: icmp_seq=2 ttl=62 time=4.57 ms       (same route)

--- 1.1.1.4 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 999ms
rtt min/avg/max/mdev = 4.497/4.536/4.576/0.078 ms
#
Как я уже сказал, единственная проблема здесь — приложения на openvpn-клиенте будут при инициировании соединений наружу использовать адрес (в данном случае) 192.168.253.45, т.к. default route у него туннельный. Решить можно, например, SNAT'ом на openvpn-сервере.

Плюсы:

- выделенную сетку реальных IP можно раскидать до единого адреса по всем системам, в т.ч. по узлам, находящимся в разных IP-сетях;

- всё решается внутри IP-стека (адреса/маршрутизация), нет необходимости возится с мостами/arp'ами/...

Минус: указанный выше момент.

Исправление berrywizard, :

Ответы:

1) proxy_arp - не в курсе; ip_forward - естественно.

2) смотря как у вас там общение хоста с ВМ'ами настроено.

3) может быть (см. ниже про косяк у меня с /26).

4) должен.

«ccd ?»: да

«про серий ip выдаваемый OpenVPN?»: «туннельный» - «серий ip выдаваемый OpenVPN», «не туннельный» - любой (вменяемый) адрес вне «серий ip выдаваемый OpenVPN».

Объясняю:

- так сказать, «холостое состояние» системы (openvpn поднят, ни один клиент ещё не подключился, в случае с вирт. машинами «eth14.8@eth14» заменить на что-то вроде «xenbr0»): 

# ip addr show
...
4: eth14.12@eth14: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP 
    link/ether 00:0a:5e:75:63:90 brd ff:ff:ff:ff:ff:ff
    inet 11.22.33.46/30 brd 11.22.33.47 scope global eth14.12
       valid_lft forever preferred_lft forever
...
6: eth14.8@eth14: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP 
    link/ether 00:0a:5e:75:63:90 brd ff:ff:ff:ff:ff:ff
    inet 192.168.254.1/24 brd 192.168.254.255 scope global eth14.8
       valid_lft forever preferred_lft forever
...
14: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 100
    link/[65534] 
    inet 192.168.253.1 peer 192.168.253.2/32 scope global tun0
...

#

# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.253.2   0.0.0.0         255.255.255.255 UH    0      0        0 tun0
11.22.33.44     0.0.0.0         255.255.255.252 U     0      0        0 eth14.12
192.168.253.0   192.168.253.2   255.255.255.0   UG    0      0        0 tun0
192.168.254.0   0.0.0.0         255.255.255.0   U     0      0        0 eth14.8
0.0.0.0         11.22.33.45     0.0.0.0         UG    5      0        0 eth14.12

#

- после подключения клиента, таблица маршрутов будет примерно такой (у меня почему-то маска /26, хотя в ccd для клиента указано 255.255.255.255, лень выяснять):

# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
1.1.1.4         192.168.253.2   255.255.255.192 UG    0      0        0 tun0
192.168.253.2   0.0.0.0         255.255.255.255 UH    0      0        0 tun0
11.22.33.44     0.0.0.0         255.255.255.252 U     0      0        0 eth14.12
192.168.253.0   192.168.253.2   255.255.255.0   UG    0      0        0 tun0
192.168.254.0   0.0.0.0         255.255.255.0   U     0      0        0 eth14.8
0.0.0.0         11.22.33.45     0.0.0.0         UG    5      0        0 eth14.12

#
а у клиента примерно такие адреса/маршруты:
# ip addr show
...
3: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:02:b3:d6:08:cb brd ff:ff:ff:ff:ff:ff
    inet 192.168.254.197/24 brd 192.168.254.255 scope global eth0
       valid_lft forever preferred_lft forever
...
10: tun0: <POINTOPOINT,MULTICAST,NOARP,UP> mtu 1500 qdisc pfifo_fast qlen 100
    link/[65534] 
    inet 192.168.253.46 peer 192.168.253.45/32 scope global tun0
    inet 1.1.1.4/32 scope global tun0
# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.253.45  0.0.0.0         255.255.255.255 UH    0      0        0 tun0
192.168.254.0   0.0.0.0         255.255.255.0   U     0      0        0 eth0
192.168.253.0   192.168.253.45  255.255.255.0   UG    0      0        0 tun0
0.0.0.0         192.168.253.45  0.0.0.0         UG    0      0        0 tun0
Ну и вуаля:
# ping -c 2 -R 1.1.1.4
PING 1.1.1.4 (1.1.1.4) 56(124) bytes of data.
64 bytes from 1.1.1.4: icmp_seq=1 ttl=62 time=4.49 ms
RR:     11.22.30.33
        11.22.33.43
        192.168.253.1
        1.1.1.4
        1.1.1.4
        11.22.33.44
        11.22.30.17
        11.22.30.33

64 bytes from 1.1.1.4: icmp_seq=2 ttl=62 time=4.57 ms       (same route)

--- 1.1.1.4 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 999ms
rtt min/avg/max/mdev = 4.497/4.536/4.576/0.078 ms
#
Как я уже сказал, единственная проблема здесь — приложения на openvpn-клиенте будут при инициировании соединений наружу получать адрес (в данном случае) 192.168.253.45, т.к. default route у него туннельный. Решить можно, например, SNAT'ом на openvpn-сервере.

Плюсы:

- выделенную сетку реальных IP можно раскидать до единого адреса по всем системам, в т.ч. по узлам, находящимся в разных IP-сетях;

- всё решается внутри IP-стека (адреса/маршрутизация), нет необходимости возится с мостами/arp'ами/...

Минус: указанный выше момент.

Исправление berrywizard, :

Ответы:

1) proxy_arp - не в курсе; ip_forward - естественно.

2) смотря как у вас там общение хоста с ВМ'ами настроено.

3) может быть (см. ниже про косяк у меня с /26).

4) должен.

«ccd ?»: да

«про серий ip выдаваемый OpenVPN?»: «туннельный» - «серий ip выдаваемый OpenVPN», «не туннельный» - любой (вменяемый) адрес вне «серий ip выдаваемый OpenVPN».

Объясняю:

- так сказать, «холостое состояние» системы (openvpn поднят, ни один клиент ещё не подключился, в случае с вирт. машинами «eth14.8@eth14» заменить на что-то вроде «xenbr0»): 

# ip addr show
...
4: eth14.12@eth14: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP 
    link/ether 00:0a:5e:75:63:90 brd ff:ff:ff:ff:ff:ff
    inet 11.22.33.46/30 brd 11.22.33.47 scope global eth14.12
       valid_lft forever preferred_lft forever
...
6: eth14.8@eth14: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP 
    link/ether 00:0a:5e:75:63:90 brd ff:ff:ff:ff:ff:ff
    inet 192.168.254.1/24 brd 192.168.254.255 scope global eth14.8
       valid_lft forever preferred_lft forever
...
14: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 100
    link/[65534] 
    inet 192.168.253.1 peer 192.168.253.2/32 scope global tun0
...

#

# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.253.2   0.0.0.0         255.255.255.255 UH    0      0        0 tun0
11.22.33.44     0.0.0.0         255.255.255.252 U     0      0        0 eth14.12
192.168.253.0   192.168.253.2   255.255.255.0   UG    0      0        0 tun0
192.168.254.0   0.0.0.0         255.255.255.0   U     0      0        0 eth14.8
0.0.0.0         11.22.33.45     0.0.0.0         UG    5      0        0 eth14.12

#

- после подключения клиента, таблица маршрутов будет примерно такой (у меня почему-то маска /26, хотя в ccd для клиента указано 255.255.255.255, лень выяснять):

# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
1.1.1.4         192.168.253.2   255.255.255.192 UG    0      0        0 tun0
192.168.253.2   0.0.0.0         255.255.255.255 UH    0      0        0 tun0
11.22.33.44     0.0.0.0         255.255.255.252 U     0      0        0 eth14.12
192.168.253.0   192.168.253.2   255.255.255.0   UG    0      0        0 tun0
192.168.254.0   0.0.0.0         255.255.255.0   U     0      0        0 eth14.8
0.0.0.0         11.22.33.45     0.0.0.0         UG    5      0        0 eth14.12

#
а у клиента примерно такие адреса/маршруты:
# ip addr show
...
3: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:02:b3:d6:08:cb brd ff:ff:ff:ff:ff:ff
    inet 192.168.254.197/24 brd 192.168.254.255 scope global eth0
       valid_lft forever preferred_lft forever
...
10: tun0: <POINTOPOINT,MULTICAST,NOARP,UP> mtu 1500 qdisc pfifo_fast qlen 100
    link/[65534] 
    inet 192.168.253.46 peer 192.168.253.45/32 scope global tun0
    inet 1.1.1.4/32 scope global tun0
# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.253.45  0.0.0.0         255.255.255.255 UH    0      0        0 tun0
192.168.254.0   0.0.0.0         255.255.255.0   U     0      0        0 eth0
192.168.253.0   192.168.253.45  255.255.255.0   UG    0      0        0 tun0
0.0.0.0         192.168.253.45  0.0.0.0         UG    0      0        0 tun0
Ну и вуаля:
# ping -c 2 -R 1.1.1.4
PING 1.1.1.4 (1.1.1.4) 56(124) bytes of data.
64 bytes from 1.1.1.4: icmp_seq=1 ttl=62 time=4.49 ms
RR:     11.22.30.33
        11.22.33.43
        192.168.253.1
        1.1.1.4
        1.1.1.4
        11.22.33.44
        11.22.30.17
        11.22.30.33

64 bytes from 1.1.1.4: icmp_seq=2 ttl=62 time=4.57 ms       (same route)

--- 1.1.1.4 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 999ms
rtt min/avg/max/mdev = 4.497/4.536/4.576/0.078 ms
#
Как я уже сказал, единственная проблема здесь — приложения на openvpn-клиенте будут при инициировании соединений наружу получать адрес (в данном случае) 192.168.253.45, т.к. default route у него туннельный. Решить можно, например, SNAT'ом на openvpn-сервере.

Плюсы: - выделенную сетку реальных IP можно раскидать до единого адреса по всем системам, в т.ч. по узлам, находящимся в разных IP-сетях; - всё решается внутри IP-стека (адреса/маршрутизация), нет необходимости возится с мостами/arp'ами/... Минус: указанный выше момент.

Исходная версия berrywizard, :

Ответы:

1) proxy_arp - не в курсе; ip_forward - естественно.

2) смотря как у вас там ощение хоста с ВМ'ами настроено.

3) может быть (см. ниже про косяк у меня с /26).

4) должен.

«ccd ?»: да

«про серий ip выдаваемый OpenVPN?»: «туннельный» - «серий ip выдаваемый OpenVPN», «не туннельный» - любой (вменяемый) адрес вне «серий ip выдаваемый OpenVPN».

Объясняю:

- так сказать, «холостое состояние» системы (openvpn поднят, ни один клиент ещё не подключился, в случае с вирт. машинами «eth14.8@eth14» заменить на что-то вроде «xenbr0»): 

# ip addr show
...
4: eth14.12@eth14: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP 
    link/ether 00:0a:5e:75:63:90 brd ff:ff:ff:ff:ff:ff
    inet 11.22.33.46/30 brd 11.22.33.47 scope global eth14.12
       valid_lft forever preferred_lft forever
...
6: eth14.8@eth14: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP 
    link/ether 00:0a:5e:75:63:90 brd ff:ff:ff:ff:ff:ff
    inet 192.168.254.1/24 brd 192.168.254.255 scope global eth14.8
       valid_lft forever preferred_lft forever
...
14: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 100
    link/[65534] 
    inet 192.168.253.1 peer 192.168.253.2/32 scope global tun0
...

#

# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.253.2   0.0.0.0         255.255.255.255 UH    0      0        0 tun0
11.22.33.44     0.0.0.0         255.255.255.252 U     0      0        0 eth14.12
192.168.253.0   192.168.253.2   255.255.255.0   UG    0      0        0 tun0
192.168.254.0   0.0.0.0         255.255.255.0   U     0      0        0 eth14.8
0.0.0.0         11.22.33.45     0.0.0.0         UG    5      0        0 eth14.12

#

- после подключения клиента, таблица маршрутов будет примерно такой (у меня почему-то маска /26, хотя в ccd для клиента указано 255.255.255.255, лень выяснять):

# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
1.1.1.4         192.168.253.2   255.255.255.192 UG    0      0        0 tun0
192.168.253.2   0.0.0.0         255.255.255.255 UH    0      0        0 tun0
11.22.33.44     0.0.0.0         255.255.255.252 U     0      0        0 eth14.12
192.168.253.0   192.168.253.2   255.255.255.0   UG    0      0        0 tun0
192.168.254.0   0.0.0.0         255.255.255.0   U     0      0        0 eth14.8
0.0.0.0         11.22.33.45     0.0.0.0         UG    5      0        0 eth14.12

#
а у клиента примерно такие адреса/маршруты:
# ip addr show
...
3: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:02:b3:d6:08:cb brd ff:ff:ff:ff:ff:ff
    inet 192.168.254.197/24 brd 192.168.254.255 scope global eth0
       valid_lft forever preferred_lft forever
...
10: tun0: <POINTOPOINT,MULTICAST,NOARP,UP> mtu 1500 qdisc pfifo_fast qlen 100
    link/[65534] 
    inet 192.168.253.46 peer 192.168.253.45/32 scope global tun0
    inet 1.1.1.4/32 scope global tun0
# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.253.45  0.0.0.0         255.255.255.255 UH    0      0        0 tun0
192.168.254.0   0.0.0.0         255.255.255.0   U     0      0        0 eth0
192.168.253.0   192.168.253.45  255.255.255.0   UG    0      0        0 tun0
0.0.0.0         192.168.253.45  0.0.0.0         UG    0      0        0 tun0
Ну и вуаля:
# ping -c 2 -R 1.1.1.4
PING 1.1.1.4 (1.1.1.4) 56(124) bytes of data.
64 bytes from 1.1.1.4: icmp_seq=1 ttl=62 time=4.49 ms
RR:     11.22.30.33
        11.22.33.43
        192.168.253.1
        1.1.1.4
        1.1.1.4
        11.22.33.44
        11.22.30.17
        11.22.30.33

64 bytes from 1.1.1.4: icmp_seq=2 ttl=62 time=4.57 ms       (same route)

--- 1.1.1.4 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 999ms
rtt min/avg/max/mdev = 4.497/4.536/4.576/0.078 ms
#
Как я уже сказал, единственная проблема здесь — приложения на openvpn-клиенте будут при инициировании соединений наружу получать адрес (в данном случае) 192.168.253.45, т.к. default route у него туннельный. Решить можно, например, SNAT'ом на openvpn-сервере.

Плюсы: - выделенную сетку реальных IP можно раскидать до единого адреса по всем системам, в т.ч. по узлам, находящимся в разных IP-сетях; - всё решается внутри IP-стека (адреса/маршрутизация), нет необходимости возится с мостами/arp'ами/... Минус: указанный выше момент.