opvnvpn: endereçando nós em LAN-behinds

Question

opvnvpn: endereçando nós em LAN-behinds

#1 resposta do (2 votos)
#2 resposta do (2 votos)
#3 resposta do (2 votos)
#4 resposta do (2 votos)
#5 resposta do (1 votos)
#6 resposta do (0 votos)
#7 resposta do (0 votos)
#8 resposta do (0 votos)

6

Eu configurei um servidor openvpn que eu posso acessar remotamente, uma vez conectado, ele cria um dispositivo tun0 no servidor e no cliente com o ip virtual 10.15.119.x. o servidor openvpn é ele mesmo 10.15.119.1.

Pergunta: como faço para abordar outros nós na lan por trás do servidor openvpn? Eu posso acessar serviços no próprio servidor openvpn com o endereço 10.15.119.1:(port), mas eu não sei como endereçar outros nós que não participam da conexão openvpn que estão na mesma LAN que o servidor openvpn:

eu poderia muito bem criar alguns iptables e rotear comandos para encaminhar portas para outros nós específicos, mas tenho certeza que tem que haver uma maneira mais agradável de fazer isso, endereçando diretamente os nós

server.conf:

dev tun server 10.15.119.0 255.255.255.0 ifconfig-pool-persist ipp.txt push "route 192.168.0.0 255.255.255.0" up ./office.up tls-server dh /home/lurscher/keys/dh1024.pem ca /home/lurscher/keys/ca.crt cert /home/lurscher/keys/vpnCh8TestServer.crt key /home/lurscher/keys/vpnCh8TestServer.key status openvpn-status.log log openvpn.log comp-lzo verb 3

o script office.up tem:

#!/bin/sh #route 10.15.119.0 255.255.255.0 route add -net 10.15.119.0 netmask 255.255.255.0 gw $5 #fixed the wrong 10.15.0.0 address

client.conf em vez disso:

dev tun remote my.server.com tls-client pull ca /home/chuckq/keys/ca.crt cert /home/chuckq/keys/vpnCh8TestClient.crt key /home/chuckq/keys/vpnCh8TestClient.key ns-cert-type server ; port 1194 ; user nobody ; group nogroup status openvpn-status.log log openvpn.log comp-lzo verb 3

Novo registros relevantes do servidor:

Thu May 26 16:59:59 2011 vpnCh8TestClient/Y.Y.Y.Y:1194 PUSH: Received control message: 'PUSH_REQUEST' Thu May 26 16:59:59 2011 vpnCh8TestClient/Y.Y.Y.Y:1194 SENT CONTROL [vpnCh8TestClient]: 'PUSH_REPLY,route 192.168.0.0 255.255.255.0,route 10.15.119.1,topology net30,ifconfig 10.15.119.6 10.15.119.5' (status=1) Thu May 26 17:02:17 2011 vpnCh8TestClient/Y.Y.Y.Y:1194 Replay-window backtrack occurred [1]

registros relevantes do cliente:

Thu May 26 16:53:30 2011 [vpnCh8TestServer] Peer Connection Initiated with [AF_INET]X.X.X.X:1194 Thu May 26 16:53:32 2011 SENT CONTROL [vpnCh8TestServer]: 'PUSH_REQUEST' (status=1) Thu May 26 16:53:32 2011 PUSH: Received control message: 'PUSH_REPLY,route 192.168.0.0 255.255.255.0,route 10.15.119.1,topology net30,ifconfig 10.15.119.6 10.15.119.5' Thu May 26 16:53:32 2011 OPTIONS IMPORT: --ifconfig/up options modified Thu May 26 16:53:32 2011 OPTIONS IMPORT: route options modified Thu May 26 16:53:32 2011 ROUTE default_gateway=10.21.2.254 Thu May 26 16:53:32 2011 TUN/TAP device tun0 opened Thu May 26 16:53:32 2011 TUN/TAP TX queue length set to 100 Thu May 26 16:53:32 2011 /sbin/ifconfig tun0 10.15.119.6 pointopoint 10.15.119.5 mtu 1500 Thu May 26 16:53:32 2011 /sbin/route add -net 192.168.0.0 netmask 255.255.255.0 gw 10.15.119.5 Thu May 26 16:53:32 2011 /sbin/route add -net 10.15.119.1 netmask 255.255.255.255 gw 10.15.119.5 Thu May 26 16:53:32 2011 Initialization Sequence Completed

