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

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?

@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.

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.)

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

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

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.

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.

Szerk:

áttettem ide, a külön SSL kérdéskörben nyitott topikba.

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.

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.

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.

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.

• Tunsafe
• https://www.dwservice.net/
• rustdesk
• meshcentral

______________

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...

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.

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.