OpenVPN затык…
-
Имеем pfSense, на нём OpenVPN сервер (Remote Access TLS/SSL). Имеем клиента на CentOS, он подключен к серверу (tun0-интерфейс) всё ок, пингует, видит. А вот машинки за этим шлюзом на CentOS не видят и не пингуют "туннельную" сетку, хотя вроде все правила не запрещают это. Куда копать?
Маршруты на клиентском CentOS (шлюзе)[root@server log]# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface inet_ip 0.0.0.0 255.255.255.252 U 0 0 0 eth0 192.168.100.0 0.0.0.0 255.255.255.0 U 0 0 0 eth3 10.10.10.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0 192.168.0.0 10.10.10.1 255.255.240.0 UG 0 0 0 tun0 169.254.0.0 0.0.0.0 255.255.0.0 U 1002 0 0 eth0 169.254.0.0 0.0.0.0 255.255.0.0 U 1003 0 0 eth3 0.0.0.0 inet_gateway 0.0.0.0 UG 0 0 0 eth0Т.е. исходя из этого видно, что сервер "знает" о туннельной сети 192.168.0.0/20 и видит/пингует её, всё ок.
Вот маршруты клиента на Win 7 за этим CentOS сервером:
C:\Users\ПК>route print =========================================================================== Список интерфейсов 11...bc 5f f4 60 70 e7 ......Realtek PCIe GBE Family Controller 1...........................Software Loopback Interface 1 12...00 00 00 00 00 00 00 e0 Адаптер Microsoft ISATAP 13...00 00 00 00 00 00 00 e0 Teredo Tunneling Pseudo-Interface =========================================================================== IPv4 таблица маршрута =========================================================================== Активные маршруты: Сетевой адрес Маска сети Адрес шлюза Интерфейс Метрика 0.0.0.0 0.0.0.0 192.168.100.1 192.168.100.82 10 127.0.0.0 255.0.0.0 On-link 127.0.0.1 306 127.0.0.1 255.255.255.255 On-link 127.0.0.1 306 127.255.255.255 255.255.255.255 On-link 127.0.0.1 306 192.168.100.0 255.255.255.0 On-link 192.168.100.82 266 192.168.100.82 255.255.255.255 On-link 192.168.100.82 266 192.168.100.255 255.255.255.255 On-link 192.168.100.82 266 224.0.0.0 240.0.0.0 On-link 127.0.0.1 306 224.0.0.0 240.0.0.0 On-link 192.168.100.82 266 255.255.255.255 255.255.255.255 On-link 127.0.0.1 306 255.255.255.255 255.255.255.255 On-link 192.168.100.82 266 =========================================================================== Постоянные маршруты: Отсутствует IPv6 таблица маршрута =========================================================================== Активные маршруты: Метрика Сетевой адрес Шлюз 1 306 ::1/128 On-link 11 266 fe80::/64 On-link 11 266 fe80::959a:37c9:fa8a:3744/128 On-link 1 306 ff00::/8 On-link 11 266 ff00::/8 On-link =========================================================================== Постоянные маршруты: Отсутствует C:\Users\ПК> И при пинге с клиента хоста за туннелем, например Code: [Select] C:\Users\ПК>ping 192.168.1.58 Обмен пакетами с 192.168.1.58 по с 32 байтами данных: Превышен интервал ожидания для запроса. Превышен интервал ожидания для запроса. Видим фигу, в то время, как с самого клиентского CentOS'a: Code: [Select] [root@server log]# ping 192.168.1.58 PING 192.168.1.58 (192.168.1.58) 56(84) bytes of data. 64 bytes from 192.168.1.58: icmp_seq=1 ttl=127 time=73.0 ms 64 bytes from 192.168.1.58: icmp_seq=2 ttl=127 time=72.8 ms 64 bytes from 192.168.1.58: icmp_seq=3 ttl=127 time=73.1 ms 64 bytes from 192.168.1.58: icmp_seq=4 ttl=127 time=75.2 msГде затык?
Если запустить пинг с клиентской машинки (Win 7) а потом "послушать" tcpdump'ом tun0 интерфейс на CentOS, то видим, что пакеты приходят на tun0 интерфейс, значит косяка в маршрутах нет? Так где же беда?
[root@server log]# tcpdump -i tun0 -n -nn tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on tun0, link-type RAW (Raw IP), capture size 65535 bytes 18:01:43.561687 IP 192.168.100.82 > 192.168.1.1: ICMP echo request, id 1, seq 316, length 40 18:01:48.454540 IP 192.168.100.82 > 192.168.1.1: ICMP echo request, id 1, seq 317, length 40
-
На pf в настройках впн укажите в IPv4 Local Network/s 192.168.0.0/20
В настройках Client Specific Overrides укажите правильный CN и там же IPv4 Remote Network/s 192.168.100.0/24Далее ,возможно что и ЦентОС подкрутить надо. Что-то типа :
iptables -t nat -I POSTROUTING -s 192.168.100.0/24 -o tun+ -j MASQUERADE
iptables -I FORWARD -i tun+ -j ACCEPT#enable IP forwarding
echo 1 > /proc/sys/net/ipv4/ip_forwardRestart network
-
На pf в настройках впн укажите в IPv4 Local Network/s 192.168.0.0/20
В настройках Client Specific Overrides укажите правильный CN и там же IPv4 Remote Network/s 192.168.100.0/24Далее ,возможно что и ЦентОС подкрутить надо. Что-то типа :
iptables -t nat -I POSTROUTING -s 192.168.100.0/24 -o tun+ -j MASQUERADE
iptables -I FORWARD -i tun+ -j ACCEPT#enable IP forwarding
echo 1 > /proc/sys/net/ipv4/ip_forwardRestart network
Помогло вот это
iptables -t nat -I POSTROUTING -s 192.168.100.0/24 -o tun+ -j MASQUERADEСПАСИБО!!
Т.е. получается, что шлюз (CentOS) должен именно маршрутизировать трафик между своими же интерфейсами, так? -
Т.е. получается, что шлюз (CentOS) должен именно маршрутизировать трафик между своими же интерфейсами, так?
Я не спец в iptables. Почитайте что-то типа http://adminunix.ru/linux-iptables-rukovodstvo-chast-1-osnovy-iptables/
iptables -t nat -I POSTROUTING -s 192.168.100.0/24 -o tun+ -j MASQUERADE
Это не марш-ция. Это вкл. nat (сетевой трансляции адресов) на всех интерфейсах tun
Маршрут Вы получили от сервера :
[root@server log]# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
…..
192.168.0.0 10.10.10.1 255.255.240.0 UG 0 0 0 tun0
….И не забудьте сделать это правило ipt постоянным. Иначе после перез-ки клиента ЦентОС связь в туннеле снова пропадет.