EDITAR graças ao wolfgangsz que notou um erro de digitação no escritório. Eu tentei novamente o tracepath sem melhorias:

$ tracepath 192.168.0.100 1: 10.15.119.6 0.261ms pmtu 1500 1: 10.15.119.1 88.989ms 1: 10.15.119.1 58.752ms 2: no reply

observe como o resultado é diferente quando o ip é aquele do servidor openvpn

$ tracepath 192.168.0.101 1: 10.15.119.6 0.308ms pmtu 1500 1: 192.168.0.101 115.713ms reached 1: 192.168.0.101 65.064ms reached Resume: pmtu 1500 hops 1 back 64

Entradas de roteamento no cliente:

$ route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 10.15.119.5 0.0.0.0 255.255.255.255 UH 0 0 0 tun0 10.15.119.1 10.15.119.5 255.255.255.255 UGH 0 0 0 tun0 192.168.0.0 10.15.119.5 255.255.255.0 UG 0 0 0 tun0 10.21.2.0 0.0.0.0 255.255.255.0 U 1 0 0 eth0 169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 eth0 0.0.0.0 10.21.2.254 0.0.0.0 UG 0 0 0 eth0

e entradas de roteamento no servidor (openvpn):

$ route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 10.15.119.2 0.0.0.0 255.255.255.255 UH 0 0 0 tun0 10.15.119.0 10.15.119.2 255.255.255.0 UG 0 0 0 tun0 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 vboxnet0 0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 eth1 0.0.0.0 0.0.0.0 0.0.0.0 U 1002 0 0 eth0 0.0.0.0 0.0.0.0 0.0.0.0 U 1004 0 0 vboxnet0

EDIT 2: verifiquei se o encaminhamento de ip está ativado

$ cat /proc/sys/net/ipv4/ip_forward 1

aqui está a saída do iptables no servidor:

