site to site openvpn probléma [Megoldódott]

Hálózatok általános

Küzdök egy ideje a következővel:

"A" háló: 192.168.1.0/24 Ovpn szerver a gw-n fut: 192.168.1.1 tun0: 10.9.0.1
"B" háló: 192.168.4.0/24 Ovpn kliens a gw-n fut: 192.168.4.1 tun0: 10.9.0.6
"C" háló: 192.168.2.0/24 Ovpn kliens a (T nat mögötti) gw-n fut: 192.168.2.254 tun0: 10.9.0.2

Tunnel él és virul, route-ok rendben, a két ovpn gép között minden megy.
A hálózatok többi gépéről nem lehet elérni a másik hálózat gépeit.
Eddig route problámának látszik, de: az ovpn gépekről mindkét oldalon el lehet érni a
távoli hálózat összes gépét. Jó, akkor biztosan tűzfal, de: mindkét hálózat összes gépéről
elérhető a vpn-tunnel másik oldali lába. Pl. a "B" hálózat gépeiről pingelhető a 10.9.0.1.

A környezet: Minden oldalon Proxmox 3.6-on vm-ben futo ClearOs 6.4 az átjáró, amin az
ovpn fut (openvpn-app eltávolítva, csak openvpn csomagon játszok).

Azért gondolom, hogy nem lenne lehetetlen, mert az "A" és "C" hálózat között ui. környezetben viszont
működik. Internetkapcsolatok: "A" és "B" Digi-s pppoe, "C" (ami működik) natolt T-home.

Ha valakinek tippje van merre keressem a hibát, ne kíméljen!

Köszi!

  • 2204 megtekintés

( kallo | 2015. 11. 07., szo – 16:54 )

1. Tisztázni kéne mit szeretnél. Melyik hálóból melyik hálót akarod elérni?
2. A kérdés megválaszolására szükség lehet még az ovpn server és kliens konfigra is.
3. Én úgy szoktam hogy pingetek egyik hálóból a másikba és tcpdump-al nézem az interfészeket, hogy a csomagok merre tartanak.

--------------------
http://grant-it.com/

"A" hálózatból kellene "B"-t is elérni, ugyanúgy mint "C"-t. "B" és "C" között nem kell
elérés.

Szerver:

port 9900
proto udp
dev tun
topology subnet
mode server
ca /etc/openvpn/easy-rsa/keys/ca.crt
# server.crt
cert /etc/openvpn/easy-rsa/keys/server.crt
key /etc/openvpn/easy-rsa/keys/server.key
dh /etc/openvpn/easy-rsa/dhparam.pem
server 10.9.0.0 255.255.255.0
push "route 192.168.1.0 255.255.255.0"
route-noexec
route-up /etc/openvpn/route-add.sh
ifconfig-pool-persist ipp.txt
client-config-dir ccd
keepalive 10 120
tls-auth ta.key 0
tun-mtu 1500
tun-mtu-extra 32
mssfix 1200
duplicate-cn
comp-lzo
max-clients 100
persist-key
persist-tun
status openvpn-status.log
log /var/log/openvpn.log
log-append /var/log/openvpn.log
verb 5

"B" Kliens:

client
dev tun
proto udp
remote public.tld 9900
resolv-retry infinite
nobind
tun-mtu 1500
tun-mtu-extra 32
mssfix 1200
persist-key
persist-tun
ca "/etc/openvpn/client/ca.crt"
cert "/etc/openvpn/client/kl1.crt"
key "/etc/openvpn/client/kl1.key"
tls-auth "/etc/openvpn/client/ta.key" 1
comp-lzo
route-noexec
route-up /etc/openvpn/route-add.sh
verb 5

NAT tekintetében elég, ha a fogadónak van publikus IP-je, a kliensek jöhetnek NAT mögül is. Ha a kapcsolat felépül, akkor utána a kapcsolat már két irányú, tehát nem érdekes, hogy a kliens egyébként NAT mögött van.

A szerver konfigurációnak tartalmaznia kell
push "route $NETWORK $NETMASK"
sorokat is. Annyit, amennyi az OpenVPN-en kapcsolaton keresztül látható - tehát ha három telephely van, akkor három ilyen sor kell, sőt, ha egy telephelyen több subnet is lenne, akkor még több kellene. A lényeg: minden OpenVPN-en át látható subnet legyen felvéve a konfigba! Nálad egyetlen ilyen sor van, tehát legalább két telephely hálózatáról nem tud az OpenVPN, ez pedig baj, mert így a klienseken nem fog beállni az extra route, hogy az adott subnet az OpenVPN interface-n át érhető el.

