1. Egy Git repository-ban melyik parancs tölti le ÉS egyesíti a távoli változásokat? (git pull)

A Git egy elosztott verziókezelő rendszer, amely lehetővé teszi a fejlesztők számára, hogy egy projekt különböző változásait nyomon kövessék és kezeljék. A Git egyik legfontosabb jellemzője, hogy lokális másolatot tart mindenki a repository-ról, így a fejlesztés nem függ folyamatos internetkapcsolattól. Ebben a környezetben a távoli repository (pl. GitHub, GitLab) tartalmazza a központi kódverziót, míg a fejlesztők a lokális gépükön dolgoznak.

A Git egyik leggyakrabban használt parancsa a git pull.

• A git pull két műveletet végez egy lépésben:
  1. Letölti a távoli repository változásait (git fetch).
  2. Merge-eli azokat a lokális branch-be (git merge).

Ez azt jelenti, hogy ha például a csapattársaid módosították a main branch-et, és te szeretnéd frissíteni a saját lokális verziódat, akkor a git pull origin main parancs automatikusan letölti és egyesíti a változásokat. Ha a távoli és a lokális változások nem ütköznek, a merge automatikusan kész. Ha viszont konfliktus van, a Git jelzi, és manuálisan kell feloldani a konfliktusokat.

Példa munkafolyamat:

Ellenőrizd, hogy melyik branch-en vagy:

Frissítsd a lokális branch-et a távoli változásokkal:

Ha konfliktus van, a Git jelzi a fájlokban, mely sorokat kell módosítani. A konfliktus feloldása után:

Tippek:

• Ha csak szeretnéd letölteni a változásokat, de nem akarod azonnal egyesíteni, használj git fetch.
• A git pull --rebase alternatíva lehet, hogy lineáris történetet tarts fenn, anélkül, hogy merge commitok szaporodnának.
• Mindig célszerű frissíteni a lokális branch-et, mielőtt új commitot küldesz a távoli repository-ba, hogy elkerüld a konfliktusokat.

Összefoglalás:
A git pull tehát a leggyorsabb módja annak, hogy szinkronizáld a lokális munkát a távoli repository-val, mert mind letölt, mind egyesít, így a fejlesztő mindig a legfrissebb kódon dolgozhat.

git add <fájlok>
git commit

git pull origin main

git branch

2. Mi történik git fetch használatakor? (Csak letölti a változásokat)

A Git verziókezelő egyik alapvető parancsa a git fetch, amely a távoli repository változásainak lekérésére szolgál anélkül, hogy azonnal megváltoztatná a lokális munkakörnyezetedet. Ez az egyik legfontosabb eszköz, ha biztonságosan szeretnéd nyomon követni a távoli változásokat, és elkerülnéd az automatikus merge okozta esetleges konfliktusokat.

Hogyan működik a git fetch?

1. Távoli változások lekérése
   A git fetch kapcsolatba lép a távoli repository-val (például GitHub, GitLab, Bitbucket), és letölti az új commitokat, branch-eket, tag-eket, anélkül hogy azokat a jelenlegi lokális branch-edhez hozzáadná.
2. Frissített referencia létrehozása
   A letöltött változások a távoli branch-ekben jelennek meg (origin/main, origin/develop stb.), de a lokális branch-ed állapota változatlan marad. Ez azt jelenti, hogy láthatod, mi történt a távoli repository-ban, mielőtt integrálnád a saját munkádba.
3. Biztonságos ellenőrzés

Ellenőrizheted a különbségeket:

Ez megmutatja azokat a commitokat, amik a távoli main branch-en vannak, de nálad még nem.

Ha szeretnéd összehasonlítani a különbségeket:

Mikor használjuk a git fetch-t?

• Elővigyázatosság miatt: Ha nem akarod rögtön egyesíteni a változásokat.
• Nagy csapatban való munka: Könnyen ellenőrizheted, ki mit változtatott, mielőtt merge-elnéd a saját munkádat.
• Merge konfliktusok elkerülése: Lehetőséget ad arra, hogy először átnézd a változásokat, és felkészülj a konfliktusok megoldására.

Példa: git fetch használata

Kapcsolódás a távoli repository-hoz:

