Задачка по Openvpn
-
т.е. опвн сервер и клиент друг-друга пингуют
а клиенты из их сетей друг-друга нет? -
да, все так.
сервера пингуются по виртуальным ip.
сеть за клиентом пингует виртуальные ip сервера, но не пингует локальные ip. Комп с клиентом пингует локальгый ip адрес сервера.
Сервер не пингует локальный IP клиента.Может все дело в vmware, у меня pfsense стоит на ESXi 4.1
-
тогда Вам надо роутинг в опенвпн донастраивать
в 1.2.3
у меня в кастом
route 192.168.10.0 255.255.255.0; - чтобы роутер про клиентскую сеть 10.х знал
push "route 192.168.3.0 255.255.255.0"; - чтобы клиент знал про сеть 3.х сервера
плюс в Client-specific добавляю
iroute 192.168.10.0 255.255.255.0 -я так понимаю это серверу дается куда сеть 10.х отдавать -
Спасибо большое, пошел сдвиг. Облазил кучу форумов, оказалось нужно в Client-specific маршрут добавить, если честно сначала думал, что это закладка для настройки pfsense в качестве клиента openvpn…
-
Как писал выше, продвинулся, осталось чуть-чуть.
Серваки пингуют друг друга по локальным и туннельным адресам. Сервак с ubuntu может пинговать сеть за pfsense, но вот pfsense не может пинговать сеть за ubuntu, соответственно и клиенты за ubuntu не могут пинговать сеть за pfsense.
Как можно исправить, я так понимаю клиенты не знают маршрут… В какую сторону копнуть?
Сейчас посмотрел, пинг даже с локальной машины сервера (traffpro) не идет во внутреннюю сеть. Хотя интернет у всех работает нормально.Destination Gateway Genmask Flags Metric Ref Use Iface 10.67.15.28 0.0.0.0 255.255.255.255 UH 0 0 0 ppp7 10.16.0.5 0.0.0.0 255.255.255.255 UH 0 0 0 tun0 10.67.15.60 0.0.0.0 255.255.255.255 UH 0 0 0 ppp2 10.67.15.31 0.0.0.0 255.255.255.255 UH 0 0 0 ppp3 10.67.15.41 0.0.0.0 255.255.255.255 UH 0 0 0 ppp5 10.67.15.25 0.0.0.0 255.255.255.255 UH 0 0 0 ppp4 10.67.15.43 0.0.0.0 255.255.255.255 UH 0 0 0 ppp10 10.67.15.59 0.0.0.0 255.255.255.255 UH 0 0 0 ppp1 80.95.33.102 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0 10.67.15.37 0.0.0.0 255.255.255.255 UH 0 0 0 ppp6 10.67.15.36 0.0.0.0 255.255.255.255 UH 0 0 0 ppp8 10.67.15.54 0.0.0.0 255.255.255.255 UH 0 0 0 ppp12 10.67.15.51 0.0.0.0 255.255.255.255 UH 0 0 0 ppp11 10.16.0.0 10.16.0.5 255.255.255.0 UG 0 0 0 tun0 10.67.15.0 10.16.0.5 255.255.255.0 UG 0 0 0 tun0 192.168.1.0 10.16.0.5 255.255.255.0 UG 0 0 0 tun0 192.168.10.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 ppp0 -
у клиентов ПК с ОпенВПН должны быть или шлюзами по умолчанию или шлюзы по умолчанию в их подсети должны знать куда роутить трафик для конкретных подсетей
-
шлюзы по умолчанию в подсети должны знать куда роутить трафик для конкретных подсетей
Да, именно в этом скорее косяк. вот только не пойму в каком месте…
Траффпро работает уже 3 месяца. Клиенты выходят в интернет через PPPoE.
WAN - PPPoE Static IP
LAN - 192.168.9.254
DHCP раздает такие адреса всем:
ip 192.168.9.10-192.168.9.100
netmask 255.255.255.0
gw 192.168.9.254C сервера никак не могу достучаться до клиентских машинок с local ip, даже ping не идет. Хотя клиенты нормально получают DHCP адреса с того же сервера и через PPPoE выходят через него же в инет. трафик, считается и тп...
Клиенты так же не могут пинговать сервер. 0_о
Вот таблица маршрутизации с сервера:root@lamp ~# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 10.67.15.28 0.0.0.0 255.255.255.255 UH 0 0 0 ppp7 10.16.0.5 0.0.0.0 255.255.255.255 UH 0 0 0 tun0 10.67.15.60 0.0.0.0 255.255.255.255 UH 0 0 0 ppp2 10.67.15.47 0.0.0.0 255.255.255.255 UH 0 0 0 ppp9 10.67.15.31 0.0.0.0 255.255.255.255 UH 0 0 0 ppp3 85.92.31.101 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0 10.67.15.41 0.0.0.0 255.255.255.255 UH 0 0 0 ppp5 10.67.15.25 0.0.0.0 255.255.255.255 UH 0 0 0 ppp4 10.67.15.59 0.0.0.0 255.255.255.255 UH 0 0 0 ppp1 10.67.15.37 0.0.0.0 255.255.255.255 UH 0 0 0 ppp6 10.67.15.54 0.0.0.0 255.255.255.255 UH 0 0 0 ppp12 10.67.15.51 0.0.0.0 255.255.255.255 UH 0 0 0 ppp11 10.16.0.0 10.16.0.5 255.255.255.0 UG 0 0 0 tun0 192.168.1.0 10.16.0.5 255.255.255.0 UG 0 0 0 tun0 192.168.10.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 ppp0а вот с клиента:
Активные маршруты: Сетевой адрес Маска сети Адрес шлюза Интерфейс Метрика 0.0.0.0 0.0.0.0 10.67.15.37 10.67.15.37 1 0.0.0.0 0.0.0.0 192.168.10.254 192.168.10.12 21 10.67.15.37 255.255.255.255 127.0.0.1 127.0.0.1 50 10.255.255.255 255.255.255.255 10.67.15.37 10.67.15.37 50 127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1 192.168.10.0 255.255.255.0 192.168.10.12 192.168.10.12 20 192.168.10.12 255.255.255.255 127.0.0.1 127.0.0.1 20 192.168.10.254 255.255.255.255 10.67.15.37 10.67.15.37 1 192.168.10.255 255.255.255.255 192.168.10.12 192.168.10.12 20 224.0.0.0 240.0.0.0 192.168.10.12 192.168.10.12 20 224.0.0.0 240.0.0.0 10.67.15.37 10.67.15.37 1 255.255.255.255 255.255.255.255 10.67.15.37 10.67.15.37 1 255.255.255.255 255.255.255.255 10.67.15.37 3 1 255.255.255.255 255.255.255.255 192.168.10.12 192.168.10.12 1 Основной шлюз: 10.67.15.37iptables-save:
# Generated by iptables-save v1.4.4 on Mon Sep 19 09:21:42 2011 *nat :PREROUTING ACCEPT [1387473:103236579] :POSTROUTING ACCEPT [1306517:93445583] :OUTPUT ACCEPT [1947798:146149985] -A POSTROUTING -o ppp0 -j MASQUERADE COMMIT # Completed on Mon Sep 19 09:21:42 2011 # Generated by iptables-save v1.4.4 on Mon Sep 19 09:21:42 2011 *mangle :PREROUTING ACCEPT [15816628:5096781475] :INPUT ACCEPT [3796648:626876795] :FORWARD ACCEPT [33946751:24415528825] :OUTPUT ACCEPT [3731124:476678886] :POSTROUTING ACCEPT [18370446:19338407950] -A PREROUTING -i lo -j ACCEPT -A PREROUTING -i ppp0 -j ACCEPT -A FORWARD -o ppp0 -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1400:65495 -j TCPMSS --clamp-mss-to-pmtu -A FORWARD -o ppp9 -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1400:65495 -j TCPMSS --clamp-mss-to-pmtu -A FORWARD -o ppp5 -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1400:65495 -j TCPMSS --clamp-mss-to-pmtu -A FORWARD -o ppp12 -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1400:65495 -j TCPMSS --clamp-mss-to-pmtu -A FORWARD -o ppp11 -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1400:65495 -j TCPMSS --clamp-mss-to-pmtu -A FORWARD -o ppp6 -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1400:65495 -j TCPMSS --clamp-mss-to-pmtu -A FORWARD -o ppp7 -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1400:65495 -j TCPMSS --clamp-mss-to-pmtu -A FORWARD -o ppp4 -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1400:65495 -j TCPMSS --clamp-mss-to-pmtu -A FORWARD -o ppp3 -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1400:65495 -j TCPMSS --clamp-mss-to-pmtu -A FORWARD -o ppp2 -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1400:65495 -j TCPMSS --clamp-mss-to-pmtu -A FORWARD -o ppp1 -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1400:65495 -j TCPMSS --clamp-mss-to-pmtu -A POSTROUTING -o lo -j ACCEPT -A POSTROUTING -o ppp0 -j ACCEPT COMMITВ чем может быть проблема? в iptables не взуб ногой….
-
фаер был закрытый…
-
-
пока решаю…
никак не могу понять как разрешить пакетам свободно "ходить" через eth0.
Сервер никак локальных клиентов не может пинговать =(
iptables -LChain INPUT (policy DROP) target prot opt source destination ACCEPT tcp -- anywhere anywhere tcp dpt:ssh NFQUEUE all -- anywhere anywhere NFQUEUE num 0 ACCEPT all -- anywhere anywhere Chain FORWARD (policy DROP) target prot opt source destination NFQUEUE all -- anywhere anywhere NFQUEUE num 0 Chain OUTPUT (policy DROP) target prot opt source destination ACCEPT tcp -- anywhere anywhere tcp spt:ssh NFQUEUE all -- anywhere anywhere NFQUEUE num 0 ACCEPT all -- anywhere anywhereiptables-save
root@lamp ~# iptables-save # Generated by iptables-save v1.4.4 on Tue Sep 20 11:40:35 2011 *filter :INPUT DROP [0:0] :FORWARD DROP [1:71] :OUTPUT DROP [0:0] -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT -A INPUT -i ppp0 -j NFQUEUE --queue-num 0 -A INPUT -j ACCEPT -A FORWARD -j NFQUEUE --queue-num 0 -A OUTPUT -p tcp -m tcp --sport 22 -j ACCEPT -A OUTPUT -o ppp0 -j NFQUEUE --queue-num 0 -A OUTPUT -j ACCEPT COMMIT # Completed on Tue Sep 20 11:40:35 2011 # Generated by iptables-save v1.4.4 on Tue Sep 20 11:40:35 2011 *nat :PREROUTING ACCEPT [51266:3564685] :POSTROUTING ACCEPT [33160:2361210] :OUTPUT ACCEPT [48506:3621584] -A POSTROUTING -o ppp0 -j SNAT --to-source 85.237.46.30 COMMIT # Completed on Tue Sep 20 11:40:35 2011 # Generated by iptables-save v1.4.4 on Tue Sep 20 11:40:35 2011 *mangle :PREROUTING ACCEPT [493942:304717401] :INPUT ACCEPT [98561:14431403] :FORWARD ACCEPT [969762:741240740] :OUTPUT ACCEPT [95875:11804316] :POSTROUTING ACCEPT [486840:437728486] -A PREROUTING -i lo -j ACCEPT -A PREROUTING -i lo -j ACCEPT -A PREROUTING -i ppp0 -j ACCEPT -A FORWARD -o ppp10 -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1400:65495 -j TCPMSS --clamp-mss -to-pmtu -A POSTROUTING -o lo -j ACCEPT -A POSTROUTING -o lo -j ACCEPT -A POSTROUTING -o ppp0 -j ACCEPT COMMIT # Completed on Tue Sep 20 11:40:35 2011 -
Какие странные правила… кто их создавал?
-
traffpro.
На форуме у них сказали вот что:судя по правилам сам traffpro всё поставил, но вот интересный момент, у вас все порты закрыты кроме 22го, у вас сам файрвол по умолчанию закрыт, либо настройте и включите защиту в traffpro (она откроет во внутреннюю сеть карту), либо настройте вайрвол по умолчанию, либо просто добавьте в файл traffpro_rule.cfg правила iptables для открытия нужных портов и протоколов.
На этом и застрял. Traffpro сам добавляем определенные правила в iptables. Если нужны свои, то нужно добавлять в traffpro_rule.cfg
У меня в этом файле:# Позволит не потерять контроль над сервером при включённой защите сервера. iptables -A INPUT -m tcp -p tcp --dport 22 -j ACCEPT iptables -A OUTPUT -m tcp -p tcp --sport 22 -j ACCEPT modprobe ip_conntrack_ftp modprobe ip_nat_ftpЗащиту сервера включил, не помогло. На тамошнем форуме молчат http://www.traffpro.ru/forum/topic_2216/1
-
попробуй добавить
iptables -A FORWARD -p icmp -j ACCEPTесли не поможет, то
iptables -A INPUT -p icmp -j ACCEPT iptables -A FORWARD -p icmp -j ACCEPT iptables -A OUTPUT -p icmp -j ACCEPTи покажи после этого опять```
iptables -L -nv -
iptables -A FORWARD -p icmp -j ACCEPT
Спасибо за помощь.
С этим правилом вроде пинг идет (а может он шел и без правила, просто из-за трудности проверить клиентские компы (в 150 километрах), я не заметил), но если у пользователя отключено pppoe соединение. Как только соединение устанавливается, сервер перестает пинговать клиента по локальному IP.route print при включенном PPPoE
Активные маршруты: Сетевой адрес Маска сети Адрес шлюза Интерфейс Метрика 0.0.0.0 0.0.0.0 10.67.15.7 10.67.15.7 1 0.0.0.0 0.0.0.0 192.168.10.254 192.168.10.12 21 10.67.15.7 255.255.255.255 127.0.0.1 127.0.0.1 50 10.255.255.255 255.255.255.255 10.67.15.7 10.67.15.7 50 127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1 192.168.10.0 255.255.255.0 192.168.10.12 192.168.10.12 20 192.168.10.12 255.255.255.255 127.0.0.1 127.0.0.1 20 192.168.10.254 255.255.255.255 10.67.15.7 10.67.15.7 1 192.168.10.255 255.255.255.255 192.168.10.12 192.168.10.12 20 224.0.0.0 240.0.0.0 192.168.10.12 192.168.10.12 20 224.0.0.0 240.0.0.0 10.67.15.7 10.67.15.7 1 255.255.255.255 255.255.255.255 10.67.15.7 10.67.15.7 1 255.255.255.255 255.255.255.255 10.67.15.7 3 1 255.255.255.255 255.255.255.255 192.168.10.12 192.168.10.12 1 Основной шлюз: 10.67.15.7при отключенном PPPoE:
Активные маршруты: Сетевой адрес Маска сети Адрес шлюза Интерфейс Метрика 0.0.0.0 0.0.0.0 192.168.10.254 192.168.10.12 20 127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1 192.168.10.0 255.255.255.0 192.168.10.12 192.168.10.12 20 192.168.10.12 255.255.255.255 127.0.0.1 127.0.0.1 20 192.168.10.255 255.255.255.255 192.168.10.12 192.168.10.12 20 224.0.0.0 240.0.0.0 192.168.10.12 192.168.10.12 20 255.255.255.255 255.255.255.255 192.168.10.12 192.168.10.12 1 255.255.255.255 255.255.255.255 192.168.10.12 3 1 Основной шлюз: 192.168.10.254 -
Это таблица маршрутизации с сервера? Какой локальный IP клиента пингуем?
-
это с клиента.
с сервера вот:root@lamp ~# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 10.16.0.5 0.0.0.0 255.255.255.255 UH 0 0 0 tun0 10.67.15.9 0.0.0.0 255.255.255.255 UH 0 0 0 ppp6 80.95.33.102 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0 10.67.15.1 0.0.0.0 255.255.255.255 UH 0 0 0 ppp1 10.67.15.3 0.0.0.0 255.255.255.255 UH 0 0 0 ppp3 10.16.0.0 10.16.0.5 255.255.255.0 UG 0 0 0 tun0 192.168.1.0 10.16.0.5 255.255.255.0 UG 0 0 0 tun0 192.168.10.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 ppp0С сервера пингую 192.168.10.12 (клиентский комп за сетью с traffpro)
-
стоп, запутался, где iptables - на сервере или клиенте?
-
iptables на сервере. Клиенты - это рабочии станции.
Сервер:
Внешний интерфейс ppp0 - со статически выдаваемым белым IP.
Клиенты подключаются через PPPoE, получают адреса из подсети 10.67.15.0/24. В интернет выходят нормально. Но вот только при работающем PPPoE не пингуются клиенты с сервера по локальным IP. И клиенты не могут пинговать сервер по локальному IP и IP за OpenVPN. Как только отключить PPPoE на клиенте, все нормально…
Тут скорее в маршрутизации затык и фаере... -
а на клиентах есть firewalls?
Попробуй на сервереtcpdump -ni eth0 icmp or arpи пингуй при поднятом PPPoE и опущенном.
-
При поднятом:
root@lamp ~# tcpdump -ni eth0 icmp or arp tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 08:12:18.396627 ARP, Request who-has 192.168.10.12 tell 192.168.10.254, length 28 08:12:18.396826 ARP, Reply 192.168.10.12 is-at 6c:f0:49:dd:1d:7e, length 46 08:12:18.396837 IP 192.168.10.254 > 192.168.10.12: ICMP echo request, id 31745, seq 1, length 64 08:12:19.402716 IP 192.168.10.254 > 192.168.10.12: ICMP echo request, id 31745, seq 2, length 64 08:12:20.410708 IP 192.168.10.254 > 192.168.10.12: ICMP echo request, id 31745, seq 3, length 64 08:12:20.530090 ARP, Request who-has 192.168.1.29 tell 192.168.1.44, length 46 08:12:20.530254 ARP, Request who-has 192.168.1.44 tell 192.168.1.29, length 46 08:12:21.418707 IP 192.168.10.254 > 192.168.10.12: ICMP echo request, id 31745, seq 4, length 64 08:12:22.426220 IP 192.168.10.254 > 192.168.10.12: ICMP echo request, id 31745, seq 5, length 64 08:12:23.434707 IP 192.168.10.254 > 192.168.10.12: ICMP echo request, id 31745, seq 6, length 64 08:12:24.079936 ARP, Request who-has 192.168.1.21 tell 192.168.1.44, length 46 08:12:24.442662 IP 192.168.10.254 > 192.168.10.12: ICMP echo request, id 31745, seq 7, length 64 08:12:25.450172 IP 192.168.10.254 > 192.168.10.12: ICMP echo request, id 31745, seq 8, length 64 08:12:26.458209 IP 192.168.10.254 > 192.168.10.12: ICMP echo request, id 31745, seq 9, length 64 08:12:27.466209 IP 192.168.10.254 > 192.168.10.12: ICMP echo request, id 31745, seq 10, length 64При отключенном:
08:53:03.322004 IP 192.168.10.254 > 192.168.10.12: ICMP echo request, id 7433, seq 1, length 64 08:53:04.330730 IP 192.168.10.254 > 192.168.10.12: ICMP echo request, id 7433, seq 2, length 64 08:53:05.338207 IP 192.168.10.254 > 192.168.10.12: ICMP echo request, id 7433, seq 3, length 64 08:53:06.346213 IP 192.168.10.254 > 192.168.10.12: ICMP echo request, id 7433, seq 4, length 64 08:53:06.346427 IP 192.168.10.12 > 192.168.10.254: ICMP echo reply, id 7433, seq 4, length 64 08:53:07.345210 IP 192.168.10.254 > 192.168.10.12: ICMP echo request, id 7433, seq 5, length 64 08:53:07.345444 IP 192.168.10.12 > 192.168.10.254: ICMP echo reply, id 7433, seq 5, length 64 08:53:08.344218 IP 192.168.10.254 > 192.168.10.12: ICMP echo request, id 7433, seq 6, length 64 08:53:08.344362 IP 192.168.10.12 > 192.168.10.254: ICMP echo reply, id 7433, seq 6, length 64 08:53:09.345254 IP 192.168.10.254 > 192.168.10.12: ICMP echo request, id 7433, seq 7, length 64 08:53:09.345466 IP 192.168.10.12 > 192.168.10.254: ICMP echo reply, id 7433, seq 7, length 64 08:53:10.348279 IP 192.168.10.254 > 192.168.10.12: ICMP echo request, id 7433, seq 8, length 64 08:53:10.348498 IP 192.168.10.12 > 192.168.10.254: ICMP echo reply, id 7433, seq 8, length 64 08:53:11.348148 IP 192.168.10.254 > 192.168.10.12: ICMP echo request, id 7433, seq 9, length 64