100+1 VPN csoport kezelése (Wireguard?)

Sziasztok!

A segítségetekre volna szükségem.
3 hónapja próbálok összehozni egy saját VPN szervert, amivel kb 3-400 klienst kellene kezelni 100+ csoportba rendezve,

+1 csoport kellene, amivel az én eszközeim lennének, és azokról el kellene érni minden másik klienset. (windows-ról + Android telefonról)

  • Egy kliens sem mehet ki netre a szerveren keresztül, és
  • csak egymást láthatják a csoportokban.

 (A mostani OpenVPN szerverhez nincs hozzáférésem és az üzembentartója fél év alatt 2x emelt árat +50% +70%)

 

A Debian VPS + Webmin telepítése egyszerű volt.

A SoftEther menedzser programja elsőre nagyon tetszett, de később kiderült, hogy:

  1. Minden egyes kliens-nél kb 50 dolgot kell konfigurálgatni, hogy NE menjen ki internetre a VPN-en keresztül a kliens,
     
  2. Ha egy switch-re 2 gép van rákötve, és mindkettőn van SoftEther kliens, akkor azok nem hajlandóak többé direktben kommunikálni egymással a LAN-on, hanem minden minden átirányítódik a VPN-re !!! A fórumuk fő-gurujai sem tudtak rá megoldást.
     
  3. lehetetlen tartós FIX IP-t hozzárendelni a kliensekhez. :-(
    (Hiába adományoztam komolyabb összeget nekik, akkor sem javították a belső DHCP fixálást.)

 

Az OpenVPN-nel is szakítani szeretnék, mert:

  •  1 új csoport + pár kliens generálása, letelepítése, konfigurálása több órás folyamat, mert valamit mindig sikerül elszúrni a kb 60 beállítás közül. (Még a kényelmes Webmin modulból is)
     
  • Senki sem tudott segíteni abban, hogy az 1 mestercsoport lássa a többit.
     
  • Állandóan változtatnak a klienseken, és az 1 évvel ezelőtt generált (másik szerver) kulcsait már nem hajlandó elfogadni. Mindezt 2 év alatt másodszor úgy, hogy kb már 400 órám ráment a kulcs-cserékre és csak a felével vagyok meg.
    Régebbi kliens nem működik már Win10/11 alatt, hiába volna még 8 év a lejáratból.

 

A napokban felfedeztem a Wireguard-ot,
 aminek sikerült egy .sh szkript-tel felrakni egy nagyon klassz UI -ját is, így gyerekjátéknak tűnt elsőre a konfigurálás. :-)

Igen ám, de:

  • egyszerűen itt sem tudom beállítani, hogy a "mester csoport" gépei rálássanak a többire.
     
  • ... és az imént olvastam itt egy hozzászólásban, hogy nagyon veszélyes lenne a csoportok (pizzériák) tulajainak mobiljaira telepíteni. Főleg, ha csak csak egyetlen wg0
     
  • Továbbá nem látom annak akadályát sajnos, hogy valahol valamelyik gépen átírják a .conf fájlt, ezáltal másik IP-t / hozzáférést kreálva maguknak, ergo nagyon komoly, több-100 féle tűzfalszabályt kellene létrehozni.
    Jól gondolom?
     
  • Ráadásul az az .sh szkript durván belepiszkált az iptables tűzfal beállításokba, és most már úgy tűnik, hogy van egy "legacy" iptables beállításom is... :-( ... de ez már egy másik topik lesz.

 

Mit tanácsoltok?

__________________________________________________

Szerk. 2023.06.21:  További infó ebben a hozzászólásban ...

_________________________________________________

Hozzászólások

Nem látom át a pontos scenario-t, de én pont OpenVPN-el csináltam hasonlót (AD-ból authentikáló user-ekkel és group-okkal) úgy, hogy minden group külön IP tartományt használt, amik egymástól tűzfallal el voltak zárva. Annak viszont semmi akadálya, hogy az Admin group viszont oda legyen engedve minden más tartományhoz.

(részletekbe nem mennék bele mert már régen volt, de tökéletesen működött - illetve szerintem működik azóta is, csak már nem vagyok ott)

"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"

Az adauth modul alatt plug-in-re gondolsz? Csak mert nem ez az egyetlen módszer, lásd: --auth-user-pass-verify paraméter. Egy jól paraméterezett ldapsearch pedig sok mindent meg tud csinálni...
Az IP osztás sem lehetetlen, mert a --client-connect paraméter használatával generálható egyéni konfig, amelyben egy jól elhelyezett ifconfig-push átadhat a kliens felé IP-t is.
Én ezzel felvértezve indulnék a feladat megoldásának.

Már tényleg régen volt (6+ éve), de ha jól emlékszem, pool IP-ket osztottam, csak group auth szerint más-más pool-ból és a pool-okra volt minden tűzfalazva. De először kapott egy quarantine pool-t a client, utána külső, python, vagy php connect script állította be a szükséges paramétereket AD-ból lekérdezett adatok alapján.

"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"

wireguardnal meg lehet adni hogy adott pubkey-hez melyik client ip engedelyezett.

az egyes csoportok kulon wgX-be keruljenek, aztan lehet beallitasni hogy mi merre mehet. a "csodascript"-et meg dobd ki a 'csaba :)

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Már késő, ha egyszer megtörtént a baj, mert az "elfelejtették" a szkript-ben közölni, hogy ha a "Strict Firewall" kérdésre "no" választ adok, attól még lefuttat egy csomó parancsot !

Ugyanakkor a szkript nélkül is próbáltam elsőre beállítani mindenfélét, hogy elinduljon az UI De 3 nap alatt sem sikerült.
Viszont a szkript lefuttatása után egyszer csak működött minden, ahogy kell !

(azóta tovább is fejlesztettem, már lehet y/n/- választani, +1 Webmin portot megadni, stb. csak még nem töltöttem fel a Gitlab-ra.)

Szerkesztve: 2023. 05. 31., sze – 16:04

OpenVPN + auth cert (ez lehet közös is minden usernek) + usernév jelszó páros, mely SQL-ből jön. SQL-ből mehet kliens ip push és megannyi paraméter, amihez php-ban admin panelt lehet írni.

A kliens IP-ket lehet csoportokba rendezni, adminisztrativ /24.../26 subnetek, amire tűzfal hűzható és megvan, hogy ki hova hogyan mehet.

Az OpenVPN igazából svájci bicska, csak egy MacGyver kezében kell legyen.

So-so. Nézőpont kérdése. Azért még is csak van a nagyvilág, aki nem fér hozzá a vpn-hez és van a szűk csoport, akivel szóba áll. És utána jön a név-jelszó ellenőrzés. Szóval azonosítja annyiban, hogy az én kutyám kölyke vagy, eggyel tovább jöhetsz. De hogy melyik, azt nem tudom :) OpenVPN is kliens certként hivatkozik rá és a név-jelszó használata esetén van egy olyan alternatíva, hogy ez lehet közös, de nem kötelező.

Ez oké, de gondoljuk át azt az esetet, hogy a tanúsítvány illetéktelen kezekbe kerül. Ebben az esetben illő cserélni. Ha közös, akkor az összes végponton el kell követni a cserét. Ha egyéni, akkor csak egy helyen kell lecserélni.
Nyilván mint mindennek, úgy ennek is megvan az ára: több tanúsítvány esetén kelleni fog valamiféle tanúsítvány kezelő rendszer.

Annak viszont semmi akadálya, hogy az Admin group viszont oda legyen engedve minden más tartományhoz.

Hát elméletben valóban. Csak azt a 3 hónapot kérném vissza az életemből, amíg az elméletet próbáltam gyakorlatba átültetni.

 

Az OpenVPN igazából svájci bicska, csak egy MacGyver kezében kell legyen.

Egyetértek. Soxor álmodtam az opcióival és ébredtem ezen rémálmokból. Csak a filmekben működik mindez elsőre sajnos.
Feladtam.
Sőt, mára már ha meghallom az OpenVPN szót ... inkább nem is ecsetelem.

 

wireguardnal meg lehet adni hogy adott pubkey-hez melyik client ip engedelyezett. Az egyes csoportok kulon wgX-be keruljenek, aztan lehet beallitasni hogy mi merre mehet ...

Ez bíztató, csak kellene egy olyan UI hozzá amivel több WG interfészt tudok egyszerre kezelni.

 

A korábban említett mellett találtam még kettőt, de abból az egyiket nemrég "befejezték" / lezárolták a további fejlesztését,

a GO-ban írtat pedig egyszerűen nem tudom felrakni úgy Debian 11 alá, hogy működjön.
 (Azt hiszem ez volt az, de szerintem ez sem kezel multi-interface -t.)

A Rackforest-nél csak néhány OS közül lehet választani, amiből aránylag a Debian-t ismerem valamelyest, de annak nem up-to-date a csomagkezelése wireguard-go terén. Elvileg sikerült fel-erőltetnem úgy, hogy build-eltem a legfrissebbet, a libc6-tal együtt, de amikor elindul a GUI, nem találja a wireguard-go parancsot, pedig elvileg hozzáadtam a PATH-hoz.

Esetleg valaki tudna segíteni órabér alapon?

OFF: nem, de ne is említsd! Itt olvastam 2 órája, azt hittem valamilyen "gumiszobás poén topik", és miután rájöttem, hogy ez bizony komoly, úgy lezsibbadt az agyam fél órára, hogy meg sem tudtam egy darabig fogalmazni ezt a topikot!

... amúgy nincs ezen a fórumon egy "Offtopik hozzászólás" gomb?

Szerintem ha elengeded a GUI-t és a mások által írt scripteket, hirtelen minden problémád meg fog oldódni. Ennyi idő alatt, mire belövöd a szükséges függőségeket és kiismered a lelkivilágukat, kb. teljesen kitanulnád az összes lehetőséget parancssorban. Eleve ennyi usert / csoportot úgysem kattintgatva fogsz kezelni, hanem saját scriptekkel adatbázisból / konfigmenedzsmentből. 

Nem mondom, hogy nem érdemes ezeket megnézni tanulási célzattal, meg hogy láss egy működő rendszert mielőtt összerakod a sajátodat, de végleges megoldásnak én nem használnék ilyen ki tudja meddig támogatott cuccokat. Egy ekkora rendszernél úgyis kell érteni, mi történik pontosan (a tunnelben és a két végén, a tűzfalban és a routingban), különben nem tudsz hozzányúlni, ha valami keresztbeáll. 

Eleve érdemes nem a userspace megoldást használni (wireguard-go), bár a sebességére igazából nincs nagyon panasz, mégis a kernelbe épített verzió tisztább, szárazabb, biztonságosabb érzés.

Nagyon szépen köszönöm a bátorító és építő jellegű szavakat!

Hidd el, én is sokat gondolkodtam már ezen, de sajnos az a baj, hogy olyan rendszerre van szükségem, amit könnyen tudok kezelni.
Márpedig a "terminál ablakban listázott" wg show utasítással nehéz átlátni:

  • ki van online,
  • vagy mikor volt utoljára
  • mi az IP címe
  • ... és Ctrl + F -fel hirtelen keresni,
  • kideríteni, mi a soron következő IP cím, amit kiadhatok a köv. kliensnek, akit 5 perc alatt fel kell vennem a csoportba
  • stb.

Mindezt 3-400 kliensnél, többnyire úgy, hogy max 5 másodpercem van a telefonom megcsörrenésétől számítva minderre.
(Az új klienset kivéve.)

Nem tudom, ki mennyire van tisztában POS rendszerek üzemeltetésével, de ahol 10 másodpercenként kell felvenni egy komplett rendelést 10 gépen egyszerre, ott nagyon sokat számítanak a másodpercek. Nem engedhetem meg magamnak, hogy 5-10-30 perceket plömplömöljek 1 feladattal.

A típusfeladatokat automatizálni kell. Akár script, akár bármi. Pláne ha időkritikus a dolog.

Illetve ennyi és ilyen kliensnél én tuti elmennék valami pull alapú automatizáció irányába (pl. Puppet, de tuti van pár amit egyszerűbb összerakni) - már ha lehet.

Illetve nem fogod megúszni az adott VPN megtanulását (és akkor nem lesz kérdés, hogy miért nem probléma, ha egy kliens konfigjában átírják az IP címet).

Hát, azért ez nem egy olyan feladat, amit csak Wireguard-on belül meg tudnál oldani - ehhez szerintem kell a GUI-n kívül egy másik rendszer, ahol a metaadataid vannak (ügyfélID, userID, szerep, végponttípus, IP, pubkey), én legalábbis valószínűleg így csinálnám. Nyilván van egy ügyfélnyilvántartásod / CRM-ed, akár oda is be lehet fűzni. A WG-ben az egyedi azonosító csak a publikus kulcs, más metaadatot nem tudsz a konfigban tárolni. 

Értem, hogy nagyjából mik az igények, de azért ha belegondolsz, innen akarsz továbblépni:

- 1 új csoport + pár kliens generálása, letelepítése, konfigurálása több órás folyamat

- már 400 órám ráment a kulcs-cserékre és csak a felével vagyok meg

Akármit csinálsz, ennél gyorsabb tudsz lenni, feltéve ha a felhasználó partner ebben. Nálam ott szokott elvérezni a dolog, hogy mindenáron el akarják küldeni a privát kulcsot is, márpedig én akkor kukázom a kulcspárat, és újat kérek. A privát kulcs semmilyen módon nem hagyhatja el azt az eszközt, ahol generálódott. Ha egy usernek több eszköze van, mindenhol legyen külön kulcs. Vagy ha több ACL csoporthoz is tartozik, ott is legyen külön kulcspár, ne csak az határozza meg az ACL-t, hogy melyik interfészre (portra) csatlakozik.

Márpedig a "terminál ablakban listázott" wg show utasítással nehéz átlátni:

  • ki van online,
  • vagy mikor volt utoljára
  • mi az IP címe
  • ... és Ctrl + F -fel hirtelen keresni,
  • kideríteni, mi a soron következő IP cím, amit kiadhatok a köv. kliensnek, akit 5 perc alatt fel kell vennem a csoportba
  • stb.

Ezt a listát beledobod egy fzf-be, és mindent kereshetsz. Sorbarendezheted allowed-ips illetve last-handshake oszlop szerint, és akkor láthatod az utolsó konfigolt IP-t az adott csoportban, illetve az utolsó "bejelentkezést" (» stateless). A nehézség valóban annyi, hogy az azonosító csak a pubkey lehet a standard eszközökkel, ezt valami adatbázisban kell tárolnod.

Még az is lehet egyébként, hogy nem is egy közös végpontot kellene csinálnod, hanem szétdobni konténerekre ügyfelek szerint (ha jól értelmeztem a felépítést), ahol mindegyikben lenne egy WG végpont, és ezek között a routing / ACL statikusan mehetne (picit egyszerűbb kezelni), nem a tunnel interfészekre húzva (valójában persze ugyanaz történne). Mondjuk ez a kérdés messzire visz már..

$ wg show all dump 

iface	pubkey		psk	endpoint		allowed-ips	last-handshake	transfer-rx	transfer-tx	pka
===========================================================================================================================
wg0	TsynuF5D...	(none)	184.125.84.123:54015	10.22.67.3/32	1684325599	24389804	64173136	off
wg0	5tSslOEo...	(none)	88.117.118.172:62891	10.22.67.9/32	1684181814	834936244	930146952	off
wg0	sVH8R+W+...	(none)	191.3.68.98:57248	10.22.67.2/32	1685544948	721486072	232404452	off
wg0	/StBpalu...	(none)	184.125.127.25:15197	10.22.67.4/32	1684824143	59748		466968		off
---------------------------------------------------------------------------------------------------------------------------
wg1	3p7cynrA...	(none)	12.165.204.192:59319	10.22.66.5/32	1685084562	62300840	119572028	off
wg1	dlSqwOsJ...	(none)	21.83.68.98:55863	10.22.66.6/32	1684996922	1534036		3551808		off
wg1	4RmC/ysE...	(none)	51.183.227.38:58061	10.22.66.4/32	1684937945	5382824		9733588		off
wg1	5/9KeN8j...	(none)	28.131.74.16:57626	10.22.66.2/32	1685536259	24215684	241923000	off
---------------------------------------------------------------------------------------------------------------------------
wg2	XHlk4u8t...	(none)	94.215.169.34:22037	10.22.65.42/32	1684131704	128004		315756		off
wg2	6DUlH945...	(none)	84.225.129.116:22163	10.22.65.65/32	1684133477	203540		1264460		off
wg2	4PPMqqNj...	(none)	76.177.53.114:58443	10.22.65.55/32	1684142176	1876		316		off
wg2	tLuKWwXw...	(none)	31.61.238.145:49672	10.22.65.43/32	1685548993	169590820	362572200	off
wg2	hEMjR9Y3...	(none)	38.142.1.149:37756	10.22.65.45/32	1685386140	387678196	3617655148	off
wg2	g2rT0XXK...	(none)	42.240.173.131:49675	10.22.65.47/32	1685533484	187259068	87482600	off
wg2	AwtEZ2Xf...	(none)	11.183.171.11:53386	10.22.65.44/32	1685117799	58991052	478024132	off
wg2	cVHz1R29...	(none)	94.225.170.62:22234	10.22.65.56/32	1684131079	321432		1734908		off
wg2	Xm3D+KHc...	(none)	42.203.64.32:63237	10.22.65.50/32	1685107453	154270560	137082928	off
wg2	z8Ok8Tck...	(none)	184.205.169.64:22215	10.22.65.58/32	1684140361	243176		400048		off
wg2	mLIVWTyE...	(none)	162.65.199.134:57489	10.22.65.52/32	1685540153	1647516028	5595093136	off
wg2	dW5QgPVj...	(none)	194.41.162.204:52343	10.22.65.57/32	1685021923	12126844	43001320	off
wg2	4wEr7n9S...	(none)	13.37.164.141:64304	10.22.65.53/32	1685542660	50809920	611341800	off

Ha ekkora cég - kliens számból ítélve - nem lenne jobb egy Sonicwall VPN, Fortinet VPN ?

3-400 kliens meg menedzselhetőség stb..

Nekem több helyen is Sonicwall FW és VPN + AD.

For Whites Only meeting room!

Megnéztem a SonicWall-t. Elsőre nagyon profinak tűnik, de a legkevésbé sem szimpatikusnak, mert:

  • Nem szeretem, hogy nem írják ki az árakat. Ebből már lehet tudni, hogy simán kijön a végén havi 6-12 helyett 120-500ezerre.
    Ergo nem az én költségvetésem. A jelenlegi fizetős ügyfelekből csak pár-10ezer jön össze. Legalább nullszaldóra jó lenne kihozni a belefektetett munkával.
     
  • Szeretem támogatni az opensource projekteket. Tényleg szoktam. És azok többnyire sokkal jobban fejlődnek.
     
  • A fő kliensük már dobta a Win7-et. (Bár a GVC még lehet, hogy támogatja.)
     
  • Senki máshoz nem lehet fordulni, ha valamit nem értek. Nem szeretek minden szupport-óra után 150Eurót fizetni.

De köszönöm szépen, hogy ajánlottad, akár még jó is lehetett volna.

Ha árban kijönnék a fizetősökből, akkor már rég LogmeIn-t, vagy AnyDesk-et, vagy DNS-Wrap-ot használnék. De azok kliensenként elkérnek vagy 5-10 eurót havonta. De amikor áremelés történt, már akkor egy csomóan visszamondták. Es a mostani helyzetben a vendéglátósok helyzete minden csak nem rózsás. Lásd rezsiárak, NTAK...

Sonicwall árazás: ebben tudok segíteni sok fajta megoldás van. VPN lc. 10-20-50-100 csomagokban lehet venni.

Opensource: jó is az, de ez a projekt több idő összereszelni. Ha napi 100e Ft-os rezsi költséggel számolsz nem biztos, hogy meg éri.

Win7: Ezt találtam: SonicWall aláírt tanúsítvány SHA256-ot használ, amely alapértelmezés szerint nem támogatott a Windows 7 rendszeren. KB3033929 update Windows 7 és a Windows Server 2008 R2 rendszerhez.

Support: van magyar cég, akik nagyon segítőkészek.

Előző cégnél, ahol dolgoztam egy nagyobb sonicwall rendszert vettek és kaptunk pár napos oktatást.

Logikus volt, hogy az új cégemnél is azt vezettem be. Azóta kisebb könyvelő/ügyvédi irodáknak is csináltam - mindenki HO-ban akar dolgozni VPN kell !!!

 

NTAK-ban nagyon-nagyon nagy munkám volt ;-)

For Whites Only meeting room!

Sonicwall SSL VPN lic. 3x100 user = 3x720 font - ez nem havi - egy szeri örök lic. hordozható, ha veszel egy új vasat.

100e Ft rezsi = kb. ennyit szoktam számolni naponta költséget vagyis, ha neked kell összerakni vagy megveszed készen. 

Egy ilyen 300-as VPN rendszer:

a.) erős vassal 1.5millió (VPN lic. együtt) = 5000,- Ft / user

b.) gyengébb vas 1.2millió (VPN lic. együtt) = 4000,- Ft / user. 

c.) HA (high availability) kialakítás - mert ugye szolgáltatásról beszélünk, a HA vasat 50%-os áron adja a SonicWall 

 

