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

HTV – Könnyű, gyors és titkosított távoli asztal (fejlesztés alatt)

A HTV egy saját fejlesztésű, jelenleg is aktívan fejlesztett távoli asztal program, amelynek célja egy könnyű, gyors, de biztonságos alternatíva nyújtása a népszerű távvezérlő megoldásokra. A projekt több fejlesztő együttműködésével készül, fókuszban a teljesítmény, egyszerűség és hordozhatóság.

✅ Alapfunkciók:

• Távoli vezérlés – Interaktív desktop hozzáférés
• Attended & Unattended hozzáférés – Felhasználói jelenléttel vagy nélküle
• Fájlátvitel – két gép között, beépített fájlkezelő felülettel

⚙️ Technikai megvalósítás:

• P2P kapcsolat UDP-n keresztül, BBR congestion control alkalmazásával
• Saját képkódoló (codec) alacsony késleltetéssel és jó tömörítéssel
• Keresztplatformos (Windows/Linux), bár a legtöbb funkció jelenleg csak Windows alatt működik

🔐 Biztonság:

• AES titkosítás minden hálózati adatcsomagon
• Jelszóval védett hozzáférés

🖥️ Felület & kezelhetőség:

• Windows tálca ikon
• HUD típusú ablak távoli gépen
• Beépített fájlkezelő

📦 Kompatibilitás & Telepítés:

• Windows és Linux kliensek (Linuxon csak kliens)
• Telepítésmentes, egyetlen .exe fájl (Windows-on), nem igényel admin jogokat

⭐ Kiemelt egyediség:

• Extrém kis méret: jelenleg ~650 KB
• Gyorsabb kapcsolatépítés és adatátvitel, mint más távoli asztal programoké, köszönhetően a BBR-alapú UDP protokollnak

📥 Letöltés:

➡️ https://mediscope.hu/htv.exe

➡️ https://mediscope.hu/htv_unpck.exe UPX mentes verzió.

➡️ https://mediscope.hu/htv_linux

Google drive

Véleményeket, hibajelentéseket és ötleteket szívesen fogadunk itt a fórumban. 😊

Sziasztok,

E-mail szolgáltatót keresek, aki saját domainemmel, 2-5 fiókkal, imappal elbír.

Mit tudnátok ajánlani?

Ami van kéznél:

• Linuxos PC-k, több is (most épp Debian 12)
• Windows PC-k, több is (most épp Windows 11)
• Naprakész böngészők (most épp Firefox 128ESR, Chrome 136, Edge 136)
• Szűz böngésző-profilok (mindenféle tárolt előzmény és kukik nélkül)
• Többféle Internet-kapcsolat (Telekom GPON, Vodafone DOCSIS, NIIF egyetemi háló, stb.), dual-stack IPv4 és IPv6 konnektivitás.

Sorozatosan futok bele abba a problémába, hogy a különböző weboldalakon a reCAPTCHA-kat képtelenség megfejteni. Végtelen ciklusban adja az újabb és újabb feladványokat, majd néhány feladvány után kiírja, hogy "try again later".

A Google nem segít. Ezernyi hasonló találat van, tehát nem vagyok egyedül a problémával, de valódi megoldást nem sikerült köztük találni.

A tapasztalatok alapján, Chrome-ból a legnagyobb a success rate, de ott is távol van a 100%-tól. Az esetek kb. 60%-ában 4-5 feladvány után megjön a zöld pipa. Már a 4-5 feladvány is bosszantó, de a legnagyobb probléma az, amikor egyáltalán nem jön meg a zöld pipa. A legrosszabb a helyzet talán Firefoxban, ahol a feladványok többségét egyáltalán nem lehet megfejteni, tippre a success rate 10% alatt van.

A probléma a demo oldalon is jelentkezik:
https://google.com/recaptcha/api2/demo

Próbálkoztam sok mindennel:

