Hálózatok általános

Üdv,

van itthon egy kis ITX-es gép, ez a tűzfal meg mindenes. Kicsit elhanyagoltam, és még mindig Debian 9 volt rajta - tegnapig, mikoris' hirtelen felindulásból upgradeltem 10-re, majd 11-re, végül 12-re.

Minden frankón működik, kivéve egy dolgot: a kliensről, ami NAT mögött van, nem megy a PPTP. (Most mindegy, hogy mennyire régi/elavult/... - van olyan ügyfél, ahol csak PPTP VPN van, és nekem mindenképp be kell jutnom).

Minden más VPN megy: OpenVPN (ok, ez sima ügy), L2TP+IPSec.

PPTP-ből egyik kiszolgáló sem. Frissítés előtt még ment mindegyik, a szerverek nem lettek átkonfigurálva, és a kliens sem.

A szerveren ezt látom a logban:

Sep  6 23:04:54 server pppd[4038238]: rcvd [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x5be9fa7f> <pcomp> <accomp>]
Sep  6 23:04:54 server pppd[4038238]: sent [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0x5be9fa7f> <pcomp> <accomp>]
Sep  6 23:04:54 server pppd[4038238]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <auth chap MS-v2> <magic 0x858d2da8> <pcomp> <accomp>]
Sep  6 23:04:57 server pppd[4038238]: LCP: timeout sending Config-Requests
Sep  6 23:04:57 server pppd[4038238]: Connection terminated.
Sep  6 23:04:57 server pptpd[4038224]: CTRL: Reaping child PPP[4038238]
Sep  6 23:04:57 server pppd[4038238]: Modem hangup
Sep  6 23:04:57 server pppd[4038238]: Exit.
Sep  6 23:04:57 server pptpd[4038224]: CTRL: Client 188.36.30.196 control connection finished

A kliensen ezt:

Sep  6 23:04:22 basil pptp[363633]: nm-pptp-service-363605 log[ctrlp_rep:pptp_ctrl.c:258]: Sent control packet type is 1 'Start-Control-Connection-Request'
Sep  6 23:04:22 basil pptp[363633]: nm-pptp-service-363605 log[ctrlp_disp:pptp_ctrl.c:781]: Received Start Control Connection Reply
Sep  6 23:04:22 basil pptp[363633]: nm-pptp-service-363605 log[ctrlp_disp:pptp_ctrl.c:815]: Client connection established.
Sep  6 23:04:23 basil pptp[363633]: nm-pptp-service-363605 log[ctrlp_rep:pptp_ctrl.c:258]: Sent control packet type is 7 'Outgoing-Call-Request'
Sep  6 23:04:23 basil pptp[363633]: nm-pptp-service-363605 log[ctrlp_disp:pptp_ctrl.c:900]: Received Outgoing Call Reply.
Sep  6 23:04:23 basil pptp[363633]: nm-pptp-service-363605 log[ctrlp_disp:pptp_ctrl.c:938]: Outgoing call established (call ID 37670, peer's call ID 10368).
Sep  6 23:04:53 basil pptp[363620]: nm-pptp-service-363605 warn[decaps_hdlc:pptp_gre.c:226]: short read (-1): Input/output error
Sep  6 23:04:53 basil NetworkManager[363615]: Child process /sbin/pptp 1.2.3.4 --nolaunchpppd --loglevel 0 --logstring nm-pptp-service-363605 (pid 363618) terminated with signal 15
Sep  6 23:04:53 basil pppd[363615]: Child process /sbin/pptp 1.2.3.4 --nolaunchpppd --loglevel 0 --logstring nm-pptp-service-363605 (pid 363618) terminated with signal 15
Sep  6 23:04:53 basil pptp[363620]: nm-pptp-service-363605 warn[decaps_hdlc:pptp_gre.c:238]: pppd may have shutdown, see pppd log
Sep  6 23:04:53 basil pptp[363633]: nm-pptp-service-363605 log[callmgr_main:pptp_callmgr.c:245]: Closing connection (unhandled)
Sep  6 23:04:53 basil pptp[363633]: nm-pptp-service-363605 log[ctrlp_rep:pptp_ctrl.c:258]: Sent control packet type is 12 'Call-Clear-Request'
Sep  6 23:04:53 basil pptp[363633]: nm-pptp-service-363605 log[call_callback:pptp_callmgr.c:84]: Closing connection (call state)

Próbáltam a tűzfalról is cli-ből (`pon` parancs), akkor a szerver logban ez látszik:

Sep  6 23:08:01 server pppd[4039609]: rcvd [LCP ConfReq id=0x1 <mru 1396> <asyncmap 0x0> <magic 0xadf9fbfd> <pcomp> <accomp>]
Sep  6 23:08:01 server pppd[4039609]: sent [LCP ConfAck id=0x1 <mru 1396> <asyncmap 0x0> <magic 0xadf9fbfd> <pcomp> <accomp>]
Sep  6 23:08:02 server pppd[4039609]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <auth chap MS-v2> <magic 0xacddbe04> <pcomp> <accomp>]
Sep  6 23:08:05 server pppd[4039609]: Modem hangup
Sep  6 23:08:05 server pptpd[4039608]: CTRL: Reaping child PPP[4039609]
Sep  6 23:08:05 server pppd[4039609]: Connection terminated.
Sep  6 23:08:05 server pppd[4039609]: Exit.