$ sudo iptables -nv -L Chain INPUT (policy DROP 1 packets, 52 bytes) pkts bytes target prot opt in out source destination 0 0 DROP all -- eth0 * 127.0.0.1 0.0.0.0/0 0 0 DROP all -- eth0 * 0.0.0.0/0 127.0.0.1 0 0 DROP all -- eth0 * 192.168.0.0/16 0.0.0.0/0 0 0 DROP all -- eth0 * 172.16.0.0/12 0.0.0.0/0 0 0 DROP all -- eth0 * 10.0.0.0/8 0.0.0.0/0 8 416 ACCEPT all -- * * 127.0.0.1 0.0.0.0/0 0 0 ACCEPT all -- * * 0.0.0.0/0 127.0.0.1 0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmp type 8 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 91 8915 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 293 28499 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:1194 1 1500 ACCEPT all -- tun+ * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT all -- tap+ * 0.0.0.0/0 0.0.0.0/0 18 2010 ACCEPT all -- eth1 * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED Chain FORWARD (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 DROP all -- eth0 * 127.0.0.1 0.0.0.0/0 0 0 DROP all -- eth0 * 0.0.0.0/0 127.0.0.1 0 0 DROP all -- eth0 * 192.168.0.0/16 0.0.0.0/0 0 0 DROP all -- eth0 * 172.16.0.0/12 0.0.0.0/0 0 0 DROP all -- eth0 * 10.0.0.0/8 0.0.0.0/0 0 0 DROP tcp -- * eth0 0.0.0.0/0 0.0.0.0/0 tcp spts:137:139 0 0 DROP udp -- * eth0 0.0.0.0/0 0.0.0.0/0 udp spts:137:139 0 0 DROP all -- eth1 * !10.0.0.0/24 0.0.0.0/0 38 57000 ACCEPT all -- tun+ * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT all -- tap+ * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT all -- eth1 * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT all -- * eth0 0.0.0.0/0 0.0.0.0/0 state NEW 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED Chain OUTPUT (policy ACCEPT 306 packets, 34543 bytes) pkts bytes target prot opt in out source destination 0 0 DROP tcp -- * eth0 0.0.0.0/0 0.0.0.0/0 tcp spts:137:139 0 0 DROP udp -- * eth0 0.0.0.0/0 0.0.0.0/0 udp spts:137:139 0 0 ACCEPT all -- * eth0 0.0.0.0/0 0.0.0.0/0 state NEW

EDIT 3

Eu acho que deixei uma informação importante, não achei que fosse relevante, mas uma resposta recente me fez pensar que isso poderia acontecer; o openvpn está diretamente conectado ao roteador, e na configuração do roteador (em 192.168.0.1) eu ativei o encaminhamento de porta para a porta openvpn 1194 para o servidor openvpn, é assim que eu estou atualmente conectando remotamente

EDIT 4

Eu tentei executar o seguinte na máquina 192.168.0.100 (servidor secundário), para ver se eu posso resolver isso dando uma rota para a rota 10.15.119.x:

sudo route add -net 10.15.119.0 netmask 255.255.255.0 gw 192.168.0.101

(o 192.168.0.101 é o endereço do servidor openvpn, 192.168.0.100 é o servidor secundário que eu quero acessar de fora)

eu tentei isso e ping 10.15.119.1 funciona para entrar em contato com o servidor openvpn, mas ping 10.15.119.6 (meu ip do cliente) simplesmente falha

EDIT 5

Eu adicionei os resultados de tcpdump no servidor openvpn ao tentar pingar 192.168.0.100 do cliente:

$ sudo tcpdump -v -i any host 192.168.0.100 tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes 11:10:43.675915 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84) 10.15.119.6 > services-host-1.local: ICMP echo request, id 2494, seq 1, length 64 11:10:43.675932 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto ICMP (1), length 84) 10.15.119.6 > services-host-1.local: ICMP echo request, id 2494, seq 1, length 64 11:10:43.676149 IP (tos 0x0, ttl 64, id 40127, offset 0, flags [none], proto ICMP (1), length 84) services-host-1.local > 10.15.119.6: ICMP echo reply, id 2494, seq 1, length 64 11:10:43.778583 IP (tos 0x0, ttl 255, id 0, offset 0, flags [DF], proto UDP (17), length 103) services-host-1.local.mdns > 224.0.0.251.mdns: 0*- [0q] 1/0/0 100.0.168.192.in-addr.arpa. (Cache flush) PTR services-host-1.local. (75) 11:10:43.778588 IP (tos 0x0, ttl 255, id 0, offset 0, flags [DF], proto UDP (17), length 103) services-host-1.local.mdns > 224.0.0.251.mdns: 0*- [0q] 1/0/0 100.0.168.192.in-addr.arpa. (Cache flush) PTR services-host-1.local. (75) 11:10:44.681801 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84) 10.15.119.6 > services-host-1.local: ICMP echo request, id 2494, seq 2, length 64 11:10:44.681809 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto ICMP (1), length 84) 10.15.119.6 > services-host-1.local: ICMP echo request, id 2494, seq 2, length 64 11:10:44.682007 IP (tos 0x0, ttl 64, id 40128, offset 0, flags [none], proto ICMP (1), length 84) services-host-1.local > 10.15.119.6: ICMP echo reply, id 2494, seq 2, length 64 11:10:45.689926 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84) 10.15.119.6 > services-host-1.local: ICMP echo request, id 2494, seq 3, length 64 11:10:45.689933 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto ICMP (1), length 84) 10.15.119.6 > services-host-1.local: ICMP echo request, id 2494, seq 3, length 64 11:10:45.690121 IP (tos 0x0, ttl 64, id 40129, offset 0, flags [none], proto ICMP (1), length 84) services-host-1.local > 10.15.119.6: ICMP echo reply, id 2494, seq 3, length 64 11:10:46.698990 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84) 10.15.119.6 > services-host-1.local: ICMP echo request, id 2494, seq 4, length 64 11:10:46.698997 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto ICMP (1), length 84) 10.15.119.6 > services-host-1.local: ICMP echo request, id 2494, seq 4, length 64 11:10:46.699190 IP (tos 0x0, ttl 64, id 40130, offset 0, flags [none], proto ICMP (1), length 84) services-host-1.local > 10.15.119.6: ICMP echo reply, id 2494, seq 4, length 64 11:10:47.706870 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84) 10.15.119.6 > services-host-1.local: ICMP echo request, id 2494, seq 5, length 64 11:10:47.706878 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto ICMP (1), length 84) 10.15.119.6 > services-host-1.local: ICMP echo request, id 2494, seq 5, length 64 11:10:47.707067 IP (tos 0x0, ttl 64, id 40131, offset 0, flags [none], proto ICMP (1), length 84) services-host-1.local > 10.15.119.6: ICMP echo reply, id 2494, seq 5, length 64 11:10:48.680540 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has services-host-1.local tell openvpnServer, length 28 11:10:48.680737 ARP, Ethernet (len 6), IPv4 (len 4), Reply services-host-1.local is-at 08:00:27:a4:e2:01 (oui Unknown), length 28 11:10:48.684812 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has dfdlinkrouter tell services-host-1.local, length 28 11:10:48.685338 ARP, Ethernet (len 6), IPv4 (len 4), Reply dfdlinkrouter is-at 00:26:5a:ae:90:88 (oui Unknown), length 46 11:10:48.716100 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84) 10.15.119.6 > services-host-1.local: ICMP echo request, id 2494, seq 6, length 64 11:10:48.716107 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto ICMP (1), length 84) 10.15.119.6 > services-host-1.local: ICMP echo request, id 2494, seq 6, length 64 11:10:48.716347 IP (tos 0x0, ttl 64, id 40132, offset 0, flags [none], proto ICMP (1), length 84) services-host-1.local > 10.15.119.6: ICMP echo reply, id 2494, seq 6, length 64

