OpenVPN vs. bármi más labdába rúghat?

Web, mail, IRC, IM, hálózatok

Sziasztok!

Felmerült egy szakmai parázsvita, hogy nem biztos jó irányt követünk, lehetne máshogy is. A jelen:
Van egy kiépített, jól működő OpenVPN szerver. Hozzá saját fejlesztett webes admin felület, ahol usereket lehet kezelni.
OpenVPN szerver configban beállított auth script + webes frontend a következőket tudja:

  • 2 faktoros login: előbb egy globális cert ellenőrzés, ha azon átjut, akkor usernév-pass páros ellenőrzés
  • A kliens gép teljes IPv4 forgalma a VPN csatornába terelve, hogy a céges hálón való lógása alatt kontrollálni lehessen a forgalmat. Esetleges reverse shell és hasonló férgesedést tompítani.
  • userenként VPN kliens IP kezelés, mely tematikus IP listából kiválasztható, pl. IT, könyvelés. Más-más subnetből, más tűzfal korlátokkal.Csatlakozáskor abba a subnetbe kerül.
  • userenként egyedileg megadható forrás IP/subnet lista, amely publikus IP címekről becsatlakozhat
  • userenként lejárati dátum, mely után azzal a loginnal nem tudnak belépni (határozott időre felvett dolgozónál vagy külső projekt partnernél hasznos).
  • userenként engedélyezés, tíltás
  • userenként látni, hogy milyen cert névvel jön fel (global cert van, időszakos cserével. Látszik, ha valaki még a régi global certet használja, ami le fog járni)
  • userenként aktivitás, épp online-offline, mikor csatlakozott utoljára
  • userenként eszköz hitelesítés = MAC cím engedélyezés, csak arról az eszközről jöhet fel, amit első csatlakozáskor automatikusan eltárol és lockol ahhoz a loginhoz.
  • 2 aktiv VPN szerver, 2 független SQL backend, köztük szinkron, hogy az userkezelés, jogosoltságok megegyezzenek.

folyamatban van:

  • token alapú +1 faktoros login
  • IPv6 kikapcsolása, ha VPN-re csatlakozik, hogy a reverse shell IPv6-on ne tudjon felépülni, megkerülve a push "redirect-gateway def1" paramétert.
  • a MAC alapú szűrés a jövőben nem biztos, hogy használható marad, mert az oprendszerek randomizálni akarják. Lehet más módon kell hitelesíteni a kliens gépet.
  • 3 rossz login próbálkozás után forrás IP ban. (Bár cert, mint első védvonal miatt csak egy szűk réteg jut el a login részig)

Felmerült, hogy sok idő elmegy(/elment) a fejlesztésre, nem is tud mindent, vegyünk egy dobozos terméket, az majd jó lesz.

Kérdezem a tisztelt IT kollégákat, Cisco, Sophos, Sonicwall és társai ezeket így vagy máshogy tudják? Ha bizonyos dolgokat nem, van hozzá API lehetőség, hogy szabadabban lehessen hozzáilleszteni egy auth modult, mint pl. az OpenVPN auth scriptjén keresztül bármit?
Ha nem ingyenes, és ismeritek az egyszeri / rendszeres költségét, kérlek azt is osszátok meg.

Tippre nem vagyunk bentebb mással sem, de azért az esélyt megadom, nehogy részrehajló legyek :)
Ja evidens, de ki ne maradjon: multi platformos kliens legyen hozzá: Linux, Windows, mac OS X, Android, iPhone.

Köszönöm!

  • 1152 megtekintés

( zeller | 2022. 10. 20., cs – 15:45 )

"A kliens gép teljes IPv4 forgalma a VPN csatornába terelve" - Tedd hozzá, hogy elméletileg... Mert egy Linux-ra feldobott kliens esetén a push-olt route-ot azért nem nagy munka átvakarni - ahogy mondjuk Windows-os kliens esetén wsl2-ből indított vpn-nél se...

Az alap feltevés az, hogy a munkavállaló user joggal futtatja a windowst és a csúnya vírus nem tudja átütni olyan könnyen a default gw beállítást.