• Enhanced tracking protection kikapcsolása,
• Mindenféle XSS protection kikapcsolása,
• Reklámszűrő kikapcsolása,
• A Javascript konzolon lévő mindenféle errorok és warningok debuggolása
• Szűz profil, pornómód, stb.
• User agent string módosítás
• IP cím váltás

Ezek egy része talán érzésre javított a success rate-en, legalábbis igéretesnek tűnt, aztán pár órával később ugyanúgy nem sikerült megfejteni a captchákat.

A dolog ott lett tarthatatlan, hogy manapság már sok olyan weboldal is recaptcha-val védett, ami a mindennapos munka során létfontosságú. (Ideértve pl. állami/közigazgatási oldalakat is)

Kinek mik a tapasztalatai?

Mielőtt még megírnátok:

• Nem, nem vagyok robot
• Igen, felismerem a tűzcsapokat, motorkerékpárokat, lépcsőket és közlekedési lámpákat

Sziasztok!

Most,hogy a Pro M Zrt átvette a sulinet üzemeltetését nem tudom pontosan kinek és hogyan is kellene megfogalmaznom az igényeinket. Ebben kérem a tisztelt segítségeteket!

Jelenleg van egy weboldalunk az intézménynév.edu.hu domainen. Ennek van természetesen https elérése. Van az intézmény belső VLAN védett hálózatán egy proxmox szerver sok kis apró szolgáltatással (nextcloud, smb, media, pihol, stb) 2 éve hibátlanul működik. Ez természetesen kívülről nem elérhető és ezen nem is szeretnénk változtatni. Jelenleg ip:port eléréssel használjuk a szolgáltatásokat. Amit szeretnénk, hogy intézményen belül működjön egy névfeloldás és https az összes subdomainen. Tehát pl https://media.intézménynév.edu.hu vagy https://nc.intézménynév.edu.hu és így tovább. 

A dns feloldás megoldható szerintem, mert a dashboard felületen ki lehet választani, hogy az adott domainhoz milyen ip-vel szeretnék subdomaint rendelni. 

Kérdéseim:

Szóval lehetséges egyáltalán, hogy a meglévő oldal ssl tanúsítványát használjuk? Ha nem milyen free megoldások adottak? Ha a proxmox szerveren beállítom a https elérést minden szolgáltatást is külön kell konfigurálni, vagy automatikusan veszik át a tanúsítványt? Mennyiben okoz gondot, hogy az egész  miskulancia védett VLAN mögött van? 

Köszönöm!

modern, secure, all-in-one email server

És jók-e a tapasztalatai?
Gyorsan össze kéne dobnom egy mailszervert 1-2 ilyen nempublikus fejlesztős domain alá. a webmail a kb. minimális elvárás

Sziasztok!

Let's Encrypt tanúsitványt akartam megújítani (lego acme), de hibába futok bele, pedig évek óta fut a megújítás három havonta.
Elsőként alkalommal CAA rekordot keresett, ezért nem újította meg. Ezt megoldottam. Erre mint egy kalandjátékban új akadály jött:
A mail.cegnev.hu domainra újítanám meg, itt a megújítás kimenete

2025/04/26 22:54:49 [INFO] [mail.cegnev.hu] acme: Trying renewal with 133 hours remaining
2025/04/26 22:54:49 [INFO] [mail.cegnev.hu] acme: Obtaining bundled SAN certificate given a CSR
2025/04/26 22:54:50 [INFO] [mail.cegnev.hu] AuthURL: [eltávolítottam]
2025/04/26 22:54:50 [INFO] [mail.cegnev.hu] acme: use tls-alpn-01 solver
2025/04/26 22:54:50 [INFO] [mail.cegnev.hu] acme: Trying to solve TLS-ALPN-01
2025/04/26 22:55:35 [INFO] Deactivating auth: [eltávolítottam]
2025/04/26 22:55:35 error: one or more domains had a problem:

[mail.cegnev.hu] acme: error: 400 :: urn:ietf:params:acme:error:dns :: DNS problem: query timed out looking up A for mail.cegnev.hu; DNS problem: query timed out looking up AAAA for mail.cegnev.hu, url:

