Rutiranje za korisnike koji pristupaju lokalnoj mrezi preko OpenVPN-a

Imam pitanje u vezi rutiranja OpenVPN konekcije.

Lokalna mreza u maloj firmi je u opsegu 192.168.11.xyz, default gateway za pristup internetu je 192.168.11.3 (Tp-link TLER6020) Jedan od web servisa se nalazi na 10.32.x.xxx i na njega se dolazi preko 192.168.11.1 gatewaya kome nemam pristup, Cisco 1841 nakacen na Telekomov FR link pod kontrolom organizacije koja hostuje web servis na 10.32.x.xxx. Kada sam u lokalnoj mrezi pristup 10.32.x.xxx radi bez problema, dodata je ruta na default gatewayu da svi upiti ka 10.32.x.xxx idu preko 192.168.11.1 gate-a.

Problem je kod korisnika koji idu preko OpenVPN konekcije, oni dobijaju IP adrese iz opsega mreze kojoj pristupaju (192.168.11.xyz), vide sve sadrzaje u lokalu, network share, stampace, remote desktop ka lokalnim masinama radi ali ne mogu da pristupe 10.32.6.228 preko 192.168.11.1 gatewaya. To mogu samo ako se nakace na remote desktop masine u lokalnoj mrezi, direktno sa svojih racunara i OpenVPN konekcije to ne radi, ocigledno nedostaje odgovarajuca ruta?

Sta se i kako moze uraditi?

Ovde ima nekoliko bitnih pitanja na koja nisi dao odgovor a koji su neophodni da bi moglo uopste da pocne da se razmislja o odgovoru (mada vec mogu da zamislim srljanje da se sto pre da bilo kakav odgovor i cuveno “jesi proverio dns?”) :)

Prvo: nisi rekao koje su podmreze u pitanju i kako su dizajnirane
Drugo: kako se dodeljuje konfiguracija klijentima koji se lokalno povezuju i kako onima koji se povezuju preko vpn-a?
Trece: kako su definisane rute na svim interfejsima?
Cetvrto: gde se nalazi vpn koncentrator?

Izvinjavam se na rudimentarnom znanju, ali da probam da odgovorim:

1. ne znam o kojim me podmrezama pitas, postoji samo jedna lokalna mreza u 192.168.11.0/24 opsegu adresa. Pomenuta WEB app na 10.32.x.xxx je portal jedne institucije i njoj se pristupa preko iznajmljene linije, prastari Frame relay link preko Cisco rutera (192.168.11.1) koji je gateway za tu konekciju.
2. lokalni klijenti dobijaju IP adresu od DHCP servera na ruteru (192.168.11.3), koji je default gateway za tu mrezu, pomenuti Tp-Link TLER6020, VPN klijenti ih dobijaju od OpenVPN servera na Q-nap NAS uredjaju koji je u lokalnoj mrezi na adresi 192.168.11.150
3. Nisam podesavao nikakve rute, osim staticke rute za web aplikaciju na 10.32.x.xxx koja ne ide preko default gateweaya vec preko rutera/gatewaya na 192.168.11.1
4. VPN koncentrator, pretpostavljam da je to VPN server, vec pomenuti Q-nap NAS uredjaj, i nema neka podesavanja osim najosnovnijih, opseg IP adresa koj se dodeljuje klijentima, port i on/off internet gateway za klijente.


U medjuvremenu sam testirao kakvo je stanje kada se sa udaljenih klijenata povezem preko PPTP VPN konekcije koja se nalazi u okviru VPN servera na samom Tp-Link ruteru, i tu imam pristup 10.32.x.xxx ali PPTP mi nije opcija za VPN, samo sam testirao hoce li raditi. Na tom Tp-Link ruteru imam i IPsec VPN ali do sada nisam uspeo da ga podesim da radi.

Pa sasvim je logično da VPN korisnici ne mogu iz 192.168.11.xyz da pronađu 10.32.x.xxx mrežu jer kako će njihov računar "znati" da se 10.32.x.xxx mreža može naći iza 192.168.11.1 gejtveja ako računar nema odgovarajuću instrukciju da preko tog gejtveja prosledi sav saobraćaj za 10.32.x.xxx, ili ako njihov default gejtvej nema svoju posebnu routing tabelu po kojoj će pakete proslediti gde treba.