a kliensnél pedig ez:

2024-09-06T23:07:34.017199+02:00 thorp pptp[1301]: anon log[ctrlp_rep:pptp_ctrl.c:259]: Sent control packet type is 1 'Start-Control-Connection-Request'
2024-09-06T23:07:34.026354+02:00 thorp pptp[1301]: anon log[ctrlp_disp:pptp_ctrl.c:781]: Received Start Control Connection Reply
2024-09-06T23:07:34.027349+02:00 thorp pptp[1301]: anon log[ctrlp_disp:pptp_ctrl.c:815]: Client connection established.
2024-09-06T23:07:35.017319+02:00 thorp pptp[1301]: anon log[ctrlp_rep:pptp_ctrl.c:259]: Sent control packet type is 7 'Outgoing-Call-Request'
2024-09-06T23:07:35.026838+02:00 thorp pptp[1301]: anon log[ctrlp_disp:pptp_ctrl.c:900]: Received Outgoing Call Reply.
2024-09-06T23:07:35.028559+02:00 thorp pptp[1301]: anon log[ctrlp_disp:pptp_ctrl.c:939]: Outgoing call established (call ID 41702, peer's call ID 10496).
2024-09-06T23:08:04.990540+02:00 thorp pppd[1288]: LCP: timeout sending Config-Requests
2024-09-06T23:08:04.994278+02:00 thorp pppd[1288]: Connection terminated.
2024-09-06T23:08:05.015707+02:00 thorp pptp[1290]: anon warn[decaps_hdlc:pptp_gre.c:226]: short read (-1): Input/output error
2024-09-06T23:08:05.018355+02:00 thorp pptp[1290]: anon warn[decaps_hdlc:pptp_gre.c:238]: pppd may have shutdown, see pppd log
2024-09-06T23:08:05.021469+02:00 thorp pptp[1301]: anon log[callmgr_main:pptp_callmgr.c:245]: Closing connection (unhandled)
2024-09-06T23:08:05.030175+02:00 thorp pptp[1301]: anon log[ctrlp_rep:pptp_ctrl.c:259]: Sent control packet type is 12 'Call-Clear-Request'
2024-09-06T23:08:05.032816+02:00 thorp pptp[1301]: anon log[call_callback:pptp_callmgr.c:84]: Closing connection (call state)
2024-09-06T23:08:05.034784+02:00 thorp pppd[1288]: Modem hangup
2024-09-06T23:08:05.036844+02:00 thorp pppd[1288]: Exit.

A tűzfalon a conntrack modulok be vannak töltve. Az iptables-ben minden át van engedve, nincs eldobott csomag.

Viszont nem találok semmi érdemi megoldást 6.1-es kernel esetén.

Bármilyen ötletet szívesen veszek.

Egyik ügyfelünk nemrég újította meg a szerződését Palo Alto eszközökre és (feltételezhetően csali jelleggel) bedobott a sales SD-WAN licenszeket a tűzfalakhoz. Mivel mindenki nyargalja most a SASE vonalat, ők is szeretnék tudni, hogy a PAN-OS SD-WAN mire képes a Prisma-val szemben, amit ugye a CloudGenix-től vett a Palo. Én azt látom, hogy a PAN-OS alapú SD-WAN előnye, hogy nem kell hozzá új hardware, hanem mehet az edge tűzfalakra és emiatt nagyon erős lesz a megoldás biztonság terén. Hátránya, hogy relative nehéz összerakni, mert kevés a fabric automatizáció benne és kevés az SD-WAN feature benne, amit más gyártóknál megszokott az ember. Olyan SD-WAN "light" hatása van nekem. A Prisma ezzel szemben full SASE és könnyűnek tűnik (:D) összedobni, de kellenek hozzá pluszban ezek az ION eszközök, amik inkább routerek, mint tűzfalak, tehát csak valami gyenge kis packet filter van bennük.

Valaki Palo Alto guru el tudja nekem mondani szerinte hova pozícionálja a gyártó ezt a két különböző SD-WAN megoldást?

Köszi!

Sziasztok.

Új helyre költözünk, utcában Telekom optika föld alatt. Kivitelező a ház gépészeti helyiségéből húzott egy csövet a Telekom egyik szerviz aknájáig, amiből elvileg az említett csövön keresztül befűzheti az optikai kábelt a lakásba. A cső egészen a beton akna széléig el van víve, és a betonakna egyik oldalán közvetlen a betonakna szélénél kandikál ki a földből.

- Tegnap jön a Telekom embere, hogy bekösse az az optikát. Rögtön az első kérdése kérdése, hogy hány kanyar van a csőben, és meg van-e valahol szakítva a cső mert szerinte sok a kanyar(3-4 max. kötődobozból fel a padra, ház szélénél le a fölébe, onnan el az aknáig)  és biztos nagy lesz a csillapítás ő így nem köti csak ha elvághatja a csövet (ha elvágja csövet sem ússza meg szerintem kevesebb kanyarral :) ). 

