[SOLVED] Openvpn, routing i maskarada...

[sulti]

Cześć,

mam problem z pełnym uruchomieniem VPN'a... Tunele zestawiają się bezbłędnie, podejrzewam jednak jakiś problem z routingiem/maskaradą.
Sytuacja przedstawia się następująco:

Kod: Zaznacz cały

       internet
          |
          |
         gw   (1.2.3.1)  
          |
          |
       /eth0\ (1.2.3.4)
---------------------
|        PC1        |
---------------------
       \tun0/ (10.10.0.1)
         |
         |
         |
       /tun0\ (10.10.0.6)
---------------------
|        PC2        |
---------------------

Na PC1 uruchomiony jest openvpn w trybie serwer, na PC2 w trybie klient. Adresy przydzielają się poprawnie, interfejsy tun0 na obu serwerach podniesione.
Konfiguracja sieci po stronie serwera PC1 wygląda obecnie tak:

Kod: Zaznacz cały

echo "1" > /proc/sys/net/ipv4/ip_forward

iptables -A INPUT -i tun0 -j ACCEPT
iptables -A FORWARD -i tun0 -j ACCEPT
iptables -t nat -A POSTROUTING -s 10.10.0.0/24 -o eth0 -j MASQUERADE

No i teraz najciekawsze - bo problem
Puszczam pinga na adres 1.2.3.4, dochodzi, tcpdump wszystko ładnie pokazuje.
Puszczam pinga na adres 1.2.3.1 i już jest gorzej. Na interfejsie eth0 PC1 widać, że ping przychodzi z tun0, wychodzi na zewnątrz, wraca odpowiedź, ale jej już nie widać na interfejsie tun0, tylko na eth0.
Identycznie jest z każdym innym pingiem (tzn. każdym innym adresem, np. 8.8.8..

Mam wrażenie, że czegoś mi brakuje przy konfiguracji maskarady. Ma ktoś jakiś pomysł?

Pozdro.
edit:
1.2.3.4 i 1.2.3.1 są normalnymi adresami zewnętrznymi.

edit2:
To może na początek jeszcze inna zagadka. Problem podobny, z tym, że trochę inny
Prosty vpn między dwoma kompami. Kompy są w sieci 10.1.0.0/16. VPN korzysta
z adresów 192.168.1.0/24. Tunel się zestawia, jednak nie można zapingować interfejsu
"zewnętrznego" serwera przez VPN z klienta. Co najlepsze, pingi te widać na interfejsie klienta
tun0 po odpaleniu tcpdump, nie widzi ich jednak polecenie ping.

routing na kliencie wygląda tak:

Kod: Zaznacz cały

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.1.1     192.168.1.5     255.255.255.255 UGH   0      0        0 tun0
192.168.1.5     0.0.0.0         255.255.255.255 UH    0      0        0 tun0
0.0.0.0         10.1.0.254      0.0.0.0         UG    0      0        0 eth0

po stronie serwera działania na iptables:

Kod: Zaznacz cały

#!/bin/bash

# wlaczenie w kernelu forwardowania 
echo 1 > /proc/sys/net/ipv4/ip_forward

# czyszczenie starych regul
iptables -F
iptables -X
iptables -t nat -X
iptables -t nat -F
iptables -t mangle -F
iptables -t mangle -X

# ustawienie domyslnej polityki
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT

# utrzymanie polaczen nawiazanych
iptables -A INPUT -j ACCEPT -m state --state ESTABLISHED,RELATED
iptables -A FORWARD -j ACCEPT -m state --state ESTABLISHED,RELATED
iptables -A OUTPUT -j ACCEPT -m state --state ESTABLISHED,RELATED

# udostepniaie internetu w sieci lokalnej
iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -j MASQUERADE
iptables -A FORWARD -s 192.168.1.0/24 -j ACCEPT

vpn - server.conf:

Kod: Zaznacz cały

port 1194
local 10.1.1.185
proto tcp
dev tun0
key /etc/openvpn/keys/server.key
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/server.crt
dh /etc/openvpn/keys/dh1024.pem
cipher AES-128-CBC
server 192.168.1.0 255.255.255.0
keepalive 10 120
comp-lzo
user nobody
group nogroup
persist-key
persist-tun
daemon
log-append /var/log/openvpn.log
verb 4

vpn - client.conf:

Kod: Zaznacz cały

client
proto tcp
dev tun
remote 10.1.1.185
persist-key
persist-tun
ca /etc/openvpn/clientkeys/ca.crt
cert /etc/openvpn/clientkeys/client.crt
key /etc/openvpn/clientkeys/client.key
cipher aes-128-cbc
comp-lzo
verb 3
mute 20

i z kompa klienta wygląda to tak:

Kod: Zaznacz cały

# ping -I tun0 192.168.1.1
PING 192.168.1.1 (192.168.1.1) from 192.168.1.6 tun0: 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=0.681 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=0.826 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=1.76 ms

Kod: Zaznacz cały

# ping -I tun0 10.1.1.185
PING 10.1.1.185 (10.1.1.185) from 192.168.1.6 tun0: 56(84) bytes of data.
^C
--- 10.1.1.185 ping statistics ---
12 packets transmitted, 0 received, 100% packet loss, time 11088ms

patrząc równocześnie na:

Kod: Zaznacz cały

# tcpdump -n -i tun0 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 96 bytes
09:56:42.716012 IP 192.168.1.6 > 10.1.1.185: ICMP echo request, id 19542, seq 7, length 64
09:56:42.717003 IP 10.1.1.185 > 192.168.1.6: ICMP echo reply, id 19542, seq 7, length 64
09:56:43.724010 IP 192.168.1.6 > 10.1.1.185: ICMP echo request, id 19542, seq 8, length 64
09:56:43.724716 IP 10.1.1.185 > 192.168.1.6: ICMP echo reply, id 19542, seq 8, length 64
09:56:44.732008 IP 192.168.1.6 > 10.1.1.185: ICMP echo request, id 19542, seq 9, length 64
09:56:44.732642 IP 10.1.1.185 > 192.168.1.6: ICMP echo reply, id 19542, seq 9, length 64
09:56:45.740208 IP 192.168.1.6 > 10.1.1.185: ICMP echo request, id 19542, seq 10, length 64
09:56:45.740882 IP 10.1.1.185 > 192.168.1.6: ICMP echo reply, id 19542, seq 10, length 64

coś tu nie gra...

Any ideas?

[saiqard]

upewnij się, czy to nie wina firewall'a otwierając go całkowicie:
iptables -A INPUT -j ACCEPT
iptables -A FORWARD -j ACCEPT
iptables -A OUTPUT -j ACCEPT

[sulti]

Właśnie przed momentem udało mi się uruchomić to dziadostwo
Jedyną zmianą jaką zrobiłem było przestawienie routingu na kliencie:
Stała trasa na adres serwera VPN przez interfejs eth0, i default gateway na tun0. O dziwo ruszyło

[saiqard]

a wcześniej też była default gateway na tun0 ustawiona?

[sulti]

Nie... Ale samo ustawienie sztywnej trasy do konkretnego zewn. adresu IP przez tun0 też nie chciało działać, dlatego szukałem przyczyn gdzie indziej...

[saiqard]

A ustawiałeś ją na tun0 (10.10.0.1)?

[sulti]

Tak, oczywiście
Pojawiły się jednak znów problemy z pierwszym pytaniem, bardzo koślawo to działało. Udało mi się znaleźć jednak rozwiązanie problemu na zagramanicznym forum:
"

OK, I finally found the issue after tens of hours and much hair pulling - the OpenVPN server simply needed rebooting! Pretty unusual for a Linux box to behave like Windows!

"
Nie chciałem za bardzo wierzyć, ale spróbowałem i zadziałało Zwykły init 6...

[COVERek]

Witam, mam podobny problem bo nie moge spingowac serwer VPN od strony klienta, ale moge dac ping odwrotnie, czyli z serwera do klienata. Raz mi sie udalo osiagnac zamierzony cel, ale nie wiem jak i teraz nie dziala... tcpdump widzi ze pakiety dochodza... Zrobilem to co bylo opisane powyzej, ale nic nie hula.

Kod: Zaznacz cały

coverek@box:~$ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.0.2.5        *               255.255.255.255 UH    0      0        0 tun0
10.0.2.1        10.0.2.5        255.255.255.255 UGH   0      0        0 tun0
adres.vpn.pl  3g              255.255.255.255 UGH   0      0        0 wlan0
10.0.0.0        10.0.2.5        255.255.255.0   UG    0      0        0 tun0
192.168.2.0     *               255.255.255.0   U     2      0        0 wlan0
link-local      *               255.255.0.0     U     1000   0        0 wlan0
default         3g              0.0.0.0         UG    0      0        0 wlan0

Gdzie 3g to router, który daje internet.
Interfejs tun0 wyglada nastepujaco:

Kod: Zaznacz cały

coverek@box:~$ ifconfig tun0
tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:10.0.2.6  P-t-P:10.0.2.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)