Ako na Windows računaru u CMD-u otkucaš "ROUTE PRINT" možeš videti rute koje su unete, i ako nemaš specifično postavljenu rutu za 10.32.x.xxx preko 192.168.11.1 ti paketi će jednostavno otići preko 0.0.0.0 gejtveja.

Ako recimo na toj istoj Win mašini u PowerShellu odradiš:

Add-VpnConnectionRoute -ConnectionName "OpenVPN" -DestinationPrefix 10.32.0.0/16

pri čemu je OpenVPN ime te VPN konekcije, svaki put kad se ona uspostavi biće automatski dodata ruta za 10.32.0.0/16 mrežu i svi paketi za nju biće poslati preko gejtveja koji je dodeljen toj VPN konekciji (i to permanentno).

Kod linuxa zavisi od distribucije do distribucije i od verzije do verzije, jedna od varijanti je recimo da u parametre VPN interfejsa dodaš nešto poput:

up route add -net 10.32.0.0 netmask 255.255.0.0 gw 192.168.11.1

Iz LAN-a je sasvim logično da ti sve radi i bez ovoga jer tu imaš ruter koji već ima podešeno routing pravilo za taj mrežni opseg i taj gejtvej, i iako pojedinačni računari pošalju pakete svom default gejtveju, taj default gejtvje je uglavnom baš taj ruter, a on će "znati" gde njih dalje da prosledi.

VPN korisnici imaju svaki svoj ruter, čak i kod istog provajdera može postojati više različitih modela sa različitim interfejsima za podešavanje, i tu nemaš taj luksuz kao u LAN-u, znači ili ćeš svakome pojedinačno budžiti pravila na ruteru, ili ćeš im poslati skriptu poput neke od ovih koje sam ja naveo da je pokrenu na svom računaru i da na njemu kreiraju routing tabelu.

I meni je to logicno, ali prostim route -p add 10.32.0.0 mask 255.255.0.0 192.168.11.1 nisam dobijao nista, a tako sam dodavao te rute na racunarima koji su lokalno u firmi kako bih upucivao pakete za 10.32 na 192.168.11.1

A ovo sto si poslao da se ubaci preko power shella:

Add-VpnConnectionRoute -ConnectionName "OpenVPN" -DestinationPrefix 10.32.0.0/16

ne radi, iako se moja VPN konekcija na windowsu zove bas OpenVPN, dobijam poruku:

Add-VpnConnectionRoute : The configuration cannot be applied to the local user VPN connection OpenVPN. : The system could not find the phone book entry for this connection.

> Problem je kod korisnika koji idu preko OpenVPN konekcije, oni dobijaju IP adrese iz opsega mreze kojoj pristupaju (192.168.11.xyz), vide sve sadrzaje u lokalu, network share, stampace, remote desktop ka lokalnim masinama radi ali ne mogu da pristupe 10.32.6.228 preko 192.168.11.1 gatewaya.

Naravno da ne mogu da pristupe, kada ne znaju kako da dođu do 10.32.6.0/24 mreže.

A da bi znali, potrebno je na OpenVPN serveru u config fajlu dodati sledeću stavku

push "route 10.32.6.0 255.255.255.0 192.168.11.1"

Posle toga samo restartovati OpenVPN server i restartovati OpenVPN konekciju kod klijenata i trebalo bi da radi.


Ako ne radi, probaj onda drugi gateway, pošto iz neobjašnjivih razloga ih imaš dva (edit: vidim da je to drugi ruter kome nemaš pristup).

Dakle.

push "route 10.32.6.0 255.255.255.0 192.168.11.3"


Inače Add-VpnConnectionRoute važi samo za Microsoftove VPN adaptere, dakle PPTP, L2TP/IPSec/Ike/SSTP.


Edit 2: Sad vidim da spominješ 10.32.0.0/16, jesi li siguran da treba toliko?

Ako treba, onda

push "route 10.32.0.0 255.255.0.0 192.168.11.1"

odnosno

push "route 10.32.0.0 255.255.0.0 192.168.11.3"

Potpis

... Vladimir Vučićević aka. Bachi
~~~ www.bachi.in.rs <<<<>>>> [email protected]
>>> It's nice to be important, but it's more important to be nice...

Hvala, pokusacu sa predlozenim, push "route 10.32..... " sam uneo u OpenVPN klijent konfiguracioni fajl, ali nije pomoglo, videcu kako ce biti kada to unesem u OpenVPN server konfiguraciju. Samo da ga nadjem na Q-napu, pretpostavljam da ce morati kroz ssh pristup, jer drugacije, preko GUI-a, nemam pristup nikakvoj dodatnoj konfiguraciji OpenVPN servera osim IP opsega i porta.