További hiányosság, hogy az OpenVPN nincs informálva arról, hogy melyik subnet melyik kliense mögött érhető el, azaz ha jön egy csomag a VPN-ben és ez elér a fogadóhoz és menne mondjuk pl. a 192.168.2.0 subnetbe, akkor a fogadónak honnan kellene azt tudnia, hogy ez a "C" telephelyen van? Nos onnan, hogy a szerver oldali konfigot kliens specifikusra kell megcsinálni - lásd ccd paraméter -, itt a kliens tanúsítványával egyező nevű konfig file-ba pedig be kell vésni a megfelelő iroute sort, a C telephely esetén ez
iroute 192.168.2.0 255.255.255.0
lenne. Ez mondaná meg a szerver oldalnak, hogy a 192.168.2.0 subnetbe menő csomagokat a "C" klienshez kell továbbítani, mert ez a subnet ott van.

Próbáld meg így valahogy:

Szerver:
port 9900
proto udp
dev tun
topology subnet
mode server
ca /etc/openvpn/easy-rsa/keys/ca.crt
# server.crt
cert /etc/openvpn/easy-rsa/keys/server.crt
key /etc/openvpn/easy-rsa/keys/server.key
dh /etc/openvpn/easy-rsa/dhparam.pem
server 10.9.0.0 255.255.255.0
push "route 192.168.1.0 255.255.255.0"
ifconfig-pool-persist ipp.txt
client-config-dir ccd
route 192.168.2.0 255.255.255.0
route 192.168.4.0 255.255.255.0
keepalive 10 120
tls-auth ta.key 0
tun-mtu 1500
tun-mtu-extra 32
mssfix 1200
duplicate-cn
comp-lzo
max-clients 100
persist-key
persist-tun
status openvpn-status.log
log /var/log/openvpn.log
log-append /var/log/openvpn.log
verb 5

"B" Kliens:

client
dev tun
proto udp
remote public.tld 9900
resolv-retry infinite
nobind
tun-mtu 1500
tun-mtu-extra 32
mssfix 1200
persist-key
persist-tun
ca "/etc/openvpn/client/ca.crt"
cert "/etc/openvpn/client/kl1.crt"
key "/etc/openvpn/client/kl1.key"
tls-auth "/etc/openvpn/client/ta.key" 1
comp-lzo
verb 5

/etc/openvpn/ccd/ mappába két fájl:
- B-hez: /etc/openvpn/ccd/kl1
ifconfig-push 10.9.0.6 255.255.255.0
iroute 192.168.4.0 255.255.255.0
- C-hez: a fájl neve legyen a C kliens cert neve.
ifconfig-push 10.9.0.2 255.255.255.0
iroute 192.168.2.0 255.255.255.0

--------------------
http://grant-it.com/

Köszi, átnézem de:

tegnap áramszünet miatt újraindult a "B", Proxmox 3.4 alatt nyűgös az r8168-al működő kártya, ezért
4.0-as Proxmox-ra frissítettem a ClearOs alatt. Most tökéletes. Hogy az újraindítás elég lett volna-e,
vagy változott a 4.0 Proxmox hálózatkezelése/tűzfala, nem tudom.

Mindenkinek köszönöm a segítségét!

( bognarattila | 2015. 11. 08., v – 20:59 )

bocs, most nincs se cérnám, se időm végig bogarászni a konfigot, de nem lehet, hogy az iroute hiányzik? (ha több kliens lehetséges - azaz nem peer-to-peer -, akkor az OpenVPN szerver nem tudja, hogy adott hálózat melyik kliens felé van; a kernel route tábláját nem használja ilyen célból).

( kallaics | 2015. 11. 08., v – 21:35 )

Ahol csak lehet én site-to-site VPN-t építenék. A Te konfigod nem site-to-site, hanem szerver-kliens alapú konfig.
T-s netnél tudod kérni, hogy publikus címet kapj és ne NAT mögött legyél.

a, A routokat mindenhol fel kell venni, értsd minden oldalon, hogy odataláljon a csomag és vissza is! Nálam úgy volt, hogy minden oldal a saját routejait kezelte így nem volt gondom soha. Arra ügyelj, egyszerre egy háló csak egy irányba legyen routeolva.

b, Tűzfal nem lehet a ludas?