Keresés

Hirdetés

Új hozzászólás Aktív témák

  • Ripper17

    tag

    válasz MaCS_70 #9657 üzenetére

    Engedd meg, hogy közbeszóljak, elég gyakori szakmai tévhitként hangoztatjátok itt ezt. (Nagyvállalati-ipari WiFi rendszerek tervezéséből, kivitelezéséből, rendszeintegrációjából élek.)

    SSID: a hálózat human-readable azonosítója, egy sima string.
    BSSID: az adott WiFi hozzáférési ponton, egy adott SSID-hoz tartozó logikai, gépi azonosító. Nevezhetjük a hozzáférési pont rádiós MAC címének is, az adott hálózathoz. Jellemző ábrázolása is a MAC címes formátum, de ez egy virtuálisan kreált cím, úgymond

    Ami a klienst érdekli: az SSID, illetve a rádiós környezet minősége (jelszint, jel/zaj viszony). Roaming döntést mindig a kliens hoz. Persze, léteznek network-assisted protokollok, de ezekből én stabilan működőt még nem láttam, ahány kliensgyártó annyiféleképp implementálják ezeket, ha egyáltalán - és nem csak beleírják a datasheetbe...meg el lehet dobatni hozzáférési pont oldalról is, pl. adott packet loss % felett, vagy jelszint alatt, de attól meg még több kliens hülyül meg teljesen.

    A jobb cuccok tudnak band steeringet (leegyszerűsítve: a dual-band kliensnek előbb válaszol a hozzáférési pont 5 GHz rádiója egy kicsit, mint a 2.4es), és ilyet már SOHO meg lakossági eszközökben is láttam. ehhez viszont pontosan az azonos SSID kell, amit mindkét sávon sugárzol.

    A kliens döntésének alapja a rádiós környezet: érzékeli-e jobb minőségben, más csatornán ugyanazt az SSID-t, amire éppen csatlakoztatva-hitelesítve van. A jobb minőség fogalma a kliens gyártójától függ, jellemzően ez rádiós paramétereken alapul. tipikusan 15 dB körüli jelszint különbség a kívánatos két, szomszédos hozzáférési pont "cellája" között ott, ahol te roamingot szeretnél. Azonos frekvenciára állítva a szomszédos eszközöket csak magadnak okozol zajt, rontod a hálózat működését.

    Arra, hogy el-eldob egy kliens egy SSID-t, vagy azon ragad, nem a hozzáférési pont oldalán kell mókolni, ez tüneti kezelés, hanem a kliens beállításai között, illetve a WiFi sugárzó eszközök megfelelő elhelyezésével az optimális rádiós környezethez. Roaming agresszivitás, mennyire preferálja az 5 GHz-t, stb...az enterprise gyártók (Cisco, Aruba) oldalain tipikusan elérhető, hogy adott WiFi kártyából melyik driver verzió az ajánlott, ezt ők ki is tesztelik. érdemes az otthoni környezetben is felrakni a gépekre. Smart eszközöknél alapvetően a wifi kezelés jobban optimalizált, de pl. a network oldali, "segítő szándékú" roaming protokollok kezelésétől az androidok többsége kifekszik. (Nyilván lehet, hogy a tied pont nem. 10 ezres nagyságrendű, egyidejű kliensnél viszont az a tapasztalatunk, hogy csak és kizárólag az alapvető WiFI szolgáltatási protokollok és a megfelelő rádiós lefedettség tervezés vezet jó megoldásra. Nem a különféle kiegészítő protokollok kapcsolgatása.)

    [ Szerkesztve ]

  • Ripper17

    tag

    válasz bambano #9675 üzenetére

    Ennyi. LEO pályán (és úgy általában rádiós kommunikációban) már nem maga a fizikai közeg áthidalása az idő, hanem a kapcsolások. Pl. az LTE mobilhálózatok alatti mikrós hálózat technológiája teljesen azonos a 3G-ével, nem lettek újraépítve a tornyok, csak maximum sávszélesség növelés történt...A mögöttes architektúrán, routing-switching mechanizmusokon kellett faragni, hogy a gyors átvitelhez szükséges megfelelő pontosságú időszinkront ne korlátozza le a hálózat. Nagyjából egy kapcsolás ma 0.5ms, egy routing 1ms nagyságrendú késleltetést ad a hálózathoz.

    Mivel nagyjából a fő internetes forgalmat geológiailag elosztott CDN-ek szolgálják ki, így ezek sem okoznak már problémát annyira.

    [ Szerkesztve ]

  • Ripper17

    tag

    válasz MaCS_70 #9676 üzenetére

    Kódolás alatt többféle dolgot is érthetünk.
    Egyrészt ugye a választott közeget és a kihasználni kívánt fizikai jellemzőjét (rádiónál ez ugye az EM hullámterjedés) kell megfognod, meghatározni, milyen állapotváltozást tekintesz a jel változásának. (vonali vagy alapsávi kódolás, szimbólum sebesség, baud rate) Hordozhat infót pl. a jel fázisa, amplitudója, frekvenciája. Ehhez kapcsolódóan jön a közeghozzáférés módja, paraméterei (pl. védőintervallum és a hossza ott, ahol többutas terjedés lehet, emiatt a szimbólumok "egymásra csúszhatnak", interferálhatnak)

    Majd ezeket a szimbólumokat modulálod: meghatározod a lehetséges jelalakok számát, és ennek a digitális technikában a 2es alapú logaritmusa adja meg, hogy egy jelalak változás hány bit infót hordoz. Pl. egy 256-QAM kódolás jelentése: a rádiós jel fázisa és amplitudója hordoz információt, mindösszesen 256 ilyen állapotot határozunk meg, azaz az elektromágneses jel 1 fizikai állapota 8 bit információt jelent.

    Nyilvánvalóan a sok jelalakot meg kell tudd különböztetni, megfelelő jel/zaj viszony szükséges. A távolsággal a jel gyengül, viszont egyre több zajt szed össze...pl a 802.11ac wifi szabvány 256-QAM-et csak a sugárzótól korlátozott távolságban tud...míg mondjuk egy DVB-S2 szabvány lakossági verziója 4 vagy 8 jelalakot tud, ahol csak a jel fázisa hordoz információt, ez az a paraméter ami a legkevesebb sérülést szenvedi el és a legkisebb hibával detektálható több 100km-es rádiós átvitel során. Viszont már ez is a 40-50 Mbps átviteli sebességet jelenti, a transzponderek tipikusan 36 MHz sávszélességet használnak ki. (nyilván ez nagyságrendben sincs pl. egy CAT6 kábel 250 MHz.ével).

    Ezt is még különféle hibavédő, hibajavító kódolásokon küldöd keresztül. Van, ami csak az entrópiát növeli ("összekeveri a biteket"), míg van ami plusz biteket szúr be. Az egész mögött komoly információelmélet és matematika van. Ezekből jön ki a végén az adatátviteli sebességed. És persze az átvitt tartalmat is tömörítheted, stbstb.

    A műholdas távközlésnél alapvetően a távolság miatt a vett jel erősen zajos, így sokkal erősebb hibajavító kódolás kell, mint egy gyakorlatilag rádiós zajoktól jól védett kábelben (az optikai szál meg majdhogynem zajmentes közeg), illetve sokkal kisebb modulációs mélységet is használhatsz és a rendelkezésre álló sávszélesség is korlátos. Viszont az egész bolygót néhány eszközön át elérheted, a jel mindig egy úton terjed, alacsony késleltetésű és stabil vonal hozható létre. Emiatt igazából jól tömöríthető (média) és/vagy alacsony késleltetésű tartalmakhoz teljesen megfelelő. Gondoljunk csak arra, hogy a katonai drónok vezérlése is műhold alapú: videójel átvitel és valós idejű vezérlés.

    [ Szerkesztve ]

  • Ripper17

    tag

    válasz SimS #9747 üzenetére

    Induljunk el Ádám és Évától.
    Ha jól értem a hálózatodban jelenleg nincs olyan Layer3-as eszköz ("router"), ami a saját IP-id fordítását ("NAT") végzi. Van viszont fizikailag 10G képes belső ("LAN") hálózatod.

    Probléma azzal, amit szeretnél onnan indul, hogy az általad leírt Netgear XS508M switch típus az adatlapja szerint nem VLAN képes, azaz nem tudsz több címtartományt használni a LAN-odban.

    Miért szeretnél több címtartományt?
    Miért tartod szükségesnek a router 10G képességét? A szolgáltatói vonalad sávszélessége mekkora? A forgalmad túlnyomó része a helyi hálózatban van ("switchelve megy"), vagy internet irányú? Minden hostnak 10G-t szeretnél adni, vagy csak 1-2 szerver/NAS kerülne 10G-re?

    - 10G képes helyi hálózatodhoz maximum pár 100M-1G internet irányú forgalom NATolása + a szükséges IP-s funkciók (pl. DHCP címosztás) egy MikroTik hEX is röhögve megoldja, filléres költség.
    - Ha a helyi hálózatodban VLAN-ozni szeretnél, azaz több címtartományt használni, akkor ki kell cserélned a switched, illetve emellé valami basic routert beszerezni.
    - Ha te natívan ki szeretnél vinni az internet fele ekkora sávszélességet, akkor inkább költöztesd adatparkba a cuccaid. :D

    A MikroTik irány amúgy nem rossz, de ebből neked a RB4011iGS+RM típus kell, ebben van egy SFP+ interface. Ezen keresztül, VLAN-ozás nélkül be tudod kötni a meglévő Netgear switched (illetve ezen át vagy akár valamelyik 1G RJ45 portjába a szolgáltatói modemet, attól függ, mekkora sávszélre fizetsz elő), míg a többi 1G portját pl. a PC-id részére már VLANba rakni, vagy a jövőben VLAN képes switcheket kötni rá.

    De előbb szerintem fogalmazzuk meg az igényedet, hogy mi a felhasználási környezet, és aztán tudunk megoldást adni. :)

    [ Szerkesztve ]

  • Ripper17

    tag

    válasz R1200GS #9781 üzenetére

    Neked 5 GHz sávos, pont-pont wifi bridge eszközre lesz szükséged.
    Amire kell figyelned ~1km távolságban: a két antenna közötti, képzelt légvonal mindenhol legalább 4-5 méterrel haladjon a tereptárgyak felett.

    Ekkora távolságon 100 deciBel-t csillapodik a jel, vételi oldalon egy -60-65 dBm-el már teljesen jó minőségű linked vannak (a normálisabb SOHO gyártók cuccainál a maximális adatsebességhez -75 dBm körüli az érzékenység, de érdemes tartalékolni kicsit a linken).

    Gyakorlatilag két, ~15 dB nyereségű antennával felszerelt eszközzel már teljesen jó vagy, és nem lesznek kihajtva a rádiók. Munkahelyemen is ilyen nyereségű antennákkal telepítünk hasonló távolságokra településeken, külterületeken. Én ennél sokkal erősebbet nem vennék.

    Szánj rá kicsit többet és vegyél a Ubiquiti portfóliójából eszközt. Ezek nagyon egyszerűen konfigurálhatóak, nekem csak jó tapasztalatom van velük, minőségi termékek és nagyon stabil a rádiós link. Ár/érték/kezelőfelület terén szerintem ezek a legjobbak, ismerősnél 5 km távolságra, hasonló esetben tavaly csináltunk egy Ubiquiti linket, azóta hozzá se kellett nyúlni.

    Ami neked pl. jó lehet
    https://www.wireless-bolt.hu/45902-ubiquiti/567940-nanobeam-m5-16dbi-5ghz-kulteri-ap-kliens

    vagy egy újabb technológiásból pl. ez:

    https://www.wireless-bolt.hu/45911-ubiquiti/657850-litebeam-5ac-gen2-kulteri-5ghz-ap-kliens

    [ Szerkesztve ]

  • Ripper17

    tag

    válasz Doky586 #9814 üzenetére

    Miért nem veszel egy mobilnetes wifi hotspotot? De komolyan, már 15ezerért is kapsz olyat (pl. Huawei E5576-320) ami - ha jól értem az igényeid - teljesen prímán tudja azt stabilan és gyorsan, amit keresel.

  • Ripper17

    tag

    válasz I02S3F #9874 üzenetére

    Nem érdemes. Jól használható piaci tudást + értéket a gyártói oklevelek adnak. Ezek az adott szinthez szükséges mélységben tárgyalják a protokollokat és ezek gyakorlati használatát.

    A legelismertebbek a Cisco Systems oklevelei. Az aktuális CCNA jól áttekinti az általános ismeretek mellett a security és wifi dolgokat is - ha levizsgázol akkor Linuxos tudás mellé már jó vagy, rendszermérnöki pozikra is mehetsz. kkv szinten jobb a széles látókör, nagyobb cégeknél hasonló skill settel tipikusan a peremterületeken (pl. hálózatot, infrastruktúrát monitorozó vagy statisztikai riportokat készítö szerverek) rendszergazda, rendszermérnök egy jó irány.

    Ha csak szigorúan az IP hálózat érdekel akkor a régi, 200-125 kódú CCNA jobb. "Cisco 200-125 Official Certificate Guide" címszóval keresgéld a neten az ebookokat.

    (A Cisco alapszintu = associate vizsgák nem csak Ciscora jók, jól áttekintik a protokollokat. Van hasonlója a Huaweinek meg a HPE-Arubának is, de ezek piaci értéke csekély - évente 1-1 pozihoz, mint "további vizsga" keresik.)

    [ Szerkesztve ]

  • Ripper17

    tag

    válasz bambano #9881 üzenetére

    "rendes, használható tudást rendes elméleti megalapozással lehet szerezni."

    Ha ez így lenne, akkor nem kellene arról beszélnünk: miért ér az elméleti megalapozást adó, neves műszaki-tudományos egyetemek elvégzése egy gyorséttermi fizetést pályakezdőként. :)

    El lehet olvasni rég kihalt protokollokat bitszinten taglaló műveket is, segít megérteni a technológiai fejlődést. De általános rendszergazdai, rendszermérnöki szinten ezek feleslegesek. BME-n is többet ért a Cisco laborban 2 félévben heti pár óra, mint bitszintig beseggelni heti 3x2 órás kurzusokon rég kihalt protokollokat.

    "a magam részéről a gyártói oklevelek értékét meglehetősen alacsonynak tartom."

    Ezt eddig csak olyanoktól hallottam, akiknek nincsen. :) Tény:
    - vannak "oklevélgyáros" emberek - ezeket egy interjún 3 keresztkérdéssel kiszűrőd-
    - vannak vendorok, ahol egy 3 napos tanfolyam végighallgatása már oklevelet ér. De tipikusan minél piacvezetőbb annál inkább kerülik ezt - a Cisco is folyamatosan validáltatja az iparággal worldwide az aktuális tematikáit, az iparág igényeit
    - vannak vendorok, akiknél a "professional" szint is teljesen nulla

    Mindazonáltal az kijelenthető (akár a nemzetközi, akár a hazai tapasztalatok és álláshirdetések alapján): a hálózatos világban a Cisco Systems oklevelei értéket képviselnek; ezek megugrásához jelentős mennyiségű munkaóra, tanulás kell és komoly elméleti tudás.

    Ha nem így lenne: nem lenne specifikálva sok nagyvállalati tenderben, hogy ilyen képesítésű mérnöke legyen a szolgáltatónak - akkor is, ha épp nem Cisco vasakról van szó.

    "a gyártói oklevelek csak az adott gyártó berendezésének kezelését tanítják meg. rendes, használható tudást rendes elméleti megalapozással lehet szerezni."

    Ez is egy gyakori téveszme, csak olyanoktól hallom akik sosem nyitottak még ki egy e-learninget vagy cert guideot sem - csak a BAU taskokat pörgetik a munkahelyen, amiket egyszer jól betanultak. Ha bármi más jön: mennek olyanhoz, aki beleöli az időt-energiát a szakmába, és ezt gyártói oklevelek teljesítésével is szeretné önmagának igazolni.

    Egy kellően haladó szint felett nem tudod elkerülni a gyártóspecifikus megoldásokat (bár ezekkel is egymást másolják a nagyok, egy jó mérnök át tud állni egyikről a másikra, tud párhuzamot vonni). Részemről ahány Cisco "associate" szintű cert guideot (wireless, routing&switching, security, devops) olvastam nagyon maximum az egyes konfigurációs parancsok voltak gyártóspecifikusak. De még a "professional" anyagok is ezek, a BGP az BGP, az STP az STP, az ACL meg ACL, és a RADIUS sem lesz más attól, hogy épp nem egy Cisco ISE-n, hanem egy Aruba CPPM-en kell implementálnod. Előveszed a config guideot hozzá, keresel cheat sheetet a CLIhez, kész.

    A 200-125ös CCNA tökéletesen végigvesz minden témakört, amivel a hálózatozást el lehet kezdeni, kezdve a fizikai rétegtől a switchelt hálózatokon át a routing és menedzsment protokollokig. Logikusan felépített mű, "kezdőknek" szóló nyelvezet, de ha 1-1 témakört már ért az ember akkor kihagyható, szépen megy a könnyűtől a mélyebb anyagok felé. Ebből a műből én nem egy, pályakezdő/gyakornok hálózatost húztam fel korrekt Level2/Level3 szintre - olyan cégekben is, ahol minimális a Cisco eszköz. :U Ugyanez a régi wireless CCNA, vagy az új CCNA wireless témakörei: az ismertetett WLAN architektúrák, megoldások tetszőleges gyártónál megvannak, csak épp más a fantázianeve.

    Én voltam már elég sok Cisco és HPE-Aruba vizsgán is, de Huawei vizsgára is láttam már rá. Előbbin nagyságrendileg több elméleti kérdés vagy általános best practice volt, míg utóbbiakon tényleg tipikusan vendor specifikus dolgok is nagy számban. Előbbi értelmes network-ös pozikban "must have" a felvételnél, utóbbiakat maximum "nice to have"-nél láttam, vagy ha adott cég 1-1 projektre keres specifikusan, gyorsan pl. Aruba expertet.

    [ Szerkesztve ]

  • Ripper17

    tag

    válasz SP4C3 #9886 üzenetére

    A hazai képzésekkel sajnos nekem is ez a tapasztalatom, még "professional" szinten is borzasztó gyengék, felületesek; sokszor érdemi tapasztalat nélküli oktatók tartják. Egyetlen létjogosultságuk: a főnök hátradőlhet, nem az ő felelőssége, hogy a kolléga nem ért a témakörhöz, hát elküldte egy 5 napos bootcampre. Mindezt annyiért, amit ha felajánl egyszeri bónusznak a kolléga önként is beleöli azt a k*100 óra tanulást-gyakorlást, amivel stabil tudása lesz. :)

    Egyetlen jón voltam, ahol érdemi tudásátadás történt - ott egy cseh oktató volt. :)

    A Cisco e-learning anyagai viszont nagyon jók, illetve a legtöbb Cisco Press mű vagy whitepaper, esetleg gyártói design guideline is hasznos. A Huawei netes konfig/design guide-jai is sok esetben baromi jól tekintik át az egyes protokollokat a konkrét parancsok, javaslatok előtt - pl. a Huawei fórumon van egy 20+ részes BGP Fundamentals anyag egy Huawei mérnöktől, messze a legjobb, áttekintőbb BGP anyag, amit olvastam.

    Itt ph!-n a Cisco-s topikban persze vannak alternatív javaslatok, én ezeknek nem vagyok híve, maximum tudásfrissítésre jók. Le kell ülni, elolvasni, feldolgozni, összerakni szimulátorban/emulátorban/laborban - bele kell ölni az időt. Csak sajnos ezt a mai, "instant világban" kevesen teszik meg.

    [ Szerkesztve ]

  • Ripper17

    tag

    válasz I02S3F #9892 üzenetére

    Ha érdekelnek ilyesmik írj rám privátban, viszonylag sok anyagom van, bár ezek az "internetes kölcsönzőkben" is elérhetőek.

    [ Szerkesztve ]

  • Ripper17

    tag

    válasz bambano #9897 üzenetére

    Sajnos nem tudok mit kezdeni a kényszeresen belemagyarázó, "csak azért is nekem van igazam" fórumkirályokkal. Vitának semmiképp sem tudom ezt nevezni, kettönk közül egyedül én érveltem - te szubjektív módon fogalmaztál meg ítéletet, amit továbbra sem támasztottál alá. Egyáltalán nem ugyanazt mondtuk, de csak kihozod: én tudom rosszul. :)

    Az egyetemi mérnöki képzettség 90% egy papír itthon, az elméleti oktatás évtizedekkel le van maradva. (Ugyanazt adják le most, mint 30 éve!) Azt hagyjuk is, mennyi értéktelen intézmény ad már ki oklevelet, vagy hogy a bolognai rendszerben 27-28 éves korukig élösködök mennyire "mérnökök".

    Elmúlt az elözö rendszer rég, ahol a Doktor Úr meg a Mérnök Úr rang volt, hátra lehetett dölni ezzel nyugdíjig. Szerinted miért száll be minél több cég, minél elöbb a müszaki felsöfokú képzésbe? Igen, pontosan azért, hogy diplomázás után ne az ö költségükön kelljen a munkaeröt 2-3 éven át a szakmára. Egy pályakezdönél kerestünk is bármiféle gyártói cert, saját fejlesztésü kis program, laborrendszer, stb. már differenciál.

    Nekem is van mérnöki MSc-m, de amit elértem a karrierben az csak és kizárólag a kurrens technológiák folyamatos megismerése miatt van. Nem egy cimborám gyártói certekkel + önképzéssel, felsöfokú végzettség nélkül is elismert IT szakember, bármikor képes megtanulni egy új CLI-t. Megint más mérnöki MSc-vel elméleti síkon se érti, ami a munkája, nem hogy bármikor átálljon más programnyelvre, CLI-re.

    [ Szerkesztve ]

  • Ripper17

    tag

    válasz inf3rno #9921 üzenetére

    A QoS azért egy nagyon komplikált témakör tud lenni.
    A teljes hálózaton kell átfüzni, azaz elöbb 2. rétegben (802.11/Ethernet), aztán ha routing is van belül akkor IP-sen. és akkor még nem nyúltál le az egyes vasak buffer/queuing/scheduling mechanizmusaihoz. Tehat igazabol a QoS:

    1. Besorolod a forgalmat (classification) egy szabalyrendszser szerint
    2. Meghatarozod az egyes forgalmi csoportok QoS paramétereit (802.1p, DSCP/TOS, ha van wifid is akkor a wifi service class)
    3. A halozati eszkozokon meghatarozod a forgalmi csoportok kezelesenek, utemezesenek, stb. modjait

    értelmesebb cuccok (wifi vezerlok vagy jobb tuzfalak) tudnak alkalmazasszintu forgalom felismerest is, es igy be tudsz allitani pl. kategoriankent (pl. p2p, browsing, VoIP) prioritasokat, limiteket.

  • Ripper17

    tag

    válasz bambano #9920 üzenetére

    Igazabol a NAT is lehet tobbfele.

    Ha a Layer4 is kell, mert portforditas/NAT overload van (azaz nem lehet 1:1 hozzarendeles a kulso es a belso IPk kozt) akkor a funkciot vegzo eszkoz bizony random portokat nyit a kulso lábán es ezekre terheli ra a belso forgalmat.
    Tehat igazabol a TCP/UDP es az IP fejlec is modosul.

    Az eredeti kerdezonek: a NAT-olo eszkoz stateful, azaz a NATolasokat nyilvantartja egy NAT adatbazisban. Ennek a kezelese ami sok eroforras.

  • Ripper17

    tag

    válasz bambano #9905 üzenetére

    Nem kifejezetten drága az oszlopsorokra betelepülés sem. Pont most csinálok egy projektet, itt ~500 méter szakaszra az elektromos szolgáltató 10eHUF/hó díjat kért.

  • Ripper17

    tag

    válasz st3v3np3t3r #9926 üzenetére

    Az Igus (igus.hu) forgalmaz sokféle kábelt "heavy duty" ipari célokra. Egy emailt megér nekik a sztori.

  • Ripper17

    tag

    válasz bambano #9937 üzenetére

    A lakossági routerek szintjére nem látok le, de egy "alaposan" topic ezen túlmutat.

    Minden más, általam ismert esetben (SOHO és enterprise gyártók) az overloaded NAT (port address translation, a nevében is benne hogy L3+L4) müködése:
    - 1 külso cím: a router lehetöség szerint a source porttal azonos portot használ. Ha erre nincs lehetöség: vegigscanneli a port tartomanyt es a legelsot allokalja hozza. A valaszuzenet miatt ezt praktikusan meg is kell nyissa kifele.
    - több külsö cim eseten ugyanez tortenik, de ha az IP pool 1. cimen nincs szabad port megcsinalja a folyamatot a 2.cimre, stb.

    Ezt a jelenseget barmikor megnezheted, ha egy nagyobb szervezet globalis irany feloli tuzfal/router NAT tablajat megnezed.

    Az egyszeru lakossagi routereknel nagy valoszinuseggel csekely azon esetek szama, ahol a local source port es a global source port nem azonos egy IPnel. De attol meg ez a tipusu NAT L3+L4 szintu forditast csinal. RFC 2663 4.1.2

  • Ripper17

    tag

    válasz inf3rno #9936 üzenetére

    Én nagyvállalati routeren/tüzfalon még nem láttam arra beállítást, hogy a NAT-nál ha szükséges (lásd elözö kommentem) milyen port tartományból dolgozzon. De még csak erre vonatkozó dokumentációt sem. Pl. TCPnél a 49152-65535 között a router kifele pont úgy "választhat", mint ahogy a gépeden futó kliens szoftverek fejlesztöi megtehetik.

    Alapból egy ilyen eszköz (amennyiben a device hardening megtörtént, azaz a nem használt menedzsment és vezérlö protokollok tiltása megtörtént) kívülröl amúgy is "zárt", nem pontosan értem mire gondolt aki ezt a tanácsot adta.

  • Ripper17

    tag

    válasz Dzsekó #10338 üzenetére

    A 100.64.0.0/10 tartomány carrier grade NAT néven ismert. Ha a CPE eszközöd WAN interface ilyen tartományú IP-t kap akkor minimum még egy NAT kell a világhálóig a szolgáltatói oldalon. (NAT444 architektúra)

    [ Szerkesztve ]

  • Ripper17

    tag

    válasz Krisztianby #11105 üzenetére

    Simán lehallgatsz a levegöböl egy handshaket és dictionary + néhány, sikerességet növelö feltételezés (pl. kezdö nagybetü, vége szám) alapú brute-force, mivel valójában hasheket cserél a kliens és az AP. Aktív esetben egy deauth keretet injektálsz a hatókörben lévö kliens fele, ezzel kikényszeríted a handshaket.

    bövebben itt jól leírják: [link]

  • Ripper17

    tag

    Hali, van aki aktivan benne van Zabbix konfiguralasban? Egy gyors kerdesem lenne privatban, most ismerkedem ezzel a megoldassal, de nem jutok elore egy dologban. valoszinuleg aki jobban ert hozza hamar megmondja merrefele induljak el. Koszi!

Új hozzászólás Aktív témák