VPN megoldást keresek KKV-hoz

KKV környezetbe keresnék egy olyan megoldást ami tudna VPN kapcsolatot biztosítani.
Az alábbi követelmények körvonalazódnak:
- L2TP lenne kézenfekvő, mert a legtöbb használandó eszközünkben ez OOTB megy, a lehetőségek limitáltak L2TP, PPTP, openVPN-re
- Konfigurálható legyen a VPN-en lógó eszközök IP címe (tudjak user alapján fix IP-t osztani)
- Egy külső hálózatból tudjon több gép is csatlakozni egyszerre
- Vannak iOS, OSX, Android, desktop, embedded Linux, Win7-10 kliensek, illetve egy QNAP NAS mint kliens. Minél több platformon megy ootb annál jobb.

Amit próbáltam:
- QNAP NAS: nem lehet a kliensek IP-jét bekonfigurálni
- Ubiquity Edgerouter: L2TP esetén külső hálózatból egy kliens csatlakozhat: https://community.ubnt.com/t5/EdgeRouter/L2TP-VPN-Multiple-connections-… openVPN nyűgös több eszköznél.

Amit nem próbáltam, de olvastam, hogy az Ubiquityvel egy cipőben jár az a Mikrotik, bár a ROSv7 már talán tudja.

Bármilyen tapasztalatot, tanácsot szívesen fogadok!

Hozzászólások

VPN -re en a SoftEther VPN-t ajanlom.

https://www.softether.org/

"If you are using VPN Client, you can use your own DHCP server to assign static IP addresses to each computer, by using unique virtual MAC addresses of VPN clients.
You can also define access-list entries on the Virtual Hub. An entry can have the username field as the matching condition. Then you can allow the specific access to the specific user."

A tobbi altalad tamasztott kovetelmenyt is tudja a SoftEther.

Nem értem, h OpenVPN ellen mi a kifogás.
Ha linux lenne a vas, akkor nem hiszem, h bármi problémába belefutsz a manual olvasáson kívűl
Ha Mikrotik, akkor csak TCP van és nincsen push és tömörítés.

Ma már van iOS-re is kiváló OpenVPN kliens, 99.5% hogy ez igaz Androidra is.

Gondolom a softether oldalarol van a tablazat. Van benne jopar marketing bullshit.
Pl. az openvpn 100 Mbit alatt tud csak, a softether meg 900 Mbit felett:)

Vagy hogy az OpenVPN nem tud NAT-T...hat persze, mert nincs ra szukseg.
Mi az a virtual DHCP es mit nem tud abbol az OpenVPN pontosan?

Az mit er, h tobb porton is tud listenelni a Softether?

Az mit er, h tobb porton is tud listenelni a Softether?

Több protokollt támogat és ugyanazt a virtuális hálózatot teszi elérhetővé ugyanazokkal a beállításokkal csak több protokoll felett.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Az oké, csak a protokollokhoz vannak többé-kevésbé fix portok ;) pl. MS-STP-t Windows kliens csak 443-on beszél, OpenVPN-nél a standard 13akármiakármi, ...
Neki mindegyik porton figyelnie kell, amit beikszelsz.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Jó ez a Softether egy időben nézegettem OpenVPN kiváltására, de ez a topic eléggé eltántorított:

https://github.com/SoftEtherVPN/SoftEtherVPN/issues/268

Azóta , ha jól látom összekapták magukat, bár a többesszám nem triviális, ha jól sejtem ez egy "one man show" volt sokáig, ha jól értem egy diplomamunkából nőtte ki magát.

Igen, egyemberes volt, nemreg szalltak be tobben is, mert kezdett elhalni a tema.

Azota a project kettevalt, az eredeti fejleszto viszi a "stable" agat, a "szokasos" ritka release-ekkel (evente talan 1-2) A developer agat meg a Github kozosseg (persze felugyelettel) Itt azert 1-2 havonta varhato uj release.

En OpenVPN-t hasznaltam ilyesmire, igaz nem routeren futott, hanem a gateway szamitogepen.
De ha az kellene, szamos routeren is tud futni (pl. openwrt alatt lattam egyszer)

Mikrotik sem tud 1 publikus IP-rol (azonos NAT-olt alhalozatrol) ket L2TP/IPsec kapcsolatot kezelni. ROSv7-et pedig max viccben erdemes emliteni.

Mikrotik sem tud 1 publikus IP-rol (azonos NAT-olt alhalozatrol) ket L2TP/IPsec kapcsolatot kezelni.