Ne radi, i dalje je problem sto racunar povezan preko OpenVPN-a ne zna kako da saobracaj ka 10.32.6.228 rutira preko OpenVPN konekcije

C:\Users\Miki>ping 192.168.11.1

Pinging 192.168.11.1 with 32 bytes of data:
Reply from 192.168.11.1: bytes=32 time=13ms TTL=64
Reply from 192.168.11.1: bytes=32 time=12ms TTL=64
Reply from 192.168.11.1: bytes=32 time=9ms TTL=64
Reply from 192.168.11.1: bytes=32 time=13ms TTL=64

Ping statistics for 192.168.11.1:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 9ms, Maximum = 13ms, Average = 11ms

C:\Users\Miki>ping 10.32.6.228

Pinging 10.32.6.228 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 10.32.6.228:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

C:\Users\Miki>tracert 10.32.6.228

Tracing route to 10.32.6.228 over a maximum of 30 hops

1 <1 ms <1 ms <1 ms 192.168.15.254
2 6 ms 7 ms 5 ms 10.4.128.1
3 * * * Request timed out.
4 ^C


Prvi hop, 192.168.15.254 je default gateway udaljenog racunara sa IP adresom 192.168.15.1 povezanog na OpenVPN a kome je dodeljena IP adresa iz opsega firme, 192.168.11.6

Kako da podesim da upit ka 10.32.6.228 ide preko VPN a ne preko lokalne LAN konekcije?

push route, kao što sam napisao, se podešava na serverskoj strani.

Prednost OpenVPN protokola jeste taj što server baca klijentima konfiguraciju, samim tim i rute.

Ako nemaš pristup serveru, onda kod klijenta stavljaš bez push i navodnika

Dakle route 10.32.6.0 255.255.255.0 192.168.11.3.

Onda restartuješ konekciju.

Svakako posle kroz cmd u windowsu kucaš route print i vidi da li je instalirana ruta.

Ako i to ne pomaže, mora na QNAP-u uključi ip forwarding da bi mogao da rutira pakete, jer je možda neko isključio, mada bi trebalo da je po defaultu uključen.

E da, pristupi 192.168.11.3 ruteru i vidi da li postoji statička ruta u kojoj se govori da je za 10.32.x.y subnet zadužen 192.168.11.1 ruter? Za tu putanju je gejtvej u stvari IP adresa od QNAP servera...


I još nešto. Koju IP adresu dobija OpenVPN klijent, iz kog opsega?

Pretpostavljam iz 192.168.15.x opsega.

I to je lepo.

Ali kako ruteri 192.168.11.3 i 192.168.11.1 znaju kako da dođu do tog opsega?

A i brate, mnogo si zakomplikovao. Zašto ne olakšaš sebi i na tom TP-Link ruteru podigneš L2TP server - https://www.tp-link.com/us/support/faq/2158/

I posle koristiš nativni windows VPN klijent i tako uspostavljaš vezu? https://www.tp-link.com/us/support/faq/1629/

Naravno, tada bi koristio Add-VpnConnectionRoute na klijentima da im dodaš statičku rutu ka 10.32.6.x opsegu.

Potpis

... Vladimir Vučićević aka. Bachi
~~~ www.bachi.in.rs <<<<>>>> [email protected]
>>> It's nice to be important, but it's more important to be nice...

Server config
Push route je podeseno na serverskoj strani, ostaje samo nepoznanica dali je potrebno restartovati OpenVPN serivs ili ceo Q-nap nas, njega nisam restartovao, mogu tek veceras.
Tu je problem sto ping 10.32.6.228 ne prolazi, a na tracert 10.32.6.228 dobijam da je prvi hop 192.168.11.1 a drugi 192.168.11.3, a trebalo bi obrnuto. I naravno da tako ne radi.

Client config
Dodavao na klijentu route 10.32.6.0 255.255.255.0 192.168.11.3 i sad ne moze uopste da se uspostavi VPN konekcija, poruka:
Warning: route gateway is not reachable on any active network adapters: 192.168.11.3
Ako dodam route 10.32.6.0 255.255.255.0 192.168.11.1 nista se ne menja, VPN konekcija radi ali paketi ka 10.32... ne idu

windows config
Dodao rutu i na windowsu, ne pomaze, na 10.32... pokusava LAN konekcije