Nem a VPS havi díjára gondoltam, valakinek meg is kell csinálni - a reszelésre mennyi idő fog elmenni? A kapott eredmény/teljesítmény/szolgáltatás az elvárt lesz?

kieg:

- VPN router oldal konfig össze lehet kattingatni 1 óra alatt (ha már meg van a cert és AD-ban,  LDAP-ban vagy radius szerveren a felhasználók - de van local user felvitelre is lehetőség).

A kliens oldal telepítése:

- megadod a VPN router elérhetőségét - kap egy jelszó és magának telepítni windowsra (next-next finish).

For Whites Only meeting room!

nemtom hogy mennyi a profit - pizzás cégnet nem könyvelünk.

De egy pizza:  2800 - 3800,-  Ft

VPN beugró: egyszeri 10,000,- Ft  és havi 1000,- Ft

Ez egy nagyon szerény kalkuláció - 3 kg sajt és 30dkg havi sajt adag.

Ezzel már rentábilis lenne szerényen.

For Whites Only meeting room!

Üdv!

Én nem vagyok nagy UI-s, fiatal korom ellenére úgy adódott, hogy nagyon sokat csalódtam ezekben, így én most az én terminál scenario-mat fogom leírni, én mit tennék mint megoldás a problémára.

"ki van online,
vagy mikor volt utoljára"
A WG alapvetően egy stateless VPN protokoll. Ez azt jelenti, hogy csak abból tutod belőni az online létét, mikor volt KeepAlive packet-je (ha állítasz ilyet kliens oldalon), vagy adott IP mikor küldött forgalmat utoljára (tűzfal, de minden kliensnek kéne szabály és amúgy sem hiszem, hogy ez lenne az optimális megoldás).

"mi az IP címe
... és Ctrl + F -fel hirtelen keresni,"
Én ilyen célra saját megoldást írnék. Épkézláb elérhetőt még nem találtam (persze ettől még létezhet). Mindenképp valamilyen adatbázisban tárolnám a felhasználókat és az adataikat (mivel relációs adatbázishoz értek rutin szinten, MariaDB-ben).
Ehhez csinálnék egy Python klienst amivel el lehet látni a feladatot shell-ből, vagy hozzádobnék egy Flask webszervert (ugyancsak azért így, mert ezzel van tapasztalatom).
"kideríteni, mi a soron következő IP cím, amit kiadhatok a köv. kliensnek, akit 5 perc alatt fel kell vennem a csoportba
stb."
Emiatt adatbázisoznék, mert az ilyen infókat így marha könnyű lenne kiszedni. Aztán klienssel lehetne szűrni később arra is az IP meg a csoport (WG IF) alapján, mikor volt online. Saját programmal QR-kóddal a profilfeltöltés is gyerekjáték. Illetve így a kritikus sebességfaktor is leküzdhető lenne.

Ja igen, mivel ez egy L3 VPN, emiatt tűzfalazni (forward chain) annyit legalább kell, hogy a CIDDR-ek amiket ráraksz az IF-ekre, azon belül lássák egymást a kliensek. A végére meg egy explicit drop és akkor nem látnak át se egymáshoz, sem a netre. Felülre meg a mindent elérős src IP-vel kell egy szabály ami mehet kb. mindenhová. Az internetelérést külön korlátozni nem kell, kliens oldalon ne routold bele a 0.0.0.0/0-t, csak a CIDDR-t amit el kell érjen, ne engedd ki a tűzfalon (ezt írtam kicsivel ezelőtt) és IPv4-nél jellemzően NAT-olás sem kell. Így biztos nem tudnak kimenni:D

A WG-ben AllowedIPs kitétellel szerver oldalon - ahogy más is írta - összekötheted a kulcs-IP párokat, tehát nem tudják ellopni más címét.

Amit én még mindenképp átgondolnék, egy csoport mérete. Eddig én még egy IP-címet / interfész adtam WG-nek, ha ez egy /24, akkor 253 kliens férne el (254, mert nincs broadcast, de nem tudom, a cím használható-e így és nem okoz-e problémát). Nagyob ciddr-rel persze ez a szám egyszerűen növelhető.

Érdekes, amit leírtál, viszont amiatt, hogy a WG előnye az egyszerűsége, az ilyen összetettebb scenario-kat nem támogatja by default (külső DB, címtár etc.) és mint írtam, épkézláb out-of-the-box eszközt sem találtam, már persze ingyenesen.

Fixme, ha hülyeséget írtam:D

TheAdam

@Mindenki:

Nagyon nagyon nagyon szépen köszönöm a hosszú és részletes válaszokat, ötleteket, tanácsokat!!!

Nem is tudtam, hogy ennyire klassz közösség van itt :-)

Külön-külön válaszok helyett megpróbálom összefoglalni:

  1. Tetszene, ha meg tudnám / tudnánk oldani Wireguard-dal. Esetleg jelentkező? ;-) ...
     
  2. Én is jobban örülnék, ha nem egyetlen wg0 interface volna, hanem kliensenként szétbontanánk, mert ha valamelyik csoport sérül, az nem akkor nagy veszteség, mintha mindet újra kellene csinálni.
     
  3. Szerintem 100+ konténer kezelése több macera, mint előny.
    Ahogyan olvasgattam eddig a témában, a docker-ek kezelése csak +1 réteg, nem okvetlenül előny, ha ugyanolyanokat kell menedzselni. Több a hibalehetőség, nehézkesebb a kezelés, konfigolás.
     
  4. Mivel minden csoportban tipikusan csak 1-2 max5-8 kliens van, a csoport-létrehozást valóban célszerű lenne automatizálni.
     
  5. Szeretem a biztonságot, de látva azt, hogy az ügyfeleim milyen magasról tesznek rá, nem tartom szükségesnek, hogy "military grade" tűzfal rendszerrel és csillió $ üzleti megoldásokat erőltessek.
     
  6. Nem kell "CRM" és "adatbázis" és hasonló naaaagy dolgokban gondolkodni!
    Most is csak 1 sor áll rendelkezésemre a jelenlegi OpenVPN szerverhez írt 20 éves PHP szkript révén,
    és a teszt-szerveremen is elegendő, ha a kulcs nevét jól határozom meg. Pl.:
     
    10.11.33.2  2023.05.31 19:37:22   BestPizza-Kukunyimfalva-PutosGep-Dellxxxx_Win732-2014.04
    10.11.33.3  2023.05.31 19:37:29   BestPizza-Kukunyimfalva-FutarGep-HPyyyy_Win732-2019.05

    Ez is bőven megteszi
     

  7. Nem fogom túllépni a 250-es méretet.
    Egymagam 100 ügyfélnél többet nem tudok lekezelni, ahogy jön 1-2 új, úgy tűnnek el a régiek.
    +Nem fogok már további 30 évig élni, 48 vagyok.
     
  8. Én azért nem dobnám ki az összes UI-t rögtön. Szerintem van 1-2 ígéretes.
     (Csak kellene egy kis segítség a telepítésükhöz...)

    Illetve ha van olyan lelkes ember, aki szerint érdemes ehhez valamit fejleszteni, szerintem egyszerűbb, ha az egyik meglévőhöz tennénk hozzá +1 oszlopot, vagy írnánk át kicsit, hogy több-wg-adaptert kezeljen, mintsem nulláról nekiállni egy "klónnak".

Nekem minderre (UI fejlesztés, multi-wg-firewall-config, automatizálási szkript-ek) garantáltan nem lenne elég kapacitásom, tehát:

  • vagy kérnék szépen (fizetős) segítséget tőletek,
  • vagy valami olyan megoldást, ami készen lefedi ezeket az egyszerűsített igényeimet és nem kerül többe 10-20ezernél havonta.

Nekem ez egy openvpn + ldap feladatnak tűnik és a UI-odat ha nagyon muszáj akkor egy LDAP browser adja neked.
Ez már nem az otthoni bütykörészős kattintós ui kategória.
Persze wireguard + ldap-pal is meg lehet csinálni valszeg.

Találtam egy ilyet, de nem ismerem : https://github.com/h44z/wg-portal
Vagy nekiállsz scriptelni.

Azonkívül eszembe jutott a pfsense firewall, annak is van openvpn meg wireguard modulja is. 
 

Gábriel Ákos

Wow! Köszönöm! Ez a WG-PORTAL eddig valahogy nem jött szembe, nagyon ígéretesnek tűnik!

És a "docker"-es példa szerint elvileg több wg0 wg1 ... ? adaptert is kezel.

A pfsence tűzfalazásnak utána kell néznem.

Eddig a Webmin tűzfalat használtam csak. Kipróblátam nemrég a firewalld -t, ami 10 másodperc alatt teljesen kizárt a rendszeremből, fél nap volt visszajutnom. :-(
Kicsit félek már a Linux tűzfal progiktól...

Neked kell majd támogatnod a 100+ klienst is ?

akkor tényleg nem próbálkoznék saját megoldással..

For Whites Only meeting room!

OFF: Nem csak "majd" ... hanem már 22 éve ezt csinálom. Hétfőtől vasárnapig a lehető leglehetetlenebb időkben is képesek hívni ha baj van, vagy ha egyszerűen neki pont pünkösdkor vagy szenteste 20 órakor jut eszébe valami... :-( Nem is részletezem!

Emellett programozok (Delphi + SQL + Lazarus + JS + C# + ... ), cég-vezetek, könyvelést ellenőrzök, gépeket telepítek, számlázok, pénz-behajtok, hibákat hárítok, adatbázisokat mentek, az okosotthonomat próbálom helyrerakni (miután 2 éve egy száraz-villám kinyírta az egész házat... )

  • és napi 4.5 órát alszom.

Meg persze NTAK-ozok. Másfél éve. Minden nap. Köszönjük neked O.V. !

  • Egy hete pedig megjelent egy salátatörvény arról, hogy az "ingyenesen letölthető éttermi program", amit állami pénzen fejlesztettek és már most többet tud, mint a legtöbbünk progija, majd kiválthatja a pénztárgépeket ! Hurrá !!! Senki sem akarja majd innentől a 22 évnyi fejlesztésemet megvásárolni. Jeeee ....

Ez a VPN-ezős, Linux-tűzfal-kizárós tortúra hiányzott még az életemből, de nagyon :-(

Ezért is vagyok nagyon hálás mindazoknak, akik itt most segítenek megoldást találni !!!

ilyen méretben még nem használtam a softethert, de ha a sajat kliensét használod, akkor szvsz 1 pipát kell betenni, hogy ne menjen minden kommunikáció a vpn felé.

az advanced részben van olyan, hogy "no adjustements routing table", akkor nem ad hozzá default gw -t.

HUP te Zsiga !

Köszönöm, ez önmagában jó hír lenne, (bár én úgy emlékszem, hogy az is be volt pipálva ... sőt még egy csomó speciális opció is,) de sajnos addig nem fogom tudni használni a SoftEther-t, amíg át nem írja valaki a belső multithread-es DHCP részét úgy, hogy lehessen fix IPket kiosztani a klienseknek.

Persze az ottani fórumon javasoltak olyanokat, hogy:

  • Tiltsam le a SE. beépített DHCP-jét
  • Telepítsek a Linux-ra egy sajátot
  • menedzseljem azt külön úgy, hogy generáljak előre MAC address-eket és hozzájuk tartozó IP-ket
  • stb.

Mondanom sem kell, hogy mennyire átláthatatlan, macerás megoldás.

Egyszerűen SE nem arra van kitalálva, hogy "corporate" módon viselkedjen.

Plusz kb 2-3x több az erőforrás igénye, mint az OpenVPN-nek és kb 250 kliens felett elkezd drasztikusan belassulni.
Vannak mérési eredmények, de meg kellene újra keresnem a sokezres fórumoldalaik között.
(Továbbá ahhoz már egy csomó mag kell és memória, ha egyszerre használná mindenki full sebességen.
Mondjuk ez nálam nem szempont, mert max 20 ember dolgozik rajta egyszerre VNC-vel és néhány pár bájtos adatbázis művelet futna csak.
Anno kipróbáltam, és egy Gigás fájl másolása két gép között úgy emlékszem 15-20%-át foglalta le 1 magnak.)

Szerintem mindenképpen jobban jársz a külön DHCP szerverrel.
Írtad, hogy programozol. Tedd az egyes kliensek adatait MAC, IP, név ... egy text fájlba és pici triviális programmal tudsz generálni egy include fájlt a dhcp.conf-hoz.

Ha kellenek egyéb DHCP paraméterek (time szerver ...) akkor azt is tudod állítani egy komolyabb DHCP szerveren.

Sokkal bonyolultabb a struktúrája de tudod ugyanígy generálni a SE vpn_server.config fájlját is ugyanebből. Egyszer összekattintgatod a policy-t és utána abból generálod az összes többi usernek.

Azt, hogy a lokális forgalmat ne zavarja át a VPN-en én úgy oldottam meg, hogy a VPN interface költségét (más helyen distance vagy metric) a manuálisan nagyobbra állítottam mint a fizikai ethernetet így ha van két route is a másik IP felé a kisebb súlyút fogja használni.
Windowson elvileg lehet a DHCP szerveren keresztül is állítani (https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-dhcpe/…). Soha nem próbáltam és úgy tűnik a netes kérdésekből, hogy van akinek nem ment.

A teljesítmény problémához nem tudok szólni soha nem mértem. Nekem 50 körüli user használja távoli asztalra és nem nagyon sírnak.
Olyat már láttam logban, hogy deus ex machina egy csomó embernek (talán mindenkinek) lebontotta a kapcsolatát és a kliensek szépen egymás után visszaépítették - nem tudtam semmihez kötni, hogy miért.

Jó hír! Sikerült felraknom a wg-portal -t! 5x annyit tud, mint a másik UI.
 (32 Giga felmásol, .env fájl beállít, service elindít, kész. :-) )
Ez a leírás nagyon klassz és sokat segített: https://github.com/h44z/wg-portal/blob/master/README-RASPBERRYPI.md

Vélemény:

  • Kezel több interface-t !!
  • ezeket el is tudom külön nevezni, és a tetején van egy lenyíló listbox, amiből ki tudom választani.
     
  • Tudok több usert létrehozni. (és talán még 1-1 csoporthoz is rendelni, így esetleg a tulajok ráláthatnak majd a saját gépeikre)
  • Van a tetején egy filterező. (Bár nálam nem lesznek olyan sokan 1-1 csoportban, szóval nincs sok értelme.)
  • listában sorolja fel a klienseket, így több elfér és jobban átlátható
  • Előre lehet "default"-ot beállítani a klienshez, így generáláskor nem kell mindent újra kitölteni.
  • A jövőben akár API-n keresztül is elérhetem, írhatok rá saját alkalmazást, ha a webes interface esetleg nem tetszik.
  • ... és még jópár hasznos apróság.

Ami így elsőre nem tetszik:  (de talán némi adománnyal majd változtatnak rajta)

  • ha már nincs "online", azaz nem csak pár másodperce volt utoljára handshake, akkor a pontos "last seen" idő=dátum helyett csak annyit ír, hogy "a while ago"
  • a csoportválasztó listában nem lehet keresni.
  • nem lehet eltűntetni a "key" oszlopot. Teljesen felesleges. Az email cím is.
  • csak local-binding-gal tudtam megnyitni az oldalt, azaz ha DOS ablakból be-SSH-ztam és manuálisan begépeltem a root jelszót.
    A webmin WebTunnel-jén keresztül nem működik, mert ezt a hibát dobja:

Amiben továbbra is segítségre lenne szükségem:

  1. Linux tűzfal konfigurálgatás, lehetőleg olyan modullal, ami Webmin alól is elérhető, azaz átlátható.
  2. interface-ek közötti rútolás. (Mester - szolgák csoportja között)

Jól gondolom, hogy minden WG interfészhez 1-1 külön portot rendeljek?

JOB:

Tudna valaki írni egy kis-szkriptet debian alá, ami egyben legenerál 100 interface-t?
 

wg001 10.11.1.0/24 port 50001

wg002 10.11.2.0/24 port 50002

... és beállítani a tűzfalat Webmin alól?

 

  • Adnék hozzáférést a szerverhez,
  • megmondja mibe kerül,
  • és 1-2 óra alatt megcsinálná.

(Egy kicsit most katyvaszosak a tűzfal beállítások, mert úgy tűnik, egyszerre van jelen iptable és iptable-legacy is.
Tőlem lehetne törölni az egészet, és akár teljesen mást felrakni.)

Köszönöm :-)

 ... igazad van, végülis ez csak egy "szöveges generálás", tehát akár:

  • excelben is megcsinálhatom,
  • notepad++ -ba átmásolom,
  • .sh -ra átnevezem, fel-FTP-zem és 1x lefuttatom.

De a tűzfal mizériára tényleg jó lenne, ha valaki segítene :-( Egyedül nem fog szerintem menni.

Ha a mastergeoup interface neve kitüntetett és a többi interface neve illeszkedik mondjuk a wg* mintára, akkor csinálhatsz olyat is, hogy
iptables -A FORWARD -i masterwg -o wg* -j ACCEPT
iptables -A FORWARD -i wg* -o masterwg -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i wg* -o masterwg -j DROP
iptables -A FORWARD -i wg* -o wg* -j DROP

Az első szabály a mastergroup-bó enged ki bármelyik klienshez.
A második szabály visszaengedi a válasz csomagokat a kliensektől.
A harmadik szabály eldobja az összes többi, klienstől érkező és a mastergroup felé menő csomagot.
A negyedik szabály a kliensek egymás közötti forgalmát tiltja.

A DROP helyett használhatsz REJECT-et is, a forgalom akkor se fog bejönni, de akkor visszamegy egy icmp nem nyert üzenet, így nem kell kivárni a time out-ot a másik oldalon.
A szabályok azon alapulnak, hogy az iptables tud wildcardot kezelni az interface névben, így egy szabállyal egyben kezelhetőek a csoportok interface-ei.

Köszönöm szépen !

 Nem tudtam eddig, hogy LEHET használni debian alatt wirdcard-okat tűzfal szabályokhoz. Klassz :-)

Ez sok mindent leegyszerűsít.

 

Csak előbb tényleg rendbe kellene tenni az egész iptable-legacy / nft kérdéskört, mert most úgy tűnik 2 fajta tűzfalam fut egyszerre, és ütik egymást.

Rákerestem a "legacy" szóra a Webmin ticket-jei között és találtam egy érdekeset, ezért írtam is gyorsan nekik, hátha mondanak valami okosat rá:

https://github.com/webmin/webmin/issues/1603#issuecomment-1572135087

(Bár valószínűbb, hogy elkönyvelnek, mint hozzá nem értőt, és nem is fogják keresni a lehetőségét, hogy hasonló hibák megelőzhetőek legyenek...)

 

Egyébként szerintem még kellhet egy olyan iptables szabály is, hogy NE engedje az klienseket csatlakozást indítani az én irányomba.
(Nehogy valamelyik futárgépről egy "ügyes" emberke átvegye az irányítást a fejlesztői gépeim felett...)

Bár akkor meg valószínűleg az SQL event-ek nem fognak megérkezni a programomba a 3051-es porton, ha csatlakozok egy távoli adatbázishoz.

Csak előbb tényleg rendbe kellene tenni az egész iptable-legacy / nft kérdéskört, mert most úgy tűnik 2 fajta tűzfalam fut egyszerre, és ütik egymást.

egy rövidke google keresés rég segítet volna, látom angolal nincs gond.

WARNING: nftables is the default firewall framework since Debian 10 Buster. This page is outdated. https://wiki.debian.org/DebianFirewall

Már rég óta nft a keretrendszer linux tűzfalhoz. (a tűzfal "netfilter" a kernelben van) https://wiki.debian.org/nftables

iptables felejtős, ne használd már.

Sajnos ha magad akarod a VPN szervert üzemeltetni nft/netfiler alapokat és adott VPN szervert alapokat meg kell tanulni.

Ha összekattingatós (Delphi/VB szintű) keretre vágysz, akkor ha van, lehet meg kell venni. De akkor ott a veszélye, hogy nincs minden vagy rendesen implemetálva úgy mint nft-re vagy wg-re nézve. És akkor lesznek a csodák, meg kizárások.

Bár iptables nft váltás is tud okozni eleinte érdekes dolgokat. Kicsit más a megközelítés.

Nagyon "vicces", amit írsz, mert pontosan EZ a link az, ami elindított a lejtőn!

- a Webmin konfigurált valamit,

- a wireguard auto-install szkript változtatott valamit

- utána megpróbáltam a javaslat alapján nft-re váltani

éééés már kész is volt a baj.

 

Ha elolvasod a teljes topikot a fenti linken, akkor neked mi jön le ebből?

 - mert szerintem a Webmin az, ami még mindig a legacy-t visszakapcsolja, mivel nem írták át a kódjukat Debian 10+ -os nft -re.

Ha elolvasod a teljes topikot a fenti linken, akkor neked mi jön le ebből?

 - mert szerintem a Webmin az, ami még mindig a legacy-t visszakapcsolja, mivel nem írták át a kódjukat Debian 10+ -os nft -re.

Sajna csak ismételni tudom magamat:

Ha összekattingatós (Delphi/VB szintű) keretre vágysz, akkor ha van, lehet meg kell venni. De akkor ott a veszélye, hogy nincs minden vagy rendesen implemetálva úgy mint nft-re vagy wg-re nézve. És akkor lesznek a csodák, meg kizárások.

Az éppen aktuálisan használt segédeszköz által betöltött szabály listát ki kell listázni/elemezni, hogy tudd mit csinált/mi romlott el.

Minden alkalommal amíg jó nem lesz.

Az ingyenes, hobbyból vagy csak pár ember által írt segédezközöknél még inkább fenn áll a veszélye, hogy nem lesz kerek.

Persze a kernel (netfilter és wg)-nél is előfordulhat, de ez van.

Biztos hogy a csillag is működik?

[!] --in-interface -i input name[+]
                                network interface name ([+] for wildcard)

Régen nem próbáltam, de nekem az rémlik hogy ilyenkor vagy csak `wg*` megy át és olyan interface nincs, vagy ha van `wg`-vel kezdődő file az aktuális könyvtárban akkor annak/azoknak a nevei helyettesítődnek be még a shellben.

Köszönöm a korrekciót, valóban a + a wildcard. De ami a lényegen nem változtat: van wildcard és így kellemesen könnyen kezelhető az összes csoport közös szabállyal, nem kell minden csoportra külön szabály, ami egyfelől gyorsítja a feldolgozást, másrészt elejét veszi az olyan problémáknak, hogy jaj, a 22. csoport kimaradt - illetve igazából egy új csoport megjelenésekor elegendő az interface névkonvenció betartása és a csoport létrehozásakor automatikusan a megfelelő szabályok érvényesek lesznek rá is.

HELP ! Kizártam magam a rendszeremből.

Valamilyen loop keletkezhetett, mert ha konzolosan megpróbálok pingelni valamit, azt mondja:

From 10.11.1.1 (10.11.1.1) Destination host unreachable.

és ha kiadok egy:

ip route list table all

0.0.0.0/1 dev wg3 scope link
...

 

Hiában adok ki neki parancsot, hogy:

wg-quick down wg3

aki 2023ban openvpnt ajanl az remelem nem informatikaban dolgozik, hanem a foldeken kapal.

Én is utálom, félre ne érts. De amíg nem működik mert nem érti addig mindegy melyikkel nem működik. Amikor meg működik akkor meg triviális átállni openvpn-ről wireguardra, akkor meg azért "mindegy". Persze "end-of-the-day" jobban jár ha eleve wireguarddal kezd mert a végén az lesz a szakmailag korrekt megoldás.

Gábriel Ákos

OFF:

 Nem akarom, hogy átmenjen ez a topik sárdobálásba, ezért az első kijelentésedre szándékosan nem reagáltam.

De azért arra kíváncsi lennék, a hazai lakosság hány százaléka rendelkezik mindazzal a tudással, melyet az elmúlt 34 évben informatikai téren szereztem.

  • általános iskola 7. osztály, Amiga500-on számlázó program írás -tól kezdve
  • elsők között neteztem az országban a BIX hálózatára kötött bérelt vonalon, még a betárcsázós modemek terjedése előtt
  • több évig egy 26 telephelyes, 1000+ iT eszközös egészségügyi gigacég informatikai igazgatójaként dolgoztam
  • és a vendéglátói informatika 22 éve, ami egy hobbiból nőtte ki magát ...

Úgy gondolom a "nem ért hozzá" meglehetősen erős, mert a legtöbb ember azt sem tudja, mi az a /24 , NAT, route, "ip a" , reg key, ssh, SFTP, VPN, CCD, port forward, bind, MTU, AES-256-GCM, ip6, ssl, keygen, keychange, mqtt, sql-auth, ... meg úgy kb felsorolhatnám a fél wiki-t ...

Aminek a legtöbbjék nemcsak értem, de kódszinten belemélyedtem!
Azaz szeretem kitanulni "mi történik a motorháztető alatt", olyan szintig, hogy volt, amikor saját webszervert írtam bele a programomba, miután lépésről lépésre megnéztem, hogyan működik egy.

___

A wireguard esetében csak annyi történt, hogy:

  1. kipróbáltam 1 klienst, amit bekonfigoltam, és MŰKÖDÖTT !
  2. Elkezdtem felvenni egy másodikat, de a laptop deformált mini-entere véletlenül leütődött a shift megnyomásakor.
  3. Ekkor az UI elmentett valami félig kész kitöltés, valószínűleg belerakva valami "default" 0.0.0.0 -át
  4. Amit a WG be-routolt pár másodperccel később,
  5. .... ééééééééééééééééééés már ki is záródtam a rendszeremből.

Ha nem "értésnek számít" az, hogy nem néztem át egy számomra új rendszer teljes forráskódját számomra idegen programnyelven 1 nap alatt, hogy lássam:

  • nincs benne SEMMI VÉDELEM ami megakadályozná a véletlenül félig kitöltött kliensek önmagukra-routolását,

nos, akkor valóban én voltam a hibás.

<OFF>: Nem, nem tartom magamat "janinak". Nagyon sok mindent nem tudok még.

És akkoriban még nem voltak "internet szolgáltatók", tehát azok a szakik jöttek kiépíteni a bérelt vonalat (ami közvetlenül a BIX-re csatlakozott) akik a BIX-et is csinálták anno. Ők mondták így. Lehet, hogy kicsit vetítettek... én pedig fiatal szűz fiú voltam a hálózatok terén ;-)

ne értsd félre. Hiába vagy 34 évben a pályán, te sem érthetsz mindenhez is. Ma már nem az a világ van amiben az informatikus az az ember, aki mindenhez ért, ami számítógép. Ennek 20 éve leáldozott.

Nyilvánvalóan nem értesz hozzá olyan szinten, mint ami a probléma megoldásához kellene, mert ha értenél, akkor nem lenne itt ez a fórum topic.

Én speciel 15 évesen írtam assembly kódot amigára (blitter és copper programozás), de ezt most a hajamra kenhetem. A 90-es évek közepén gophert (is) használtam a bérelt vonalon, mert akkor még nem volt http protokoll (vagy legalábbis nem igazán volt elterjedt), és az első linux szerveremet is egy bizonyos finn ftp szerverről letöltött csomagokból raktam össze.

Ezek ellenére, ha VPN konfigurálásról van szó akkor az aki 10 éve még a csattogós lepkét tolta, de egy éve csak vpn szervereket telepít, az simán túltesz rajtam vpn témakörben. És még sok hasonló dolog van, amihez lövésem nincs a 30+ évnyi IT tapasztalatom ellenére. (CIO nem voltam, de bocs, no offense, az nem IT, hanem közgazdász meló. :))