então parece que o ping está chegando ao servidor e ele responde de volta, mas os pacotes são descartados antes de entrar no vpn, então eu adicionei uma linha no iptables para registrar todos os pacotes INPUT e FORWARD descartados ou rejeitados e aqui está o que está sendo filtrado em /var/log/syslog

May 30 10:59:24 openvpnServer kernel: [40433.898392] iptables INPUT denied: IN=eth1 OUT= MAC= SRC=192.168.0.101 DST=224.0.0.251 LEN=98 TOS=0x00 PREC=0x00 TTL=255 ID=0 DF PROTO=UDP SPT=5353 DPT=5353 LEN=78 May 30 10:59:24 openvpnServer kernel: [40434.001003] iptables INPUT denied: IN=eth1 OUT= MAC=01:00:5e:00:00:fb:08:00:27:a4:e2:01:08:00 SRC=192.168.0.100 DST=224.0.0.251 LEN=62 TOS=0x00 PREC=0x00 TTL=255 ID=0 DF PROTO=UDP SPT=5353 DPT=5353 LEN=42 May 30 10:59:24 openvpnServer kernel: [40434.001102] iptables INPUT denied: IN=eth1 OUT= MAC= SRC=192.168.0.101 DST=224.0.0.251 LEN=72 TOS=0x00 PREC=0x00 TTL=255 ID=0 DF PROTO=UDP SPT=5353 DPT=5353 LEN=52 May 30 11:03:28 openvpnServer kernel: [40677.329586] iptables INPUT denied: IN=eth1 OUT= MAC= SRC=192.168.0.101 DST=224.0.0.251 LEN=67 TOS=0x00 PREC=0x00 TTL=255 ID=0 DF PROTO=UDP SPT=5353 DPT=5353 LEN=47 May 30 11:03:29 openvpnServer kernel: [40678.330065] iptables INPUT denied: IN=eth1 OUT= MAC= SRC=192.168.0.101 DST=224.0.0.251 LEN=67 TOS=0x00 PREC=0x00 TTL=255 ID=0 DF PROTO=UDP SPT=5353 DPT=5353 LEN=47

Eu comentei a maioria dos comandos DROP e REJECT do iptables para ver se isso funciona, mas ainda estou com o mesmo problema, aqui está o meu iptables depois de remover todas as gotas

$ sudo iptables -L -nv Chain INPUT (policy ACCEPT 88 packets, 15209 bytes) pkts bytes target prot opt in out source destination 3404 3162K ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0 0 0 REJECT all -- !lo * 0.0.0.0/0 127.0.0.0/8 reject-with icmp-port-unreachable 2950 249K ACCEPT all -- tun+ * 0.0.0.0/0 0.0.0.0/0 12881 6906K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 162 9696 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:22 1 42 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:1194 0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmp type 8 60 10407 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 limit: avg 5/min burst 5 LOG flags 0 level 7 prefix 'iptables INPUT denied: ' Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 30 2448 ACCEPT all -- tun+ * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:1194 0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 limit: avg 5/min burst 5 LOG flags 0 level 7 prefix 'iptables FORWARD denied: ' Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 2826 857K ACCEPT all -- * tun+ 0.0.0.0/0 0.0.0.0/0 17443 5842K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0

EDIT 6