- Eközben megérkezett a kivitelezőm villanyszerelője is aki előkészítette a csövezést, és olyan szépen összevesztek a Telekomos szakival azon, hogy most kinek a feladata a csövet az aknába bevezetni és hogy az akna melyik oldalán kell bevezetni, hogy csak na. A vége az lett, hogy Telekomos srác telefonált, majd jön egy ásó csapat 2 héten belül aki kiássa azt az 1 méteres szakaszt és bedugja a gégecsövemet az aknába majd ha ez megvan, megint két héten belül jön valaki aki ténylegesen beköti az optikát. De hogy én hogy a piklibe fogok 9 nap múlva, mikor lejár a szabim dolgozni net nélkül az nem érdekel senkit ...

Szóval két kérdésem lenne ezzel kapcsolatban: 

- én nem értek az optika hálózatokhoz, tényleg számít hány kanyar van abban a gégecsőben?

- ki a búbánatnak kellet volna azt a nyüves csövet bedugni az aknába? Mert nekem nem büdös a munka kiásom azt 30-100 cm!!! (igen centiméter) "árkot". De én azt megtehetem? Azt sem tudom hol futkároznak ott a kábelek, mi van ha átvágok valamit ...

Szerk:

Na megtörtént a bekötés a mai napon.

Garázsban födém alatt kb 10 cm-re falban egy kötődoboz onnan megy a kpe cső a  padlásra, ház szélén le, föld alatt megy az aknáig. Aztán kiderült, abban az aknában nem volt valami és nem tudtak rákötni, de a következő aknában mókolva megoldották valahogy. A két ásó emberke bevitte a kpe csövet az aknába. Előttem lévő aknából meg valami merev kábelbehúzót szó szerint átkalapáltak a a kpe csövön. Egy helyen kellet átvágniuk a kpe csövet, de korrekt módon tettek rá valami összekötőt hogy folytonos legyen. Majd a "merev" kábelbehúzó végére tettek egy bálázómadzagot (konkrétan Claas márkájút :D ) azt visszahúzták az aknába majd azzal behúzták az optikát s ment szépen a dolog. 

