Hálózatok általános

Sziasztok

Van egy T-Online optikánk egy Sagemcom 5655 routerrel. A router rá van kötve egy pfSense tűzfalra. Ezen keresztül megy ki a teljes hálózat, kb 250 eszköz.

Tavaly kezdődött, hogy nagy terhelésnél az RTT és RTTsd egyre nagyobb, míg végül már csomagvesztés is van. Idén ez már úgy néz ki, hogy amint terhelés éri a WAN gatewayt, szépen lassan elszáll az egész és 60% körüli csomagvesztés van. Keresgéltem neten, leginkább azt találtam, hogy pufferfelfúvódás okozhatja a problémát, és hogy korlátozzam le a kimenő és bejövő sebességet, hogy a szolgáltató eszközei megbírkózzanak vele.

Gondoltam még rá, hogy a sagemcom routert átrakatom modem módba. Tudom, hogy eleve úgy célszerű használni, de eddig nem volt gond. Esetleg az megoldhatja a problémát?

Évekig nem volt semmi ilyen probléma. Mitől jöhetett ez elő? Lehet hogy modem csere megoldaná a problémát? A jelenlegi modem már olyan 5-6 éve itt van.

Van egy másik T-online-os vonalunk is (KIFÜ hálózat) azon nincsenek problémák, ha azon engedem ki a forgalmat. Viszont az lassabb attól függetlenül, hogy ugyan úgy optika. 

sziasztok

van egy win10-es gép amit kineveztem softether szervernek.
digi net van, ami néha megszakad egy pillanatra mostanság.
ez a softethernek nem tetszik (leáll) és csak újraindítás után lehet ismét csatlakozni a vpn-re.
a felhasználók a softether saját kliensét használják, automatikus újrakapcsolódás be van kapcsolva.
van-e erre valamilyen megoldás? hogy ha elmegy a net akkor újrainduljon a softether szerver?
köszi mindenkinek a segítséget.

Sziasztok!

Egy érdekes dolgot tapasztaltam. Van egy hálózat, a router 192.168.0.1-en csücsül, a hálózaton levő eszközök:

- Van egy FreePBX telefonközpont
- Vannak rajta Grandstream PoE telefonok
- Van néhány asztali gép
- Wifi AP-k
- A Wifin néhány telefon és tablet
- Valamint van 2 db Fanvil kaputelefon, egy i10-es és egy i20-as.

A telefonszervernek, a telefonoknak és a kaputelefonoknak fix IP címük van 0.200-tól kezdve, a DHCP természetesen ezt a tartományt nem osztja.

A kisebbik, i10-es kaputelefonra rá kellett (volna) néznem, mert be kellett volna hangolni, de meglepetésemre a webes felületét nem lehetett elérni. Ellenben az IP címét lehetett pingelni, valamint telefonhívás is működött róla, a telefonszerverrel tehát fel tudta venni a SIP kapcsolatot.
A másik Fanvil készülék (i20) webes felülete tökéletesen elérhető volt.

A kérdéses készüléket fizikailag áttettem egy másik (az előzőtől teljesen független) hálózatba, ott viszont elérem a webes admin felületet!

Mi okozhatja ezt? IP cím ütközés nincs, most, hogy ki van véve az eszköz a hálózatból, az IP címe nem elérhető.

Gábor

Update:

A leszerelés előtt elfelejtettem ellenőrizni, hogy az újraindítás elegendő-e a hiba megszüntetéséhez. Most visszaraktam az eredeti hálózatba az eszközt és tökéletesen működik.

Köszönöm mindenkinek a választ!

Van a /etc/hosts file-ban egy ilyen sor:

127.0.0.1 name1 name2 valami_barmi name3

Aztán van a /etc/httpd/conf.d/00_VirtualHost.conf file-ban egy ilyen bejegyzés:

<VirtualHost *:80>
    ServerAdmin root@localhost
    DocumentRoot /var/www/html/valami
    ServerName valami_barmi
    ErrorLog logs/valami-error_log
    CustomLog logs/valami-access_log common
</VirtualHost>

Aztán másodperceket kell várjak, mire feljön a weboldal. Valami timeout-ra vár szerintem, aztán ha azon túlvan, már megcsinálja, amit szeretnék.

Mi állhat a jelenség hátterében, mit nézzek meg, hogy azonnal reagáljon?

Közben eszembe jutott egy lehetséges megoldás. Előfordulhat az, hogy a böngészőbe írt valami_barmi előbb a 443-on (https) próbálkozik, majd timeout után jön a 80-as portról (http) történő lekérés? Ha nem akarok semmiféle titkosítást, elvégre localhost, hogyan beszélhetem rá arra, hogy ez menjen gyorsan? Pl. https-ről dobjon át http-re, vagy akármi, nem tudom, mi jöhet szóba.

Megoldás:

A névfeloldás sorrendje volt rossz, előbb fordult dns szerverhez, s csak akkor a hosts file-hoz, ha az előbbi nem sikerült.

Köszönöm mindenkinek, aki segített! :)
 

Otthonról nem érem el a Fedora build szervert, míg munkahelyről igen. Névfeloldás van, pingre is jön válasz, de Firefox „Unable to connect” üzenettel, elinks pedig „Connection refused” üzenettel örvendeztet meg, viszont ezzel egyidőben munkahelyről elérem a https://koji.fedoraproject.org/ címet.

Mi történhetett, és mi a megoldás? Valamiért a szolgáltatóm IP-tartományát fekete listára tette a Fedora build szervere? A szolgáltatóm kergült meg? Terroristának nyilvánítottak, és blokkolták a nyugati propaganda szerint dezinformációnak minősített oldalt? :)

Megoldás:

Fogalmam sincs. Biztos rájöttek, hogy mégsem vagyok terrorista. :)

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