como sugerido por Steven, eu adicionei 3 tcpdumps, 2 no servidor e um no cliente, enquanto do cliente, rodando

$ ping 192.168.0.100 PING 192.168.0.100 (192.168.0.100) 56(84) bytes of data. ^C --- 192.168.0.100 ping statistics --- 5 packets transmitted, 0 received, 100% packet loss, time 4024ms

mas primeiro eu liberei todas as regras do iptables no servidor openvpn:

$ sudo iptables -L -nv Chain INPUT (policy ACCEPT 206 packets, 26537 bytes) pkts bytes target prot opt in out source destination Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 50 packets, 7781 bytes) pkts bytes target prot opt in out source destination

aqui está a saída do primeiro tcpdump no servidor openvpn

$ sudo tcpdump -vn -i tun0 '(host 192.168.0.100 or host 10.15.119.6)' and icmp tcpdump: listening on tun0, link-type RAW (Raw IP), capture size 65535 bytes 13:54:30.871403 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84) 10.15.119.6 > 192.168.0.100: ICMP echo request, id 3145, seq 1, length 64 13:54:31.870534 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84) 10.15.119.6 > 192.168.0.100: ICMP echo request, id 3145, seq 2, length 64 13:54:32.879562 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84) 10.15.119.6 > 192.168.0.100: ICMP echo request, id 3145, seq 3, length 64

um segundo tcpdump no servidor:

$ sudo tcpdump -vn -i eth1 '(host 192.168.0.100 or host 10.15.119.6)' and icmp tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes 13:54:30.871429 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto ICMP (1), length 84) 10.15.119.6 > 192.168.0.100: ICMP echo request, id 3145, seq 1, length 64 13:54:30.875508 IP (tos 0x0, ttl 64, id 28969, offset 0, flags [none], proto ICMP (1), length 84) 192.168.0.100 > 10.15.119.6: ICMP echo reply, id 3145, seq 1, length 64 13:54:31.870544 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto ICMP (1), length 84) 10.15.119.6 > 192.168.0.100: ICMP echo request, id 3145, seq 2, length 64 13:54:31.870760 IP (tos 0x0, ttl 64, id 28970, offset 0, flags [none], proto ICMP (1), length 84) 192.168.0.100 > 10.15.119.6: ICMP echo reply, id 3145, seq 2, length 64

e um terceiro tcpdump, desta vez no cliente:

$ sudo tcpdump -vn -i eth0 host 192.168.0.100 and icmp tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes ^C 0 packets captured 0 packets received by filter 0 packets dropped by kernel

IMPORTANTE aqui está outra coisa que pode ser útil, no cliente eu corri ip route show

$ sudo ip route show 10.15.119.5 dev tun0 proto kernel scope link src 10.15.119.6 10.15.119.1 via 10.15.119.5 dev tun0 192.168.0.0/24 via 10.15.119.5 dev tun0 10.21.2.0/24 dev eth0 proto kernel scope link src 10.21.2.118 metric 1 169.254.0.0/16 dev eth0 scope link metric 1000 default via 10.21.2.254 dev eth0 proto static

mesmo comando no servidor openvpn

$ sudo ip route show 10.15.119.2 dev tun0 proto kernel scope link src 10.15.119.1 10.15.119.0/24 via 10.15.119.2 dev tun0 192.168.0.0/24 dev eth1 proto kernel scope link src 192.168.0.101 metric 1 169.254.0.0/16 dev eth1 scope link metric 1000 default via 192.168.0.1 dev eth1 proto static

versão openvpn:

$ openvpn --version OpenVPN 2.1.0 x86_64-pc-linux-gnu [SSL] [LZO2] [EPOLL] [PKCS11] [MH] [PF_INET6] [eurephia] construído em 12 de julho de 2010 Originalmente desenvolvido por James Yonan Copyright (C) 2002-2009 OpenVPN Technologies, Inc.

sistema operacional é Ubuntu 10.10 x86_64

Por que eu entro no log do cliente:

ue May 31 14:45:41 2011 /sbin/ifconfig tun0 10.15.119.6 pointopoint 10.15.119.5 mtu 1500 Tue May 31 14:45:41 2011 /sbin/route add -net 192.168.0.0 netmask 255.255.255.0 gw 10.15.119.5 Tue May 31 14:45:41 2011 /sbin/route add -net 10.15.119.1 netmask 255.255.255.255 gw 10.15.119.5