Persze, ha talál sérülékenységet a rendszerben, az ellen sokat nem tudunk tenni, max egy vírusírtóval tompítani a kockázatot.

De ha van jobb ötlet, bármire vevő vagyok. Elborult ötlet, de az is felmerült, hogy kapnak egy mikrotik szappantartót, rajta beállítva a vpn, tűzfalazás és amit oda rádug, akkor céges hálóban van korlátokkal, ha lehúzza akkor az otthoni lanon. Na az ellen a root is kevés :)

Ha lesz olyan user/group, akinek kell local admin jog, máris meg vagytok lőve ezzel a push defgw dologgal. Jó megoldást nem tudok openvpn-nel, ipsec-et még nem néztem komolyabban.

A plusz router-es megoldásra anno volt példa: Cisco VPN-koncentrátor meg egy raklapnyi kis PIX, és ezek kerültek ki az érintettekhez (meg boot cd, így a pécét sem kellett felügyelni, mert a bebootolt Linux csak egy rdp session-t épített fel a központi TS-farmhoz, a helyi lemezt nem tudta elérni az user)

( zeller | 2022. 10. 20., cs – 15:54 )

"global cert van, időszakos cserével. Látszik, ha valaki még a régi global certet használja, ami le fog járni" - Fájni fog, tudom, de ez így baromira nem jó. A cert innentől kezdve csak a titkosításhoz köll, pedig lehetne vele yool azonosítani az usert/végpontot - akár chipkártya, vagy usb-s cert. tárolóeszközzel (Android-on meg a HD/üzemeltetés által a telefonba töltött cert+key párossal, ahol a kulcs jelszavát a telefon tulajdonosának nem is kell ismernie(!)).

A "2 független SQL backend, köztük szinkron" is eléggé -hogy is mondjam- addig jó, amíg ténylegmegvan a szinkron, ha egyszer széthullik valami miatt, akkor lehet gondolkodni, hogy hogyan legyen egybegyúrva.

Nem voltam túl részletes, mert igy is eléggé az voltam, de kifejtem :)

A global cert az valójában "usert" hitelesítő cert. Az OpenVPNben megadható, hogy egy cert vagy sok cert + név-jelszó páros.

Lehetne sok cert is, jelenleg max 2 van az átmeneti időszakban: régi és az új.
Ez nem a szervert hitelesíti, hanem a klienst, hogy az ő CA-jával van-e aláírva, passzol-e a szerver certhez.
Sok éve raktam össze, de akkor úgy kísérleteztem ki, hogy ez nem a kézfogáshoz kell, hanem eggyel utáni lépcső. Az easyRSA toollal is client -ként hivatkozok a kulcsra, amikor generálom. Én úgy gondolom ez akkor kliensnek leküldendő cert. Ha kiveszem a kliens configból a auth-user-pass sort, akkor ezen certben lévő nevet fogja usernévnek tekinteni.
A felvetést attól elfogadom, úgy is tervben van a modernizálás (pl. comp-lzo -ról való leszokás, hatékonyabb titkosítási algoritmus választása, egyéb config tuning), megnézem ismét ezt is. Lehet, hogy tévedtem. Mindenesetre ezen kulcs nélkül nem lehet szóba állni a szerverrel, tehát a név-jelszó logint nem lehet pörgetni. Az a második védvonalban van.

A 2 független SQL backend között egy php kód szinkrozinál ütemezve. Soronként átnézi a bejegyzéseket és ahol változott pl. a jelszó, átírja a másodlagos vpn SQL-jében. Az írás egyirányú.  Nem SQL replika megy, azt felesleges bonyolításnak éreztem.

 

"azonosítani az usert/végpontot - akár chipkártya, vagy usb-s cert. tárolóeszközzel "

A kiindulási alap az, hogy a kiadott dolgozó másolhatja, átteheti nem ellenőrzött céges gépre is a VPN kulcsot vagy egy külső partner is tovább adhatja egy fentebbi support csapatnak, akiket nem hagytunk jóvá.
Úgy érzem ez ellen a kulcs önmagában kevés, bár mi is alkalmazzuk.