Az egyetlen negatív dolog hogy az egyik ásó emberke a földes izzadt tenyerével a frissen hófehérre vakolt házfalnak támaszkodott és ott virít a fazon egy baták nagy tenyérlenyomat.

Sziasztok,

A véleményetekre lennék kíváncsi.

10+ éve "hagyományos" RJ45 krimpelőt használok és elég jól bírta ez idő alatt, de kezd kicsit lötyögni minden rajta és már kezd javíthatatlan állapotba kerülni. Most ahogy nézegetem az utódját, előkerült az "átmenő" (pass through) vs hagyományos krimpelő kérdéskör. Érdekelne a véleményetek hogy ez csak ízlések és pofonok kérdése, vagy van valós előnye? (havi kb 100 krimpelést csinálok)

Én azért használtam a hagyományosat mert valahogy tetszik hogy teljesen "zárt" a rendszer és szinte sosincs belőle problémám hogy nem ér végig az ér a csatlakozóban, plusz ott az a gondolatkör ami miatt kicsit félek tőlük hogy ott szabadon "fityegnek" a vezetékek, szóval ha valaki kihúzza az eszközből és ledobva ott marad (anélkül hogy a másik vége is kihúzásra kerülne) akkor nem annyira szimpatikus hogy egy passziv POE cucc esetén simán rövidre lehet zárni ha ráfröccsen egy csepp víz.

Szóval az a kérdésem hogy én vagyok lemaradva amiért még nem ilyen átmenős krimpelőt használok, vagy tényleg kinek mi a kedvenc színe problémakör ez? Kinek mi a tapasztalata, javaslata a két fajtával kapcsolatosan?

Előre is köszönöm

Mint "házi rendszergazda" a család nagyobb részének én adminisztrálom a többnyire windows-os gépeit, már többször felmerült bennem, hogy beletanulok az AD-be.

De aztán ezt soha nem léptem meg. Mindig találtam valami kibúvót, elvoltam a sima file sharing-el, LDAP-ot végül csináltam pár éve (openldap-al), meg egyesével beállítgattam a gépeket, helyi userekkel.

Gépből viszont egyre több van, igazából userből is szerencsére :D, időből viszont egyre kevesebb. Illetve a windows egyre nagyobb kontrollmániáját némileg lehet ellensúlyozni azzal, ha beléptetném domain-be őket, pl. használhatnék domain account-okat cloud account helyett.

Tehát a dilemma, amivel gondolom nem vagyok egyedül:

Érdemes-e 2024-ben beletanulni a Samba AD-be? Vagy az egész technológia úgy halott, ahogy van? Fogadjam el, hogy minden megy a felhőbe?

Ennek megválaszolásához a következő tapasztalatok megosztására számítanék azoktól, akiknek van:

Tud egyáltalán rendesen együttműködni a Win 11 a Samba AD-vel? Azt is olvastam, hogy ebben az esetben a domain controller lehetőleg ne legyen fájl szerver is. Hát most ezért két gépet nem fogok beállítani, de virtualizálgatni sincs nagyon kedvem, bár abból már fut kb. 5 virtuális szerverem.

Normális dokumentációt hol találok hozzá?

Win 9x idejében még klasszik sambával volt roaming profile is, de aztán azt kb. az XP korszakban ki kellett kapcsolni, mert egyszerűen annyi adatot szinkronizált egy-egy ki-belépéskor. Nem tudom, hogy ezen a téren javult-e a helyzet.

Mi a helyzet a linuxos kliensekkel? Azokkal mennyire tud együttműködni? Gondolok itt is valami osztott home directory-kra, és központi belépésre.

Keresni próbálnék valami gyakorlatorientált leírást / videót a DHT (routing) működéséről.

