Cu ajutorul colegului Serafin Rusu care mi-a dat o idee am gasit o solutie. Nu prea am rezolvat, mai degraba am ocolit problema pentru care nu gasesc in continuare explicatie. Rezolvarea a fost sa inversez rolurile capetelor de tunel (client-server). Astfel, specificand in ccd-ul aferent clientului prin iroute ca exista o clasa 172.24.100.0/24 in "spatele" GW-ului, a reusit si openvpn-ul sa inteleaga ce vreau si sa ruteze pachetele.
Probabil ca "iroute" pe client e mult mai important pentru creierul openvpn-ului decat "push route" pe server (bug sau feature). -- Catalin Bucur On 25/09/2017 17:05, Catalin Bucur wrote: > Salutare, > > > Intr-un mediu virtual de test am 5 VM-uri cu CentOS: > P1, P2, P3 - provideri de net > GW - configurat cu 3 tabele de rutare iproute2 > HOST - in "spatele" GW-ului, incerc sa-l rutez prin P3 > am configurat un policy based routing relativ basic. Sa zicem ca am 2 > provideri de net P1 si P2 la care am configurat fail-over si un al > treilea "provider" P3. Intre P3 si GW e configurat un vpn (OpenVPN) prin > care vreau sa trimit traficul de la un anumit ip, indiferent daca P1 sau > P2 sunt alive. > > Chestiunea cu fail-over intre P1 si P2 e rezolvata, durerea intervine la > rutarea traficului prin P3. Dintr-un anumit motiv pentru care nu gasesc > inca explicatie, source based routing-ul functioneaza (pachetele sunt > trimise prin vpn pe GW), dar nu ajung in celelalt capat (P3). Daca in > loc de OpenVPN folosesc un tunel IPIP problema e rezolvata. > > Incerc sa dau ceva detalii fara sa creez un cearsaf, mai pot reveni cu > suplimentari daca e cazul. > > 172.24.100.254 e HOST-ul pe care vreau sa-l rutez prin vpn > 10.13.0.2 e GW-ul pe care e configurat iproute2 > 10.13.0.1 e P3 > 10.111.0.0/24 e clasa de vpn intre GW si P3 (10.111.0.4 e pe P3) > > ========== CONFIG OpenVPN Server (GW) ========== > port 1194 > proto udp > dev tun > ca keys/ca.crt > cert keys/server.crt > key keys/server.key # This file should be kept secret > dh keys/dh2048.pem > topology subnet > server 10.111.0.0 255.255.255.0 > ifconfig-pool-persist ipp.txt > push "route 172.24.100.0 255.255.255.0" > keepalive 10 120 > tls-auth keys/ta.key 0 # This file is secret > cipher AES-256-CBC > persist-key > persist-tun > status openvpn-status.log > log-append /var/log/openvpn.log > verb 3 > ================================================== > > ========== CONFIG OpenVPN Client (P3) ========== > client > dev tun > proto udp > remote 10.13.0.2 1194 > resolv-retry infinite > nobind > persist-key > persist-tun > ca client/ca.crt > cert client/client.crt > key client/client.key > remote-cert-tls server > tls-auth client/ta.key 1 > cipher AES-256-CBC > verb 3 > ================================================== > > Legat de iproute2 eu zic ca e totul functional, asa cum vad si in rute: > > [root@IPR2-GW ~]# ip route get to 8.8.8.8 from 172.24.100.254 iif eth3 > 8.8.8.8 from 172.24.100.254 via 10.111.0.4 dev tun0 > cache iif * > > Dar nu vad niciun pachet venind dinspre GW catre interfata de vpn de pe P3. > Folosind un tunel IPIP simplu cu aceleasi ip-uri, interfete etc: > > Pe GW: > ip tunnel add tun0 mode ipip remote 10.13.0.1 local 10.13.0.2 > ip link set tun0 up > ip addr add 10.111.0.1/24 dev tun0 > > Pe P3: > ip tunnel add tun0 mode ipip remote 10.13.0.2 local 10.13.0.1 > ip link set tun0 up > ip addr add 10.111.0.4/24 dev tun0 > > totul functioneaza foarte bine, vad pachetele pe interfata de tunneling > de pe P3, mai departe pot face ce vreau cu traficul respectiv. > > > Configuratia de OpenVPN e simpla/clasica, nu-mi dau seama ce vrea de la > mine ca sa nu imi blocheze acel trafic. > Daca aveti idei va rog sa mi le impartasiti, eu m-am saturat de facut > tot felul de teste :-) > > > Mersi, > _______________________________________________ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