"HD/üzemeltetés által a telefonba töltött cert+key párossal, ahol a kulcs jelszavát a telefon tulajdonosának nem is kell ismernie(!))."

Ez már jól hangzik. Régen hasonló volt. Userenként 1 cert és annak belső jelszava, de azt a jelszót offline a cert tárolta. Offline az user jobb katt át tudta írni az OpenVPN kliensben és ami mégrosszabb: offline brute-force törhető úgy, hogy arra semmi rálátásunk sincs.
Melyik jelszóra gondolsz hát itt?

"A global cert az valójában "usert" hitelesítő cert." - Nem. Ugyanis azt írod, mindenkinek ugyanaz, tehát a cert nem mondja meg, hogy kiről van szó, csak azt, hogy valaki, aki birtokában van a certnek. Azonosítás csak az usernév/jelszó párosnál van, ami egy faktor. Ha a jelszókezelést kiegészíted token által generált idő alapú jelszóval, akkor lesz 2FA-d.

"A 2 független SQL backend között egy php kód szinkrozinál ütemezve. Soronként átnézi a bejegyzéseket és ahol változott pl. a jelszó, átírja a másodlagos vpn SQL-jében. Az írás egyirányú.  Nem SQL replika megy, azt felesleges bonyolításnak éreztem."

Aha. ha meg az elsődleges kidől 1-2-3-x időre, akkor kézzel megfordítot a "szinkron"-t, miután az elsődleges visszajött, miközben volt módosítás? Lehet így is, de ha nem muß, nem kell az embernek magát szivatni... Meg persze az is kérdés, hogy mennyi időre eshet ki a DB, mint szolgáltatás, illetve mennyi az az időtáv, amennyi adat elveszhet?

Mi lenne, ha user-enként lenne a cert (nem egy közös használatú), ahol a CN egyezik a username értékkel és az OpenVPN szerver csak egyező CN és username esetén enged be? (Ezt mind tudja alapból az OpenVPN).

Az user cert privát kulcsa védhető plusz jelszóval még ezen felül (ahogy írod, sajna erőből feltörhető), ami az user nem kívánt tevékenysége ellen nem véd (oda tudja adni a kulcsot, meg tudja mondani a jelszót hozzá), de legalább a kulcs ellopása esetén plusz egy védvonal. Ráadásul OpenVPN szerver oldalon CRL-lel egyesével tudod kitiltani őket, így az usernév/pass ellopása nem elég a belépéshez, mert a kötelezőan azonos CN-re szóló cert már CRL-en van.

Igaz, N darab user cert-et évente (vagy sűrűbben) frissíteni jóval több meló, mint egyetlen közösen használt certet. Más oldalról a user felelőssége növelhető, ha nincs közös pont, így nem tud hárítani mindenki, hogy biztosan nem tőle került ki a cert/key.

Valamint a user privat kulcsat (a ceges ca altal alairt certjet) tarolhatod hardverben, nem masolhato modon, pl. usb tokenben, es akkor az is egy faktor, hogy nala kell lennie, ergo nem lophato el a tudta nelkul, es igy nem bruteforceolhato a tudta nelkul, konkretan ha nem munkara hasznalja a gepet, akkor bent sincs a token a gepben. Igaz, igy visgont szivas a cert ujitas, mert be kell vele ballagni a ceghez fizikailag, plusz leltar a tokenre, stb.

( godot v | 2022. 10. 20., cs – 16:07 )

Szerkesztve: 2022. 10. 20., cs – 16:09

Attól függ mik az igények, mi az amit nem tud és kéne? Sok "Enterprise" helyen elvárás a VPN-től  a posture is. Azaz vírusirtó megléte, adatbázis frissesség ellenőrzés a kliensen, nyitott portok, telepített szoftverek stb, ettől fűggően korlátozott hálózatba jutsz etc...

Javaslom nézd meg a www.packetfence.org -ot ez egy teljes körű open source NAC megoldás, össze lehet lőni openvpn-el is többek között (bár  openvpn oldali scriptelgetés/fejlesztés nélkül csak az alap dolgokat fogja tudni megoldani ez is out of the box).