• Letölti az összes távoli branch-et és frissíti a lokális referencia tárolót (refs/remotes/origin/*).

Ellenőrzés:

• Itt láthatod az összes távoli branch-et, amelyeket most frissített a fetch.

Merge, ha szükséges:

• Most integrálhatod a változásokat a saját main branch-edbe.

Összefoglalás

• git fetch = letöltés merge nélkül
• Biztonságos, mert nem változtatja meg a lokális munkád állapotát.
• Ideális ellenőrzésre, különösen csapatmunkában, ahol gyakoriak a változások.
• Ha később szeretnéd a változásokat integrálni, manuálisan merge-elned kell.

A git pull és git fetch közti különbség kulcsfontosságú: míg a pull letölt és automatikusan merge-el, a fetch csak letölt, így kontrolláltan lehet integrálni a változásokat.

git merge origin/main

git branch -r

git fetch origin

git diff main origin/main

git log HEAD..origin/main

3. Egy REST API esetén melyik HTTP metódus NEM idempotens? (POST)

A webes alkalmazások és szolgáltatások kommunikációjában a REST (Representational State Transfer) API az egyik legelterjedtebb architektúra. A REST alapelve, hogy a kliens és a szerver HTTP metódusokkal kommunikál, amelyek egyértelműen meghatározzák a kérések jellegét: lekérdezés, létrehozás, frissítés, törlés. A legismertebb HTTP metódusok: GET, POST, PUT, DELETE, PATCH.

Idempotencia fogalma

Az idempotens művelet azt jelenti, hogy többszöri végrehajtás ugyanazt az eredményt adja, mintha egyszer hajtottuk volna végre. Ez különösen fontos API tervezésnél és hibatűrésnél, mert ha egy kliens újraküldi a kérést (pl. hálózati hiba miatt), az nem okozhat nem várt változást az adatbázisban vagy az állapotban.

• Idempotens metódusok: GET, PUT, DELETE
  • GET: Csak lekérdez, nem változtatja az állapotot.
  • PUT: Többszöri végrehajtás ugyanazt az erőforrás állapotot állítja be.
  • DELETE: Ha egyszer töröltük az erőforrást, a további törlések ugyanazt az eredményt adják (erőforrás már nincs).
• Nem idempotens metódus: POST
  • Minden POST kérés új erőforrást hozhat létre, vagy más hatást generálhat, így többszöri végrehajtás különböző eredményt adhat.
  • Példa: Ha egy POST /orders kérést küldünk, minden kérés egy új rendelést hoz létre az adatbázisban. Ha ugyanazt a kérést kétszer küldjük, két külön rendelés jön létre.

Példák a gyakorlatban

GET:

• Lekéri a 123-as felhasználó adatait. Többször is végrehajtható, az eredmény ugyanaz (feltéve, hogy nem változtatták a felhasználót más módon).

PUT:

• Frissíti a felhasználó nevét. Ha többször küldjük, az eredmény ugyanaz: a név beállítódik.

POST:

• Minden kérés új rendelést hoz létre. Többször küldve több rendelés jön létre.

DELETE:

• Törli a 456-os rendelést. Ha újraküldjük, a rendelés már nincs, de a végállapot ugyanaz: a rendelés nem létezik.

Miért fontos a nem idempotens POST?

• Biztonság és hibakezelés: A nem idempotens műveleteket óvatosan kell használni hálózati újraküldés esetén. Például egy fizetési tranzakcióhoz POST-ot használunk, mert minden új kérés új fizetést generálna.
• API tervezés: A fejlesztőknek tisztában kell lenniük az idempotenciával, hogy előre lássák, milyen hatása lesz a kliens kéréseinek többszöri végrehajtása.
• Hibatűrés: Idempotens metódusoknál biztonságosabb az automatikus újrapróbálkozás. Nem idempotens műveleteknél érdemes unique token-t vagy empotency key-t használni, hogy elkerüljük a többszörös létrehozást.

Összefoglalás

• Idempotens: GET, PUT, DELETE
• Nem idempotens: POST
• A POST minden új kérésnél potenciálisan eltérő eredményt hoz, ezért hiba- és duplikációkezelésnél külön figyelmet igényel.
• REST API tervezésnél az idempotencia kulcsfontosságú a stabil, megbízható és prediktálható működéshez.

DELETE /orders/456

POST /orders
{
    "product": "Laptop",
    "quantity": 1
}

PUT /users/123
{
    "name": "Attila Szécsi"
}

GET /users/123

4. Egy hibakeresés során a ping működik, de a weboldal nem érhető el. Mi a legvalószínűbb hiba? (DNS probléma)

Hálózati problémák diagnosztizálásakor gyakran találkozunk azzal a helyzettel, hogy az eszköz kapcsolódik a hálózathoz, de bizonyos szolgáltatások nem működnek. Egy klasszikus példa: a ping parancs sikeres, de egy weboldal (HTTP/HTTPS) nem elérhető. Ez a helyzet általában DNS problémára utal.

Mi a DNS?

A DNS (Domain Name System) egy olyan szolgáltatás, amely a felhasználó által megadott domain neveket (pl. www.example.com) IP címekké alakítja, hogy a számítógépek hálózati szinten tudjanak kommunikálni.

• Ha a DNS működik, a böngésző vagy bármely kliensprogram le tudja kérdezni a domainhez tartozó IP címet.
• Ha a DNS hibás, a kliens nem találja az IP címet, és a weboldal nem töltődik be, még ha a hálózati kapcsolat maga működik is.

Miért pingel működik, de weboldal nem?

A ping parancs általában közvetlenül az IP címre küld csomagokat, például:

Ha ez működik, az azt jelenti, hogy a fizikai kapcsolat, az útvonal és a hálózati interfészek rendben vannak.

Ha viszont megpróbálod a domain nevet pingelni:

és nem működik, a probléma valószínűleg a DNS feloldás.

Gyakori DNS problémák

1. Helytelen DNS szerver beállítás
   • A kliens gép vagy router nem tudja, melyik DNS szervert használja, vagy a megadott szerver nem elérhető.
2. DNS cache hiba
   • A kliens vagy a helyi hálózat elavult DNS információt tárol, ami miatt nem oldódik fel a domain.
3. Tűzfal vagy hálózati szabály korlátozása
   • A DNS kérések blokkolva lehetnek, míg a ping ICMP csomagok engedélyezettek.
4. Internetszolgáltató problémák
   • A szolgáltató DNS szerverei hibásak vagy nem válaszolnak.

Hibakeresés lépései

1. Teszteld az IP elérhetőségét

Pingelj közvetlen IP címet:

Ha sikeres → hálózat működik.

1. Teszteld a DNS feloldást

Pingeld a domain nevet:

Ha sikertelen → valószínű DNS probléma.

1. Ellenőrizd a DNS beállításokat

Windows:

Linux:

• Nézd meg, hogy a megfelelő DNS szerver van-e beállítva (pl. 8.8.8.8 a Google DNS).

1. DNS cache ürítése

Windows:

Linux: a szolgáltatás újraindítása (pl. systemd-resolved):

1. Alternatív DNS használata
   • Próbálkozhatsz nyilvános DNS-sel: Google (8.8.8.8, 8.8.4.4) vagy Cloudflare (1.1.1.1).
2. Traceroute / nslookup

Ellenőrizheted, hol akad el a kapcsolat:

Összefoglalás

• A ping működése jelzi, hogy a fizikai hálózat rendben van.
• A weboldal nem elérhetősége legtöbbször DNS problémára utal.
• Gyakori okok: helytelen DNS, cache probléma, tűzfal korlátozás, szolgáltatói hiba.
• A megoldás: DNS ellenőrzése, cache ürítése, alternatív DNS kipróbálása, szükség esetén hálózati beállítások módosítása.

A DNS-problémák megértése kulcsfontosságú minden hálózati adminisztrátornak, mivel a felhasználók gyakran azonnal weboldal-hibaként tapasztalják a problémát, miközben a fizikai hálózat működik.

tracert www.example.com  # Windows
traceroute www.example.com  # Linux

nslookup www.example.com

sudo systemctl restart systemd-resolved

ipconfig /flushdns

cat /etc/resolv.conf

ipconfig /all

ping www.example.com

ping 8.8.8.8

ping www.example.com

ping 8.8.8.8

5. Egy IPv4 hálózat: 192.168.10.0/26. Hány használható host cím van? (62)

Az IPv4 címzés az egyik alapja minden hálózati kommunikációnak. És igen, ez az a rész, ahol a diákok fele elveszik a /26-nál, a másik fele meg magabiztosan rosszat számol. Szóval nézzük rendesen.

IPv4 cím felépítése

Egy IPv4 cím 32 bitből áll, amit általában négy oktettre bontva írunk le, például:

192.168.10.0

A /26 azt jelenti, hogy:

• az első 26 bit a hálózati rész
• a maradék 6 bit a host rész

Mert:

32 - 26 = 6

Hány cím van összesen?

A host bitek száma határozza meg, hány cím lehetséges:

2^host bitek száma = 2^6 = 64

Tehát a teljes címtartományban 64 IP cím van.

Miért nem használható mind a 64?

Mert a hálózat nem ilyen nagylelkű.

Két cím nem használható hostként:

1. Hálózati cím (network address)
   • Az első cím a tartományban
   • Azonosítja a hálózatot

Jelen esetben:

1. Broadcast cím
   • Az utolsó cím a tartományban
   • Minden hostnak szóló üzenetekre használjuk

Jelen esetben:

Használható host címek száma

Összes cím – 2 = használható host címek
64 – 2 = 62

Tehát a helyes válasz: 62

Tartomány meghatározása

Most nézzük meg konkrétan:

Hálózati cím:

Első használható:

Utolsó használható:

Broadcast:

Gyors fejben számolás (vizsgán életmentő)

A /26-ot érdemes így megjegyezni:

• /24 → 256 cím
• /25 → 128 cím
• /26 → 64 cím

Mindig feleződik. Mint a diákok motivációja év végére.

Tipikus hibák

• 64-et válaszolnak, mert nem vonják ki a 2 speciális címet
• Rosszul értelmezik a prefixet (/26)
• Nem tudják meghatározni a tartomány végét

Gyakorlati jelentőség

Ez nem csak elméleti kínzás:

• VLAN tervezésnél tudni kell, hány eszköz fér el
• DHCP scope beállításnál pontos tartomány kell
• Subnetelésnél optimalizálod a hálózatot

Ha valaki itt hibázik, később egy teljes hálózatot tud elrontani. Szóval igen, ez fontos.

Összefoglalás

• /26 → 6 host bit
• 2⁶ = 64 összes cím
• 64 – 2 = 62 használható host
• Tartomány: 192.168.10.0 – 192.168.10.63

192.168.10.63

192.168.10.62

192.168.10.1

192.168.10.0

192.168.10.63

192.168.10.0

6. Mi a broadcast cím a 192.168.10.0/26 hálózatban? (192.168.10.63)

A broadcast cím az egyik legalapvetőbb, mégis rendszeresen félreértett fogalom a hálózatok világában. Pedig nem egy misztikus dolog, csak egy konkrét szabály: mindig a hálózat utolsó címe.

Mi az a broadcast cím?

A broadcast cím egy speciális IP cím, amelyre küldött csomagot a hálózat összes eszköze megkapja.
Ez afféle „mindenkinek szól” üzenet.

Példák, ahol használják:

• ARP lekérdezés (kié ez az IP?)
• DHCP (IP cím kérés)
• bizonyos hálózati protokollok

Fontos: hostnak nem adható ki, mert nem egy konkrét gépet jelöl.

Kiindulási hálózat

192.168.10.0/26

Mint az előző feladatban:

• /26 → 6 host bit
• 2⁶ = 64 cím

Tartomány meghatározása

Egy /26-os hálózat blokkmérete:

256 - 192 = 64

Vagy egyszerűbben:

• /26 → 64-es lépések

Tehát a hálózat így néz ki:

192.168.10.0 – 192.168.10.63

Broadcast cím meghatározása

A broadcast cím mindig:

a tartomány utolsó címe

Tehát:

192.168.10.63

Ez a helyes válasz.

Bináris megközelítés (ha valaki szereti a fájdalmat)

IP cím:

192.168.10.0 = 11000000.10101000.00001010.00000000

/26 → első 26 bit fix (hálózat), utolsó 6 bit a host

Broadcast esetén:

• minden host bit = 1

000000 → 111111

Ez decimálisan:

63

Tehát:

192.168.10.63

Gyakori hibák

• 192.168.10.255
  → reflexből /24-re gondolnak (nem, itt /26 van)
• 192.168.10.64
  → ez már a következő alhálózat kezdete
• 192.168.10.62
  → ez az utolsó használható host, nem a broadcast

Gyakorlati jelentőség

Ez nem csak vizsgakérdés:

• DHCP broadcasttal indul
• hálózati hibakeresésnél fontos
• rossz broadcast cím → kommunikációs hibák
• VLAN-oknál külön broadcast domain-ek vannak

Egy rosszul számolt broadcast simán okozhat „miért nem működik semmi” típusú napokat.

Gyors ellenőrzési módszer

Ha már kiszámoltad:

• első cím → hálózat
• utolsó cím → broadcast
• közte → hostok

Ha nem ezt látod, valahol félrement.

Összefoglalás

• /26 → 64 cím
• Tartomány: 192.168.10.0 – 192.168.10.63
• Broadcast: 192.168.10.63
• Nem használható hostként

7. Egy switchen két azonos MAC cím külön porton jelenik meg. Mi történik? (MAC tábla frissül)

A switch működésének egyik alapja a MAC cím alapú továbbítás. Ha ezt nem értjük, akkor a hálózat viselkedése teljesen kiszámíthatatlannak tűnik. Pedig nem az, csak könyörtelenül logikus.

Mi az a MAC cím?

A MAC (Media Access Control) cím:

• egy egyedi azonosító, amit a hálózati kártya kap
• 48 bites (pl. 00:1A:2B:3C:4D:5E)
• Layer 2 (adatkapcsolati réteg) szinten használjuk

A switch nem IP alapján dolgozik, hanem MAC cím alapján.

Hogyan működik a switch?

A switch egy úgynevezett MAC address table-t (CAM tábla) tart fenn:

Amikor egy frame beérkezik:

1. A switch megnézi a forrás MAC címet
2. Eltárolja: „ez a MAC ezen a porton van”
3. A cél MAC alapján továbbítja a frame-et

Mi történik, ha ugyanaz a MAC két porton jelenik meg?

Na itt kezd érdekessé válni.

Ha a switch ezt látja:

• ugyanaz a MAC cím jön be egy másik portról

akkor ezt gondolja:

„Oké, akkor ez a MAC most már itt van.”

És frissíti a MAC táblát.

Tehát:

• nem hibát dob
• nem áll le
• nem pánikol

Egyszerűen átírja a bejegyzést az új portra.

Következmény: MAC flapping

Ha ez folyamatosan történik (oda-vissza váltogat a két port között), azt hívjuk:

MAC flapping

Ez már nem vicces jelenség:

• a forgalom ide-oda ugrál
• csomagvesztés lesz
• instabil hálózat
• néha teljesen „szellemjárta” működés

Mi okozhat ilyet?

Ez az a rész, ahol a diákok általában random tippelnek. Nem kell.

Tipikus okok:

1. Hálózati hurok (loop)
   • Két switch összekötve több kábellel STP nélkül
   • Klasszikus „bedugtam még egy kábelt, mert volt hely” hiba
2. Virtualizáció
   • Egy VM több helyen jelenik meg (pl. migráció közben)
3. Hibás konfiguráció
   • Port security rosszul beállítva
   • trunk/access keverés
4. MAC spoofing
   • Valaki szándékosan hamis MAC címet használ
5. Hibás hálózati eszköz
   • Ritkább, de előfordul

Hogyan lehet felismerni?

Cisco switchen például:

show mac address-table

Ha azt látod, hogy ugyanaz a MAC:

• hol az egyik,
• hol a másik porton jelenik meg

akkor bingo, megvan a probléma.

Logban:

MACFLAP_NOTIF

Megoldási lehetőségek

1. STP (Spanning Tree Protocol) használata
   • automatikusan megszünteti a hurkokat
2. Port security
   • korlátozod, hány MAC lehet egy porton
3. Hálózati topológia átnézése
   • felesleges kábelek megszüntetése
4. Virtualizáció ellenőrzése
   • VM migrációk, bridge-ek

Miért nem IP konfliktus?

Ez egy gyakori rossz válasz.

• Az IP konfliktus Layer 3 probléma
• A switch viszont Layer 2-n működik

Itt MAC címről beszélünk, tehát:
→ nem IP probléma

Összefoglalás

• A switch a MAC táblát dinamikusan frissíti
• Ha ugyanaz a MAC másik porton jelenik meg → átírja
• Ez normális viselkedés
• De ha folyamatos → MAC flapping, ami komoly hálózati hibát jelez

8. Mi az STP root bridge kiválasztás alapja? (Legkisebb Bridge ID)

A Spanning Tree Protocol (STP) egy Layer 2 protokoll, amelynek célja, hogy megakadályozza a hálózati hurkok (loopok) kialakulását. Ha hurkok vannak egy switch hálózatban, az brutális problémákhoz vezet:

• broadcast storm
• MAC tábla instabilitás
• teljes hálózati összeomlás

Az STP ezt úgy oldja meg, hogy létrehoz egy fa struktúrát (spanning tree), ahol nincs kör.

És ennek a fának kell egy gyökere. Ez a root bridge.

Mi az a root bridge?

A root bridge:

• a hálózat központi referenciapontja
• minden útvonal ehhez viszonyítva kerül kiszámításra
• minden switch „ehhez igazodik”

Fontos:
Nem feltétlen a legerősebb eszköz lesz, hanem amelyik „nyer” a kiválasztás során.

Hogyan történik a kiválasztás?

A root bridge kiválasztása egyetlen szabályon alapul:

A legkisebb Bridge ID nyer

Mi az a Bridge ID?

A Bridge ID két részből áll:

1. Prioritás (Priority)
   • Alapértelmezés: 32768
   • Adminisztrátor állíthatja
2. MAC cím
   • Egyedi azonosító

Formátum:

Bridge ID = Prioritás + MAC cím

Döntési folyamat

1. A switchek összehasonlítják a prioritást
   → kisebb nyer
2. Ha azonos a prioritás:
   → kisebb MAC cím nyer

Tehát:

• alacsonyabb szám = jobb esély
• a „legkisebb” Bridge ID lesz a root

Példa

Mindkettőnél azonos a prioritás → MAC dönt

→ SW2 lesz a root, mert kisebb a MAC címe

Miért probléma ez?

Mert a hálózat nem gondolkodik, csak számol.

Simán előfordul:

• egy régi, lassú switch lesz a root
• miközben a legerősebb eszköz ott áll kihasználatlanul

Ez kb. olyan, mintha a leglassabb tanuló diktálná a tempót. Ismerős helyzet.

Hogyan állítjuk be tudatosan?

Egy normális hálózatban nem bízzuk a véletlenre.

Cisco például:

spanning-tree vlan 1 priority 4096

Minél kisebb számot adsz:
→ annál nagyobb eséllyel lesz root

Tipikus stratégia:

• core switch → alacsony prioritás
• access switch → magasabb prioritás

Mi történik a root kiválasztás után?

• Minden switch kiszámolja a legrövidebb utat a root felé
• Kialakul egy loopmentes topológia
• Egyes portok blokkolt állapotba kerülnek

Ez az ára annak, hogy ne haljon meg a hálózat egy broadcast stormban.

Kapcsolat az előző kérdéssel

Emlékszel a MAC flappingre?

Na azt nagyon gyakran az okozza, hogy:

• nincs STP
• vagy rosszul van beállítva

Tehát:
→ STP = életbiztosítás Layer 2-ben

Gyakori hibák

• „legnagyobb MAC cím”
  → nem, pont fordítva
• „leggyorsabb switch”
  → a protokollt nem érdekli
• „legtöbb VLAN”
  → teljesen irreleváns

Összefoglalás

• STP célja: loopok megszüntetése
• Root bridge: a hálózat központja
• Kiválasztás alapja: legkisebb Bridge ID
  • először prioritás
  • aztán MAC cím

9. Mi történik, ha két VLAN között nincs routing? (Nincs kommunikáció)

A VLAN (Virtual Local Area Network) az egyik legalapvetőbb hálózati szegmentálási technika. A lényege, hogy egy fizikai hálózatot logikailag több különálló hálózatra bontunk. És itt jön a csavar: ezek a hálózatok nem látják egymást automatikusan.

Mi az a VLAN?

A VLAN:

• egy logikai hálózat Layer 2 szinten
• külön broadcast domain
• saját IP tartománya van

Példa:

Ez két teljesen külön világ.

Mi történik routing nélkül?

Ha nincs routing:

A VLAN-ok között nincs kommunikáció.

Ez nem hiba. Ez a működés.

Egy VLAN-ban lévő gép:

• tud kommunikálni a saját VLAN-jában
• nem tud elérni más VLAN-t

Miért van ez így?

A switch (Layer 2 eszköz):

• csak MAC címek alapján dolgozik
• nem ért az IP routinghoz

A VLAN-ok pedig:

• külön broadcast domain-ek
• nincs köztük automatikus kapcsolat

Tehát:
→ Layer 2 nem tud Layer 3 helyett gondolkodni

Példa helyzet

• PC1 → VLAN 10 → 192.168.10.10
• PC2 → VLAN 20 → 192.168.20.10

PC1 megpróbálja pingelni PC2-t:

ping 192.168.20.10

Mi történik?

• PC1 látja, hogy más hálózat
• elküldi a default gateway-nek
• DE nincs router → nincs válasz

→ kommunikáció sikertelen

Hogyan lehet megoldani?

Kell egy Layer 3 eszköz, ami routol:

1. Router (klasszikus megoldás)

• minden VLAN-hoz egy interfész vagy alinterfész
• default gateway-ként működik

2. Router-on-a-stick

• egy fizikai interfész
• több subinterface
• trunk kapcsolat a switch felé

3. Layer 3 switch

• beépített routing
• gyorsabb, modernebb megoldás

Mi történik routing esetén?

Ha van routing:

1. PC1 elküldi a csomagot a gateway-nek
2. Router megvizsgálja a cél IP-t
3. Átküldi a megfelelő VLAN-ba
4. PC2 megkapja

→ működik a kommunikáció

Biztonsági jelentőség

Ez nem csak technikai részlet.

A VLAN-ok egyik fő célja:

• szegmentálás
• biztonság növelése

Például:

• diák hálózat ≠ tanári hálózat
• vendég WiFi ≠ belső hálózat

Ha nincs routing:
→ teljes izoláció

Ha van routing:
→ szabályozni kell (ACL-ekkel)

Gyakori hibák

• „lassú kapcsolat”
  → nem lassú, nincs
• „DHCP hiba”
  → DHCP külön kérdés
• „kábel rossz”
  → a fizikai réteg működik

A valóság:
→ nincs Layer 3 kapcsolat

Tipikus valós hiba

• VLAN-ok szépen létrehozva
• IP-k beállítva
• minden „jónak tűnik”

És mégsem működik.

Mi hiányzik?
→ gateway / routing

10. Router-on-a-stick esetén mire van szükség? (Subinterface-ek és trunk kapcsolat)

A router-on-a-stick egy olyan megoldás, amely lehetővé teszi, hogy több VLAN között routing történjen egyetlen fizikai interfészen keresztül. Igen, egy darab porttal. Nem, nem varázslat, csak jól kihasznált szabványok.

Mi az alap probléma?

Az előző kérdésben láttuk:

• VLAN-ok külön hálózatok
• routing kell köztük

A klasszikus megoldás:

• minden VLAN → külön fizikai router interfész

Ez jól hangzik… amíg nincs 10 VLAN-od és 2 portos routered.

Mi az a router-on-a-stick?

Ez egy olyan megoldás, ahol:

• egy router interfész
• több VLAN forgalmát kezeli
• taggelve (802.1Q trunk)

A router logikailag több interfészre bontja ugyanazt a fizikai portot.

A működés lényege

Két kulcselem kell:

1. Trunk kapcsolat (switch ↔ router)

A switch és a router között:

• trunk link van
• több VLAN forgalma megy át rajta
• 802.1Q taggelés történik

Switch oldalon:

interface Fa0/1
switchport mode trunk

2. Subinterface-ek a routeren

A router fizikai interfészét felosztjuk:

interface Gig0/0.10
encapsulation dot1Q 10
ip address 192.168.10.1 255.255.255.0

interface Gig0/0.20
encapsulation dot1Q 20
ip address 192.168.20.1 255.255.255.0

Minden subinterface:

• egy VLAN-hoz tartozik
• saját IP címe van
• ez lesz a VLAN default gateway-e

Hogyan működik a gyakorlatban?

1. PC VLAN 10-ben → elküldi a csomagot a gateway-nek
2. Switch → trunkon továbbítja (taggelve VLAN 10)
3. Router → subinterface felismeri a VLAN-t
4. Router → routolja a másik VLAN-ba
5. Visszaküldi trunkon → megfelelő VLAN-ba

→ kommunikáció működik

Miért hívják így?

„Router-on-a-stick” =
mintha a router egy „pálcán” (egy interfészen) keresztül kommunikálna minden VLAN-nal.

Elég beszédes név, még ha kicsit rajzfilmszerű is.

Előnyök

• Kevés fizikai interfész kell
• Egyszerűbb eszközökön is működik
• Jó oktatási és kisebb hálózati megoldás

Hátrányok

Na itt jön a realitás:

• szűk keresztmetszet
  → minden forgalom egy porton megy
• teljesítmény limitált
  → nem skálázódik jól
• egyetlen hibapont
  → ha ez az interfész leáll, minden megáll

Ezért nagyobb hálózatokban:
→ Layer 3 switch a megoldás

Gyakori hibák

• nincs trunk beállítva
  → VLAN-ok nem jutnak át
• rossz VLAN ID a subinterface-en
  → teljes káosz
• nincs IP cím
  → nincs gateway
• elfelejtett no shutdown
  → klasszikus önszabotázs

Kapcsolat a 9. kérdéssel

Ott:
→ nincs routing → nincs kommunikáció

Itt:
→ van routing → működik

A router-on-a-stick konkrétan egy megoldás arra a problémára.

Összefoglalás

Router-on-a-stick esetén szükséges:

• trunk kapcsolat (802.1Q)
• subinterface-ek a routeren
• minden VLAN-hoz külön IP (gateway)

Egy fizikai interfész → több logikai hálózat kezelése

11. Mi a különbség a statikus és dinamikus routing között?

A routing lényege:

hogyan jut el egy csomag egyik hálózatból a másikba

A kérdés csak az, hogy:

• te mondod meg kézzel az útvonalakat, vagy
• a routerek egymás között megbeszélik

Statikus routing

Ez a „mindent én tudok jobban” megközelítés.

A statikus routingnál:

• az útvonalakat kézzel állítod be
• a router nem tanul magától
• nincs automatikus alkalmazkodás

Példa

ip route 192.168.2.0 255.255.255.0 192.168.1.2

Ez azt jelenti:

• ha a cél a 192.168.2.0 hálózat
• akkor küldd a 192.168.1.2 felé

Előnyök

• egyszerű
• kiszámítható
• nincs protokoll overhead
• biztonságosabb (nem „beszélget” más routerekkel)

Hátrányok

• nem skálázódik
• minden változást kézzel kell kezelni
• hibára nem reagál automatikusan

Ha kiesik egy útvonal:
→ a hálózat csak néz, mint diák a váratlan röpdolgozatnál

Dinamikus routing

Itt a routerek:

• kommunikálnak egymással
• útvonalakat tanulnak
• automatikusan frissítenek

Ez már egy kicsit intelligensebb rendszer.

Hogyan működik?

A routerek routing protokollokat használnak, pl.:

• RIP
• OSPF
• EIGRP
• BGP

Ezek:

• információt cserélnek
• kiszámolják a legjobb útvonalat
• reagálnak a hálózati változásokra

Példa (OSPF)

router ospf 1
network 192.168.1.0 0.0.0.255 area 0

Ez:

• bekapcsolja az OSPF-et
• hirdeti a hálózatot

Előnyök

• automatikus útvonal-kezelés
• hibatűrés (failover)
• jól skálázódik
• kevesebb kézi konfiguráció nagy hálózatban

Hátrányok

• bonyolultabb
• több erőforrást igényel
• hibakeresés nehezebb
• rossz konfiguráció → nagyobb baj

Itt nem egy route hibás, hanem az egész hálózat tud rosszul dönteni.

A két megoldás összehasonlítása

Mikor melyiket használjuk?

Statikus routing:

• kis hálózat
• kevés útvonal
• stabil topológia
• default route beállítás

Dinamikus routing:

• nagy hálózat
• sok útvonal
• változó topológia
• redundancia szükséges

Valós élet példa

Otthoni hálózat:
→ statikus (vagy default route)

Iskola / cég:
→ gyakran dinamikus (OSPF)

Internet:
→ BGP (igen, az a szörnyeteg)

Tipikus hiba

„Beállítottam statikusan, működött, aztán valami elromlott.”

Persze, mert:
→ a hálózat nem gondolkodik helyetted

Dinamikusnál meg:
„valami elromlott, és fogalmam sincs miért”

Összefoglalás

• Statikus routing: kézi, egyszerű, de rugalmatlan
• Dinamikus routing: automatikus, komplex, de alkalmazkodó

12. RIP – amikor a hálózat „számolgat”

A RIP (Routing Information Protocol) az egyik legrégebbi dinamikus routing protokoll. Olyan, mint egy lelkes, de nem túl okos diák: próbálkozik, de egyszerű szabályokkal dolgozik.

Működési elv

A RIP:

• distance-vector protokoll
• a hop count alapján dönt
• maximum 15 ugrásig működik

Hop count = hány routeren megy át a csomag

Példa

Ha egy hálózat:

• 2 routeren keresztül érhető el → jobb
• 5 routeren keresztül → rosszabb

RIP szerint:
→ a kevesebb ugrás mindig jobb

Ami persze néha tévedés, de hát nem filozofál.

Működés

• 30 másodpercenként frissít
• elküldi a teljes routing táblát a szomszédoknak
• nem túl hatékony

Ez konkrétan:
→ „mindenkinek mindent elmondok mindig” stratégia

Előnyök

• egyszerű konfiguráció
• könnyen érthető
• oktatásra ideális

Hátrányok

• lassú konvergencia
• nem skálázódik
• max 15 hop → nevetségesen kevés

Ezért:
→ modern hálózatban ritkán használják

13. OSPF – amikor a hálózat már gondolkodik

Az OSPF (Open Shortest Path First) egy link-state protokoll, ami már nem csak számolgat, hanem ténylegesen „térképet rajzol” a hálózatról.

Működési elv

Az OSPF:

• minden router ismeri a teljes topológiát
• kiszámolja a legrövidebb utat
• a Dijkstra algoritmust használja

Nem csak azt nézi:
→ hány ugrás

Hanem:
→ mennyire „jó” az út

Metrika: COST

Az OSPF nem hop countot használ, hanem:

• sávszélesség alapú költség
• gyorsabb link → kisebb cost

Ez már egy értelmes döntés.

Területek (Area)

Az OSPF hálózat:

• area-kra osztható
• pl. Area 0 (backbone)

Ez segít:

• skálázni
• csökkenteni a terhelést

Előnyök

• gyors konvergencia
• skálázható
• intelligens útválasztás

Hátrányok

• bonyolult konfiguráció
• több erőforrás kell
• hibakeresés nehezebb

14. Konvergencia – a hálózat „megnyugszik”

Ez az a fogalom, amit mindenki bemagol, de kevesen értik elsőre.

Definíció

A konvergencia az az állapot, amikor:

minden router ugyanazt az útvonal-információt ismeri

Egyszerűbben

Ha történik egy változás:

• kiesik egy link
• új hálózat jelenik meg

akkor:

• a routerek frissítik az adatokat
• „megbeszélik egymással”
• kialakul az új stabil állapot

→ ez a konvergencia

Példa

1. Egy kapcsolat megszakad
2. Routerek észlelik
3. új útvonalat számolnak
4. frissítik a routing táblát

Amikor mindenki ugyanazt tudja:
→ konvergált a hálózat

Miért fontos?

Mert konvergencia közben:

• csomagvesztés lehet
• rossz útvonalak lehetnek
• hálózat instabil

RIP vs OSPF

Tipikus valós helyzet

• RIP: „várjunk még 30 másodpercet…”
• OSPF: „már újraszámoltam, nyugi”

Összefoglalás

• RIP: egyszerű, hop count alapú, elavult
• OSPF: intelligens, gyors, modern
• Konvergencia: a hálózat stabil állapotba kerülése

15. ACL – amikor végre valaki szabályokat hoz

Az ACL (Access Control List) az a pont a hálózatban, ahol eldöntjük:

ki beszélhet kivel, és ki nem

Ez lényegében egy szűrőlista, amit routeren vagy switchen alkalmazunk.

Működés

Az ACL:

• szabályok sorozata
• felülről lefelé vizsgál
• első találat dönt

Ha nincs találat:
→ implicit deny (mindent tilt)

Igen, a hálózat alapból bizalmatlan. Talán tanult az emberektől.

Példa

access-list 10 permit 192.168.1.0 0.0.0.255

Ez:

• engedi a 192.168.1.0 hálózatot
• minden más → tiltva

ACL típusok

Standard ACL

• csak forrás IP alapján dönt
• egyszerű

Extended ACL

• forrás + cél IP
• portok (pl. HTTP, FTP)
• protokollok

Ez már tényleg használható.

Alkalmazás

interface Gig0/0
ip access-group 10 in

Ez:

• bejövő forgalmat szűri

Gyakori hibák

• rossz sorrend
• túl általános szabály elöl
• elfelejtett „permit”

→ és máris minden le van tiltva

Valós példa

• diákok ne érjék el a szervert
• vendéghálózat izolálása
• bizonyos portok tiltása

16. NAT – az internet egyik legnagyobb hazugsága

A NAT (Network Address Translation) azt csinálja, hogy:

belső IP címeket külsőre fordít

Ezért tud egy egész hálózat:
→ egyetlen publikus IP mögött működni

Miért kell?

IPv4 cím kevés van. Nagyon.

Ezért:

• belső hálózat: privát IP-k
• internet felé: publikus IP

NAT típusok

Static NAT

• 1:1 megfeleltetés
• fix kapcsolat

Dynamic NAT

• IP poolból oszt

PAT (Port Address Translation)

• sok belső IP → 1 külső IP
• portok alapján különböztet

Ez a leggyakoribb.

Példa

Belső:

• 192.168.1.10

Külső:

• 84.2.3.4:1025

Router:
→ átírja az IP-t és portot

Előnyök

• IP cím spórolás
• belső hálózat elrejtése

Hátrányok

• bonyolultabb hibakeresés
• nem „valódi” end-to-end kapcsolat

Az internet eredetileg nem így lett kitalálva. Csak hát közben elfogytak a címek.

17. DHCP – mert senki nem akar IP-t kézzel írni

A DHCP (Dynamic Host Configuration Protocol) automatikusan ad IP címet.

Ez az egyik leginkább alulértékelt dolog:
→ nélküle mindenki szenvedne

Mit ad a DHCP?

• IP cím
• alhálózati maszk
• default gateway
• DNS szerver

Működés (DORA)

Ez az a rész, amit mindenki bemagol, aztán elfelejti:

1. Discover – kliens keres szervert
2. Offer – szerver ajánlatot ad
3. Request – kliens elfogadja
4. Acknowledge – szerver megerősíti

→ kész, van IP

Példa konfiguráció (routeren)

ip dhcp pool LAN
network 192.168.1.0 255.255.255.0
default-router 192.168.1.1
dns-server 8.8.8.8

Előnyök

• automatikus
• gyors
• kevesebb hiba

Hátrányok

• szerver hiba → nincs IP
• biztonsági problémák (rogue DHCP)

Valós helyzet

• otthon → router DHCP
• iskola → központi DHCP szerver
• VLAN-ok → DHCP relay kell

Összefoglalás

• ACL: forgalom szabályozása
• NAT: IP cím fordítás
• DHCP: automatikus IP kiosztás

Ez a három együtt:

• szabályoz
• elrejt
• kiszolgál

Magyarul:
→ működő hálózat alapja

19. IPv6 – mert az IPv4-et már régen kinőttük

Az IPv4 címtartománya:
→ elfogyott

Nem „majd elfogy”, hanem konkrétan már elfogyott. Ezért született az IPv6, ami egy kicsit… túlzásba vitte a jövőbiztosítást.

Címformátum

IPv4:

• 192.168.1.1

IPv6:

• 2001:0db8:85a3:0000:0000:8a2e:0370:7334

Igen, elsőre úgy néz ki, mint egy rossz jelszó.

Egyszerűsítés

IPv6-ben:

• nullák elhagyhatók
• rövidíthető

Pl.:

2001:db8::1

Ez már emberibb. Kicsit.

Címhossz

• IPv4 → 32 bit
• IPv6 → 128 bit

Ez azt jelenti:
→ gyakorlatilag kifogyhatatlan címkészlet

Annyi IP van, hogy minden homokszemnek jutna külön.

IPv6 előnyei

• rengeteg IP cím
• nincs szükség NAT-ra
• egyszerűbb routing
• beépített biztonsági lehetőségek

IPv6 cím típusok

• Unicast → egy eszköz
• Multicast → több eszköz
• Anycast → legközelebbi eszköz

Broadcast?
→ nincs

Végre valaki rájött, hogy az felesleges zaj.

Automatikus konfiguráció

IPv6 tud:

• SLAAC (önkonfiguráció)
• DHCPv6

Tehát:
→ még kevesebb manuális munka

Miért nem használja mindenki?

Mert:

• IPv4 még „elmegy valahogy”
• átállás bonyolult
• kompatibilitás problémák

Ez az informatikai világ egyik klasszikus esete:
→ „jó ez még, majd egyszer lecseréljük”

20. WiFi – amikor nincs kábel, de vannak problémák

A vezeték nélküli hálózat kényelmes. És cserébe tele van problémával.

Alapfogalom

WiFi = vezeték nélküli LAN

Szabványok:

• 802.11 a/b/g/n/ac/ax

Igen, mintha valaki billentyűzeten végiggurult volna.

Frekvenciák

• 2.4 GHz
  • nagyobb hatótáv
  • lassabb
  • több zavar
• 5 GHz
  • gyorsabb
  • kisebb hatótáv
  • kevesebb interferencia

Titkosítások

WEP

• elavult
• könnyen törhető
  → gyakorlatilag nincs védelem

WPA / WPA2

• sokáig szabvány
• még használják

WPA3

• jelenleg a legbiztonságosabb
• modernebb titkosítás

Biztonsági problémák

WiFi-nél:

• bárki „hallgathatja” a forgalmat
• brute force támadások
• hamis access point (evil twin)

Ezért:
→ titkosítás kötelező

Gyakori hibák

• „gyenge a net”
  → nem a net, a WiFi
• rossz csatorna
• túl sok eszköz
• falak, interferencia

A WiFi:
→ rádiótechnika, nem varázslat

Valós élet

• iskola: több AP kell
• VLAN-ok WiFi-n is
• roaming problémák

És persze:
→ „a 3-as teremben mindig rossz”

Összefoglalás

• IPv6: jövőbiztos IP rendszer, rengeteg címmel
• WiFi: kényelmes, de problémás
• WPA3: jelenleg legbiztonságosabb titkosítás

Dolgozat: https://forms.gle/wRtTDZmBcb29DA3P6