A DNS A rekordjának a lekérdezése nem sikerül. Amit ma beállítottam, az egy CAA rekord volt, mert erre is panaszkodott a megújítás kérésekor (legutóbb még nem).
A DNS-ben ugyanolyan elnevezéssel szerepel egy 'CAA' és egy 'A' rekord is ("mail")

A googli szerint másnak is volt ilyen gondja és a nameserver üzemeltetője oldotta meg. Írtam már én is nekik, de hétvége van.

Más futott bele ilyenbe, mi lett a megoldás?
Köszi

szilárd

Frissítés1 

Sziasztok!

Egy kis segítséget szeretnék kérni. Napi szinten küld a részünkre a román posta elszmolásokat emailben, amit az email szolgáltatónk rfc meg nem felelés miatt elutasít, tehát nem kapjuk meg.

Részletek:

A RO posta a levelet elküldi az info@muzeugelarie.ro és a mindenki.mef@gmai.com címre. A gmailes címre megjön, a másikra nem.
A levelező szolgáltatónk tájékoztatása szerint a következő hibaüzenettel utasítja el a rendszerük a levelet:

F=<mindenki.mef+caf_=info=muzeugalerie.ro@gmail.com> rejected after DATA: syntax error in 'From:' header when scanning for sender: malformed address: <noreply@ro.post> may not follow noreply@ro.post  in "noreply@ro.post <noreply@ro.post>"

Valamint a kommentjük: ha az e-mail címhez tartozó név speciális karaktert is tartalmaz, akkor idézőjelben kell lennie. ( RFC5322 ). Ezt a hibaüzenet - amit már továbbítottuk - egyértelműen jelzi.

A román postával igen nehéz a kommunikáció. Mit írjunk nekik, mit kellene változtatniuk, hogy jó legyen a levél, ne legyen ez a hiba? Ugyanis én nem látok a címben hibát.

Mellékelem az üzenet fejlécét:

Delivered-To: mindenki.mef@gmail.com
Received: by 2002:ac8:624d:0:b0:475:1c70:5e76 with SMTP id kt13csp2582982qtb;
        Tue, 15 Apr 2025 01:06:42 -0700 (PDT)
X-Forwarded-Encrypted: i=2; AJvYcCWEok/1ho2cIdH3oJFI6Y5RMn804sE9kwH0/lt7Qm47QoAXckXlUWDcYIcr9gpLbZw6YOXp63rxdU4mZtk=@gmail.com
X-Google-Smtp-Source: AGHT+IHo2jidAuj42aqduBWYKbprz1Bc2NJifA/Tm4kFTVIx1/ms/peJg+8PUY+2dGLc09S0QsQN
X-Received: by 2002:a05:690c:6907:b0:6ef:6f24:d093 with SMTP id 00721157ae682-7055998ec9dmr256024867b3.6.1744704402446;
        Tue, 15 Apr 2025 01:06:42 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1744704402; cv=none;
        d=google.com; s=arc-20240605;
        b=J4EZKEmmPu4i6JExVxVf50WbnB9H+ZEATJEkfD+I9cABm/yGhwcCGwIVxabwTpV0Rp
         eeGXIapQfwraPmQy8V3oYiSd8rzvSX5L5KnYhe2L0SC8RzPnHTJnl3Vu3ggiuPWpiyKP
         yab/aZDLXWa9AhahLvdhpSNdA12rEBc9qRocHwgiFkynYuqBLk1TIJx8PN8ZphRGpTvX
         y6dq6DNyZoML2NYHQYN5wNGQ79Ruo8MJEtUAD/ijD3wTySNyFz9sgZIcpW6Nv92e9yfl
         oL3sRJnNGTfTz1Kheq3GOcL7GJL/ecSfX4h3XlKZJcQDjY4QUHEbIZ4BBOO8BJYifGPs
         xoFg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
        h=date:from:message-id:subject:to:mime-version:dkim-signature;
        bh=nkFlSPE1Gqb9ZI12fVBS5TRoG3p7XBBqPkb6hcwh64A=;
        fh=H79OlrvpVRihXO/Nsw1P9iOFDUweI01BTcqHzBet9Ag=;
        b=Lhyfpwn0VCjQ0F1fuctNFtVYvir16BzndhVCIil76DN5GWl3kgr8Wq1PhK6DtLpFmK
         KGyBmnfcE91PYvDCSymI//500F9ooz+O+31Xzk9/y3TbloRA9Fhbo18RTLppPfrUzJ8R
         Q7OCxTs4fQJBAzUkRB8oAzalfdXjYTZ6q6gH4swQ/z16j4sA2HNerge9xDJGgOoETs4Q
         B9w0It3ah/qrBBeE6Z9QijFlHncEpmYEbs1GutbR7vs2o1Rp0dwnbBuCugGjjEhT6lbZ
         peU0wWa/lkX9czOL3SE4SGWKY5QAb/emWLymqNqwjn89vJ68PEHELvOb6ty5LgSfwDiR
         10BQ==;
        dara=google.com