Vagy ha Enterprise megoldás kell Cisco Anyconnect+ISE , ha van pénz lóvéra :)

Evés közben jön meg az étvágy :) Itt is úgy volt. Ami megvalósult, azokat konkrét igények alapján fejlesztettük bele az évek során. 

A linket köszönöm, szétnézek ott.

Ami hibaként merült fel: az eszköz hitelesítés.
Jelenleg megoldott, de állítólag Android 12 és Windows 11 már változtatni akarja és a jövő abba mutat, hogy nem lehet letíltani majd ezt a funkciót. Így ellehetetlenül ez a védelmi funkció a VPN szerverben.

A MAC, pontosabban az utolsó 3 bájtja mindig módosítható volt, úgyhogy a női trikó (maca dressz) alapú azonosítás - mondjuk úgy - nem igazán erős kihívás, privacy okból meg pláne célszerű volt leszokni ennek az azonosításra történő használatáról.

Valamilyen okosabb agent nélkül nem fogod megúszni, az már látszik :-/

Nem ennyire egyszerű...

Windows-on könnyebb...

A "cryptoapicert" opciónak megadod a Windows melyik cert bugyrában keresse a certet. Ha ez TPM-en van akkor kész :).

Hogy hogyan kerül a TPM-be a cert + a kulcs az meg a megfelelő Windows-os doksiban le van írva :)

https://blog.securityevaluators.com/how-to-harden-openvpn-in-2020-part-…

Linux-on a szokásos "sajtreszelés":

https://github.com/tpm2-software/tpm2-pkcs11/blob/master/docs/OPENVPN.md

Már megérte feldobni a témát. Az első link ide vitt:  https://github.com/evgeny-gridasov/openvpn-otp

Abban egy ilyen van, kliens configba kell tenni: static-challenge "Enter Google Authenticator Token" 1

És ezzel megvalósul az amit egy ideje keresünk: plusz változót lehet feladni kliens oldalról. Új lehetőségeket ad.
Köszönöm! :)

Foleg, hogy ha valaki (kulsos) tobb cegnek is dolgozik, akkor nem fogja szopatni sajat magat, felhuz cegenkent egy virtualis gepet, es igy nem utkoznek sem az adatok, sem az adott ceg altal megkivant szoftverek. Egy virtualis gepben meg olyan MAC cimet allit be, amit nem szegyell, pl: DEADBEEF

( zrubi v | 2022. 10. 21., p – 10:03 )

Ahogy én látom:

az OpenVPN azt csinálja ami a neve sugall: kiépít egy VPN csatornát. pont.

(+ Nyilván ehhez szorosan kapcsolódó dolgok, mint authentikáció és authorizáció, IP címzés)

 

Az enterspájz megoldások, messze túlnyúlnak ezen, mert gondoskondi akarnak arról, hogy a kiliens 'tiszta', és csak úgy engedik a felszenteltnek (hitt) (enterspájz) hálózatra. És egyben ez is a legnagyobb bajuk. Ugyanis ez egyszerűen nem lehetséges.

De azért ők ezt mégis próbálják, erőltetik minden áron. Ami ahhoz vezet, hogy a vpn kliens 'god módban' fut majd a gépen, szétcseszi a route-olást, nevfeloldást, random root CA-kat telepít, feltöri a HTTPS kapcsolatokat, stb. Nem is beszélve a rootkitről, amit 'ellenőrzés' céllal telepít a gépedre. Ezek ráadásul igen kevés eséllyel (és sikerrel) futnak linuxon.

 

Én ezeket a förmedvényeket senkinek nem ajánlom!

Ezek  a "security theater" részei, és csak arra jók, hogy a felelőséget 3rd party-ra hárítsák.

Valós technikai haszunk erősen megkérdőjelezhető.

 

szerintem.

zrubi.hu

"szétcseszi a route-olást, nevfeloldást, random root CA-kat telepít, feltöri a HTTPS kapcsolatokat, stb. Nem is beszélve a rootkitről, amit 'ellenőrzés' céllal telepít a gépedre. Ezek ráadásul igen kevés eséllyel (és sikerrel) futnak linuxon."