Érdemes félretenni néha a "biztosneménvagyokahülyeezeréveűzömaszakmát" hozzáállást, mert magamon tapasztalom, hogy az esetek jó részében bizony, de.

"Hiába vagy 34 évben a pályán, te sem érthetsz mindenhez is. Ma már nem az a világ van amiben az informatikus az az ember, aki mindenhez ért, ami számítógép. Ennek 20 éve leáldozott."

Ez nagyon így van.

Szerintem: jobb ha az embernek "széles" a tudásanyaga mint "mély". Tudja a dolgokat hova tenni, tudjon rendszerezni, legyenek meg azok az alapfogalmai amire a specializációt építeni tudja. Legyen képes gyorsan, sokat tanulni, a részleteket gyorsan megtalálni. Én azt gondolom pont ezt a képességet adja meg a felsőoktatás ha jó. Nem a Go nyelv vagy a SpringBoot 67. objektumának a 423. paramétere a lényeg, azt majd megtanulja, kikeresi ("adj egy könyvet a hétvégére, jövő hétre tudni fogom"). 

Vagy most itt a ChatGPT, ha vakon vagy simán átver egy csomószor. Ha visszakérdezel, kijavítod akkor továbbvisz. Adott esetben sokkal gyorsabban célt érsz mint google-el. De ehhez az elméleti alapoknak és a kritikuk gondolkodásnak meg kell lennie.

Gábriel Ákos

oké, a szakmai kérdés: Wireguard alapon bármi tud RADIUS-al authentikálni, vagy bármilyen módon authentikálni windows AD-NPS környezetben?

Vagy, így 2023-ban mivel illik megoldani a hagyományos "terepen dolgozik, de el kell érni a backoffice erőforrást" problémát? Lehetőleg úgy, hogy ne kelljen miatta még egy authorizáció forrást üzemeltetni, vagy taknyolni api illesztésekkel.

+1

Sosem értettem hogy miért ajánlgatja mindenki a Wireguard-ot pl on prem enterprise környezethez (igen tudom itt most a topic nem ilyen) valami normális RAS VPN megoldás (akár OpenVPN) helyett.

Nem tud sem routeot pusholni a kliensre, sem ip-t osztani automatikusan (Radiusból), nem tud AD-ból/Radiusból autholni, nem tud MFA-t, nem tud TPM-ből kliens cert authot és még sorolhatnám mit nem tud.

Lehet hogy vannak erre körbetaknyolt "cloud only" megoldások, de az sok helyen nem opció.

Megvan a helye a Wireguard-nak de ez az agyatlan ajánlgatás mindenre is elég vicces.

Ugyanez az IPSEC rant is. Hiába csodálatos a Wireguard, ha az enterprise gyártóknál az egyetlen interoperábilis s2s vpn opció az IPSEC.

Vagy mondjon valaki egy megoldást egy Palo Alto és egy FortiGate vs Juniper SRX vs Cisco FTD tűzfal összekötésére.

Engem tényleg érdekel, hogy van -e ilyen. Most pfsense+openvpn alapon nagyjából pár perc alatt megoldható N darab AD user vpn beléptetése, és szabályozása ki mikor merre meddig vpn-ezik.

Ugyanez valami 2023 konform  megoldással abszolválható? Lehetőleg úgy, hogy ne kelljen userenként 18 dollárt havonta perkálni?

(Ez a "minden-as-a-service" meg különösen idegesít.. Itt csak 15 dollár, ott csak 5 euró, és azt veszi észre az ember, hogy emberenként 100k+ Ft a havi rezsi, és ebben nincs benne vas, meg energia, csak szoftver, de ez már nagyon off...)

Abban igazat adok hogy észnél kell lenni a SaaS vásárlásoknál de abban nincs igazad hogy "nincs benne vas meg nincs benne energia".
Pont hogy van benne az is, csak nem nálad. Sőt a maintenance se nálad van hanem azt is kifizetted. Meg a backupot meg az auditot, meg a DR-t.

 

Gábriel Ákos

... úgy értettem a vasat, hogy erre jön még rá a céges laptop, a céges teló, az energia alatt meg az iroda áram és fűtésköltsége értendő.

Nyilvén kevesebb energia és munka költségem van, ha nem onprem-en futnak azok a szerverek, amik a szolgáltatásaimat biztosítják, de nem feltétlen jövök ki olcsóbbra, és lehet, hogy nincs is szükségem arra a szintű redundanciára és megbízhatóságra amit az akármi-as-a-service biztosít.

Ez így van. Sőt, egy csomó megvett SaaS amúgy on-prem annyira keveset fogyaszt(ana) hogy pont nulla a pluszköltsége.
Például nekem ha már van a hostingban egy bérelt vasam az hogy azon elfut még egy gitlab vagy bitwarden server az hw és energia szempontból pont nulla plusz költség.
Munka szempontjából persze nem.

Van egy olyan mondásom már régebb óta hogy a nagyon picinek meg az elég nagynak érdemes "cloudoznia" meg SaaS-t vásárolnia, van egy elég széles középréteg aki jobban jár ha on-prem vagy IaaS vásárlással megoldja. 

Gábriel Ákos

Hadd kérdezzek vissza (tényleg érdekel, nem kötözködés): SSH kulcsos központi authentikációt hogyan oldasz meg RADIUS-sal, AD-val biztonságosan?

Mert a feladat itt is kb. ugyanaz: privát kulcs nem hagyhatja el a kliensgépet, a szervereken ne kelljen egyesével konfigurálni a publikus kulcsokat, hanem vegye valami központi címtárból, jogosultsághoz kötötten. Erre van megoldás?

Gőzöm sincs, mert csak néha kell vpn-el foglalkozni. Ahol kellett, ott az is elég, ha kézzel legenerálja a kulcsot az ember, és ha a konfig már a helyén van, onnantól kezdve működik a dolog, mert RADIUS-on keresztül pl. usernév+jelszó alapon már megy az AD authentikáció és authorizáció.

Ha ez így wireguard alapon is menne, akkor az a legtöbb helyen már okés.

Egyébként úgy rémlik, hogy ipsec alapon lehet AD klienseknél auto enroll-t csinálni, és akkor nem kell kézzel tanusítványokat közlekedtetni.

AD +sssd +authorized_keys integráció példa:

https://blog.ndk.name/linux-ssh-authentication-against-active-directory…

Az SSH kulcs privát része meg vagy TPM-ből:

https://blog.ledger.com/ssh-with-tpm/

Vagy valami FIDO2 compatible cuccból:

https://developers.yubico.com/SSH/Securing_SSH_with_FIDO2.html

Mert a feladat itt is kb. ugyanaz: privát kulcs nem hagyhatja el a kliensgépet, a szervereken ne kelljen egyesével konfigurálni a publikus kulcsokat, hanem vegye valami központi címtárból, jogosultsághoz kötötten. Erre van megoldás?

Én ezt a melót ansible playbookal csinálom. A címtár ebben az esetben az inventory.yml.

wireguard fole neked kell ezt osszerakni, ugyanis a wireguard direkt egy nagyon pici, minimalis dolog. ezert is szuletett meg a tailscale, es ezert tud a ceg mukodni.

tailscale tud AD-bol authentikalni (meg csomo masik SSObol is), aztan majd o managelgeti neked a keyeket.

+1

 

En sem ertem, miert kene a felsoroltakat tudni egy VPN-nek.... Egy VPN az esetek 99%-aban egy tuzfalon vagy egy routeren fut. Ezek pedig a kerdezo altal felsoroltakat mind tudjak. Nekem pont az a velemenyem, hogy az openvpn es tarsai tulírt, bloat cuccok, ahol az "egyszeruseg neveben" belepakolnak mindent, olyat is, amire amugy abszolut nincs szukseg.

Egyaltalan nem mind1... ha pl neked egy full "tiszta" (mint egy patch kabel) VPN alagut kell mondjuk ket tuzfal kozott egy MPLS/IPVPN vonalon belul, akkor minek a sok plusz cucc? 

Minek implementalni pontosan ugyanazt, amikor az esetek 99%-aban ott lesz mellette az adott feature? (mert router vagy valami tuzfal)

Ha nekem az a fontos, hogy legyen egy feature, akkor engem nem feltétlenül érdekel, hogy melyik része implementálja, így hát tök mindegy.

Ha meg egy alap minimál feature az elvárást, akkor meg nyilván kiválasztok egy olyat, ami erre a célra a legoptimálisabb (tehát nincs tele minden más feature-el is.).

Nem tudok jobb szót rá továbbra sem, mint a svájci bicska. Azzal, hogy az authentikáció során szerveren egy scriptet tudsz neki adni és annak visszatérési értéke szerint engedi vagy nem engedi be a usert, nagy lehetőséget (és veszélyt) ad a rendszergazda kezébe.

Ha akarom, a legvadabb feltétel rendszereket tudom felsoroltatni az auth scriptbe, ami alapján beengedem a dolgozót. Az AD, LDAP alap. Olyan is számításba jöhet, hogy pl. szabadságát tölti a céges naptár szerint vagy idegen MAC addressről jönne vagy meghatározott public IP tartományból, országból jönne akkor nem engedem be. Hardveres vagy szoftveres tokent tudok társítani a felhasználóhoz. Vagy akkor VPNezhet be, ha épp az időkép szerint esik az eső...hogy egy elborult ötletet is mondjak. 

Oké, egy funkció nekem is nagyon hiányzik: kliens gép biztonságának ellenőrzése és ha nincs a windows, vírusírtó frissítve, akkor tagadja meg a felcsatlakozást. Bár elvileg kliens oldal connect scripttel ezt is át lehetne hidalni, ha elmélyülnék a power shellben.

Van egyéb hátránya is: performancia, bár egy céges road warriornál olyan nagy adatok nem pörögnek. Site-to-Site tunnelnek meg ott a WG.

Summázva az előny-hátrányokat, eddig nem találtam jobbat.

Azta !!! Nem semmi !

Ez aztán tényleg ígéretes, így elsőre. Főleg a 13.4K csillag és a 440 lezárt hibajegy.

Persze kicsit parázok, hogy a céges kliens APP-ot nyúlják le ehhez.

Ki tudja, mikor adnak ki azokból (auto-frissítve) telóra és iOS-re egy olyan változatot, ami már nem kompatibilis ezzel az opensource serverrel, csak a sajátjukkal?

Holnap nekiállok felrakni és tesztelni. (Vagy még ma éjjel, ha sikerülne visszaszereznem az irányítást a szerverem felett...)

Tailscale kliens + HeadScale szerver:

 Jól látom, hogy alapból nincs hozzá UI, de van pár "alpha" változat?

  Pl.: https://github.com/simcu/headscale-ui

Ti hogyan használjátok?

 

... illetve így hirtelen NEM látom, hogy :

  1. hol lehet letiltani, hogy NE mehessenek netre a kliensek a szerveren keresztül
  2. Hogyan lehet a csoportosítást beállítani, hogy ne lássák egymást a csoportok.
     ... vagy erre szolgálnak a USER-ek?

Sikerült visszaszereznem a hatalmat a gép felett :-)

Ami kihívás volt, hogy a :

systemctl stat

nem listázott minden futó szolgáltatást, így nem tudtam leállítani azt, amit nem is láttam, hogy fut.

Márpedig kiderült, hogy a korábban telepített WG-UI felpakolt egy csomót, amik a háttérben nonstop újraindították a WG-t.

systemctl stop wgui.path
systemctl stop wgui
systemctl stop wgui_http

wg-quick down wg3

Kedves Tamás!

  Köszönöm, de már nem keresem, tudom, hol a leírása ennek, nagyon segítőkészek voltak a fórumon is.

De ezt egyáltalán nem nevezném egyszerűen menedzselhető, tévesztésmentes, KÉSZ, egyszerű, átlátható megoldásnak:

  • külön lista a gépekről (SoftEther alapon) - név + MAC
  • külön a DHCP beállítások MAC + IP .... plusz annak a telepítése, menedzselése, konfigurálása, kitanulása ...
  • és külön egy "jegyzetek", ahol ki kell keresnem, ki kinek a kie milyen IP-vel.

Korábban már utaltam a dolog időkritikus tényezőire, amikor vissza kell keresni 1-1 klienst 2 másodperc alatt.

 

Egyenlőre nekifutok a headscale -nek és meglátom, hogy válik be.

HEADSCALE:

Tudtam, hogy nem megy simán ... (aka Morgó - Hófehérke)

Valamiért nem akar elindulni a szolgáltatás.

A Webmin-ben a LOG-keresés nem ad ki semmit 'headscale' -re.

Van valami ötlet arra:

  • Hogyan lehetne kideríteni, mi a baja?

Ezen leírás alapján csináltam. Szerintem vagy Let's encrypt a baja, (mivel nincs engedve a 80-as port befelé) vagy valami más a config.yaml -ban.

Köszönöm szépen!

Fura... ez ismétlődik:

 

Jun 03 11:58:41 vpnm systemd[1]: headscale.service: Scheduled restart job, restart counter is at 1.
░░ Subject: Automatic restarting of a unit has been scheduled
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ Automatic restarting of the unit headscale.service has been scheduled, as the result for
░░ the configured Restart= setting for the unit.
Jun 03 11:58:36 vpnm systemd[1]: headscale.service: Failed with result 'exit-code'.
░░ Subject: Unit failed
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ The unit headscale.service has entered the 'failed' state with result 'exit-code'.
Jun 03 11:58:36 vpnm systemd[1]: headscale.service: Main process exited, code=exited, status=1/FAILURE
░░ Subject: Unit process exited
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ An ExecStart= process belonging to unit headscale.service has exited.
░░
░░ The process' exit code is 'exited' and its exit status is 1.
Jun 03 11:58:36 vpnm headscale[36827]: 2023-06-03T11:58:36+02:00 FTL ../../../home/runner/work/headscale/headscale/cmd/headscale/cli/server.go:26 > Error start>
Jun 03 11:58:36 vpnm headscale[36827]: 2023-06-03T11:58:36+02:00 INF listening and serving gRPC on: 127.0.0.1:50443
Jun 03 11:58:36 vpnm headscale[36827]: 2023-06-03T11:58:36+02:00 INF Enabling remote gRPC at 127.0.0.1:50443
Jun 03 11:58:36 vpnm headscale[36827]: 2023-06-03T11:58:36+02:00 INF Setting up a DERPMap update worker frequency=86400000
Jun 03 11:58:36 vpnm headscale[36827]: 2023-06-03T11:58:36+02:00 INF No private key file at path, creating... path=/var/lib/headscale/noise_private.key
Jun 03 11:58:36 vpnm headscale[36827]: 2023-06-03T11:58:36+02:00 INF No private key file at path, creating... path=/var/lib/headscale/private.key
Jun 03 11:58:36 vpnm systemd[1]: Started headscale coordination server for Tailscale.
░░ Subject: A start job for unit headscale.service has finished successfully
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ A start job for unit headscale.service has finished successfully.
░░
░░ The job identifier is 1342.

 

 