O que é uma máscara 255.255.255.255 para a rede virtual?

@skrewler, este é o resultado do netstat:

primeiro, do cliente quando o openvpn está em execução:

$ netstat -rn Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 10.15.119.5 0.0.0.0 255.255.255.255 UH 0 0 0 tun0 10.15.119.1 10.15.119.5 255.255.255.255 UGH 0 0 0 tun0 192.168.0.0 10.15.119.5 255.255.255.0 UG 0 0 0 tun0 10.21.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0 0.0.0.0 10.21.2.254 0.0.0.0 UG 0 0 0 eth0 $ ifconfig -a eth0 Link encap:Ethernet HWaddr 08:00:27:0c:86:1c inet addr:10.21.2.118 Bcast:10.21.2.255 Mask:255.255.255.0 inet6 addr: fe80::a00:27ff:fe0c:861c/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:22701 errors:0 dropped:0 overruns:0 frame:0 TX packets:12806 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:2855655 (2.8 MB) TX bytes:1224261 (1.2 MB) lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:8 errors:0 dropped:0 overruns:0 frame:0 TX packets:8 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:480 (480.0 B) TX bytes:480 (480.0 B) tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet addr:10.15.119.6 P-t-P:10.15.119.5 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

e o client.conf:

dev tun0 remote my.server.com tls-client pull ca keys/ca.crt cert keys/client.crt key keys/client.key ns-cert-type server status logs/openvpn-status.log log logs/openvpn.log comp-lzo verb 4

segundo, do servidor openvpn

$ netstat -rn Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 10.15.119.2 0.0.0.0 255.255.255.255 UH 0 0 0 tun0 10.15.119.0 10.15.119.2 255.255.255.0 UG 0 0 0 tun0 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth1 0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 eth1

server.conf

dev tun server 10.15.119.0 255.255.255.0 ifconfig-pool-persist ipp.txt push "route 192.168.0.0 255.255.255.0" tls-server dh keys/dh1024.pem ca keys/ca.crt cert keys/openvpn-server-key.crt key keys/openvpn-server-key.key user nobody group nogroup status openvpn-status.log log logs/openvpn.log comp-lzo verb 4

com a configuração acima, eu posso:

1) ping do cliente para 192.168.0.101 (o servidor openvpn) 2) ping do openvpnserver para 10.15.119.6 (o cliente)

o que eu não consigo fazer é ping 192.168.0.100 (servidor de rede local secundário) do cliente.

192.168.0.100 realmente responde ao cliente como o tcpdump nos shows do openserver, mas de alguma forma esses pacotes não retornam para o cliente

networking openvpn routing tun

por lurscher 31.05.2011 / 22:26

8 respostas

2

Eu passei pelas respostas e acho que sou perspicaz para onde você está com tudo isso.

Vamos fazer algumas verificações simples para restringir o problema:

De um dos clientes OpenVPN que não é capaz de executar ping em um host 192.168.0.x: %código% Também nos forneça netstatn -rn para * nix ou ifconfig -a %código% ipconfig /all

Do servidor openvpn: %código% %código% %código% ping <openvpn server external 10.21.x address>

Além disso, sua configuração atual do servidor e do cliente openvpn provavelmente estará em ping <openvpn 10.15.x address e na máquina cliente netstatn -rn ou ping <a 192.168.0.x host>

Eu tenho uma configuração semelhante. No meu servidor OpenVPN eu tenho o equiv desta regra iptables (alterado hostmask / interface para o que seus valores devem ser):

# Generated by iptables-save v1.4.4 *nat :PREROUTING ACCEPT [5:332] :POSTROUTING ACCEPT [5:740] :OUTPUT ACCEPT [5:740] -A POSTROUTING -s 10.15.119.0/2 -o eth1 -j MASQUERADE COMMIT

Parece que seu problema é definitivamente porque você está com falta de iptable_nat.

# lsmod | grep nat iptable_nat 5011 1 nf_nat 19101 2 ipt_MASQUERADE,iptable_nat nf_conntrack_ipv4 12548 3 iptable_nat,nf_nat nf_conntrack 72270 4 ipt_MASQUERADE,iptable_nat,nf_nat,nf_conntrack_ipv4 ip_tables 17942 2 iptable_nat,iptable_filter x_tables 21613 3 ipt_MASQUERADE,iptable_nat,ip_tables

ping <a 10.15.x host> ou tente com o parâmetro ping <a 10.21.x host> .