Routing... Ugyebár a nagyvilágot és a vpn-en túli világot nagyon nem lenne jó összeengedni egy ilyen végponton, nagyon nem lenne jó, ha a végpont a céges hálózaton kívül másfelé is tudna direktben kommunikálni. tetszik, vagy sem, de ez is feladata a vpn-nek: a nagyvilág felé _zárt_ hálózati végponttá alakítani az adott eszközt. Névfeloldás dettó, nem biztos, hogy öröm és bódottá, ha a céges k1fszm.intra címéről random szolgáltató random nameserverénél kezd érdeklődni a kliens.
A CA-k dolga, hogy a hitelesítéshez a megbízható harmadik felet adják - nagyon kevés az a cég, amelyik a belső hálózatán is megengedheti magának, hogy publikus CA-tól vegyen a szerverekre tanusítványt - egyrészt, mert ahhoz belül is publikus TLD alatti nevekre lenne szükség (ekkor bejön a DNS téma, meg a split dns ugye...), másrészt ha nem DV-s cert, akkor kifejezetten drága tud lenni, ha meg DV, vagy hasonló, akkor valameddig be kell engedni a külső felet validálási céllal, méga LE-s certeknél is.
Az SSL-bontás az előbbihez (is) kapcsolódik: a tartalomszűréshez, illetve a DLP-hez minimum a nagyvilág felé irányuló SSL/TLS forgalmakba bele kell nézni, ha tetszik, ha nem. (EZ utóbbi esetben a HR-en(!) tessék kopogtatni, és bejelenteni, hogy a munkavégzés feltételeit nem fogadod el)

De vevő vagyok a javaslatodra, ami megoldja az összeroute-olás, a belső CA-k, illetve a DLP/content filtering miatti ssl/tls bontás általad felvetett problémáját a kliensen történő routing/dns módosítás, illetve ca telepítés nélkül.
 

Ugyebár a nagyvilágot és a vpn-en túli világot nagyon nem lenne jó összeengedni egy ilyen végponton

Ez kifejezetten helyzet függő, semmiképpen sem általános VPN elvárás. Sőt!

 

De vevő vagyok a javaslatodra, ami megoldja az összeroute-olás, a belső CA-k, illetve a DLP/content filtering miatti ssl/tls bontás általad felvetett problémáját a kliensen történő routing/dns módosítás, illetve ca telepítés nélkül.

Az én véleményem csak az, hogy ezek egyike sem része a VPN-nek. A problémák valósak, csak semmi közük a VPN-hez.

Amit Te vázolsz, az egy valós - ám igen speciális igény - és messze túlnyúlik a VPN kapcsolat fogalmától. Igy - szerintem - igen rossz irány, hogy ezeket egy VPN kliensbe tömörítik. vagy legalábbis próbálják...

Ez innnetől egy TELJES végpont kontroll, ami az egész hardver és szoftver felett átveszi az irányítást.

 

szerintem.

zrubi.hu

>  Ez innnetől egy TELJES végpont kontroll, ami az egész hardver és szoftver felett átveszi az irányítást.

Ezt is szokták árulni, már régen nem "csak" vpnt. Leginkább azért, mert az ügyfeleknek erre van igényük.

>A problémák valósak, csak semmi közük a VPN-hez.

vs

> Ezek  a "security theater" részei, és csak arra jók, hogy a felelőséget 3rd party-ra hárítsák. Valós technikai haszunk erősen megkérdőjelezhető.

El kellene dönteni, hogy melyiket gondolod, mert egy kicsit ellent mondanak egymásnak. Az első, egy érvelhető álláspont (a helyzet valóban nem ideális, az, hogy egy ilyennek kizárólag a vpnnek kell foglakozni, azért vitatható), a második, hát, az elég nehezen tűnik védhetőnek.

Érdemes megnézni mit mond erről az Openconnect projekt ami ugye nyílt forráskódú klienst biztosít (mivel a Cisco Linux-os kliense 32bit x86 only bináris blob volt ebből indult ki  projekt annó sok éve) Cisco Anyconnect, Juniper, Forti, Palo Alto VPN megoldásokhoz.....