Jól értelmezem, hogy annak ellenére, hogy "finished successfully", mégis újraindítja magát?

 

Státusz lekérdezés:

root@vpnm:~# systemctl status headscale
● headscale.service - headscale coordination server for Tailscale
     Loaded: loaded (/lib/systemd/system/headscale.service; enabled; vendor preset: enabled)
     Active: inactive (dead) (Result: exit-code) since Sat 2023-06-03 12:03:07 CEST; 2h 46min ago
    Process: 39311 ExecStart=/usr/bin/headscale serve (code=exited, status=1/FAILURE)
   Main PID: 39311 (code=exited, status=1/FAILURE)
        CPU: 139ms

Jun 03 12:03:07 vpnm systemd[1]: Stopped headscale coordination server for Tailscale.

Bocsánat a késői válaszért, 1 perccel ezelőtt sikerült elindítani!

IGEN, port hibára panaszkodott, de nem értem miért. Semmi más nem használta azt, amit beállítottam: 8989

Átraktam másikra, így már elindult a service.

 

Sorry, hogy nem vettem észre az a kis >jelet a sor végén, és nem következtettem rá, hogy lehetne jobbra is még valami,
 illetve, hogy nincs sortörés! Tisztára noob-nak érzem magam.

Nos, elvileg már jónak kellene lennie, de sajnos most az SSL-re panaszkodik. SSL_ERROR_INTERNAL_ERROR_ALERT

  • mivel a szerveren nem üzemel egyetlen hivatalos weboldal sem
  • ezért a 80-as port sincs nyitva
  • így viszont a Let's Encrypt sem tudja magát update-elni. (Egyébként a webmin magától megcsinálná...)

Sajnos http://localhost:8080 sem jó úgy ha:

  • Webmin SSL tunnel -en keresztül próbálom
  • vagy windows-on kiadok powershell alatt egy :  ssh -L 8080:localhost:8080 root@vpn.egyem.hu -p 22

, mert azt írja hibának, hogy:

Client sent an HTTP request to an HTTPS server.

SSL? A headscale alapbol http-t tud, SSL support nincs

Ez nem igaz.

A config.yaml fájlban ott vannak az auto-ssl megújításhoz megadandó parandcsok:

   acme_url, acme_email, tls_letsencrypt_listen, stb.

illetve lehet neki adni direkt path -t, ha már kész kulcsokkal akarunk dolgozni:

tls_cert_path: ""
tls_key_path: ""

 

Pont ez a problémám, hogy mindez ütközik a caddy-vel, mert az már alapból lefoglalja a portokat, amik az SSL megújításhoz kellenek.

... de mindjárt írok a topik aljára, hol is tart ez az egész.

Mert azon keresztül végzi az SSL hitelesítést.

A Let's E. oldalán magyarázták olvasatom szerint, hogy az "egyszerű" módszer az (ha nincs dinamikus DNS API hozzáférés), hogy egy fájlt generál valahová egy kulccsal, amit a Let's E. szervere megpróbál visszaolvasni, és ha ott van, ahol lennie kell normál http:// ... alatt, akkor elfogadja.

Az SSL / Caddy kérdéskör kapcsán nyitottam egy másik topikot itt ...

Ja, hogy te mindent kattintós-egyberakott módon szeretnél? Akkor vagy a caddy csináljon certet a vépéenednek, vagy beszéd le ról,a hogy magának oildja meg, és certbot-tal csinálj/frissíts annyi és olyan certet, ahányat és amilyet csak akarsz. Igen, ez első körben parancssoros móka, illetve ha a certet használó motyó nemveszi észre, hogy új certet kapott és ehhez újra kell indítani/küldeni kell neki valamilyen signal-t, akkor azt lehet, hogy kézzel kell belefaragnod, de ennyi.

A jó hír, hogy találtam egy "headscale-quickstart" szkriptet, ami alapján tudok jelenleg haladni.

Ez elvileg mindent beállít magától, de docker alapon, amit hivatalosan a headscale nem támogat.