Na 192.168.11.3 ruteru postoji staticka ruta za 10.32.6.0 > gateway 192.168.11.1


OpenVPN klijenti dobijaju adrese iz opsega 192.168.11.0, udaljena masina sa koje testiram je u lan opsegu 192.168.15.0


Pomenuo sam da sam na kratko podigao PPTP server na Tp-Linku i da to radi tako, a da sam sa IpSec/L2TP imao problema da to uopste proradi. Zato mi je OpenVPN bio resenje.
Pokusacu jos jednom sa VPN serverom na Tp-Linku, to mi je jedino resenje koje ce najverovatnije dati rezultate.

Resio preko L2TP VPN konekcije, pitanje je samo koliko je manje pouzdan VPN protokol, u odnosu na OpenVPN?

Ako je L2TP, onda to nije kriptovano, a ako je L2TP/IPsec, onda je poprilično sigurno ako koristiš jak preshared key.

Potpis

... Vladimir Vučićević aka. Bachi
~~~ www.bachi.in.rs <<<<>>>> [email protected]
>>> It's nice to be important, but it's more important to be nice...

Da, da, L2TP/IPsec, definisan je preshared key.

Hvala na pomoci!

I performanse su bitne. Probaj da predjes na wireguard ako mozes. Mnogo jednostavnije za konfigurisanje a performanse neuporedivo bolje.

Za ruter stoji IPsec VPN Throughput (3DES) 99Mbps.

Kako niko živi ne koristi više 3DES, već AES, pretpostavljam da će moći da izvuče 30 - 50Mb/s. Za tu web aplikaciju sasvim dovoljno.

@mwolf kako si podesio klijentski vpn u Windowsu?

Disabluj ipv6 u tom virtualnom L2TP adapteru, a ako ti je pod ipv4 ostalo štiklirano use default gateway on remote network, imaj u vidu da tako *sav* saobraćaj od klijenta (pa tako i onaj koji nije namenjen pristupu LAN mreži, dakle i saobraćaj ka Internetu) ide preko VPN konekcije, što će ti ubiti bandwith u tvojoj firmi i zagušiti ruter koji nije šampion što se performansi tiče.

Verovatno želiš da samo saobraćaj namenjen od/ka tvojoj firmi ide preko VPN konekcije, a sav ostali saobraćaj preko ISPa od korisnika koji se kači na VPN.

To se postiže tako što deštikliraš use default gateway on remote network, a onda Add-VpnConnectionRoute dodaš rute ka 192.168.11.0 subnetu (osim ako VPN klijent već dobija IP adresu iz tog subneta, onda ne treba) i ka 10.32.6.0 subnetu.

Potpis

... Vladimir Vučićević aka. Bachi
~~~ www.bachi.in.rs <<<<>>>> [email protected]
>>> It's nice to be important, but it's more important to be nice...

Korektno radi, oko 100mbps, ali je 3DES, takvu IPsec polisu pali automatski kada se kreira L2TP VPN server. Postoji mogućnost kreiranja novih IPsec polisa ali to trenutno prevazilazi moje "poznavanje" ove tematike.

L2TP konekciju sam podesio tako da se koristi L2TP/IPsec with pre shared key, key je generisan sa nasumičnim alfanumeričkim karakterima, isključen je IPv6 i default gateway on remote network, kako ne bi rutirao sav saobraćaj preko VPN-a.
Takođe nisam uradio Add-VpnConnectionRoute... zato što VPN klijenti dobijaju adrese iz istog opsega kao i lokalni korisnici u firmi, a dodao sam klasicnu persistent rutu sa route -p add 10.32.6.0 prema 192.168.11.1 gatewayu.

Dobro, 3DES nije baš najsrećnije rešenje sa sigurnosnog aspekta, ali je svakako sigurnije od PPTP protokola i dovoljno siguran za tvoje potrebe.

Prednost Add-VpnConnectionRoute komande u odnosu na route -p add komande jeste ta što se sa Add-VpnConnectionRoute ruta kreira automatski samo dok je konekcija aktivna i briše kada konekcija nije aktivna, a u drugom slučaju stoji u sistemu i kad konekcija nije aktivna, ali dobro, to i nije toliko bitno.

Potpis

... Vladimir Vučićević aka. Bachi
~~~ www.bachi.in.rs <<<<>>>> [email protected]
>>> It's nice to be important, but it's more important to be nice...