https://www.infradead.org/openconnect/csd.html

https://www.infradead.org/openconnect/tncc.html

https://www.infradead.org/openconnect/hip.html

Ha ezeket ennyire könnyű átdobni a palánkon akkor...?

 

Egyébként van nyílt megvalósítás egy köteg RFC_vel ami az ilyen posture-t próbálja meg szabványosítani (és talán? normálisan működővé tenni). A gyártók szokás szerint magasból tesznek az egészre.

A Strongswan projekt szépen összeszedte:

https://docs.strongswan.org/docs/5.9/tnc/tnc.html

Néztem, teszteltem is, anno mikor még ilyesmivel foglalkoztam. Mint mondtam, a helyzet nem annyira ideális, a technikai megvalósítás sok esetben elég borzasztó, 1) de az attack vector mindenképpen hosszabb, 2) adminig komprommitált host kell hozzá. Persze, ez az önbevallásos dolog messze nem az igazi, az tény, de egyébként megoldható lenne ám, hogy a ne legyen ennyire könnyen átvágható (csak adminisztratív/usability oldalról fájna, és ugye az ügyfelek :) ).

illetve emlékeim szerint a junipersen lehetett úgy pipálni scriptet odafent, hogy ne legyen a dolog ennyire triviális.

>A problémák valósak, csak semmi közük a VPN-hez.

vs

> Ezek  a "security theater" részei, és csak arra jók, hogy a felelőséget 3rd party-ra hárítsák. Valós technikai haszunk erősen megkérdőjelezhető.

El kellene dönteni, hogy melyiket gondolod, mert egy kicsit ellent mondanak egymásnak. Az első, egy érvelhető álláspont (a helyzet valóban nem ideális, az, hogy egy ilyennek kizárólag a vpnnek kell foglakozni, azért vitatható), a második, hát, az elég nehezen tűnik védhetőnek.

Attól, hogy a problémát valósnak ítélem, továbbra is az a véleményem hogy a legtöbb enterspájz "megoldás"  nevetséges, és teljesen rossz irányba 'kapálódznak'. -> security theater.

 

szerintem.

zrubi.hu

( buccaneers v | 2022. 10. 21., p – 11:22 )

Mi SonicWall - NetExtender SSL VPN-t használunk.

AD-s userekkel, szép dashboard, loggolás minden - de van API-ra is lehetőség, de azt nem használjuk.

1920. augusztus 01. a Magyarországi Tanácsköztársaság vége.

1918. március 21. – 1920. augusztus 01. Magyarországi Szocialista Szövetséges Tanácsköztársaság.

Nagyon nagy történelmi bűn, hogy létrejöhetett Magyarországon, 1918-ban a tanácsköztársaság.

csak a VPN licensz kb. nettó árak:

   1db-os    50USD   

 50db-os  600USD

100db-os 800USD

de ehhez kell egy tűzfal eszköz  + 2 éves licensz nettó 500ezer forint

HA-t szeretnél 2 tűzfallal, akkor a második lényegesen olcsóbb.

 

Nem megy át a teljes forgalom a VPN csatornán.

1920. augusztus 01. a Magyarországi Tanácsköztársaság vége.

1918. március 21. – 1920. augusztus 01. Magyarországi Szocialista Szövetséges Tanácsköztársaság.

Nagyon nagy történelmi bűn, hogy létrejöhetett Magyarországon, 1918-ban a tanácsköztársaság.

( arpi_esp v | 2022. 10. 22., szo – 21:44 )

mi is fejlesztettunk valami hasonlot meg vagy 5 eve, az 3 faktoros ha ugy nezzuk (per-kliens cert, usernev+jelszo, sms-ben kuldott 1x hasznalatos pinkod), bar a mienk erosen epit az AD-re, amit lehet ott tarolunk (pl. AD csoport tagsag hatarozza meg a tuzfal szabalyokat), a web ui inkabb csak statusz/log nezegeteshez van.  anno sok ceg megvette mert a cisco es tarsaihoz kepest toredek aron adtuk, es az adathalaszattal ellopott user+pass esetere megoldas volt, nyilvan nem tud annit mint a cisco es tarsai, bar pl. antivirus check meg ilyesmi is van benne (winre es macre van sajat kliens app) opcionalisan.