Tehát azon dolgozom jelenleg, hogy a szkript alapján létrehozzak saját configot mind a Caddy, mind a headscale számára.
 (Hivatalosan a headscale csapata már a reverse proxy-t sem támogatja, de attól még jó ötletnek tűnik számomra, hogy :

  • a Caddy legyen a "front" és
  • az intézze az összes SSL kérést + újítást,
  • továbbítsa localhost-ról a portokat proxiként kifelé (MQTT, headscale dashboard + api, webmin)

Amik jelenleg foglalkoztatnak:

  1. Engedélyezzem-e a [MagicDNS] opciót?
     - Egyik oldalról klassz lenne ip címek helyett annyit írni, hogy:  futargep.fincsipizza.hu
     - de mivel egyetlen gépet sem szeretném, hogy kimehessen netre az én VPN szerveremen keresztül, nem tudom, hogy ez a DNS szolgáltatás tényleg csak a lokális gépeknek fog domain-t adni?
     - Továbbá nem szeretném, hogy a lokális LAN-on ha beírom, hogy "ping futargep" akkor a VPN-en keresztük kezdje routolni a helyi switch helyett. (Ahogy a SoftEther-rel pórul jártam.)
     
  2. Hogyan tudom kikapcsolni az auto-SSL-ezést headscale alatt (mivel a Caddy fogja csinálni...)
     
  3. Engedélyezzem a randomize_client_port -ot ?
     
  4. Default porton használjak mindent, vagy a biztonság kedvéért inkább irányítsam másra? (utóbbi felé hajlok)
     
  5. Mi a bánat az a grpc_listen_addr és metrics_listen_addr ?
     - kell ezeket kiengednem direktben a netre?

Állapotjelentés:

  1. Egy héten át próbáltam beállítani, hogy a Caddy, mint proxy https-en keresztül kiszolgálja a headscale-webui -t.
     
  2. Nem jött össze, ezért letöröltem az egészet és lefuttattam natúrban az "auto-install" szkriptet, amit valaki írt anno és MŰKÖDIK !
    Ez amúgy 3 docker konténert rak fel: headscale + Caddy + ui
     
  3. A gond csak az, hogy nem a legnépszerűbb, legjobban fejlesztett, legnagyobb tudású WebUI -t, hanem egy kis egyszerűt, ami nem kezel több-networköt.
     
  4. Az is kiderült időközben, hogy a headscale-be még NEM implementálták az UI alól kezelhető ACL -eket, márpedig anélkül nemigen lehet beállítani, ki mihez férhet hozzá.
     
  5. Látva ezt a példát, ami csak 11 user-t és 4 csoportot mutat, felmerül a kérdés, mekkora meló 100 csoportot és 300 gépet egyenként beleírni egy szöveges doksiba?
     
  6. Ennek ellenére nekiálltam, felraktam docker-be a mási WebUI-t, (és egy portrainer -t)
    De még nem jöttem rá:
     - hogyan lehet Docker-en belül konfigolni az UI-t,
     - illetve a Caddyfile -t is hozzá kell igazítani, hogy kiszolgálja.

Alternatíva:

  1. Szemezgetek a NetMaker -rel.
     
  2. Úgy tűnik, ebben rengeteg mindent be lehet állítani, 1-1 pipa ki/be kapcsolásával. ezzel meghatározva, melyik kliens hogy viselkedjen (relé-, turn-server, mesh, kapu ... )
     
  3. Még tanulmányozom a doksiját... de így elsőre nagyon ígéretes!
     
  4. Valószínűleg oda is felteszem a kérdésem, mert nem teljesen látom még át, hogy kell-e nekem Egress kapu is, vagy elég az Ingress.

látom kitartó vagy.

Én az elején erről beszéltem, hogy ha nem lehet megcsinálni 2-3 nap alatt, akkor nem érdemes vesződni.

Egy dobozos termékkel pl: SonicWall (ez volt a reklám helye) - pár nap alatt meg lehet csinálni AD-val és mindennel (tesztelés, dokumentáció, user betanítás stb.)

For Whites Only meeting room!

Én úgy számolok, hogy ha full 1 hónapot "vesződök" vele, azaz kb 200 órát, akkor:

- havi 50.000 forintot beszedve az ügyfelektől 2 év alatt megtérül

- a teljes rendszer az én irányításom alatt áll,

- bármikor egyszerűen upgrade-elhetem, lecserélhetem, stb.,

- A nyílt API-n keresztül akár saját menedzser-t írhatok hozzá,

- és közben rengeteget tanulok / fejlődök !

 

Emellett a SonicWall:

- nem biztos, hogy tud "relay gateway" -t,  "TURN gateway" -t, UDP punchhole -t

- és azt is ugyanúgy meg kell tanulni, ki kell tapasztalni,

- emellett már írtam, hogy ott is kivezették alapból a Win7 32bit-es klienst.

 

De nagyon szépen köszönöm, hogy:

 - aggódsz értem,

 - és építő hozzászólásokkal segítesz !

Ez egy nagyon rossz gazdasági modell és tanulási szempontból is nagyon alacsony a hatásfoka, akkor is ha nagyon gyorsan tanulsz.
Én kifejezetten egy termék-központú megoldásban gondolkodnék, mert az többször felhasználható és nem csak te fejleszted.
Én biztosan a kész tűzfal-megoldásokat nézegetném, ne legyen fizetős, legyen open source.
Mostani ismereteim alapján pfsense-t ajánlom.

Gábriel Ákos

Ha Te a 100 ügyfeles, 300 munkaállomásos rendszer ilyen mértékű fejlesztése után összesen havi 50 ezer Ft-ot szedsz be, vagy ennyivel kalkulálsz, akkor valami teljesen más munka után kellene nézni. Tisztán üzleti, megélhetési szempontból nézve. Már elnézést.

Ha visszaszámolom, hogy 50e Ft/hó, 2 évre az neked 200 munkaóra díja, akkor az 6000 Ft per óra vállalkozóként, tehát kézben marad belőle (ha kreatívan könyvelsz) 4000 Ft/óra. A hatvani Bosch-ban az operátorok (betanított munka gyártósor mellett) 2800 Ft/órát keresnek, felelősség, tanulási kényszer, vállalkozási nyűgök, stb. nélkül. Ezen is érdemes lenne elgondolkozni (nem a Bosch-ba menésen, hanem az árazáson).

Ügyfelenként havi 50 ezer az oké. Vagy ha nagyon kicsik, akkor legyen havi 25 ezer Ft a díjuk (fejenként), és körbecsókolgathatnak havonta, hogy milyen olcsó vagy. Ez 100 ügyfélre havi 2.5 millió. Az egy nagyjából elfogadható bevétel egy egyszemélyes vállalkozásnak (ugye vállalkozásnál a bevétel nem egyenlő fizetés...). De havi 50 ezer összesen, az még viccnek is rossz, nem bevételnek.

Ha megvan a normális bevétel, akkor meg tudsz választani bevált, működő, azonnal használható terméket, 2 nap ráfordítási igénnyel. A 2 nap után meg tudsz mással pénzt keresni, vagy pihenni, családdal lenni. Aztán egy ilyen kész rendszer beüzemelése nem zárja ki, hogy megtanulj/összerajtk egy hasonló sajátot, aztán a "gyári" cuccot lecseréld arra, hogy még nagyobb profitra tegyél szert, vagy függetlenítsd magad hosszú távon mindenkitől.

Na persze ha nem pénzkeresésre csinálod ezt az egészet, hanem szabadidő kitöltésre, akkor nem szóltam.

Tudom, hogy VPN-es tanácsért jöttél, mi meg többen életvezetési ötleteket adunk és kritizálunk, de többek között azért tart itthon ez a szakma ott, ahol (pláne vidéken, pláne KKV-k körében), mert ilyen szakik dolgoznak, akik az ügyfélnek való spórolás miatt képesek eszméletlen sok munkát beletenni bármibe, kurvára kevés pénzért. Mert a pizzasütős ügyfél sír, hogy drága vagy. Persze, közben meg csak a kajaszállító futárok havi 1 milliót keresnek, annyi a kajarendelés, ergo a pizzasütő is degeszre keresi magát. Csak nem akarja kifizetni Neked, mert meglátta, hogy élősködni is tud rajtad egy kis sírással...

ilyen fokú mazochizmust..

- nem akarom megszólni mindenki arra b.ssza el az idejét, amire akarja - DE

fejlesztőként és rendszer integrátorként optimumot, szakami igényességet és a best practice mellett kellene dolgozni - sztem itt ezek nem valósultak meg.

 

NTAK-nál is nagyon sokáig tartott, mire sikerült certtel aláírni és rendesen beküldeni az adatokat..

For Whites Only meeting room!

NetMaker:

Megint csak Morgót tudom idézni:

 - Tudtam, hogy nem megy majd simán...

Kiderült, hogy a netclient_x86.msi illetve a netclient.exe nem fut 32 biten.

Persze sehol egy szóval nem említik ezt az "apróságot", és még az _X86 is eléggé félrevezető.

Egyetlen lezárt hibajegy van erről az Github-on, ahol egy fejlesztő ezt az 2 sort írta "megoldásként" annak, aki 1 éve felvetette:
 

Fordíts le magadnak:

$ GOARCH=386 GOOS=windows GOHOSTARCH=amd64 CGO_ENABLED=0 go build -o bin/windows/netclient-386

 

De ennyiből fogalmam sincsen, hogyan. Még soha nem fejlesztettem semmit GOlang alatt.

...

Közben letöltöttem a GO-t.

Ezen leírás alapján pofonegyszerűnek kellene lennie.

De a valóságban:

PS E:\WgVPN\NetMaker\netclient-develop> GOARCH=386 GOOS=windows GOHOSTARCH=amd64 CGO_ENABLED=0 go build -o bin/windows/netclient-386
GOARCH=386 : The term 'GOARCH=386' is not recognized as the name of a cmdlet, function, script file, or operable progra
m. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
At line:1 char:1
+ GOARCH=386 GOOS=windows GOHOSTARCH=amd64 CGO_ENABLED=0 go build -o bi ...
+ ~~~~~~~~~~
    + CategoryInfo          : ObjectNotFound: (GOARCH=386:String) [], CommandNotFoundException
    + FullyQualifiedErrorId : CommandNotFoundException

Megpróbáltam "felcserélni" a sorrendet, hogy "go" legyen elől:

PS E:\WgVPN\NetMaker\netclient-develop> go build GOARCH=386 GOOS=windows GOHOSTARCH=amd64 CGO_ENABLED=0 -o bin/windows/netclient-386

go : malformed import path "GOARCH=386": invalid char '='
At line:1 char:1
+ go build GOARCH=386 GOOS=windows GOHOSTARCH=amd64 CGO_ENABLED=0 -o bi ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (malformed impor...nvalid char '=':String) [], RemoteException
    + FullyQualifiedErrorId : NativeCommandError
 
malformed import path "GOOS=windows": invalid char '='
malformed import path "GOHOSTARCH=amd64": invalid char '='
malformed import path "CGO_ENABLED=0": invalid char '='
malformed import path "-o": leading dash
package bin/windows/netclient-386 is not in GOROOT (C:\Program Files\Go\src\bin\windows\netclient-386)

 

További probléma lesz később, hogy:

 - még ha le is fordítom magamnak, a beépített AUTO-UPDATE szerintem le fogja tölteni a legfrissebbet, kilövi a működő szolgáltatást (deamon-t), felrakja a 64biteset, ami aztán nem fog elindulni.

linuxos goval is tudsz windowsra exet csinalni. problad ott.

Köszönöm, igen, találtam ilyen cikkeket a neten.

Közben rájöttem, hogy nagyon egyszerű felrakni a Go fordítót windows-ra.

És alig foglal valamicskét az E:\ meghajtón.

 

Csak aztán jöttek a gondok:

  1. Az első fordításnál automatikusan letöltött 500+ MB anyagot szétszórva mindenfelé a C:\ meghajtóra.  :-(
     
  2. Aztán olvastam mindenhol, hogy windows alatt "set GOARCH=386" paranccsal tudok 32 bites változatot fordítani.
  3. De nem ez történt. Ugyanúgy 64bites Exe készült.
  4. Megtudtam, hogy a "go env" paranccsal tudom ellenőrizni a jelen beállításokat.
  5. De kiderült, hogy hiába állítom át 386 -ra, rögtön visszaáll amd64 -re !!
  6. Szóval szerintem most megpróbálok mindent letakarítani a gépemről, (a C:\ -n 15178 fájl és 3073 mappa )
  7. aztán felrakom az egészet egy 32 bites gépre és ott újrafordítom.

... és még mindig ott az az aggasztó "auto-update", ami valószínűleg első próbálkozásnál ki fogja nyírni saját magát.

Szerkesztve: 2023. 06. 19., h – 10:41

Az éjjel annyit haladtam, hogy:

  • felraktam egy Win7 32 -bites gépre a GO-t
  • bekonfigoltam az összes PATH elérést, hogy normális, ellenőrzött helyekre pakolja a többszáz megányi sallangját
  • észrevettem, hogy ez a szemét TÖRÖLTE a windows-nak az alap PATH elérési útvonalait, és berakta a HELYÉRE magát egyedül !!!
  • majd rájöttem, hogy amit állítgattam CACHE és egyéb útvonalakat, abban a pillanatban rezetelődnek, amint új parancssort nyitok, és úgy szétpakolgatta a többszáz megákat ÚJRA máshová is

stb.  ... szóval inkább nem részletezném ezt az egész "gógó" fordítót :-(

Szóval a problémákat félretéve: MAGA A FORDÍTÁS MÁR MŰKÖDIK.

 

Csakhogy az EXE nem azt csinálja, amit kellene. Mindent kipróbáltam, de ami lefordul netclient.exe Win7 32 bit alatt, az egy használhatatlan trutyi. (nem ad semmi hibát fordításkor.)

Bármilyen parancsot=paramétert adok neki, mindenre ugyanezt a hibaüzenetet írja ki:

E:\netmaker\netclient-develop>netclient version
[netclient.exe] Fatal: could not reliably write WireGuard driver, please ensure Netclient is running with Admin permissions

Azaz egy téves hibaüzenetet. Nem tudni, mi a valódi baja az EXE-nek... még "--verbosity 4" esetén is.

Egyedül a "help" részek működnek, ha command paraméter nélkül indítom el.

...

Belemásztam a kódba, és azonosítottam, hogy a config_windows.go -ban a gondok. Nem is kicsit:

  • Hard-kódolva van a C:\Windows könyvtár,
  • // jelek voltak \\ helyett,
  • igazából a 64 bites fordításhoz is a 32 bites wireguard.dll -t használja!
  • szerintem az if .. else ágak is rosszak
  • stb.

Én nem programozom GO-ban, de elég egyszerűnek tűnik a kód. Kicsit olyan az egész, mintha valaki életében nem foglalkozott volna windows-zal, és elkezdte volna megírni ezt a részt, majd félbehagyta.

És annyira nincs is szükség az egész kódra. Szerintem kihagyható úgy ahogy van, mert csak annyit tesz, hogy megnézi, van-e wireguard.dll, és ha nincs, akkor megpróbál bemásolni egyet a system32 mappába, amit amúgy embed-elt az EXE-be.

A netclientutils.go -ban amúgy is már 2db WG kereső függvény.

... kutakodom tovább.

Megtaláltam a hibát a GO kódban.

config.go >> 389. sor: checkUID()

Most már lehet kiadni neki parancsokat, de installálni még mindig nem tudom.

Aki írta a kódot, összekeverte a "Program Files (x86)" mappákat, ezért aztán rossz helyre telepíti magát. Erről van is egy HIBAJEGY / javítás, de nem commit-olták!

Ráadásul úgy tűnik, a hibás helyre:
"C:\Program Files (x86)\Netclient\"
alá automatikusan bemásolódó winsw.exe szolgáltatást sem tudja elindítani, mert az az EXE is 64 bites.

Szóval most meg kell keresnem, hogyan kerül beágyazásba az a másik exe, és honnan származik?

Hát ez a netclient.exe GO nyelven írva rendesen kifog rajtam.

Amint javítom az egyik hibát, jön a következő.

  • A "C:\Program Files (x86)\Netclient\" hibát megoldottam: os.Genenv("ProgramFiles") + "\\Netclient"
     
  • A winsw programot kicseréltem egy .NET20 változatra, és az hibátlanul fut minden windows 32/64 alatt, ráadásul 17Mega helyett csak 0.8 -at ágyaz be az EXE-be.

 

Most viszont ott tartok, hogy:

 a local.go fájl 73. sorában van egy ilyen:

ncutils.RunCmd("Set-NetIPInterface -Forwarding Enabled", true);

Ami miatt a szolgáltatás (daemon) nem indul el, mert ez egy powerscript parancs, nem pedig "cmd.exe" féle legalábbis nem Win7 alatt.

- Szerintem végtelen ciklusban kerültél. Nem érzed úgy ezzel a valamivel, hogy nagyon törékeny, bizonytalan lesz, ha össze is áll?

Ezt írtad az OpenVPN-re: "Állandóan változtatnak a klienseken, és az 1 évvel ezelőtt generált (másik szerver) kulcsait már nem hajlandó elfogadni". Ebből többet nézel ki? Mert egyébként semmi gond nincs az OpenVPN-nel, elég jól össze lehet hozni, főleg szkripteléssel, nagyságrendelig kevesebb idővel, mint amit már itt küzdöttél. Stabilitást vársz, ugyanakkor olyan technológiák irányába mész, amikben kódolva van, hogy előbb-utóbb problémás lesz, főleg ha régi technológiákról sem mondasz le.

- Miért kell egyáltalán ez a VPN? Milyen kommunikáció megy csoporton belül? Tőled milyen kommunikáció megy a csoporttagok felé?

- A 32 bites Win7-ek támogatása erősen kérdéses cél, ha problémába ütközik - ahogy mások is írták. Saját költségeden másnak spórolsz. Vagy mondd meg az illetőnek, hogy maradhat, de ennyibe kerül a működtetése. Sorra potyog ki a régi szoftverek támogatása, csak idő kérdése, hol mikor milyen fal jön elő.

Esetleg egy Mikrotik routeren nem gondolkodtál? A 7-es routerosben már default benne van a WG, tudod szervernek és kliensnek is használni. Winbox-ban grafikus felületen tudod tutujgatni, tudsz minden wg interface-hez külön subnet-et allokálni amit utána tudod a firewallban akár szűrni.

Jah és ha nem kell a fizikai vas akkor tudod csak simán virtuális gépbe telepíteni amihez a hivatalos oldalon is tudsz licenset venni:

L4: 45$
L5: 95$
L6: 250$
 

https://help.mikrotik.com/docs/display/ROS/RouterOS+license+keys

Köszönöm az ötletet, de nekem nem áll össze ebből:

- hogyan lehetne 100+ külön helyet gazdaságosan elérni úgy,

- hogy nekem ne kelljen 100+ Wireguard virtuális interface-t felraknom minden gépemre és telómra

- és ne kellene minden egyes (nem általam, hanem lokális informatikusok vagy internet szolgáltatók által menedzselt) routert lecserélni egy ilyen 100.000 forintos licencesre?

Ezen az ábrán: https://help.mikrotik.com/docs/display/ROS/WireGuard

  nekem úgy tűnik, 1 eszköz ez csak 1 pizzériára jó.

És a legtöbb pizzéria nem érheti el egymást, tehát tilos őket összehangolni. Mások pedig, amelyek "franchise"-ban vannak, (üzletlánc több telephellyel) 1 egységként KELL működniük.

 

A "szimplán Wireguard" szerveres megoldást már korábban 1x sikerült megcsinálnom, de nem volt tökéletes, mert azt tapasztaltam, hogy:

 - a WireGuard kliense eléggé fapados,

 - nehézkes létrehoznom 1db "mestercsoportot", ha sok külön hálókártyára bontom szét a csoportokat,

 - vagy bonyolult tűzfalszabályokkal kell elválasztanom egymástól a külön csoportokat.
 (Ami még azzal a veszéllyel is jár, hogy ha kikerül a központi kulcs, akkor MINDEN kliensen le kellene cserélni.)

Szóval egyenlőre a TailScale még mindig jobb megoldásnak tűnik.
(Sőt, a netmaker méginkább, ha sikerülne fordítanom 1 clienst hozzá 32 bitre is...)

Köszönöm az ötletet, de a WireGuard kliens programmal az a bajom, hogy mikor Win7 32 bit alatt teszteltem:

  • Minden egyes alkalommal, amikor újracsatlakozott,
  • egy-egy ÚJ hálókártyát hozott létre!
    (1 napig teszteltem, és kb 18-nál járt)
  • Emiatt folyton feldobta a "válassz hálózati módot",
  • ahol újra és újra meg kellett adnom, hogy "Munka", nem pedig "Nyilvános".
  • ... amihez rendszergazda jelszó is kell, amit a felhasználóknak NEM adok meg.

Tehát gyakorlatilag használhatatlan volt feladatra, miszerint:

 - "1x beállítom és örökre működik a háttérben, a user-nek pedig nincs nyúkapiszka hozzáférése admin jelszó nélkül".

Vagy esetleg én néztem valamit félre, és van valahol valami speckó "hidden options" ?

2023-ban miért van Win7 32 bites OP rendszer bármilyen, éles használatban lévő számítógépen? Csak nem a fillérbaszás okán?

Miért nem tudod azt mondani, hogy mondjuk a Win10-nél régebbi rendszert nem támogatsz, és 64 bitesnek kell lennie mindenképp. Ne mondja azt senki, hogy olyan üzlete van, ahol az utóbbi 10 év munkájával nem tudta kitermelni a Win7-es gép lecserélésének költségét.

OFF:

 Azért, mert:

  1. Nem mondhatom meg másnak, hogy mire költse a pénzét. Még ha volna is neki "felesleges".
    10 vendéglátóhelyből már kb 7 bezárt itt a környékünkön, közöttük 20-30 évesek is.
     
  2. Ha "követelményeket állítok", akkor mást választanak, pl. az ingyenes NTAK-os programot.
     
  3. Nekem lenne a legeslegnagyobb szívás, ha Win7 32 bit rendszerek helyett mindenki hirtelen áttérne Win10 64bitre , ugyanis
    átlag 50db Win7 rendszerrel foglalkozok időben annyit
    = mint 1db Win10-es gép problémáival.

    A mai napig stabilan fut kb 10db WinXP-s POS rendszerem is!
    - Reggel bekapcsolják, 7 másodperc alatt elindul a 15+ éves gép,
    - egész nap dolgoznak egyetlen probléma nélkül, Firefox-ban szól az online zene a háttérben + email +++
    - este 23órakor kikapcs.
    - évi 1 takarítás a zsírgőzös poros párás körülmények között is elég azoknak a vasaknak.
     

  4. A legtöbb régebbi drágán vásárolt blokknyomtatónak nincs is stabil drájvere Win10-re.
    Azokat is dobják ki, ne csak a gépeiket?
     
  5. Tények:
    A PizzaProgramom EXE-je:
     - Win7 32bit alatt (3GB RAM) egy 6 éves gépen 4 másodperc alatt indul el
     - Win10 64bit alatt egy 3 éves (kb 4x gyorsabb, 8GB RAM) gépen,  7-15 másodperc
    Frissítés:
     - Volt olyan, hogy a déli csúcsidőben a Win10 egyszeriben újraindult, és 15 percen át "frissítéseket telepített". Se kérdés, se jóváhagyásra várás, se semmi.
     - Volt, hogy a hálózatos nyomtatás Win10 alatt egyik nap még működött, másnaptól már nem.
    stb...
     
  6. Mert én magam sem szeretem ezt az amerikai nagyvállalatok által ránk kényszerített:
    - "évente vegyél újat mindenből" mentalitást.
    Gyűlölöm azokat, akik mindent kihajigálnak, csak mert:
    - "már régi ...  vagy rá kellene szánni egy kicsit a javításra."

https://www.smithsonianmag.com/science-nature/burning-truth-behind-e-wa…

 

Ui.: Köszönöm szépen mindazoknak, akik segítenek építő jellegű ötleteikkel a probléma megoldásában,
illetve jól esik, hogy néhányan együttéreznek velem!

De ahogyan már korábban is kértem, hálás lennék, ha ez a szakmai topik kizárólag a VPN-ekkel foglakozó kérdéskört tárgyalná.

egy kérdés csupán:

- Nem gondolkoztál már linux-os kliens megoldásokon ? a Delphis programod tud linuxon futni (újrafordítással) ?

Egy vajdasági ismerős srác csinált a horvát tengerpartra ilyen pincéres appot - ott linuxot használt és Delphi/Lazarus -t a 2000-es évek elején.

For Whites Only meeting room!

OFF:

- Nem gondolkoztál már linux-os kliens megoldásokon ? a Delphis programod tud linuxon futni (újrafordítással) ?

 

Óóóóó dehogynem !!!

  1. Kb 15 éve olyan 4-6 hónapot fektettem bele, hogy megvalósítsam, hogy VINE alatt fusson,
  2. aztán a "nyomtatókezelésnél" meghalt az ötlet.
     
  3. Később fizettem egy fejlesztőnek hónapokon át, hogy :
     - írja át az AlphaSkin orosz komponenscsaládot Lazarus -ra, hogy át tudjak térni multi platformra
    kb 5 hónap után feladta, mert csurig volt spékelve Win Message -ekkel.
    22 évből 18-at erre az egy komponenscsaládra alapoztam. Még a DB rácsok is azzal mennek helyenként.
    Ennyi munkát nem lehet csak úgy "kidobni".
     
  4. Próbáltam 3D-be újraírni az egész frontendet (Unity3D alatt)
     - fizettem 15 hónapig egy "C# 3D specialistát",
     - közben én is kitanultam a C# alapokat és a Unity3D-t,
     - és mikor már eleget tudtam, rájöttem, hogy azért nem halad, mert:
     - csak Copy-Paste módon programozott, és annyit sem értett, mi az a "függvény" vagy "objektum"
    (GameObject-ek definiálása helyett "névre keresett" mindent sornál ... )
     

a horvát pincéres app még Compaq PDA-n ment és WIFI-n küldte be a rendeléseket - nagyon nagy volt a placc - mire végig az összes asztalnál és felvette a rendeléseket az első asztalnak már akár kész is volt a rendelése..

A konyhán volt egy linuxos szerver és oda futattak be a rendelések.

For Whites Only meeting room!

OFF:

 Én inkább olcsó Tabletekben gondolkodtam, már 15 éve megy 3D asztaltérképpel együtt szépen.
(Úgy forgathatja a pincér, ahogy éppen áll...)

Wifi-hez régen DD-WRT-zett Linksys-eket építettem ki, most már inkább TP-Link Omada EAP- ... szériás MESH

/off

ON:

Jelenleg a tabletekre is kénytelen vagyok OpenVPN klienseket telepíteni, ami néha akár 20%-ban is megfogja az egyik Atom proci magját !
(A másikat meg 40%-ban a VNC, ha távsegítséget kell adnom.)

Ezért is szimpi a Wireguard alapú VPN, mert azzal is csökken a terhelés rajtuk és tovább bírja majd az akksi.

nem azért de ezeknek már rég raspberry pi-vel kéne menniük, linuxszal.

Nekem is átfutott az agyamon. Bár jól megsz****tam volna az utóbbi pár év RPi hiánya miatt...

Összefoglalva:

  • Az RPi nem alkalmas 10+ évnyi Firebird adatbázis gyors kezelésére
  • Ha a hálózattal van valami gond, nem tudnám távdiagnosztizálni azon keresztül, hogy "miért nem jó a windows-os nyomtatáskezelés".

Szóval értelmetlen lenne számomra.

Inkább egy felhős-vékonyklienses üzemeltetéshez lenne való szerintem.
Az enyém egy "offline Alkalmazás", ami mellesleg tud neten kommunikálni és lokális webszerverként működni. (built in intraweb srv.)

Réges-régen nem a probléma megoldásán dolgozol hanem egy mellékszálon: 32 bites go-t akarsz fordítani 10+ éves windowsra.
Ha voltál CIO pontosan tudod hogy fel kéne állítanod egy döntési fát/mátrixot.
Ki kéne hátrálni ebből a csőből és "felülről" ránézni az egész problémára, ismét.

Gábriel Ákos

32 bites go-t akarsz fordítani 10+ éves windowsra. ...
Ki kéne hátrálni ebből a csőből és "felülről" ránézni az egész problémára, ismét.

Igen, köszönöm a "kijózanító szavakat", pont itt tartok most.

Védelmemre annyit, hogy :
- Ha valaki tudja, hogy el fog esni, előtte leül.

A kristálygömböm éppen offline volt, nem gondoltam, hogy ennyire bénán van megírva a NetMaker kliense.
Azt írta valaki 2 éve, hogy neki sikerült lefordítania, de szerintem akkoriban még nem tartott ennyire Win10 64 alap felé a fejlesztés.
És abban sem vagyok biztos, hogy szolgáltatásként futott nála, GUI-val együtt.

Én úgy vagyok vele, ha valami nem indul pöccre, akkor felejtős. Nyilván kivétel, ha egyértelmű a probléma oka és én vagyok a hunyó, de fordítással kínlódni nem ez a kategória egy könnyen üzemeltethető alkalmazással. Nem sok jót vetít előre, kristálygömb sem kell hozzá.

Nekem az az érzésem, hogy több energiát kellene a technológiák kiválasztásába és alapozásba fektetned, kisebb eséllyel lőnél mellé. Például nem értem a GUI-hoz való ragaszkodásodat sem, amennyi időt eltöltöttél már GUI és hasonló vadászatokra, azalatt simán megtanulhattad volna normálisan kezelni CLI-ből és konfig fájlokból, ráadásul egy raklap függőséget kidobhattál volna.

OpenVPN-hez való hozzáállásodat sem értem, főleg ha már működött, a minden vacakra elcseszett idő töredékéből összehozhattál volna egy megfelelő szervert. Attól, hogy egyszer peched volt vele még nem biztos, hogy a kidobás az optimális, főleg, hogy a leírtak szerint nem is feltétlenül a technológiával volt probléma. Akár két OpenVPN szerverben is gondolkodhatnál: egy régebbi és egy újabb.

Jól értem, hogy itt arról van szó, hogy te alapvetően vmi kajálda szoftvert üzemeltetsz, aminek a backendje nálad van, és azért kell a vpn, hogy az ügyfelek elérjék?

Mert akkor csinálj úgy VPNt imho, hogy az egészet hagyod a picsába, tegyél egy normális HTTPst a backendhez, autholj az applikációban, azt kész, mehet az interneten, jó az. Ha dolgozol is vele, legalább olyanon, ami közelebb van a core businesshez, neked is előre mutat (és talán komfortosabban is mozogsz azon a területen).

Nem, nem erről van szó.

Minden étterem más, és nálam (egyenlőre) nincs semmilyen backend.

 

  1. Az étterem tulajoknak el kell érniük a saját éttermüket biztonságosan.
  2. Nekem is minden gépet.
  3. ... talán később a gépeknek egy központi tárhelyet egyéb szolgáltatások miatt. (MQTT, SQL replica, stb.)

Ingyenes megoldás még a RustDesk és a MeshCentral is, és mind kettőnél van lehetősége saját központi szervert üzemeltetni.

https://rustdesk.com/

https://meshcentral.com/info/
MeshCentral - Basics:  https://www.youtube.com/watch?v=D9Q7M7PdTg0
MeshCentral - How to install and Configure it:  https://www.youtube.com/watch?v=T8LllCqCRG0
--
Légy derűs, tégy mindent örömmel!

  1. Nem mondhatom meg másnak, hogy mire költse a pénzét. Még ha volna is neki "felesleges".
    10 vendéglátóhelyből már kb 7 bezárt itt a környékünkön, közöttük 20-30 évesek is.

szinvonalat hozni kell, es lesz vendeg. kozepes szarok elhullanak. tudok par pizzazot pesten (ha mar pizza a tema) ahol ha most kitalalnam hogy kajalni akarok, nem kapnank asztalt mara.

1. Valóban. Semmit vásárlásra nem kötelezheted. Nem is kell. Te azt mondod meg, hogy mi kell ahhoz a rendszerhez ami szerinted szakmailag megfelelő. Az ügyfél meg eldönti, hogy kifizeti, vagy néz valami gagyibbat. Ha szerinted szakmailag megfelelő 2023-ban Win7 32 biten futtatni bármit, akkor szakmailag gondok vannak.

2. Akkor mást választanak. Olyan terméket, szolgálattást kell csinálni, amit a minőségéért, szolgáltatásaiért vesznek, nem azért, mert olcsó, és jár mellé örökös ingyen rendszergazda.

3. A Win10-zel vannak problémák, de a Win7-tel is voltak. Ráadásul ennyi év alatt nem ülni kellett volna egy 25 éves, már akkor sem modern alapokra írt szoftveren, vagy rosszabb esetben azt foltozgatni (ahogy összeraktam magamban, Delphi progi Firebird adatbázissal), hanem fejleszteni kellett volna a v2.0, v3.0 stb. verziókat, melyek mára webes API backend-ből és böngészőben futó kliensből kellene álljon. Pláne ilyen ügyfél volumen, igények és feladatok esetén.

4. Igen, ki kell dobni. Elavult. Nem azt mondtam, hogy 1-2-3 évente le kell cserélni a cuccokat, de 10 évente csere férjen már bele. Ha nem fér, el kell gondolkozni az üzelti terven, vagy a tulajdonos sóherságán. Mindkét esetben legyen másnak az ügyfele, aki a szolgáltatásának a lényegi részére pár ezer Ft-ot szán havonta (a rendelős kajánál a hiedelmekkel szemben nem a kaja a lényegi rész, hanem a profi, könnyen használható és jól működő rendelési rendszer...)

5. Visszautalva a 2. pontra, ha böngészőben futna, RPi vagy hasonló vékony kliensekkel, állandóan működő backend-del, akkor ilyen, hogy indulási idő, fel sem merülne. A gyakorlatban meg valószínű azért lassabb az újabb gép újabb rendszerén, mert a program egy régi "szar" (mármint a bináris kész kód, a fordító meg a kompániája miatt), ami nagyon nem a mostani gépekre és OS-ekre optimalizál. Ennyi lehet a titok. Már csak az érdekel, hogy Firebird 2.5 szigorúan (vagy még 1.5?!), vagy lehet 3.0 is, most 2023-ban a Firebird 4.0 korában?

6. Már bocs, de a 25 éves üzemeltetői tapasztalatom alapján ez azoknak a dumája, akiknek a rendszere csak régi cuccokon működik jól, és a fejleszés helyett inkább meg kell magyarázniuk, hogy miért is jobb az elavult régi vas és OS. Ráadásul ez illik is az ügyfelek igényeihez, mert nem kell semmire költeni. A valóságban rémálom Firebird 1.5/2.5, Java 1.6, Borland Database Engine DLL-t igénylő, Oracle 10g kliessel futó, IE6-ot kérő, stb, stb, stb. rendszereket üzemeltetni, alájuk hardvert-szoftvert biztosítani, menteni, új gépre költöztetni.

A topik szerintem nem tudja kizárólag a VPN témakört tárgyalni, mert olyasimre keresel megoldást, aminek a koncepciója hibás, valamint a kapott javaslatokat sem veszed komolyan, továbbra is csak a saját fejed után mész. Így jön a szokásos, "akkor találjuk ki mi, mire gondolhatott a költő" eset.

Engem nagyon érdekelne az eredeti probléma, amit meg kell ezzel a rengeteg darab, komoly ACL rendszert is igénylő VPN-nel oldani.

Ugyanis lehet, hogy a probléma valami teljesen más megközelítéssel megoldható könnyebben és jövőtállóbban, mint a sok-sok VPN-es rendszer kialakítása.

Miért nem jó az, hogy van egy szem WG VPN végpont a szerver oldalon, a klienseknél minden gépen van WG "kliens", ami ide becsatlakozik, aztán az aránylag egyszerűen tűzfallall (vagy magával a WG-vel is) megoldható, hogy a kliensek egymást ne érjék el, csak a központi szolgáltatást. A szolgáltatáson belül meg megvalósítható az ACL-es rész (ami így teljesen VPN-től, kapocsolattól független és robosztus lesz), hogy mindenki csak a saját adataiba turkáljon, a másét ne is lássa.

Igen, én is nagyon örülnék, ha 1 óra alatt össze tudnék hozni egy 10-20 évig működő stabil megoldást.

De egy másik topikban éppen azt tárgyaltátok, hogy mennyire veszélyes dolog több-csoportot egyetlen központi mesterkulccsal megoldani. (És egyet is értek.)

Úgy vélem sokkal biztonságosabb lenne, ha :

 - egy újonnan generált kliens kulcs kizárólag saját csoportját / magát és max a szervert érje el

 - és úgy kellene külön jogokat adni neki később.

Nem pedig:

 - egy ideiglenesen kiosztott vendégkulcs rögtön rálásson minden csoport minden kulcsára,

 - és csak akkor nem, ha gondosan állítgatom a tűzfal vagy ACL-es szabályokat.

 

Ha pedig az egyik étterem bezár, vagy kompromittálódik, akkor törölhetem az egész csoportot egyben.

Az hogy bármilyen megoldás 10-20 évig hozzányúlás nélkül működjön: irreális elvárás hacsak az egész nincs a kezedben és meg tudod tiltani bárminek is a megváltoztatását.

Az hogy egy új wg interfészen keresztül egy új kliens mit lát kizárólag rajtad múlik, beállíthatod teljesen nyíltra és teljesen csukottra (és bármi másra eközött). 1-2-3 tűzfal szabály az egész.

Az "először nincs semmi joga" és utána "adok neki egyesével" hozzáállással egyetértek.

Gábriel Ákos

Állandóan változtatnak a klienseken, és az 1 évvel ezelőtt generált (másik szerver) kulcsait már nem hajlandó elfogadni. Mindezt 2 év alatt másodszor úgy, hogy kb már 400 órám ráment a kulcs-cserékre és csak a felével vagyok meg.
Régebbi kliens nem működik már Win10/11 alatt, hiába volna még 8 év a lejáratból.

 

Ezt mondjuk nem igazán értem, volt a normális desktop kliens, tray iconnal, rendes log(debug) ablakkal, újabban lett ez a balfasz telefonos kinézetre hajazó, de emiatt kliens kulcsot nem kellett cserélnem. Szerver verziót viszont kellett ugrani, mert az elfogadott algoritmusok közös halmaza üres lett.

A 2 évnél régebbinél még MD5 kulcsokat generált a VPN-es rendszergazda.

Amikor megtudtam, kikeltem magamból, hogy mi a bánatért nem AES256???

 

Akkor generálta újra az összes kulcsot.

KB 5-800 órám elment a távoli kulcs-cserékre összesen az elmúlt másfél év alatt.

Olyanokra is magamnak kellett rájönnöm, hogy a config fájlokba bele kell írnom:
key-direction 1

Aztán kiderült, hogy csak az "egyik felének" (talán az auth) állított be AES256-ot,
de a kommunikációhoz SHA1-et. Meg 2K alapot, nem 4K-sat.

Ezért a mostani 2.6.3 már azt is visszadobja. Hiába állítok BÁRMIT a config fájlba.

Összegezve:

Nagyon nagyon megutáltam az OpenVPN-t, hogy mi a bánatért erőltetik kliens oldalon ezt a működésképtelenséget basszus???
Ráadásul kb 2 évente és úgy, hogy a 2.6.2-nél még működött, a 2.6.3-nál már nem.

 

Tele van a fórumuk olyan "megoldásokkal", hogy :

 - generálj új kulcsot...

De ha egyszer nem az én kezemben van a szerver ???

Na azért az md5 kidobása nem 2 évvel ezelőtt történt, hanem már több, mint 5:

https://openvpn.net/security-advisory/planned-removal-of-md5-support/

Szóval aki 2 éve még ilyen certet generált, azt kéne seggberúgni, erről az OpenVPN nem tehet.

(SHA256 a hash, nem AES256)

Egyébként meg a certeknek az a jellemzőjük, hogy időnként lejárnak, szóval a cserére nem árt felkészülni amúgy is valami automatizmussal.

OpenVPN tipikusan olyan, hogy alig kell megadni valamit a kliens configban. A nagyrésze központilag a szerverből állítható. Nem tudom mit bűvészkedtél, de OpenVPN azért egész jól tud menni. 1-2 szívás néha beüt, jellemzően winre visszavezethetően, de elég jó rugalmas cucc.

"De ha egyszer nem az én kezemben van a szerver ???"

Akkor itt a gond. OpenVPN saját szerveren szépen muzsikál 10+ éve, 100+ klienssel.

Értem, de nálad hány különválasztott csoportban fut az a 100 kliens?

  • Kell e mellé mestercsoport?
  • Kell szabályoznod, hogy a csoportok ne férjenek egymás gépeihez?
  • Hogy lehet ezt megoldani 3x 100 tűzfal szabály nélkül?

stb.

Mondom: 2 HÓNAPOM ráment ezek kitapasztalására,
és 1 csoport létrehozása 3 kliens generálással, fix IP cím állítással = 2.5 óra !!!
 ... és a 3. csoport végül nem is működött, mert valamit benéztem és további 4 óra küzdés után feladtam.

 

Egyáltalán nem felhasználóbarát megoldás egy Wireguard / TailScale / NetMaker-hez képest.

Ha eltekintünk attól, hogy miért kell egymást közt is beszélgetniük a klienseknek, miért nem elég a szerverrel, akkor kíváncsi lennék, hogy milyen csoport kezelést használtál az OpenVPN-nel? Mert hogy nincs benne tudomásom szerint, szóval valamivel körbe kell szkriptelni hozzá. Ami meg egy random web adminnal elég lutri, hogy működik-e vagy sem.

Van a hivatalos GUI, az OpenVPN Access Server, de az meg fizetős.

OpenVPN Access Server

Igen, köszönöm, tudok róla.

Az volt, ami "beugrasztott", hogy OpenVPN alapon csináljam meg, mert "csak nem lehet annyira bonyolult" ...

tévedtem.

A hivatalos árát nézted?

 

A srác anno:

  •  /net30 IP kiosztással (4esével) és
  • kliens oldali push route-tal,
  • tűzfal szabályokkal és
  • külön porton külön daemonnal oldotta meg.

és úgy, hogy az még nem tudott P2P -t.  (Ahogy tudtommal most is csak linux alatt tud.)

Nem néztem, csak kíváncsi voltam erre a csoport megoldásra, mert ezt tuti egyedileg kellett megoldani.  Ha kevés csoport van, akkor megoldás a több példányban futtatás különböző portokon, ha sok csoport van, akkor meg kell valami egyedi szkript (learn-add-nál meghívottat ajánlanak a konfigban). Azért ezt nem lenne bonyolult leprogramozni, usernév jön a certből, csoporttagságot ott tárolod, ahol akarod (akár egy szövegfájlban is), a szkript meg kezeli az iptables-t (vagy itt az új tanulnivaló, az nftables).

Itt én érzek némi ellentmondást.

Ha van (volt) VPN-es rendszergazda, és Ő készített (réges rég elavult) kulcsokat, akkor miért neked ment el 800 órád a kulcsok cseréjére? Miért nem a VPN-t üzemeletető ember foglalkozott a VPN-nel? Ha a kliensekkel nem foglalkozott, akkor pontosan mi módon volt VPN rendszergazda úgy, hogy a szerverrel gyakorlatilag semmit sem kell csinálni, a kulcsokat meg egy BASH script megcsinálja további hozzányúlás nélkül 10 perc alatt.

Ha 300 ügyfél géppel kell dolgoznod az eddigiek alapján, akkor gépenként 1 óra 40 perc és 2 óra 40 perc közötti időt (tehát átlagosan 2 órát) töltöttél kulcs cserével? A kulcs csere utáni 1 óra 39 perc - 2 óra 39 percben mit kellett még a klienssel csinálni?

Bocs. Abszolut semmit nem befolyásol az életemen az ügyed, a munkád, de már kezd bosszantani, hogy egy (az eddigiek alapjá) 25 éves, (az eddigiek alapján) koncepcionálisan hibás rendszert próbálsz meg átültetni az eddiginél modernebb építőelemek felhasználásával valahová, ami közben kérdezel ugyan, de a sok-sok különböző segítő válasz ellenére mégis folyton csak azt csinálod, ami a Te fejedből pattan ki. Mi értelme ennek az egész topiknak?

Szerintem a kevés alvás miatt már nem lát tisztán: csak megy, kínlódik, próbálgat.

Nyugodtan végig pihenhetne egy hétvégét, hetet, a megvalósulás tempóját látva a lényegen nem változtatna, friss aggyal pedig akár gyorsan meg is lehetne a megoldás.

A probléma az, hogy le sem írta az elvárást - hiába kérdeztük többen is -, csak a mindenféle alternatívákkal jön elő.

Holott a morzsákból összeszedve ha jól értem kb egy RDP-hez vagy VNC-hez kell ez az egész VPN, mert más (még) nem fut. Erre például egy ingyenes DWService tökéletes, ügyfelekkel meg is tudja osztani a kapcsolatot (vagy fordítva). Ha pedig további szolgáltatásokat akar, nem is feltétlenül kell VPN. Csak azelőtt is lehet, hogy kellene 1-2 hét szabi, mert különben beleugrik valami isten tudja technológiába, aminek van GUI-ja.

Múltkor belefutottunk egy pfsense bugba, hogy bizonyos verzió (2.5.0 talán) a kiválasztott helyett sha-1 certet generált

workaroundnak a kliensnél működött emlékeim szerint a 
 tls-cipher=DEFAULT:@SECLEVEL=0 
a kulcscseréig

https://redmine.pfsense.org/issues/11705

Úgy általában, mi is nyűglődünk a wireguard és az openvpn (pfsense) között. Openvpn csak egy szálon fut és a nyomorult képes megakasztani a netforgalmat egy pillanatra a már kapcsolódott usereknél, amikor a kézfogást csinálja egy új kapcsolódóval. (voip döccent mindig) A wireguard meg nem tud lenyomni routingot...  Lehetne akár minden usernek saját openvpn példány (úgy nem akad meg más user kézfogás miatt a forgalom), csak az meg nem integrálódik a pfsensebe, hogy közös konfig legyen az alapjuk.

Azt értem hogy a régi szerver nem a te irányításod alatt áll. De az újat elvileg te irányítod majd, nem?

Akkor meg biztos hogy a legegyszerűbb megoldás felé mennék és felraknék egy openvpn-t az új serverre.

További előny: a mostani windowsokon sem fog kelleni semmi újat installálni csak a vpn konfigot kell lecserélni.

Gábriel Ákos

Nem látom be hogy annyira másképpen menne a layer 3 VPN wireguard v openvpn alatt (konfigurációs szempontból). Szerintem nagyjából egyforma szintű "hálózati megértés" kell hozzájuk. 

Nem lehet hogy a TUN/TAP kavarás miatt  a layer 2 openvpn-el volt bajod?
... és most azért lehet a Wireguard "megváltás" mert az layer 3 ?

Gábriel Ákos

Szerkesztve: 2023. 06. 20., k – 13:45

Nézem ezt a topic-ot mióta, de valahogy mintha egyre rosszabb lenne az irány..

Azt kellene eldönteni, hogy fejlesztő vagy, vagy üzemeltető? Ha előbbi, nem neked kellene ezzel foglalkozni és ezt a hátteret kitalálni/megvalósítani az alkalmazásodhoz, ha utóbbi, akkor meg nem így kellene nekiállni, sem ennyire túlbonyolítani.

Egy Headscale-nek (tudom, hogy korábban itt is volt róla szó, csak innen elkezdted túlbonyolítani) pl. minimális erőforrásigénye van, dockerben (+ reverse proxy konfig, én pl. nem Caddy-zek) 5 perc alatt felhúzod kulcsrakészen (ekkor GUI még nem kell!), utána ACL-ekkel pár óra alatt finomhangolod a teljes környezetet. Ez tipikusan az, amit konténerizálni érdemes, és egy Authentik, Authelia, vagy hasonló még mindig kerülhet elé (ennek kezelésére felhúzhatsz mellé egy GUI-s konténert is). Nyilván ez csak egy példa és máshogy is lehet, de ez a fordítgatás a topic vége felé agybaj.

Minden egyéb plusz réteg plusz komplikációt és függőséget hoz magával, több olyan vetületet, ami eltörhet, ha túlzottan ráépítesz, én ilyen tekintetben a minimális számú építőelemben hiszek (Netmaker, Netbird, stb, biztos jó, csak tuti nem azzal kezdenék ekkora számú kliensnél sem).

Egy Headscale-nek ...

Jól mondod.

Én is pont most akarok visszatérni ebbe az irányba !

Elegem lett a Go nyelvből és a fordítgatásból. Akkor már inkább az ACL bűvölés!
 (Csak még azt is előbb ki kell tanulnom.)

Authelia -ról még nem hallottam, utánanézek!

 

Azt kellene eldönteni, hogy fejlesztő vagy, vagy üzemeltető?

Sajnos, ha éttermi informatikával foglalkozol, akkor MINDENHEZ kell értened!
Könyvet tudnék írni abból, hány féle esettel találkozunk, ami üzemeltetés, és úgy indul, hogy:
 - Jónapot kívánok, ezt a telefonszámot kaptam és az a gondunk ezzel a "Termó" programmal, hogy ...
(Nem is ez a neve, ott a fejlécben, de ki sem tud annyit olvasni, hogy : " TermiPRO - azéTermiPROgram +36 20 916 0275 " és még csak 10+ éve dolgozik vele napi 18 órát.

(... amiről pl. a végén kiderül, hogy most kötötték be az IP TV-t a meccshez és a szolgáltató 10 perce volt ott, majd egy router rezet után távozott...)

Ez nem így van.

Te vagy az, aki rámondod, hogy mindenhez IS értesz, majd megoldod.

Aztán ezen vállalás alapján rák hárul minden IS.

Hozzám oszt jöhetnek, hogy a desktop így meg úgy. Én pl. szerveres, hálózatos szaki vagyok, ahhoz értek, amennyire értek. Nem fogok az ügyfél kényelmére desktop vonalon tanulgatni, hogy az ő élete egyszerűbb és olcsóbb legyen. Pláne nem kezdek el szoftvert fejleszteni neki, holott eredetileg programozó vagyok. De nem lehet mindent IS csinálni, mert akkor minden IS szar lesz...

Nem foglalkozom éttermi informatikával, nem is szeretnék, valamint erősen hiszek a SOD-ban, aminek láthatóan itt is lenne haszna. :)

Sokkal jobban nem szeretnék beleszólni, de ami még felmerült bennem, de átolvasva a topic-ot, nem egyértelmű számomra (ha mégis szerepel, elnézést, de azt látom, hogy más is kérdezte): _miért_ igény/szükséglet, hogy az érintett eszközök rálássanak egymásra? Ha jól értem, több különböző cégről van szó, előnyös sem lenne, adatkezelési és egyéb szempontokból eredően.

Ez a fenti válaszomon nem változtat, persze, ACL (ha HS/TS) vagy hasonló megoldással ez kezelhető - csak a leírt use case szerintem nem indokolja.

Nekem sose volt ezzel problémám (gyári táppal).
(szerk: SD volt benne) de én már mindben lecseréltem SSD-re.

A docker miatti sok írás kicsinálja a kártyás bármiket, SSD vagy rendes HDD kell mellé.
Rendes HDD is tök elég, usb2.0 a limit úgyis.

Gábriel Ákos

Nem csak VNC + RDP kell,

  • a klienseknek kell egymással beszélniük
  • egy csoporton belül,
  • IPv4 alapon,
  • "belső hálózatként" (virtInterface)
  • stabilan és folyamatosan fenntartva a kapcsolatot.

(SQL, MQTT, socket event, intraweb, ... ki tudja még később mi)

______________

Köszönöm szépen az új tippeket is! Meg fogom nézni a többi felsorolt lehetőséget is, de szerintem már csak elseje után.

______________

A Netmaker-t és a GO nyelven 32 bitre fordítást már elvetettem.

De attól még a 64 bites változat kódja is egy katasztrófa.
(NEM a "Win7 hibája", ha pl. fixre kódolják bele összevissza backslash-el a C:\\\\Program Files//... könyvárat, vagy C:\Windows-t.)

______________

OFF:

Bocsánat, hogy nincs időm mindenkinek azonnal egyenként válaszolni, de ma is csak 4 órát aludtam

 - az NTAK miatt 20-an hívnak naponta,
 - amíg valakivel beszélek 2 másik "nem fogadottam" keletkezik,
 - amit 1 éven át halogattak a vendéglősök, most akarják 1 hét alatt megcsináltatni velem (több hetes giga-projekteket is.)
 - tőlem kérdezik, hogy kell a pénztárgépben rendesen kezelni a borravalót és bankkártyát.
 (Mert a pénztárgépesük összevisszaságokat beszél!)

stb...

Miért nem járható út az, hogy nem egyedi VPN klienseket telepítesz a gépekre, hanem minden egyes helyszínre leraksz egy helyi átjárót, ami megcsinálja a kapcsolatot a központi kiszolgáló felé. Így megmarad az, hogy a kliensek egy hálózatba látják egymást, és csak az a forgalom megy a VPN csatornába amit beengedsz. 

Többen kérdeztük, mi a topológia és mi a megoldandó feladat, de eddig választ egyikünk sem kaptt.

Az eddigi infók alapján valószínű van egy ~4700 Ft-os TP-Link TL-WR740ND router a pizzériák 97%-ban (a maradél 3%-ban meg az egy szem PC-re van kötve a net), és az aztán nem segíti meg a site-to-site VPN-ek létrehozását.

Persze ilyenkor IT MacGyver felkiált, hogy akkor legyen a S2S cucc az egyik munkaállomáson. De arra meg senki sem figyel, hogy az a gép mindig működjön, meg a fenti router-isten extra statikus route-okat sem kezel, így ez is megbukott.

Mindez azért, mert a OP 25 éve, hogy elinduljon a vállalkozása, belement abba, hogy úgy kapnak az ügyfelek rendszert, hogy semmit nem vesznek és semmiért nem fizetnek, a rendszergazda-programfejlesztő-technikus-supportos vállalkozó hozott anyagból csinál meg mindent. De olyanra, hogy a DARPA is kérje a licencet.

Aztán úgy tűnik az eddigiekből, hogy szegény ebbe beleragadt úgy beletett munkamennyiség és elkért fizetés terén, mint az akkor használt technológiákkal. Viszont most valami megborult (például felmondott az OpenVPN szerver üzemeltetője és nem mondja meg a root jelszót a szerverhez), így muszáj új VPN-t csinálnia. De mivel az eddigi OpenVPN rendszergazda a lehető legrosszabban csinálta a dolgát, ezért az eddigi szívásokról maga az OpenVPN szoftver tehet, mennie kell, és valami más kell helyette. De persze úgy legyen aktuális az új VPN technológia, hogy WinXP meg Win7 32 bit kliensek is vannak, amik addig kell üzemben maradjanak, míg fizikailag el nem kopnak, mert az egész ki van fizetve, nehogy már 10-15 évenként le kelljen a PC-ket cserélni.

A rendszert én úgy képzelem el, hogy minden kliensen fut a program helyben, Firebird adatbázissal. Az egyes példányok valami módon megüzenik egymásnak, mit kell mindenkinek beírni, módosítani vagy törölni a helyben lévő adatbázisból. Rosszabb esetben az egyik munkaállomáson megosztáson van a Firebird fájl, hogy a többiek elérjék. Eddig úgy tűnik, nincs központi szerver, nincs központi adatbázis. Azért kell az OpenVPN, hogy a főnök távolról is tudja nézegetni az aznapi állást (egyébként ugye LAN-on megoldható lenne a dolog VPN nélkül).

Tökéletesen összefoglaltad!

OFF: Mindennek az okai:

  1. Én egy szoftvert adok el.
     
  2. Többnyire már annak is örülnöm kell, hogy:
    - nem egy "korábban megvásárolt" PC,
    - tetszőlegesen telepített windows-ára kell táv-telepítsem,
    hanem esetleg:
    - ÉN mondhatom meg, milyen előre előkészített (POS rendszerre optimalizált) windows-ra legyen felrakva.
    (Ami természetesen Win10 64bit már egy ideje.)
     
  3. És esetleg nagy ritkán, ha nem túl sóher a főnök, akkor kuncsoroghatok egy "távelérés" havidíjért.
     - Amit az OpenVPN-es mostani üzemeltetője kap meg,
     - de nekem kell egyenként kisírni a párezer forintokat attól a kb 40%-tól, aki kéri, és esetleg még fizet is.
     - De már ez a pénz sem elég az OpenVPN-esnek és 2x emelt fél év alatt árat: +50% és 70% )

    Miközben az "ingyenes" TeamView-errel kell versenyeznem ezért.

Tehát 98% -ban nincs semmi beleszólásom a hálózati topológiába!

És van olyan, hogy az ügyfélnek sincs beleszólása. Pl. :

  • Az épület bérlemény.
     
  • Egy "pláza által biztosított" al-hálózati végpont.
     
  • Önkörmányzati épület mellék-kábelezése.
    (A "Nemzeti adatvédelmi" szervezet felügyeli a hálózatot és a rákötött gépeket távolról!!!)
     
  • Műemlék épület,
    (Ahol még a rendezvény teremben sincs végpont, tilos falat fúrni... és max ADSL van, még 4G sincs.)
     
  • Volt Orosz épület, 40-60 centis betonfalakkal...
     
  • Autópálya felügyelet által biztosított net (autós pihenőben).
     
  • Van, ahol a 3G / Wifi alapú speciális szolgáltató adja az egyedi Microtik routert és osztja ki a DHCP-t és Guest Network Wifit... mert oda egyetlen szolgáltató sem húz kábelt.

És még sorolhatnám...

Tehát a legjobb eset az, ha 1-1 géphez hozzáférek rendszergazdaként!

Továbbá azt sem szabhatom meg az ügyfélnek:

  • Milyen laptopot / PC-t vegyen otthonra magának
  • és milyen telefont

... melyekkel távolról hozzá kell férnie a rendszerhez, hogy ellenőrizze.

"Egy "pláza által biztosított" al-hálózati végpont."

Amire egy mikrotik/Tomato/OpenWRT rámehet, ami OpenVPN kliens is tud lenni. A teljes hálót beköti a VPN alá. Több, plázában üzemelő franchise hálózat így csinálja és _évek_óta stabilan megy.

Akartam is már mondani: van még egy lehetőséged. Add ki a melót, mármint a kivitelezést valakinek vagy dolgozzatok össze aztán visszakapod az üzemeltetést, ha kész van az átalakítás. De ennyi szenvedést látni is rossz. Nyúlj a zsebbe, fizesd ki a szakit, aki csinált már ilyet, aztán dőlj hátra és évekre le tudva a probléma. Max win support marad, amíg a programod nem lesz linuxos, mert utána annyi problémád sem lesz.

Szomorúan olvasom, hogy jól tippeltem meg nagyjából mindent. Én tiszta szívemből sajnállak, hogy ilyen slamasztikába taszítottad magad az "ügyfélnek mindig igaza van" (teljesen hibás) vállalkozói elv alapján.

1. Ha szoftvert adsz el, akkor megmondod a minimális hardver, szoftver, hálózati követelményeit. Ebbe mindent bele lehet venni, aminek szerinted a jó működéshez és a Te nyugodt életedhez benne kell lennie. Ami ennek nem felel meg, az kimarad a rendszerből. Pont.

Te itt valószínűleg elköveted azt a hibát, hogy minden követelményből engedsz, ráadásul sokat, hogy megvegyék a szoftvert. Úgy érzed, hogy ha betartatnád a követelményt és rendes árat is kérnél mindenért, akkor nem vennék meg a cuccodat, nem kérnék a szolgáltatásodat. Az az igazság, hogy ez igaz is meg nem is. Kb. a kétharmada onnantól nem kérné, megszabadulnál a fillérbaszó hülyéktől. De a maradék egyharmad meg kérné, amiből rendes árral bejönne a mostani pénz (vagy több) és rendes követelménnyel meg a nyugodt életed is meglenne (nem napi 3-4 óra alvás jutna a sok kínlódás mellett). Persze egy ilyen váltás nem könnyű lelkileg, de nagyjából abból kell választanod, hogy tönkremegy a céged és/vagy belerokkansz vagy durván változtatsz a működéseden, árazásodon.

2. Ez fordítva kell legyen. Te mondod meg, hogy mi kell, és vagy van nekik, vagy megveszik. Ha nekem elmondja egy leendő ügyfél, hogy mit szeretne, akkor én elmondom a legjobb szakmai tudásom alapján, hogy mi kellene a megoldáshoz, és az mennyibe kerül. Az ügyfél abból választhat ezután, hogy kéri, vagy nem kéri. Utóbbi esetben más szolgáltató után néz, ugyanis én nem adom a nevem és nem teszem bele a sok munkám olyan dologba, ami szerintem (és a tudásomhoz mérten) szakmailag nem megfelelő. Ha más olyant vagy jobbat tud olcsóbban, akkor rajta (majd fejlesztem magam, ha ez egyszer előfordul), ha rosszabbat tud olcsóbban, akkor meg vagy megelégszik azzal az ügyfél (de nem én kínlódon a szarral), vagy visszatér hozzám, hogy mégis kéri.

3. Nem kell kucsorogni. Távelérés kell, anélkül nem működik, és XYZ Ft a havi díja. Ennyi. Nehogy már a hozzá nem értő, sóher ügyfél döntse el, hogy Te mivel és mennyit szopsz.

Az, hogy milyen az internet végpont teljesen mindegy. Egy rendes VPN-nel el fognak tűnni az igazi végpontok, Te csak a virtuális hálózaton kell dolgozz. Ez a rendes VPN nem a használt szoftvertől, technológiától rendes, hanem a megvalósítás jóságától. Én pl. OpenVPN-t használnék ilyen vegyes környezetben, mert az a legtámogatottabb ilyen széles eszköz és OS palettán. Minden más sokkal újabb, és emiatt sokkal háklisabb azon, hogy min futtatod.

Valóban (ahogy már írtam előzőleg is) az ügyfélnek nem mondhatod meg, hogy mit vegyen. Javasolhatod. Meg kikötheted, hogy mi kell minimum a rendszer használatához. Aztán ha nem olyant vesz, magára vessen. Azt kell mondani (könyörtelenül), hogy megadtad a specifikációt, annak nem felel meg amit vett, így nem tudsz neki segíteni az eszköz használatba vételében. Pont.

Tehát 98% -ban nincs semmi beleszólásom a hálózati topológiába!

Ebben az esetben szerintem alapvetően két dolgot tehetsz:

- elmondod, hogy mi kell hozzá, oldja meg szépen az ügyfél, mert ez nem a te dolgod. Én személy szerint egyetértek ggalloval, hogy szerintem is át kellene gondolnod az üzleti stratégiát, mert ha jól értem, egy olyan sarokba rajzoltad magad, hogy hát ha pénzt mersz kérni, majd kicserélik valami ingyen alternatívára, miközben látszik, hogy te kilóméter hosszan szopsz olyan dolgokkal, amik még csak nem is részei a valós szolgáltatásodnak, és baszol el 800 órákat ennek az "ingyen" izének a tutujgatására. 800 óra az 5 munkahónap, az nagyon durva. Értem, hogy emberileg kellemetlen, de tényleg az van, hogy téged ezzel kihasználnak. Tudom, hogy szar azt mondani, hogy ez nem fér bele, de összességében üzletileg hulljon csak a nem fizető ügyfél, ha meg tudja oldani ingyen, akkor hajrá, akkor minden filléred drága lesz neki. Üzletelj azokkal, akiknek értelmesen értéket tudsz teremteni, és megy nekik úgy, hogy ki is tudják fizetni. 

- Műszaki oldalról meg leginkább azt, hogy olyan megoldást gyártasz, amihez nincs szükség arra, hogy speckó dolgokat kelljen csinálni azon a területen, ahol nincs semmi beleszólásod. Tudom, hogy fáj, de valószínűleg itt egyszerűen elszabtad az architektúrát.

Alapból ott a gond, hogy ő egy terméket akar eladni, ami egy szoftver.
Valójában viszont távadminisztrációt és más szolgálatásokat is nyújt mellé, akár ingyen.

Látok hasonlót nagyban is, amikor sóher ügyfél nem hozzéértő it részét kell supportálni, miközben elvieg programhoz szól fejlesztésre és annak használatára támogatás és nem infrastruktúra üzemeltetéshez van szerződés. Csak a végére mindig oda lyukad ki, hogy segítsünk ingyen, mert különben nem fizetik ki a termék díját... vezetői döntés. Aztán megy a csodálkozás, ha a devek egy része felmond, hogy ő nem ezt vállalta.

egy olyan sarokba rajzoltad magad, hogy hát ha pénzt mersz kérni, majd kicserélik valami ingyen alternatívára

Itt rogton ket opcio van, valoszinuseg szerint novekvo sorrendben:

  1. tenyleg ki tudjak valtani, es akkor OP-nak at kell gondolnia a bizniszet
  2. nem tudjak kivaltani, csak a pofajuk jar

Egyékbént a +50% és 70% simán költség oldalról is jogos lehet, durván emelkedtek a díjak szerverhotelekben. (Feltételezve, hogy normális infrastruktúrán ment a szolgáltatás) 
És persze az infláció miatti egyéb költségnövekedések is drágítják a működést. 

Az "ingyen" teamviewer kapcsán pedig a kalózszoftverrel persze, hogy nem lehet versenyezni, de valsz nem is kell. Ha fizetnék a licensz díjakat, akkor lehet az több lenne, mint amit a szolgáltatásért magáért hajlandóak fizetni. Ilyen ügyfél csak viszi a pénzt.

Jól értem, h van egy működő megoldásod, amin javítani és fejleszteni kéne csak pár apróságot, ehelyett te a falba vered inkább a fejed?

Klasszikus.

Szerkesztve: 2023. 06. 22., cs – 21:57

Update:

Egyenlőre 4 órányi oktató-videóanyagot sikerült megnéznem a MeshCentral -hoz.

Nagyon tetszik!
Még nem jutottam el odáig, hogy felrakjam, de csak idő kérdése.

Valószínűleg azt nem tudja, hogy :

 - "csoporton belül IP alapon elérjék egymást a gépek egyedi portokon" 3050, 3051 , stb...
 - hacsak nem futtatok valahogy egy bizonyos "felügyeleti manager exét, ami Port-Relay -t tud szolgáltatni.
  (De azt még nem látom át, hogyan lehetne ezt a háttérben futtatni GUI nélkül.)

A "legrosszabb esetben" két rendszert fogok minden gépre tenni:

 - egy MeshCentral -osat

 - és egy multi-network HeadScale -t pusztán a FireBird-nek, esetleg még az MQTT-nek.

Ezzel a redundancia is meg lenne oldva.

Lehet hogy megy ez MeshCentrallal is.
Elvileg egy Multi-Domain MeshCentral server CrossDomain Adminnal és MeshCentralRouterek (mapping/tunelling) kellenek hozzá.

MeshCentral - Multi-Domain Server
https://www.youtube.com/watch?v=eqInqM9olXA
https://ylianst.github.io/MeshCentral/meshcentral/#domains

MeshCentralRouter
https://www.youtube.com/watch?v=BubeVRmbCRM
https://github.com/Ylianst/MeshCentralRouter
--
Légy derűs, tégy mindent örömmel!

Miért kellene elérni csoporton belül a gépeknek? 1 vpn user = 1 telephely. Miért kellene több telephelynek egymást elérnie?

Miért kellene elérni csoporton belül a gépeknek?

Bocsánat, lehet én vagyok már túl zombi, de ezt a kérdést nem egészen értem.

  1. Nekem rá kell látnom minden csoport minden gépére. 100.111.0.0/16
  2. Minden csoportban minden gépnek látnia kell egymást. 100.111.x.0/24
  3. Egy csoport SOHA nem láthat rá más csoport gépeire.
  4. Egyetlen gép sem léphet ki a netre a szerveren keresztül, tehát "lokális VLAN-ként" kell működjön.

Na de ezt helyi hálózat megoldja. Erre van a switch. Gondolom ezek a gépek egy területen vannak.

Nem. Teljesen rosszul gondolod.

Ahogyan már korábban is magyaráztam és a feladatot megfogalmaztam:

Virtuális (Layer3+) hálózatként kell összekötni különféle eszközöket:

  • A tulajdonos Android / iPhone -ját
  • Az üzletvezető(k) laptopját / otthoni PC-jét / telefonjait
  • A "kitelepülős" = rendezvényes PCket
  •  és persze az étterem (esetleg különböző épületeiben elhelyezkedő) PC-it is,
    (Amik néha külön külön neten vannak, ha nem lehet összekábelezni a korábban leírtak miatt.)

mind mind 1 hálózaton kell, hogy lássák egymást.

  • Van olyan is, ahol 1 diszpécser kezel két program két külön adatbázisát úgy, hogy az 1-ik helyen van a telefon, de a város másik felében a másik konyha + kiszállítási pont.

stb.

Hibás a megközelítés, javaslom más irányba elindulni (habár nekem még ennyi hozzászólásból sem latható az, hogy a kliensek milyen szolgáltatást hol akar igénybe venni):

- egy étterem egy hálózat, itt a kliensek egymással tudnak kommunikálni

- ha két külön telephely van, akkor össze kell kötni őket VPN segítségével

- ha központi szolgáltatás kell elérjenek, akkor telephelyeként 1 VPN csatornával kapcsolódnak a szolgáltatási pontra, és nem klienseként 

- ha távoli elérést kell biztosítani, akkor az megoldható vagy direktbe a telephelyre kapcsolódással (ennek megfelelő követelménye van, oldja meg az ottani üzemeltető), vagy a központi szolgáltatási ponton keresztül.

A 100.111 onnan jöhet, hogy a Headscale csak a CGNAT tartományon (100.64.0.0/10) belüli IP címek használatát engedi a végpontjai számára. Gondolom megmaradt az eredeti HS-es próbálkozásból.

OP-nek: nyilván figyelembe kellene venni, hogy a Digi-s nem-publikus címes előfizetési végpontok ebből a tartományból kapnak címet, meg a Telekom-os mobil internetek is például. Persze egyiknél sincs publikálva, hogy a teljes /10-et használjk, vagy annak csak egy részét. Valóban okozhat nem kevés fejtörést és ütközést, ha csak hasraütősen van a CGNAT-on belüli tartomány kijelölve.

Hirtelen én is megijedtem, hogy a Mobilnettel ütközhet ez a tartomány.

Kipróbáltam:

 - A Yettel 84.224.x.y címet osztott

 - A Telekom valóban 100.89.x.y

 - Vodás kártyám nincs.

 - A DigiMobilt 1 hete visszamondtam.

Ha "alulról" osztja a DHCP-jük, azaz 100.64-től, akkor ha a "tetejére" lövöm be, úgy talán mázlim lehet.

 

Minden mást tartománnyal sajnos már találkoztam mindenhol. (192.168.x. , 172... , 10.x....)

Tehát azokkal nagyobbnak látom az esélyt az ütközésre.

 

Lehet, hogy szerencsésebb lenne, ha ezek a rendszerek alapból már IPv6-ot használnának, de az nagyon sok rendszeren le van tiltva.

A HS/TS-nek pl. az az egyik lényege, hogy - nagyon leegyszerűsítve - átmegy a NAT-on. A végpontok "külső címe" nem változik, csak a HS/TS-en belül kapnak egyet annak saját tartományával, ne keverd össze ezeket a dolgokat, mert csak még jobban összezavarodsz.

Nem bántani akarlak, de az egész koncepció rossz. Ennek a cuccnak jó 10-15 éve egyetlen böngészőben kéne futnia, felhős backend-en, skálázott db-vel és hasonlókkal. Döglött lovon utazol, rettenetesen elavult technikai és koncepcionális stack-kel, és most ennek a levét iszod.

Talán az utolsó gondolatom, hogy az is rettenetesen hibádzik, hogy csak ismerkedésekkel temérdek időt elpazarolsz. MeshCentral, vagy mi, 4 óra YT..ehhez képest ennek a topicnak az indíttatására is húztam fel minap megnézni egy HS-t, 5 perc volt a deploy, 10 perc alatt beléptettem az eszközeimet, 1 óra alatt játékból összeraktam egy ACL-policyt. Nyilván nálad az eszközök számossága miatt nálad egy nagyságrenddel több időt venne igénybe, de nem többszáz órát, mint amint egyes "próbákba" már beleöltél. Nekem nem tűnik úgy, hogy közelednél a megoldáshoz, se magadtól, se a tippjeinktől.  

Én is pont így tettem a HS/TS-sel, pontosan ezen topic apropóján, és valóban 1-2 óra felállítani az alap rendszert végpontokkal, ACL-lel. Még subnet router-rel is kísérleteztem, meg két kölön helyszínen exit node-dal. Meglepően jól működött minden elsőre.

Aztán lehetne script-tel és az API-t használva félig automatizáltan csinálni a nagyobb volument, ha sikerül egy jó alapot kitalálni.

Egy baja van csak, amit nem biztos, hogy meg lehet ugrani (pontosabban meg lehet, csak nem feltétlen lesz optimális megoldás), mégpedig azt, hogy

a HS csak egyetlen Tailnet-et (egy logikai hálózatot) kezel, így egy HS példány esetén csak ACL-lel szeparálhatók az ügyfelek (ez viszont műszakilag elég, mert akihez nincs hozzáférés, ott a mesh kapcsolatok sem jönnek létre, nem csak tűzfal szintű a szeparáció),

vagy annyi HS példány kell, amennyi ügyfél (ez scipt/Ansible/stb. módon még meg is oldható), de akkor meg a "master admin" node a problémás, mert a TS jelen formájában egy node csak egy szerverre tud bejelentkezni egyidőben, nincs konkurrens csatlakozás több HS szerverhez egy node-ról. Erre megoldás lehet megfelelő számú TS kliens futtatása a master admin node-on konténerezve (ez azért meredek, de megoldás), viszont ilyenbe nem mennék bele, mert adminisztrációs rémálom a sok HS példány is és a sok master node is. Még lehetne kísérletezni master node terén a TS kliens fast user switching-gel, hogy megy-e több különböző login server esetén is ez a funkció... De akkor is problémás lenne 100-as nagyságrendő HS példányt menedzselni.

Ennek kiderítése is belefért nekem a 2 órába...

Egyetlen OpenVPN szerverrel valószínű le lehetne kezelni az egészet szépen. A szerver a VPN kliensekhez maximum /16 subnet-et enged, az pont jó 255 ügyfélig, ügyfelenként 255 kliensig. Onnantól meg IP tartomány alapján simán tűzfallal lehet szeparálni minden ügyfelet csoportokba. És a master admin node is megoldott, mert őt meg majd engedi a tűzfal mindenhová. Ehhez egyetlen szerver kell publikus fix IP címmel és nyitható porttal, mindenki lehet aztán akármilyen IP cím és NAT mögött. Persze a hub-and-spoke rendszer miatt a késleltetés és a sávszélesség korlátos, dehát eddig is így működött, és a leírtak alapján nem a késleltetés és a sávszélesség a gond most.

Egyetértek. Én HS/TS esetén egy komoly ACL-listára szavaznék, de ízlés dolga. És ahogy korábban is írtuk neki, máshogy is megoldható, csak azért hoztam ezt a példát, mert szóba került, illetve mert a saját házi tesztem is jó eredményeket hozott (örülök, hogy azonos eredményre jutottunk :)), illetve mert OpenVPN-nel komolyabban pár éve már nem foglalkozom, de szakterületem sem volt soha.

Amit elsősorban ki akartam hozni ebből, hogy már csak egy gyors teszt (aminek eredménye egy működő setup) sem vesz el 1-2 óránál többet, nettó idő- és energiapazarlásnak érzek 4-x órákat YT-videókat nézni "ismerkedésnek".

... ennek a topicnak az indíttatására is húztam fel minap megnézni egy HS-t, 5 perc volt a deploy, 10 perc alatt beléptettem az eszközeimet, 1 óra alatt játékból összeraktam egy ACL-policyt.

Igen, idáig én is eljutottam, sőt, még egy UI-t is raktam mellé, aztán egy másikat.

De amikormegpróbáltam megalkotni magamnak a "mester csoportot", és egy véletlen ENTER lenyomástól loopba került az egész szerver: órákat vett igénybe visszanyerni az irányítást.

Szóval jó, jó, ez a HS de valahogy "nem az igazi". Ekkor kezdtem el a másik irányba menni.
Gondolom mások sem úgy vesznek autót, vagy választanak feleséget, hogy rászán 10 percet, és lesz ami lesz.

Én most 10-15 évre tervezek, ezért inkább most derüljenek ki az ilyen esetek, mint mikor már prod. fut.

____________________________

Amíg nem javasolta valaki a MeshCentral-t, addig a HS volt a befutó. >> És a HS -ről sem hallottam addig, amíg valaki nem javasolta itt. >> Előtte a WireGuard -ról sem hallottam amíg egy másik fórumon nem említették ...

Szép lassan csorognak be ebben a topikban az infók, és ott tartunk, hogy végre van két esélyes megoldás is! :-)
 (Max egyszerre fogom futtatni a kettőt, és valamit egyikből használok, más funkciókat a másikból.)

Az, hogy végignézem az összes oktatóvideót, lehet, hogy feleslegesnek tűnik, de ezekből rengeteg fontos dolgot megtudtam, hogyan érdemes biztonságosan üzemeltetni a szervert, mert a default beállítás nagyon nem az. 3FA, stb.

Most éppen az 1500 soros "példa konfig fájlt" elemzem, hogy mik azok a funkciók, amik jók lehetnek még valamikor?
 (Pl. Telegram push üzik, GitHub login, sendmail, ViewOnly setup, stb.)

Az aktuális hibajegyeket is meg szoktam nézni (Pl. Debian 12 kompatibilitás...)

____________________________

Nagyon szépen köszönöm mindenkinek az eddigi segítségnyújtást!
Fantaszikus sokat haladt a dolog pár nap alatt ahhoz képest, hogy előtte az OpenVPN-nel mennyit szívtam egyes egyedül eredménytelenül hónapokon át.
(Nemhiába írják sok helyen, hogy az mára már elavult tech-nek számít. De ebből semmiképpen sem akarok vitát kirobbantani, mindenki azt használ, ami szerinte a legjobb.)

Ne haragudj, de nálam valahogy egy teljes HS-környezet ACL-estül való felhúzása után sem "került loopba az egész szerver", azóta is üzemel. Csak ha már biztonságos üzemeltetés..

Olyan nincs, hogy 10-15 évre tervezel, nem fenntartható - látod most is hova jutottál. Az informatikában 3-5 év már sok idő a legtöbb esetben. Abban, amit te csinálsz, különösen annak kellene lennie, a 10-15 év álomvilág.

Mindegy, a magam részéről nem tudok/szeretnék többet hozzátenni, nagyon nem azonosan és azonos elvek mentén dolgozunk. Az, ahogy te csinálod a dolgokat, 98%-ban nálam fel sem merülhet, nincs metszéspont.

Huh, ezt a topikot olvasni is fájdalom. A kérdezőnek megpróbálták többen leírni mi a helyes irány, de ragaszkodik az elképzeléséhez.

Voltam vállalkozó és amit csinál a kérdező az sztem. is teljesen rossz kocepció.

Két irányt javasolnék. 

  1. Ő egy szoftvert ír és ez a produktuma. Az, hogy ezt ki, hol futtatja az nem az ő gondja. Neki egy rendes dokumentációt kell adni a végfehasználóknak a minimális és/vagy ajánlott konfigurációt illetően.Ha ehhez szeretne plusz szolgáltatásként rendszergazda szolgáltatást is adni az ügyfélnek, akkor az külön szerződés, külön pénz!
  2. A másik eset, hogy azt mondja, hogy terméket egy általa kiválasztott eszközön szállítja az ügyfélnek, amolyan black box megoldásként. Ehhez elég pár minimális követelmény (hálózati beállítás, az eszközt X évente meg kell vetetni vagy beépíteni a havidíjba stb.)  és a rendszergazdaság nem ide tartozó dolog lesz.

Fejlesztőként jó eséllyel a B opció mellett voksolnék egy ilyen piacon. ugyanakkor, mint vállalkozó, meg menekülnék és a kiutat keresném, mert ezek a sóher vállalkozók többnyire szép, drága autókban ülnek és a pizzéria neki kb. zsebbpénz a reggeli kávéjához. Fájdalmas kimondani, de ez a modell vállalkozás szempontjából nem más, mint vegetálás, esetleg a döglött lovon való lovaglás tipikus esete. Az ügyfeleimnek tisztában kell lennie azzal, hogy én is profitért dolgozok, tehát az üzlet az üzlet és meg kell fizetniük az időt és a munkát. Az, hogy utána beülünk együtt meginni egy sört az ügyféllel az más kérdés.

Itt én a vállalkozás oldalán változtatnék egy, akár több lépcsős áremeléssel első körben, ahhoz hogy legyen profit és legyen mit visszatenni a cégbe. Gondolok itt arra, hogy ha ezt már korábban megtörténik, akkor profit most visszaforgatható lenne egy profi VPN megoldásba, mint szolgáltatás bővítés, majd minimális plusz munkával lehetne sokkal több pénzt keresni. Ennek nem késő most se neki kezdeni és lehet csak az ügyfelek fele marad meg, de ők is eltartják majd a vállalkozást ha tényleg ennyire ragaszkodnak a termékhez.

Hogy honnan tudom mindezt? Onnan, hogy én is voltam vállalkozó és ugyanígy álltam hozzá,  mint te, de én hamar rájöttem, sőt volt olyan aki ezt egyenesen a szembe mondta, hogy ne szégyelljem elkérni a munkám árát. Sajnos addigra már elfogyott a lendületem (teljes kimerülés és kialvatlanság) és nem volt erőm változtatni. Szóval nem megbántani szeretném a kérdezőt, hanem felhívni arra a figyelmet, hogy vállalkozás oldalról szemlélet lehetne váltani és optimaliálni a vállalkozás működését.

Én azt gondolom, hogy 3. opció is van: amit most csinálna (távelérés szolgáltatás), de világosan fel kell deríteni, hogy műszakilag mit tud vállalni, azt követelményként meg kell határozni és elkérni az árát - ahogy írod.

De legelőször is gondolkodni és utána nekiesni, mert már nekem is fáj, hogy mennyi időt beletolt az ide-oda kapkodásba, fórumozásba stb-be, ennyi idő alatt saját maga bőven megcsinált volna egy olyan OpenVPN alapú megoldást, amit szeretne. Az OpenVPN azért jó neki, mert a klienseken már ott van, és mivel nem kevés kliensről van szó, a megoldás terítése sem másodlagos.

Hozzátéve, hogy számomra továbbra is kérdéses, hogy miért kell VPN, nem tartom kizártnak, hogy más módon is meg lehetne/lehetett volna ezt valósítani az eddig VPN technológiák felderítésébe szánt időből, például egy központi szolgáltatás, ami adatot cserél a végpontokkal (végpontoktól kap adatot és küld is nekik), például https alapon, ami jó eséllyel bárhol átmegy.

OFF:

Mindenkinek nagyon szépen köszönöm a cégvezetési / életmód tanácsokat.

Rendkívül megható, hogy ennyire aggódtok értem! Jól esik végre egy

  • ennyire segítőkész és
  • építő jellegű, többnyire visszafogott megfogalmazást preferáló

közösséggel találkozni. ;-)