Ez az IPsec limitációja (nem lehet megkülönböztetni a sessionök csomagjait egymástól, nincs benne sem session id, sem portszám, sem semmi kapcsolati azonosító, ami alapján a NAT-oló gépre visszaérkező válaszcsomagokat szét lehetne válogatni).

Azért nem ilyen rossz a helyzet:

https://wiki.strongswan.org/projects/strongswan/wiki/Connmark

The connmark plugin uses Linux Netfilter conntrack marks on transport mode connections to separate flows between clients. As two transport mode clients behind the same NAT use identical IPsec policies, some special binding of upper layer protocols is required to return data over the correct SA. While any client-initiated protocol supported by conntrack can be separated, the main purpose is to differentiate multiple L2TP sessions.

Szóval van erre megoldás.

De OpenBSD is tudja ezt npppd+isakmpd-vel.

A releváns commit 2012-ből:

https://marc.info/?l=openbsd-cvs&m=134246321705999&w=2
https://marc.info/?l=openbsd-cvs&m=134249542915684&w=2

Ha Windows10-es lapstopok (na jó Win7-8.1 még játszik), akkor SSTP és Mikrotik.
SSTP nem érzékeny a NAT-ra, a kliensen "csak" a root certet kell telepítgetni, a többi benne van a rendszerbenm csak be kell állítani.
Én pl. egy másik szerver LetsEncrypt certjét és kulcsát másoltatom scripttel a Miki-re, és még egyedi root cert-et se kell másolgatnom a kliensekre, bár AD-ból az se olyan megeröltető.
Sajnos az SSTP gyárilag még a Lumiákban se volt támogatott, sebességben meg OpenVPN UDP-n a király (NAT őt sem zavarja meg), de van az az uplink, amikor már olyan mindegy.

QNAP-en virtualizálva egy pfSense?

openvpn -t ajánlom.
- ha van egy pc-s tűzfalad (endian, pfsense) azzal triviálisan megoldott.
- ha virtuális gépbe / konténerbe rakod, oda is tehetsz akár egy ilyen disztribúciót és akkor kattintós, akár egy sima debian-t commandline használatra.

Nekem otthon egy Linksys E4200-on tomato firmware-el is van openvpn-em, az is tök oké.

--
Gábriel Ákos

- ujabb OSX-eken nincs mar PPTP tamogatas, sem uj IOS-en. sot mintha win10-be is dobtak volna mar, de ebben nem vagyok biztos.
- PPTP, L2TP mukodesehez kell a vpn passthru opcio a kliens(!) routeren, ez mostanaba az ipv6 ganyolasok (nem dualstack) miatt sem UPC sem T-home routereken nem szokott mukodni alapbol (kerni kell ugyfelszolgalaton, es akkor a kovetkezo fw frissitesig jo), sem a legtobb public wifin.
- SSTP atmegy mindenen (https alapu), de csak windowson supportalt OOTB (OSX-en csak cli megoldast talaltam, amit rootkent inditva mukodik). router oldalon linux vagy win server kell hozza.
- OpenVPN is atmegy mindenen (jo esetben, de lattam mar olyan wifit ahol szurtek), de semmi se tamogatja OOTB, se router se kliens oldalon. plusz a macera a certekkel.
- a fix ip-hez dobozos megoldasoknal a radius szokott kelleni.

szerintem ha nagyon dobozt akarsz es (ugyan nem OOTB, de) jo supportot minden kliensen akkor vegyel valami cisco megoldast...

L2TP-t nem nagyon használnak IPSEC nélkül interneten keresztül. Az L2TP+IPSEC NAT-T+transport mode -hoz meg az UDP500 és UDP4500-as porton kívül nem kell más, plusz a megfelelő szerver implementáció ami tudja kezelni a több kliens azonos NAT mögött szituációt.

És valóban, ha ragaszkodunk az OOTB klienshez (de minek?) akkor ez van kb mindenben: IOS,OSX,Windows,Android, Linux stb,,

Az OOTB klienseknek megvan a maguk baja.

A "gyártó" specifikus kliensek "ugyanúgy" működnek minden támogatott platformon, legalábbis elméletben.

OOTB kliensre amúgy másik lehetőség (a pptp-t hagyjuk) az l2tp+Ipsec mellett az Ikev2. OOTB Ikev2 kliens van Windows7+,IOS,OSX,Blackberry platformokon, Android-ra pedig Strongswan Google Play-ról.. Szerver oldalra szintén Strongswan.