de az ilyen hazibarkacs megoldasok csak addig jok amig nem kell egy komolyabb auditon atesni valamiert. akkor buko mert neked nyilvan nem lesznek olyan biztonsagi tanusitvanyaid (papirra gondolok, nem ssl certre) amit elfogadnak...

raadasul az openvpn mar magaban egy ultra nagy ganyolmany, az hogy windozon dhcp szervert emulal es ugy ad ip-t admin jog nelkul, vagy a defgw1 amikor 2db /1 maskkal uti felul a defgw stb. raadasul 1-2 evente varialjak hogy epp milyen titkositast fogad el, igy allandoan csreelgetned kell a certeket ha frissul az openvpn es meg sorolhatnam. mi is ejtettuk ezt az vonalat es inkabb attertunk sstp es l2tp/ikev2 iranyra es abba integralunk 2fa megoldasokat. szerver oldalon pppd-hez is lehet auth plugint irni c-ben, nem is tul nehez, onnantol mar kb ugyanott vagy, csak a kliensre nem kell openvpn telepiteni hanem a nativ 'drivert' lehet hasznalni ami azert sokkal tisztabb szarazabb erzes, legalabbis amig jo az ha a teljes forgalmat a vpn-be akarod zavarni. split tunnelig eleg maceras tud lenni ugyanis, kb ez az egyetlen elonye az openvpn-nek hogy ott egyszeru 1-1 subnetet routeolni csak szelektiven.

sokáig mi is OpenVPN-t használtunk, de amikor hardveres tűzfalat beszereztük, akkor már egyben akartunk mindent kezelni és nagyobb végponti biztonságot - ezért vettünk SonicWall tűzfalat és VPN -t.

1920. augusztus 01. a Magyarországi Tanácsköztársaság vége.

1918. március 21. – 1920. augusztus 01. Magyarországi Szocialista Szövetséges Tanácsköztársaság.

Nagyon nagy történelmi bűn, hogy létrejöhetett Magyarországon, 1918-ban a tanácsköztársaság.

( akoscomp | 2022. 10. 24., h – 13:42 )

Én épp ma gondolkodtam el azon, hogy mi értelme a VPN-nek, ha azt a pár szolgáltatást ami vpn-en belül van(nálunk sambán kívül minden webes szolgáltatás), berakhatom egy SSO mögé, ami lényegében ugyanazt nyújtja, de sokkal dinamikusabban. A samba meg átvihető seafile-ra vagy nextcloud-ra.

VPN értelme lehet még: ssh és egyéb management hálózat elérése anélkül, hogy kiengednéd a nyílt netre.

SAMBA-val megoldható a zfs+shadow copy, így van sok sok visszaállítási pontod, amit ugyan a seafile is tud, de sokkal nyögvenyelősebben. Nálam a seafile párszáz GB adattal és sok apró fájlnál elvérzett. Egy sima fájl letárolásra amúgy is bloatware. Arra a samba egy fürge pehelysúlyú megoldás.

Persze, ha a teljes cég ki van szervezve a felhőbe annak minden előnyével és hátrányával együtt, akkor tényleg nem sok létjogosultsága lehet. Max adminoknak kell egy belső service háló a switcheket, routereket piszkálni.

Mi értelme a főbejáratnak és az ott levő védelmi intézkedésekkel ahelyett, hogy minden irodát megfelelő elektronikus védelemmel az utcáról is bejárhatóvá tennénk?
Filozófia kérdése, hogy egy helyen csinálsz rendszeresen auditált, felülvizsgált erős védelmet, vagy sok védelmi pontot alakítasz ki és mindegyiket rendszeresen auditálni akarod.

( dragi v | 2022. 10. 24., h – 16:13 )

Softether. OpenVpn protokollt is képes kezelni.