Természetesen a legtöbb dologban igazatok van, és ha "lement" ez az egész NTAK őőőőrület, utána újraértékelem az egész életemet.

Ahogyan szerintem sokan mások is abból a kb 170 cégből, akik eddigi életüket "éttermi informatikára" specializálták és most állami milliárdokból fejlesztett "ingyenes és javasolt" változattal kell versenyeznünk, melyet olyan "hírekkel" marketingelnek, mint:
- "kiváltja a pénztárgépet".
Ami valóban igaz, amennyiben 210E + Áfáért AEE egységet vesz helyette.

Anno 20 éve, amikor egy kezemen meg tudtam számolni, hány ilyen program volt a piacon, jó 5letnek tűnt a "mikro-pizzériákra" specializálódni, mert "nagyhotelekre" és "óriáséttermekre" volt már más, nagy-céges, milliós költségvetéssel.

De valóban mostanra sok mindent változott, és én is látom, milyen verembe kerültem.
Erre tényleg az NTAK ingyenes programja tette rá a "cserkót a barnahurkára".

Ui.:

Ha már úgyis átment a topik félig OFF-ba:

 - Mivel az én ügyfeleim picik, többségük az életben maradásért küzd az 5x-ös villanyszámla és a 3x-os alapanyagárak mellett, napi 16-18 órát rohangászva H-V, nem pedig hófehér Jaguárral jár.