por 01.06.2011 / 01:00

2

Você precisará enviar uma rota para os clientes. Isso é feito usando a opção "push" no arquivo de configuração do servidor.

Por padrão, o servidor OpenVPN apenas enviará uma rota para si mesmo.

Em geral, ao configurar um servidor VPN, é uma boa ideia ter a VPN trabalhando em uma sub-rede separada, para facilitar o seu roteamento e facilitar a configuração do firewall. Exemplo:

O servidor que executa o servidor OpenVPN possui um endereço IP interno de 10.15.119.1. Seu endereço IP público é 123.1.2.3. E toda a sua rede interna está em 10.15.119.0/24. Em seguida, você configuraria o servidor OpenVPN para executar em 10.15.120.0/24, que fornecerá até 63 possíveis conexões de cliente (cada conexão requer uma pequena sub-rede de 4 endereços IP). O primeiro cliente que se conecta receberá o endereço IP 10.15.120.5. Se você agora enviar a rota para 10.15.119.0/24, o cliente adicionará uma rota à sua tabela de roteamento para que todo o tráfego dessa sub-rede entre no túnel. O servidor OpenVPN irá então transferir esse tráfego para sua conexão ethernet privada.

Leia a página de manual do OpenVPN (ou a documentação na internet) para obter os detalhes exatos de como enviar uma rota.


por 21.05.2011 / 22:24

2

Talvez eu não esteja entendendo direito, mas o equipamento que você está tentando acessar por trás do servidor VPN tem uma rota configurada que aponta para a sub-rede do cliente OpenVPN?

Se você estiver executando o OpenVPN em um sistema que não é o seu gateway padrão e requer uma rota separada, esses servidores não poderão receber pacotes de volta para seus clientes.

Os pings originados de seu servidor OpenVPN estão sendo enviados de uma interface para a qual o equipamento pode rotear, mas talvez os pings voltando para os clientes não tenham nenhuma rota para voltar se os outros servidores não souberem sobre essa rota.

Isso pode ser irrelevante se você estiver NAT em seu tráfego de clientes no servidor, mas eu não vi nada para indicar isso nas configurações que você postou.


por 27.05.2011 / 20:04

2

Tente isto:

Adicione uma regra SNAT do iptables em seu servidor.

iptables -t nat -A POSTROUTING -s 10.15.119.0/24 -o eth0 -j SNAT --to-source 10.21.2.118

Isso dará a qualquer conexão IP de cliente VPN para seus outros servidores na rede uma NAT de trabalho / roteada para a qual retornar.


por 01.06.2011 / 01:08

1

Por que você não libera completamente as regras do iptables para tirar essa possibilidade do caminho? E quanto ao iptables no cliente? Lave também.

iptables --flush iptables --table nat --flush iptables --delete-chain iptables --table nat --delete-chain iptables -P FORWARD ACCEPT iptables -P INPUT ACCEPT iptables -P OUTPUT ACCEPT

Em seguida, execute um tcpdump mais limpo no servidor openvpn, enquanto executa o ping do cliente para 192.168.0.100:

tcpdump -vn -i tun0 '(host 192.168.0.100 or host 10.15.119.6)' and icmp

Execute também um segundo despejo no servidor ao mesmo tempo:

tcpdump -vn -i eth1 '(host 192.168.0.100 or host 10.15.119.6)' and icmp

Um terceiro despejo no seu cliente:

tcpdump -vn -i eth0 host 192.168.0.100 and icmp

Parece que o ping atinge 192.168.0.100, a resposta chega ao openvpn, mas não ao seu cliente. Mas tem certeza de que o cliente não está soltando a resposta? O primeiro e terceiro tcpdump irão verificar isso.


por 30.05.2011 / 19:09

0

A configuração que você está tentando realizar é uma solicitação um pouco esotérica e é abordada por um recurso do OpenVPN que não é muito conhecido.

A maioria das configurações de VPN é configurada de tal forma que o cliente que se conecta ao servidor VPN é o último link da cadeia, e não há outros computadores ou redes atrás dele que precisem estar acessíveis na VPN. Em seu cenário, existem redes por trás do servidor VPN, bem como os clientes VPN, e essas redes precisam poder se comunicar diretamente. Existem várias maneiras de fazer isso:

