OpenVPN routing

 ( InfinityP | 2015. november 1., vasárnap - 19:08 )

Sziasztok!

A következőt szeretném megvalósítani: Adott egy OpenVPN szerver (Debian), illetve pár kliens (Ubuntu, Debian). A szerver beállítás "kész", a két kliens tud csatlakozni minden gond nélkül. Viszont szeretném, hogyha a kliensek csatlakozva vannak, akkor a VPN szerveren keresztül menjen minden forgalmuk. Na ezzel van a problémám.

Ha jól tudom, az utóbbihoz szükségem van a következő opcióra a kliens konfigurációjába:
redirect-gateway def1

Viszont ezzel csak azt sikerült eddig elérnem, hogy a kliensnek nem lesz internetkapcsolata.

A szerveren a sysctl -p kimenete:
net.ipv4.ip_forward = 1

A szerver konfigurációja:
script-security 3 system
port 1194
proto udp
dev tun

ca /etc/openvpn/certs/ca.crt
cert /etc/openvpn/certs/szerver_neve.crt
key /etc/openvpn/certs/szerver_neve.key
dh /etc/openvpn/certs/dh4096.pem
tls-auth /etc/openvpn/certs/ta.key 0

server 172.16.1.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "redirect-gateway def1"
push "dhcp-option DNS 208.67.222.222"
push "dhcp-option DNS 208.67.220.220"

keepalive 1800 4000

cipher DES-EDE3-CBC
comp-lzo

max-clients 3

user nobody
group nogroup

persist-key
persist-tun

verb 5
mute 20

A kliens konfigurációja:
script-security 3 system
client

remote xxx.xxx.xxx.xxx

ca /etc/openvpn/certs/ca.crt
cert /etc/openvpn/certs/kliens_neve.crt
key /etc/openvpn/certs/kliens_neve.key

cipher DES-EDE3-CBC
comp-lzo yes

dev tun
proto udp

redirect-gateway def1
nobind
resolv-retry infinite
route-method exe
route-delay 2

tls-auth /etc/openvpn/certs/ta.key 1

nobind
auth-nocache

persist-key

persist-tun
user nobody
group nogroup

Ami még számomra érdekes, hogy a kliensről tudom pingelni a szervert, illetve fordítva, valamint a kliensen ha egy hosztnevet próbálok pingelni, akkor a névfeloldást elvégzi, viszont válasz nem érkezik.

Amikor a kliensről akarok pingelni, akkor az a szerver kimenő interfészén így néz ki (ping hup.hu):
33 0.232346 172.16.1.6 195.228.252.138 ICMP 100 Echo (ping) request id=0x3a19, seq=13/3328, ttl=63 (no response found!)
157 1.240732 172.16.1.6 195.228.252.138 ICMP 100 Echo (ping) request id=0x3a19, seq=14/3584, ttl=63 (no response found!)
225 2.248724 172.16.1.6 195.228.252.138 ICMP 100 Echo (ping) request id=0x3a19, seq=15/3840, ttl=63 (no response found!)
241 3.256973 172.16.1.6 195.228.252.138 ICMP 100 Echo (ping) request id=0x3a19, seq=16/4096, ttl=63 (no response found!)
284 4.279942 172.16.1.6 195.228.252.138 ICMP 100 Echo (ping) request id=0x3a19, seq=17/4352, ttl=63 (no response found!)
403 5.272929 172.16.1.6 195.228.252.138 ICMP 100 Echo (ping) request id=0x3a19, seq=18/4608, ttl=63 (no response found!)
518 6.281360 172.16.1.6 195.228.252.138 ICMP 100 Echo (ping) request id=0x3a19, seq=19/4864, ttl=63 (no response found!)
636 7.384644 172.16.1.6 195.228.252.138 ICMP 100 Echo (ping) request id=0x3a19, seq=20/5120, ttl=63 (no response found!)
1086 11.500621 172.16.1.6 195.228.252.138 ICMP 100 Echo (ping) request id=0x3a19, seq=24/6144, ttl=63 (no response found!)
1216 17.369465 172.16.1.6 195.228.252.138 ICMP 100 Echo (ping) request id=0x3a19, seq=30/7680, ttl=63 (no response found!)

Segítségeteket előre is köszönöm!

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Natolast allitottal be, tuzfalban engedve van ez a forgalom?

Ha jól tudom, akkor ennek a tűzfal szabálynak elégnek kellene lenni hozzá:
iptables -t nat -A POSTROUTING -s 172.16.1.0/24 -o venet0:0 -j MASQUERADE

Miután így sem működött, próbálkoztam még pár dologgal, eredménytelenül:
iptables -A INPUT -p udp --dport 1194 -j ACCEPT
iptables -A INPUT -i tun0 -j ACCEPT
iptables -A FORWARD -i tun0 -j ACCEPT
iptables -A OUTPUT -m state --state NEW -o venet0:0 -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -m state --state NEW -o venet0:0 -j ACCEPT
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

Szia!

A venet0:0 miatt gyanús hogy openvz konténerben futtatnád.
Ehhez viszont a kiszolgálón is szükséges beállításokat elvégezni, ha esetleg még nem lenne engedélyezve:
https://openvpn.net/index.php/access-server/docs/admin-guides/186-how-to-run-access-server-on-a-vps-container.html

A nathoz szükséges modulokat is engedélyezni kell a konténerhez:
http://linuxworldweb.blogspot.hu/2012/04/enable-iptable-nat-support-on-openvz.html

Szia!

Igen, valóban OpenVZ konténerben fut. Sajnos a hoszt géphez nincs hozzáférésem, viszont a szolgáltató elvégezte, amit írtál, illetve a TUN/TAP engedélyezését biztos, mert enélkül gondolom nem is tudná az OpenVPN létrehozni a tun0 interfészt, illetve a kliensek sem tudnának hozzá csatlakozni.
Hogy a nathoz szükséges modulokat engedélyezte-e a szolgáltató arról fogalmam sincs, csak annyit tudok erre mondani, hogy -látszólag- minden iptables szabályt megeszik a konténerben lévő gép.

vigyázz, mert openvz konténerben kiadott iptables parancsokra a host node-on keletkeznek a hiba log-ok.

~~~~~~~~
deb http://deb.uucp.hu/ wheezy yazzy repack

Köszi, ezt eddig nem tudtam. :(

Jelenleg ott tartok, hogy a tcpdump szerint elküldött csomagokra sem érkezik válasz, vagy a címzett a 172.16.1.0/24-ből érkező címeket látja, s ezért nem kapom meg.