... van, aki a harmadik szívinfarktusán van túl.
A legtöbbjüktől elvált már a párja, mert "nincs is férje". (De persze az éttermi bevétel után követeli a bíróságon a felét, amit a programom statisztikájából kifotózott.)

Miközben:

  • az alkalmazottak kilopják a szemét,
  • a futár benzint tankol a céges autóba dízel helyett,
  • és olyan telefonokat kap, mint:

     - Mié' kűd' ide Covidos futárt a házamho'? Hogy képzelik, hogy megfertőzik a györökeimet?
    V: - Miért gondolja, hogy ha beteg lenne, akkor dolgozna?

     - Mer' maszk van rajta!
    V: - Ez az előírás.

     - Hmmm... Maguk hogyan fertőtlenítik a pizzát?
    V: - Hővel.

Mivel az én ügyfeleim picik, többségük az életben maradásért küzd az 5x-ös villanyszámla és a 3x-os alapanyagárak mellett, napi 16-18 órát rohangászva H-V, nem pedig hófehér Jaguárral jár.

az ilyet nyilvan be kell zarni, mert nem eri meg csinalni. eddig sem erte meg, csak mostmar talan ertik, miert nem.

... van, aki a harmadik szívinfarktusán van túl.

mennyire megeri! ja, nem.