ARC-Authentication-Results: i=1; mx.google.com;
       dkim=pass header.i=@ro.post header.s=nzath202411 header.b=HhGMELia;
       spf=pass (google.com: domain of msprvs1=20200vwvwymka=bounces-1682@spmailtechnolo.com designates 147.253.211.76 as permitted sender) smtp.mailfrom="msprvs1=20200vwvWYMKa=bounces-1682@spmailtechnolo.com";
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=ro.post
Return-Path: <msprvs1=20200vwvWYMKa=bounces-1682@spmailtechnolo.com>
Received: from mta-253-211-76.smtp-out.sparkpostmail.com (mta-253-211-76.smtp-out.sparkpostmail.com. [147.253.211.76])
        by mx.google.com with ESMTPS id 00721157ae682-7053e138665si193917327b3.143.2025.04.15.01.06.42
        for <mindenki.mef@gmail.com>
        (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
        Tue, 15 Apr 2025 01:06:42 -0700 (PDT)
Received-SPF: pass (google.com: domain of msprvs1=20200vwvwymka=bounces-1682@spmailtechnolo.com designates 147.253.211.76 as permitted sender) client-ip=147.253.211.76;
Authentication-Results: mx.google.com;
       dkim=pass header.i=@ro.post header.s=nzath202411 header.b=HhGMELia;
       spf=pass (google.com: domain of msprvs1=20200vwvwymka=bounces-1682@spmailtechnolo.com designates 147.253.211.76 as permitted sender) smtp.mailfrom="msprvs1=20200vwvWYMKa=bounces-1682@spmailtechnolo.com";
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=ro.post
X-MSFBL: c1u0l6v9TKSDEcFzVBk7tEyjyzsWoMmlkIMWsjx7VOI=|eyJ0ZW5hbnRfaWQiOiJ zcGMiLCJtZXNzYWdlX2lkIjoiNjdmNDkxMTNmZTY3M2RlMzIxOTgiLCJzdWJhY2N vdW50X2lkIjoiMCIsImN1c3RvbWVyX2lkIjoiMTY4MiIsInIiOiJtaW5kZW5raS5 tZWZAZ21haWwuY29tIn0=
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ro.post; s=nzath202411; t=1744704402; i=@ro.post; bh=nkFlSPE1Gqb9ZI12fVBS5TRoG3p7XBBqPkb6hcwh64A=; h=To:Subject:Content-Type:Message-Id:From:Date:From:To:Cc:Subject; b=HhGMELia+y9hhY6u3fDJFcHu+HHtQG5Nkm2Y5neiCx9tCLauAOsqNANq5/SxW7AYF
     iFNi6yo8FxxSw20yz7UuH4rWU2kC6tDeEaNOpxg3PPT92bQdW85woE4BXL8miw7VXn
     5dybjuuYmcihs09Hiz30lmPc5iNDhw2gNSUpTI6g=
Authentication-Results: i-0d93dc8e2d1653229.mta1vsmtp.sd.prd.sparkpost smtp.user=<hidden>; auth=pass (PLAIN)
Received: from [159.69.68.133] ([159.69.68.133:56002] helo=nl) by i-0d93dc8e2d1653229.mta1vsmtp.sd.prd.sparkpost (envelope-from <t-bounce-8ed73a2e-19d0-11f0-8db7-1118684969ec@nl.ropost.ro>) (ecelerity 4.8.0.74368 r(msys-ecelerity:tags/4.8.0.17)) with ESMTPSA (cipher=AES-256-GCM) id 89/1A-64280-1931EF76; Tue, 15 Apr 2025 08:06:42 +0000
MIME-Version: 1.0
To: "info@muzeugalerie.ro" <info@muzeugalerie.ro>, "mindenki.mef@gmail.com" <mindenki.mef@gmail.com>
Subject: Fisiere : MUZEU GALERIE SRL transmise in data : 15-04-2025
Content-Type: multipart/mixed; boundary="----MIME delimiter for sendEmail-565177.01277426"
Message-Id: <20250415080638.35623.8ed73a2e-19d0-11f0-8db7-1118684969ec.nl@nl.ro.post>
X-Newsman-RP: t-bounce-8ed73a2e-19d0-11f0-8db7-1118684969ec@nl.ro.post
From: "noreply@ro.post" <noreply@ro.post>
Date: Tue, 15 Apr 2025 08:06:39 -0000

 

Gábor

Sziasztok!

Érdekelne, hogy más rendszerüzemeltetőknél is előfordul-e néhanapján a következő jelenség:

A "néhanapján" időintervallumot nem tudom pontosan definiálni, hiszen a tavalyi évben ha jól emlékszem kétszer fordult elő, idén pedig most hétvégén először.

Tehát olykor előfordul, hogy egy adott M365 tenantban láncreakciószerűen (tehát nem egyszerre, hanem 1-2 órán belül folyamatosan, egymás után) "kitörlődnek" a felhasználók jelszavai. Néhány érdekesség:

- Két rendszert üzemeltetek, tavaly volt olyan, hogy egyszerre mindkettőnél elindult ez a folyamat. A mostani hétvégén érdekes mód csak az egyik rendszert (m365 tenantot) érintette.

- Egyetlen egy felhasználó mégis vissza tudott logolni az általa felírt jelszóval, a többiek nem, nekik teljesen újakat kellett generálnom.

- Nagyon fontos: NEM MINDEN felhasználó jelszava törlődik ilyenkor! Körülbelül 5-10% részénél nincsen probléma.

- Igen, használok AD Sync-et, pontosabban most már Entra Sync-et ugyebár.

Valakinek valami ötlet/gondolat/tipp esetleg?

Nagyon köszönöm előre is!

Üdv!

Arról érdeklődöm, hogy van-e a gmail-nél olyan lehetőség, hogy megnézzem, hogy egy adott levelet kitöröltem-e? Tehát, tudom, hogy elküldtem adott dátumon adott címre, de szeretném tudni, hogy valamikor törölve lett-e, ha nem találom a gmail-es mappáim között?

Avagy a törölt leveleket el lehet valahol érni, amik a kukából is elkerültek már?

Nézegettem ezt a takeout-ot, de óriási adathalmazt generál, egyelőre nem látom át.

Köszönöm.

Sziasztok!

 Néhány kolléga kínába utazik hamarosan. Jelenleg mikrotik routeren beállított saját VPN-t használunk, melyet már számos európai országból teszteltek az elmúlt években, nem volt vele gond. Viszont Kína egy más kategória ugye az ottani igen erős szigorítások miatt. Kérdésem, van-e valakinek tapasztalata ottani nethasználatot illetően? Szerintetek onnan fog-e menni a saját VPN elérése, vagy mindenképp elő kellene fizetni olyan VPN kliensre, melyet például utazási oldalak is hirdetnek?

Segítségetek előre is köszönöm!