Opção 1: Configure o NAT de origem em cada cliente. Essa não é a opção preferida, pois adiciona sobrecarga no lado do cliente, além de exigir que cada cliente seja configurado individualmente para o NAT de origem. Manter essa configuração em um grande número de redes será um pesadelo.

Opção 2: Use o recurso iroutes fornecido pelo OpenVPN. Usando o iroutes você é capaz de especificar explicitamente as redes por trás de cada nó na rede e, assim, permitir que as várias redes se comuniquem através do roteamento interno do OpenVPN. O principal benefício do uso de iroutes sobre o NAT de origem é que não há sobrecarga do cliente e a configuração é executada apenas no servidor VPN. Tenha em mente que você ainda precisa especificar as rotas a serem empurradas no servidor VPN - a adição de iroutes deve ser realizada além disso e serve ao único propósito de definir os intervalos de rede por trás de cada nó da VPN.

Como iroutes não são um assunto trivial, aconselho ler as páginas seguintes. Se você tiver problemas específicos com a instalação de iroutes, faça essas perguntas aqui.

link link


por 25.05.2011 / 22:57

0

Eu fiz o que você está pedindo, eu fiz algumas coisas diferentes. Por um lado, eu usei um dispositivo de toque.

Veja abaixo:

server.conf

port 1194 proto udp dev tap0 ca /etc/openvpn/keys/ca.crt cert /etc/openvpn/keys/server.crt key /etc/openvpn/keys/server.key # This file should be kept secret dh /etc/openvpn/keys/dh1024.pem ifconfig-pool-persist ipp.txt server-bridge 192.168.220.1 255.255.255.0 192.168.220.90 192.168.220.100 # GATEWAY - NETMASK - START DHCP - END DHCP push "route 192.168.220.0 255.255.255.0" client-to-client keepalive 10 120 comp-lzo max-clients 20 persist-key persist-tun status openvpn-status.log verb 3

client.conf

remote xxx.xxx.xxx.xxx 1194 udp pull tls-client persist-key ca ca.crt nobind persist-tun cert cert.crt comp-lzo dev tap key key.key resolv-retry infinite


por 28.05.2011 / 00:58

0

Tente remover o "up ./office.up" do seu arquivo de configuração do servidor e reiniciar o OpenVPN. Não é necessário (o daemon openvpn criará as rotas para a rede definidas pela diretiva "server") e algumas falhas podem impedir que os pacotes dos seus clientes sejam roteados corretamente.


por 31.05.2011 / 17:35

Tags networking openvpn routing tun

Como combinar dois domínios do Active Directory [closed] Aumenta o ulimit do arquivo para o daemon do asterisco

score 2 · Accepted Answer

Eu passei pelas respostas e acho que sou perspicaz para onde você está com tudo isso.

Vamos fazer algumas verificações simples para restringir o problema:

De um dos clientes OpenVPN que não é capaz de executar ping em um host 192.168.0.x: %código% Também nos forneça netstatn -rn para * nix ou ifconfig -a %código% ipconfig /all

Do servidor openvpn: %código% %código% %código% ping <openvpn server external 10.21.x address>

Além disso, sua configuração atual do servidor e do cliente openvpn provavelmente estará em ping <openvpn 10.15.x address e na máquina cliente netstatn -rn ou ping <a 192.168.0.x host>

Eu tenho uma configuração semelhante. No meu servidor OpenVPN eu tenho o equiv desta regra iptables (alterado hostmask / interface para o que seus valores devem ser):

# Generated by iptables-save v1.4.4 
*nat
:PREROUTING ACCEPT [5:332]
:POSTROUTING ACCEPT [5:740]
:OUTPUT ACCEPT [5:740]
-A POSTROUTING -s 10.15.119.0/2 -o eth1 -j MASQUERADE
COMMIT

Parece que seu problema é definitivamente porque você está com falta de iptable_nat.

# lsmod | grep nat
iptable_nat             5011  1 
nf_nat                 19101  2 ipt_MASQUERADE,iptable_nat
nf_conntrack_ipv4      12548  3 iptable_nat,nf_nat
nf_conntrack           72270  4 ipt_MASQUERADE,iptable_nat,nf_nat,nf_conntrack_ipv4
ip_tables              17942  2 iptable_nat,iptable_filter
x_tables               21613  3 ipt_MASQUERADE,iptable_nat,ip_tables

ping <a 10.15.x host> ou tente com o parâmetro ping <a 10.21.x host> .