A legtöbbjüktől elvált már a párja, mert "nincs is férje".

pikacsu face! (ja, nem.)

De persze az éttermi bevétel után követeli a bíróságon a felét, amit a programom statisztikájából kifotózott.

termeszetesen, hiszen az jar neki. nem latok semmi osszefuggest a ketto kozott.

 

c'est la vie.

Az a baj, hogy Te az ügyfeled szemével nézed az egészet, nem szolgáltatói/vállalkozói szemmel. Az üzleted sikerénél és a rendszerek megfelelő működésénél fontosabb az ügyfél elégedettsége, ami kizárólag a fizetendő összegtől függ, semmi mástól.

Beleéled magad a helyzetükbe és ki akarod mindet segíteni. De ezt csak addig szabadna megtenni, amíg nem a Te károdra megy úgy anyagilag mint erkölcsileg. Ráaádsul látatlanba is biztos vagyok abban, hogy a magát nagyon rossz sorsúnak mondó pizzériások 80%-a messze nem olyan rossz sorsú, csak látja, hogy Rád ezzel lehet hatni. Nagyon kevés az olyan elhivatott bolond, aki egy sikertelen céget is visz tovább bármi okból, a legtöbben nemhogy a sikertelent, de a nem-annyira-sikeres-mint-szeretném céget is simán bezárják. Ez alapján tudható, hogy aki nem zárt be, az valójában sikeres.

Mi is dolgozunk együtt egy céggel, aki főleg kereskedik. Szolgáltatási területen pont ilyen a hozzáállásuk, mint Neked, hogy "dehát havi 10 ezernél többet nem lehet kérni tőlük IT üzemeltetésért, mert nincs miből kifizetniük, a vásárlási számlákat is óriási késéssel tudják csak fizetni". Így esetiben javítottak nekik mindent, sokszor bőven áron alul vagy ingyen, merthogy mondván nincs pénzük. Munkatársam lement tárgyalni az üzemeltetési szerződésről (mert belekeveredtünk egy szolgáltatásunkkal mi is az ügyükbe), korrektan elmondta, hogy mi mennyi munka, az mennyi pénz, ha saját emberrel oldák meg az mennyibe kerül és mikorra lesz olyan ember, mi mindent kellene venni beriházásként, ha nem szolgáltatásban akarnak fizetni ezt-meg azt, stb. Kötöttek is havi nettó 120 ezres szerződést az alapján az egy megbeszélés alapján, és fizetik is rendesen. Meg is van oldva minden rendesen. Mindenki elégedett. Ez azért történt így, mert a szolgáltató nem bízott magában, plusz elhitte az ügyfél sirámait. Ez csak egy példa a sok közül, amit tunék mondani ilyen témában.

Én egyébként ezek után szívesen segítenék Neked egy jó hálózati architektúra kitalálásában ha szeretnéd, ez a fő munkaterületem. Aztán ha kialakul egy jónak tűnő modell, akkor megvalósítod, mert látom, a munka elvégzésével nincs problémád. Így PM-ben, ha érdekel.

céginformációból is ki lehet hámozni

OFF: ... de nagyon.

Egy újonnan nyíló étteremnél aligha. És ez a jellemzőbb.

Ha már van valakinek programja, ritkán cseréli és kezd (iT analfabétaként) újratanulni mindent, felvinni az étlapot és a nyersanyagreceptúrát, allergéneket, árakat, felhasználókat, neveket, címeket, nyitóstandot, stb.

_____________________

Emellett, (amint a válófél esetéből utaltam már rá) a forgalomból semmit sem lehet kihámozni.

Volt olyan tulaj, aki a Covid idején a saját félretett vésztartalékából vitt be havonta 500-at, hogy ne kelljen kirúgni a 3 gyerekes, svájci hitelt nyögő pincér-apukát. (Fürdőváros, Szabolcs megye.)
És mikor bekrepált egy villámcsapásnál a PC-je, és odahoztak egy másik használtat gyorsan,
akkor mondjam ilyenkor, hogy:
 - Nem felel meg az általam szigorúan előírt szabványnak, nem telepítem fel rá a programot!

Pedig a Covid előtti forgalom teljesen más számokat mutatott.
De attól még mire mindent levon az ember, addigra jó ha nem szalad mínuszba.

Egy havi 5-8 milliós bevételnél egy "aprócska sajt drágulás" úgy át tudja billenteni a mérleget, hogy csak tátod a szádat hónap végén, hogy már megint a másodállásából kell behoznia a pénzt, hogy ki tudja fizetni az embereket.

+100 áremelésnél minimum 20%, de egyes helyeken akár 30-50%-kal visszaeshet a forgalom, amíg meg nem békélnek az emberek, illetve a műsajtos ehetetlen ízű konkurencia is emel 90 forintot.

(Gondolom nem kell példákat felhoznom arra, hogy a lakosság 98%-a az "óccót" választja a minőség helyett.)

____________________

Egy Budai jól menő pizzázó tulaja kiszámolta (még covid előtt) egy 6-füles giga excel táblában:

 - amennyiben minden Áfát, 12 órás munkabért, szolgáltatásokat, rezsit, IPA, környezetvédelmi díj, kéményseprő, Artisjus, stb. kifizet
 - 1000 Ft bevételre: -1032 Ft kiadás jutott.

Tehát rákényszerítik a becsületes vállalkozásokat, hogy ne legyenek azok !

A mostani rezsivel és csökkent bevétellel még rosszabb a helyzet.

____________________

És sorra zárnak be az üzletek. Egymás után. Az én ügyfeleim is.
De legalábbis átalakulnak:

  • Kirúgták a pincéreket,
  • megszüntették a kiszállítást, elküldték a futárt is, bezárják a webáruházat,
  • beáll a feleség a pultba, és
  • már csak napi 1-2 napot vannak nyitva egy-egy rendezvényre.
    Így nem kell egész héten fűteni / hűteni / szakácsot fizetni stb.

Akikről Te beszélsz, azok gondolom az olyan 1000 millás pályázati pénzből felújított üzletek, akiknél a "tudjuk kik" ebédelnek, 240 forintos Gundel palacsintát.  Nekem ilyen ismerőseim / partnereim nincsenek.

Ezért Tisztelettel megkérlek:

  • Ne általánosíts olyan kérdésekben, melyekbe nincs valódi belelátásod.

Köszönöm!

Ezen a HSZ-en jól láthatod magad is ha visszaolvasod kicsit más szemmel, hogy mennyire az ügyfeleid mellett állsz saját magad helyett. Az ő érdekeiket képviseled magad előtt és mások előtt is, nem a sajátodat.

Ez amit itt leírtál mind az a kamu magyarázat, amivel Téged megetetnek az ügyfeleid, hogy eszedbe se jusson bármin változtatni.

Az újonnan nyíló étterem azért nyílik, mert van lóvé és úgy érzik, hogy még többet fognak keresni, mint amit beletesznek. Ergo nem kell azzal jönni az újnak, hogy milyen magasak a költségei, és IT-ra már nem jut...

Az meg egy ordas kamu, hogy mindenki szívjóságból, a 3 gyerekes alkalmazott miatt működteti az egyébként rosszul menő éttermét. Itthon a KKV-k legtöbbje már akkor elküld embert, ha a tulaj egyik hónapban 5000 Ft-tal kevesebbet tud kivenni, mint az előzőben. Persze van kivétel, de az irtózat ritka, ha 100 ügyfeled van, akkor 3-ra tippelném a rendes tulajok számát belőle, 97 a mindenkit kihasználó élősködő.

A valóság az, hogy ahogy felmegy valaminek az ára, azt azonnal átterhelik az ügyfélre. Az ügyfél meg fizeti (max. valamilyen mértékben kikerekedik a szeme közben), csak ha már nem telik neki, akkor egyre ritkábban vásárol, majd egyszer csak nem vásárol. Nem igaz az, hogy egy emelésre eltűnik a vásárlóközönség. Pláne akkor, amikor mindenki emel, mert úgy alakult a világ.

A Covid-ot teljesen ki kell venni minden döntésből, magyarázkodásból, mert az egyszeri eset volt (persze előfordulhat ugyan ilyen gebasz, de az egy másik eset lesz). Arra viszont nagyon jó volt, hogy rávilágított, mennyi olyan vállalkozás van, aminek valóban nem szabadna lennie, mert az nem vállalkozás, amikor a tulaj hazavisz egy rosszabb fizetést belőle havonta, meg mellékállás kell a főállású vállalkozása mellé. Az ilyeneket nem sajnálni kell, hanem elengedni (mint ügyfelet).

Én salgótarjáni vagyok, ez egy lecsúszott, szegény város lett mostanra országos összehasonlításban. Ellenben vagy egy csomó pizzéria (kiszállítós, helyben fogyasztós kevés van, de az nem is volt sok soha), mindben 1-2 óra a várakozási idő (ergo van forgalmuk rendesen), a futárok nem saját kocsival, hanem a pizzéria által biztosítottal szállítanak (vagy Foodpanda, stb. bérszállító viszi), és van, ahol 4 futár is van egyidőben. Ahhoz azért eléggé szép bevétel kell, hogy csak a 4 kocsit megvegyék, felmatricázzák és fenntartsák, az összes többi költségről nem beszélve. Akkor egy ilyen hely havi pl. nettó 50 ezret simán ki tud fizetni az informatikára, ami mára a működésük alapja. És ez egy kifejezetten ruppótlan város.

A villámcsapott PC-s szeretetszolgálatos esethez: igen, mondd azt, hogy ez nem felel meg. Neked nem dolgod a vállakozásuk anyagi lehetőségeit figyelembe venni. Csak a saját vállalkozásodban dolgod az anyagiak figyelembe vétele. Ha valami tönkrement, és azt nem tudja kifizetni, akkor ott a vállalkozás működésének a vége (legalábbis egy időre). Ha tönkremegy a pizzasütő kemence, akkor mit csinál? Vesz egy rezsót, mert arra maradt csak? Nem. Megjavíttatja, vagy vesz újat. Pont így kell minden mást is nézni egy vállalkozásban. A boltban sem vették szerintem figyelembe a szegény ember helyzetlét, így a lisztet, sajtot, sonkét, satöbbit pont ugyan annyiért adták neki, nem lett olcsóbb semmi. Meg kevesebbet sem tehet hirtelen a kész ételre, mert akkor nem fogják megvenni.

A budai menő pizzázós eseted egyenesen nevetséges. Mármint az, hogy elhiszed neki, hogy megmagyarázza az idióta gazdag budai "vállalkozó", hogy neki muszáj lopni-csalni-hazudni-kihasználni, mert magasabb a költsége, mint a bevétele. Ennek ellenére évek óta sikeresen működik még mindig budán. Hát persze.

Kész ételt és italt árulni mindig is a világ egyik legjobb üzlete volt, az egyik legmagasabb árréssel. Ha más tud működtetni mondjuk kereskedelmi vállakozást mondjuk 25% átlag árréssel havi 10 millió bevétel mellett X fővel, akkor egy étterem is tudjon már havi 10 millió bevétel mellett X fővel jól működni, miközben 70% körüli az árrésük...

Nincsen semmi baj a filantrópiával, csak kell mellé egy jól fizető állás vagy régebbről gyűjtött tőke. De ha most nem vagy gazdag és nem hobbi ez a tevékenység, akkor pár év múlva te szorulsz arra, hogy valaki kisegítsen. Reális, hogy téged, a beszállítót ki fognak segíteni ezek az ügyfelek? 

Vagy a másik irányból is lehet nézni, mert ezt szoktam gyakran hallani ráfizetéses projekteknél: várható, hogy később valami nagyobb, jól fizető megrendelésed legyen tőlük? Mert akkor ez egy befektetés.

Persze, simán létezik, hogy valamilyen üzletágba itthon nem érdemes belefogni. Ha ők viszik a veszteséges vállalkozást, idokolt -e / érdemes -e neked is veszteségbe kerülni és elveszteni idődet, pénzedet?

Vagy úgy is feltehető a kérdés, hogy adott esetben neked lesz-e luxuskocsid és több évre elegendő tartalékod a bankban, hogy finanszírozd magadat nehezebb időkben? Ha a megsajnált cégvezetőnek van, neked viszont nincs, akkor valaki túl hiszékeny.

" Nekem ilyen ismerőseim / partnereim nincsenek."  "az én ügyfeleim picik, többségük az életben maradásért küzd" 

Szóval kizárólag csóró ügyfeleid vannak, akik nem engedhetik meg, hogy megfizessék a szaktudásodat, de te ennek ellenére egyre több és több energiát ölsz bele ebbe a bizniszbe, ahelyett, hogy a "B" terven dolgoznál.

Így van. Meg ilyen messzire nem kell menni, az látszik mit és mennyit vesznek, és mennyi alkalommal kell bármit csinálni nekik eseti fizetős alapon.

Mi magunk nem így üzletelünk. Egyáltalán nem vesszük figyelembe az ügyfél bemondott vagy valós anyagi helyzetét (azt az ügyfél maga mérje fel, hogy mire mennyi pénze van, és ki akarja-e nekünk vagy másnak fizetni), hanem az igényeik alapján számolunk egy árat, és arról tárgyalunk. Nyilván van valamennyi mozgástér, de ezen belül sem engedünk csak úgy az árból, hogy olcsóbb legyen, hanem mindig elveszünk valamit az igért szolgáltatásból is olcsósításnál (még ha az csak egy mondvacsinált tétel is), nehogy az legyen, hogy velünk lehet alkudozni. Nem lehet. Az elvárásokat lehet újragondolni és arra új árat kérni. Aztán meg van olyan, hogy bizonyos szint alá nem megyünk (ezt inkább szolgáltatás minőségre-tartalomra értem, és ez ad egy minimum árat is), meg van olyan, hogy bizonyos dolgokat nem vállalunk bármilyen feltétellel (pl. VPN szervert vagy épp adatmentést nem csinálunk egyszeri munkaként, csak üzemeltetési szerződéssel, mert úgy is van vele folyamatos feladat és felelősség aztán).

Sajnos nagyon sokan nem bíznak a tudásokban, nem hiszik el annak értékét, és nem merik elkérni a valódi pénzbeni ellenértéket. Ez sokszor amitt van, hogy mások meg nem igazán értenek hozzá, így bármennyit kapnak érte, az nekik talált pénz. A gyorsan összekókányolt melókból meg sokat vállalnak a kevés pénz ellentételezésére. Így lenyomják az árakat olyan szolgáltató vállalkozásoknál is, akik értenek hozzá, csak nem elég magabiztosak a tudásukban, eszmei és pénzbeni értékükben.

én sem az ügyfél anyagi helyzete alapján árazok, hanem úgy ahogy te is írtad, de egy adósságtengert maga előtt görgető cégnek maximum akkor dolgozok, ha előre fizet.... nem szeretek ingyen dolgozni, és a hosszú lejáratú hitelezés sincs a tevékenységi körömben.
 

kicsit off:

a napokban mutattott nekem a haver - egy 3 oldalas céges weboldalt (WP + Business & law free theme) - a webfejelsztő cég 1 milliónál tart és még nincs kész. kb. 2 napos munka volt - minden annyit ér, amit el lehet érte kérni..

nem tudom a story végét, hogy ki van-e fizetve, de dobtam egy hátast..

(nem állami - tisztán piaci cég)

For Whites Only meeting room!

Csak 100millió feletti árbevétel esetén lesz kötelező adatszolgáltatás - most még.

Ekkora cég már ki tudja köhögni a VPN árát a többire meg maradt időd megcsinálni.

For Whites Only meeting room!