Amikbe eddig belebotlottam, nagyon egyetemi-akadémikus úton próbálják taglalni a témát. Nem akarom magamnak leprogramozni az implementációt, szigorúan enduser v. sysadmin szempontból szeretném csak megérteni, h. ki - kivel mit kommunikál a gyakorlatban.

A feladat "egyszerű" (szerintem rohadtul nem triviális): windows / linux környezetben 2 tetszőlegesen távol levő gép között hogyan lehet megoldani fájlcserét, pl. köztes torrent tracker nélkül, qbittorrent kliens használata esetén?

Az egy elfogadható kompromisszum, h. ha A meg akar osztani egy fájlt B-vel, akkor a torrent fájlt A elküldi B-nek (pl. emailben). De publikus tracker ne kelljen hozzá. Privát az lehet, ha a self-hosted qbittorrent beépített tracker-e elégséges ehhez. Vajon B-n (és A-n) kívül másnak lesz fogalma róla h. az a konkrét fájl létezik A-nál? Illetve csak az tudja letölteni a fájlt, akinek a torrent fájl a birtokában van? Ha B nem osztja meg senki mással, akkor képes bárhogyan 3. fél megszerezni ezt a fájlt? Azaz van rá valami discovery metódus tetszőleges fájlok felkutatására hash alapján? 

A peer discovery hogyan működik, 1-1 szoftveres implementáció meghatározza a felderíthető node-ok körét? Azaz ahány DHT implementáció van, annyi különálló DHT sziget létezik az internet fölött? Vagy aki DHT-t beszél (azon belül is adott reviziót, nem tudom ennél is vannak-e generációk mint pl. IPv4, IPv6 stb) azok mind elérik egymást, kliens/szerver szoftver különbözőség ellenére is?

Na kb ilyesmik érdekelnének.

Sziasztok

Van egy kubernetes alapú csoda, és azt szeretnénk, hogy az egyik rajta futó oldal csak bizonyos ip-kről legyen elérhető. Sajnos jó megoldással nem találkoztunk eddig. Van olyan, ami "magasabb rétegbeli" megoldás (calico), de annyira, hogy az iptables megoldások töredékét sem tudja, valamint átveszi teljesen a iptables feletti uralmat. Amivel csak annyi gond, hogy az alap beállításokat, többi portot azon a gépen nem iptables-ben kellene hanem az adott alakalmazásban megoldani (amit a limitációk miatt nem tudunk és viszonylag kényelmetlen is lenne, ha van már kidolgozott megoldás a automatizáció/környezet managelésére).

Docker esetén van egy sima tábla (DOCKER-USER ?), amit nem piszkál a docker. Van valami hasonló megoldás kubernetes alapú cuccokra is?

Köszi.

hilo

A cegnel szuksegem lenne egy kicsit erosebb IP design tudasra...tud valaki ajanlani konyvet/kurzust ami segithet nekem ebben 'gyurni'? (VLAN, VRF, VPRN, DSCP. BGP, subnet...es hasonlo temak)

Az a problemam , hogy kb vegtelen mennyisegu anyag van a temaban a neten  es indulasnak kb lehetetlen megtippelni melyik lehet a nyero..

koszi!

Egy Global Protect VPN-hez kellene csatlakoznom, ami eddig Debian alól rendben ment is. Most azonban megszüntették a linux támogatását, és Windows alól kell felcsatlakoznom.

Már elég régóta nem vagyok jártas Windows berkekben, ezért kérdezem, létezik-e valamilyen minimál Windows verzió egy ilyen csatlakozáshoz, vagy egy teljes Windows 10-et fel kell telepítenem a GlobalProtect miatt?

Sziasztok!

Egy kutatócsoport tagja vagyok, nagyjából 10 ezer e-mailt kellene kiküldenünk (nem spam, jogkövető módon feliratkozott személyek). Eddig Gmail-ből küldtük 500-asával, de sokkal egyszerűbb lenne, ha egyszerre ki tudnánk küldeni az e-maileket.

Tudtok olyan szolgáltatót ajánlani, akinek a levelei nem a spambe mennek, hanem ténylegesen megkapja minden címzett a levelet? Nem ingyenes megoldást keresek, hanem jót.

Köszönöm.