De ha már bonyolultabb konfigot akarsz, akkor ezek az OOTB kliensek különböző limitációkkal rendelkeznek.

Jó példa a split tunneling. Ekkor ugye csak bizonyos routeok mennek a VPN-be, mondjuk LDAP csoporttagság/Radius Class alapján, a default gw nem arra mutat. Namost ezt a működést az OOTB kliensek különbözőképpen támogatják. A probléma, hogy hogyan oldod meg, hogy a routeok lekerüljenek a kliensre. Legegyszerűbb persze kézzel felvenni a tunnel interfész felé.
Windows-on, Linux-on ezt még megoldod kézzel (de könyörgöm minden VPN kapcsolódás után?), Android-on vagy IOS-on meg nem igazán.
A Windows beépített L2tp/Ikev2 kliense küld DHCPINFORM kéréseket a felépült tunnelben ahol option 249-el tudsz visszaküldeni routing infót, a többi kliens meg nem.
Az Ikev2 esetében a Windows mindig 0.0.0.0/0 Traffic Selectort küld, és nem szűkiti a TS-t az alapján amit az Ikev2 szervertől kapott.

https://wiki.strongswan.org/projects/strongswan/wiki/ForwardingAndSplit…

A másik a challenge-response támogatása, ha például két faktoros auth-ot szeretnél (pl extra OTP+PIN ablak feldobása), OOTB kliensek nem támogatják.

És még sorolhatnám.
Szóval több platform támogatása OOTB klienssel a legegyszerűbb esettől eltekintve eléggé szívás.

igen ez igy van :(
mi mondjuk az l2tp-nel bekuldjuk a teljes forgalmat ceghez (van eleg savszel) es legalabb ott van addig tuzfalazva a forgalma amig eleri a belso dolgokat. de ha akarnank se tudnank splittelni.
pptp-nel meg az is izgi hogy pl mac osx-en defaultbol nem megy arra a forgalom csak ha kulon beallitod, mig windows eseten igen.
openvpn-nel tok jo hogy lehet route-okat pusholni a kliensre, csak ha nem adminkent futtatja a kliens akkor nem fogja tudni beallitani/ervenyesiteni.

+sok, nekem is ez volt a problémám vele, lehet valahogy trükközni az ütemezett feladatoknál rendszergazdai jogú indítással. (nem is szerencsés, ha a júzer elkezd otthon a "saját kényelméből" feltelepítgetni mindent, aztán meg csodálja, ha lassú a gépe, ha meg mondom neki, itt elkezdi, á biztos én csesztem el valamit, nem is az ő vacka fogja a gépet)

Openvpn-hez nem kell rendszergazda jog a 2.4+-es verzió óta Windows-on.

Lásd:

https://github.com/OpenVPN/openvpn-gui

OpenVPN GUI 11 and later can make full use of the Interactive Service functionality in recent versions of OpenVPN. This changes a number of things:

OpenVPN GUI can store its settings in user-specific part of the registry under HKEY_CURRENT_USER
OpenVPN is able to delegate certain privileged operations, such as adding routes, to the Interactive service, removing the need to run OpenVPN with admin privileges. Note that for this to work the OpenVPNServiceInteractive system service has to be enabled and running.

"openVPN nyűgös több eszköznél"

Ezt nem tudom hogy mibol szurted le.

Nekunk jelenleg 5 pfSense van OpenVPN-el, amik allandoan elerhetoek minden platformrol.
Ebbol az 5-bol 2 site-to-site es ezeken vegyesen van kliens szerver es mind mindenhonnan elerheto.

Android, iPhone, Linux/Windows kliensek mennek rendesen.

Full-ban volt hogy a 2 "sima" nem site-to-site box-on logott tobb mint 50-en Linux Raspberry, amiken alhaloban gatewayek voltak amcsiban es Londonba csatlakoztak be.

Az osszes gep virtualisan 1GB Rammal, meg 1 procival.
Nevleges fogyasztas kb 3W a VMware szerint.

Nincs isten hogy lecserelnem barmi masra, mert megy mindig es soha senki nem zorog hogy gond lenne.
Max ha egy update elcseszi a kliens rendszert, akkor ujra kell huzni. Legutobb egy Mac-en volt gond a Tunnelblick klienssel es ennyi. Ami gond szokott lenni az a tavoli kliens hogy tcp vagy udp az OVPN szerver tipusa.
Tavoli kliensnel (mondjuk Amcsibol Europaba csatlakoznak) jobb a tcp szerver, mint az udp, tapasztalat ezt mutatta.