diff --git a/app/docs/guides/training/networking/01_full_docs.md b/app/docs/guides/training/networking/01_full_docs.md
index a02b89150e25c7a3652b94e3967e451b05d52b80..9710ce987a6cf476a1419f223bd0f51bdec9c2e2 100644
--- a/app/docs/guides/training/networking/01_full_docs.md
+++ b/app/docs/guides/training/networking/01_full_docs.md
@@ -5,7 +5,7 @@
Ez egy networking gyorstalpaló, teljesen az alapoktól.
A cél az, hogy aki elolvassa, annak legyen fogalma arról, mi szükséges a hálózaton keresztül történő kommunikációhoz, mik a lépései, milyen hálózati eszközök vesznek részt ebben, mi a feladatuk. Hogyan épül fel egy „interneten keringő” üzenet, és hogyan jut el egyik eszköztől a másikig. Természetesen mindezt olyan részletességgel, hogy az alkalomig el tudjátok olvasni.
-Ha úgy érzed, ez neked megy, tudsz válaszolni az alábbi kérdésekre (vagy esetleg hallgattad a KomHálók 1 című tárgyat), nem szükséges elolvasnod ezt. Azért átfutni mindenképp megéri:)
+Ha úgy érzed ez neked megy és tudsz válaszolni az alábbi kérdésekre, akkor nem szükséges elolvasnod ezt. Azért átfutni mindenképp megéri:)
:::info Kérdések
@@ -15,7 +15,7 @@ Ha úgy érzed, ez neked megy, tudsz válaszolni az alábbi kérdésekre (vagy e
1. Pingeled a 8.8.8.8-at, és válaszol. Pingeled a google.com-ot, és nem válaszol. Mi lehet a baj?
1. Milyen címmel címzünk layer 2-n? És layer 3-on?
1. Ki az a felfedező, aki keres neked egy IP címet?
-1. Ha az lenne a feladatot, hogy SSH-zz be egy eszközre, hanyas porton próbálnád keresni?
+1. Ha az lenne a feladatot, hogy SSH-zz be egy eszközre, hanyas porton próbálnád meg? Mit tennél, ha nem sikerülne?
:::
@@ -24,8 +24,10 @@ Ha úgy érzed, ez neked megy, tudsz válaszolni az alábbi kérdésekre (vagy e
- A Schönherz teljes hálózatát a KSZK üzemelteti
- 2db 10Gbites Uplinkkel rendelkezünk az egyetem felé
- Nálunk volt az elsők közt elérhető az IPv6
+- Nálunk volt az elsők közt elérhető gigabites hálózat
- Több, mint 1100 végponttal rendelkezünk
-- RTR-1 annyit fogyaszt, mint egy hajszárító (Bár picit nehéz lenne hosszabban megtartani)
+- RTR-1, az elsődleges központi eszközünk, annyit fogyaszt, mint egy hajszárító (Bár picit nehéz lenne a fejed fölé tartani)
+- Van már több olyan hálóeszközünk, amelynek konfigját automatizálva menedzseljük (Ansible és Gitlab-ci segítségével)
:::
@@ -38,11 +40,11 @@ alt="Bevezető hálózat"
width="500px"
/>
-De mégis hogyan kapja meg a számítógépünk a kért weboldalt, miért tudunk beszélgetni barátainkkal, mit is jelent az, hogy „az internethez kapcsolódva”?
+De mégis hogyan éri el a számítógépünk a kért weboldalt, miért tudunk beszélgetni barátainkkal, mit is jelent az, hogy „az internethez kapcsolódva”?
Az internet hálózatok hálózatok ... hálózatok hálózata, felhasználók milliárdjait köti össze, és ebből egy a mi gépünk. Ezt végiggondolva jogos az első kérdés, hogy mégis hogyan van ennyi eszköz azonosítva?
-A hálózat szereplői, és maguk a hálózatok is, különböző címzésekkel érhetők el. De még mielőtt a címzéseket kifejtjük, fontos tudni azok módjait. Ha van egy üzenetünk, ami egyetlenegy címzettnek szól, akkor az üzenet **unicast**. Ha azt szeretnénk, mindenki meghallja a mondandónk, mindenkinek megcímezzük. Ez a **broadcast**. Létezik egy kettő közti állapot, mikor egy bizonyos csoport minden tagjának, de kizárólag csak csoporttagoknak szól az üzenetünk. Ezt hívjuk **multicast**nak.
+A hálózat szereplői, és maguk a hálózatok is, különböző címzésekkel érhetők el. De még mielőtt a címzéseket kifejtjük, fontos tudni az üzenetküldések lehetséges módjait. Ha van egy üzenetünk, ami egyetlenegy címzettnek szól, akkor az üzenet **unicast**. Ha azt szeretnénk, mindenki meghallja a mondandónk, mindenkinek megcímezzük. Ez a **broadcast**. Létezik egy kettő közti állapot, mikor egy bizonyos csoport minden tagjának, de kizárólag csak csoporttagoknak szól az üzenetünk. Ezt hívjuk **multicast**nak.
További információért tekintsük meg az alábbi ábrát.
<img
@@ -50,7 +52,7 @@ src={require('./img/network_large.png').default}
alt="Extrémebb hálózat"
/>
-Ez egy bonyolultabb hálózat. A hengerek routerek, a téglatestek switchek, egyelőre nem baj, ha nem tudjuk pontosan, mik ezek az eszközök és mi a feladatuk. Most a hangsúly az **alhálózat** (subnet) fogalmának elsajátításán van. A bekarikázott részek az alhálózatok. Az alhálózat olyan eszközök csoportja, amin belül mindenki megkapja a broadcast, azaz a mindenkinek szóló üzeneteket. Nyilvánvalóan lehetetlen és értelmetlen lenne az, ha az internethez csatlakozó összes létező eszköz megkapná az általunk kiküldött broadcast üzenetet. Ezek a csoportok, vagy más néven broadcast domainek osztják kisebb alhálózatokra a nagy egészet. Sok szó lesz még arról, hogy gyakorlatban ez hogyan történik. Előtte még térjünk vissza az ábrához.
+Ez egy bonyolultabb hálózat. A hengerek routerek, a téglatestek switchek, egyelőre nem baj, ha nem tudjuk pontosan, mik ezek az eszközök és mi a feladatuk. Most a hangsúly az **alhálózat** (subnet) fogalmának elsajátításán van. A bekarikázott részek az alhálózatok. Az alhálózat olyan eszközök csoportja, amin belül mindenki megkapja a broadcast-ot, azaz a mindenkinek szóló üzeneteket. Nyilvánvalóan lehetetlen és értelmetlen lenne az, ha az internethez csatlakozó összes létező eszköz megkapná az általunk kiküldött broadcast üzenetet. Ezek a csoportok, vagy más néven broadcast domainek osztják kisebb alhálózatokra a nagy egészet. Sok szó lesz még arról, hogy gyakorlatban ez hogyan történik. Előtte még térjünk vissza az ábrához.
Az eszközök switchekhez vannak kötve, a switchek routerekhez.
A routerek másik routerekhez. Az összekötött routerek hatalmas hálózata alkotja az internetet. Ennyi észrevétel egyenlőre elég.
@@ -134,9 +136,9 @@ Ez nem azt jelenti, hogy ne lehetne a világon egyedi IP címünk. Ezt hívjuk *
A `10.0.0.0/8`, `172.16.0.0/12` és a `192.168.0.0/16` tartományokat **privát hálózati cím**eknek hívjuk, legtöbbször ilyen címet kapunk egy átlagos alhálózatba becsatlakozva.
-Privát,( vagyis publikus interneten nem találkozhatunk velük, erről „gondoskodnak a routerek”. A külvilág számára elfedik az általuk vigyázott alhálózat összes eszközét, egy IP címként mutatva az egész alhálózatot. Ez a **NAT** (Network Address Translation), erről egyelőre elég ennyit tudni.
+Privát (vagyis publikus interneten nem találkozhatunk velük), erről „gondoskodnak a routerek”. A külvilág számára elfedik az általuk örzött alhálózat összes címét, egy publikus IP címként mutatva az egész privát alhálózatot. Ez a **NAT** (Network Address Translation), erről egyelőre elég ennyit tudni.
-A `127.0.0.1` címet még érdemes megemlíteni, ez az úgynevezett **loopback** cím. Ez minden számítógép számára a saját belső címe, ide küldi a saját magának szóló üzeneteket.
+A `127.0.0.0/8` -as tartományát még érdemes megemlíteni. Ebből a tartományból kikerülő bármelyik címet **loopback** -nek hívjuk. Ez csak a saját hálózati kártyánkon belül használható (~saját gépen beül). Nagyon sok féle dologra szoktuk használni pl.: hálózat tesztelés, webszerver futatása lokális fejlesztésre stb.
Van még egy fontos IP cím, amit ismerni kell. Minden, az interneten kommunikálni kívánó eszköznek szüksége van a sajátján kívül még egy IP címre, hogy ezt megtehesse. Ezt hívjuk **default gateway**-nek.
@@ -164,7 +166,7 @@ Ha egy weboldalt szeretnénk megnézni, az előbbi „ha felkeressük a google.c
### DNS
-A visszautalásokat folytatva, fényt derítünk „a „valami varázslat” folytán”-ra. Ez a varázslat a **DNS** (vagy névfeloldás, Domain Name System). A DNS olyan hierarchikus felépítésű szerverek hálózata, amik az ember által olvasható domain nevekhez (például google.com, edu.vik.bme.hu) IP címet társítanak. A legtöbbet használt DNS szerverek a Google 8.8.8.8 című és a CloudFlare 1.1.1.1 című szerverei. Mikor rákeresünk a google.com-ra, vagyis tudni szeretnénk az IP címét, a gépünk először lokálisan megnézi, van-e arról valami információja. Ha nincs, kérést intéz az (már előre ismert) DNS szervernek. Ha ő sem tudja, továbbdobja a következőnek. A kérésünk egészen addig kering, míg választ nem ad valaki. De nem ám véletlenszerűen dobálóznak. A domain nevek hierarchikusak, és a DNS szerverek is hierarchikusan vannak elosztva ez alapján. Példaként az edu.vik.bme.hu. Hu-ból van a legtöbb, ezen belül bme is van jó pár, és így tovább. A szerverek tudják, hogy a lefedett domain neveiken belül merre továbbítsák a kérést. Ha létezik a domain név, meglesz az IP cím.
+A visszautalásokat folytatva, fényt derítünk „a „valami varázslat” folytán”-ra. Ez a varázslat a **DNS** (vagy névfeloldás, Domain Name System). A DNS olyan hierarchikus felépítésű szerverek hálózata, amik az ember által olvasható domain nevekhez (például google.com, edu.vik.bme.hu) IP címet társítanak. A legtöbbet használt DNS szerverek a Google 8.8.8.8 című és a CloudFlare 1.1.1.1 című szerverei. Mikor rákeresünk a google.com-ra, vagyis tudni szeretnénk az IP címét, a gépünk először lokálisan megnézi, van-e arról valami információja. Ha nincs, kérést intéz a (már előre ismert) DNS szervernek. Ha ő sem tudja, továbbdobja a következőnek. A kérésünk egészen addig kering, míg választ nem ad valaki. De nem ám véletlenszerűen dobálóznak. A domain nevek hierarchikusak, és a DNS szerverek is hierarchikusan vannak elosztva ez alapján. Példaként az edu.vik.bme.hu. Hu-ból van a legtöbb, ezen belül bme is van jó pár, és így tovább. A szerverek tudják, hogy a lefedett domain neveiken belül merre továbbítsák a kérést. Ha létezik a domain név, meglesz az IP cím.
Figyelem, jól haladunk, végigjártuk az **OSI modell**t!! Úgy, hogy nem is beszéltünk róla.
@@ -178,24 +180,24 @@ alt="OSI Modell" width="450px"/>
Már oldalak óta arról olvasunk, hogy nagyon különböző feladatkörökre lehet osztani a hálózati kommunikációt. Ezeket a feladatokat, felelősségeket rétegekbe rendezték, és elnevezték őket, hogy ilyen szép ábráról tanulhassunk. Meg azért, hogy mindennek meglegyen a saját felelőssége, függetlenül a többiektől, és ha egy réteget kicserélünk, ez a többire ne legyen hatással.
Ahhoz, hogy minden egységesen működjön, előre definiált szabályok, eljárási módok szükségesek. Ezt hívjuk protokollnak. Akármilyen hálózati eszközről beszélünk, mind ismeri a protokollokat és az OSI modellt, és ez alapján jár el. Ezért tud működni az internet.
-A kép jobb oldalán olvashatók a rétegek nevei és felelősségük, jobb oldalon pedig, hogy minek hívjuk az adott rétegbeli „üzenetet”.
+A kép jobb oldalán olvashatók a rétegek nevei és felelősségük, bal oldalon pedig, hogy minek hívjuk az adott rétegbeli „üzenetet”.
A színkód is fontos. Ez a 7 darab réteg alaposan átgondoltak, de gyakorlatban nem különítünk el ennyit. Az azonos színű rétegeket egynek értelmezzük a TCP/IP modellben, ami az OSI modell továbbgondolása, vagy inkább gyakorlatba ültetése.
Az **1., fizikai réteg**gel ebben a jegyzetben külön nem foglalkozunk. Ez a témakör inkább arról szól, hogy mégis hogyan juttatjuk el bitjeinket a különböző rendelkezésre álló közegeken keresztül.
A **2., adatkapcsolati réteg** a „MAC-címes” réteg. Itt történik a fizikai címzés, az eszköz fizikai azonosítása.
-A **3., hálózati réteg** az „IP címes” réteg. Itt történik a logikai címzés, hogy a világon merre is keressük azt az eszközt. Megvalósítja a végponttól végpontig tartó kapcsolatot.
-A **4., szállítási réteg** a „portos” réteg. Tudja, hogy melyik szolgáltatásnak címezték az üzenetet, küldő és fogadó oldalon is azonosítja a kommunikáló szolgáltatásokat.
+A **3., hálózati réteg** az „IP címes” réteg. Itt történik a logikai címzés, hogy a világon merre is keressük azt az eszközt.
+A **4., szállítási réteg** a „portos” réteg. Tudja, hogy melyik szolgáltatásnak címezték az üzenetet, küldő és fogadó oldalon is azonosítja a kommunikáló szolgáltatásokat.
A **„felsőbb rétegeket”**, amik már a felhasználói élményt gazdagítják, erről is csak minimálisan beszélünk.
### Egy üzenet útja
De hogyan kell ezt elképzelni a gyakorlatban, hogyan lesz a bitekből weboldal?
-Nos, tegyük fel, hogy megszületett az adathalmazunk, ami például egy http kérés. Mivel most a legfelső rétegekkel nem foglalkozunk, feltesszük azt is, hogy ez az adathalmaz készen áll arra, hogy a webserver értelmezze és válaszoljon rá. Az egyben elküldhető méretűre darabolt adathalmazt feldarabolás (vagyis szegmentálás) után szegmensnek hívjuk, és ellátjuk egy portszámmal. A szegmenst megcímezzük a google.com IP címével, hogy a router tudja, merre kell küldeni a tőlünk kapott csomagot (packet). A csomagunkat a default gatewaynek kell küldeni, hiszen azon keresztül mennek ki alhálózatunkból az üzenetek. Megcímezzük a csomagot a default gateway MAC-címével. Mostmár ez egy Ethernet keret. És az üzenetünk elküldhető állapotban van.
+Nos, tegyük fel, hogy megszületett az adathalmazunk, ami például egy http kérés. Mivel most a legfelső rétegekkel nem foglalkozunk, feltesszük azt is, hogy ez az adathalmaz készen áll arra, hogy a webserver értelmezze és válaszoljon rá. Az egyben elküldhető méretűre darabolt adathalmazt feldarabolás (vagyis szegmentálás) után szegmensnek hívjuk, és ellátjuk két portszámmal. Egy forrásporttal, ami a küldő "programot" és egy célporttal, ami a "távoli szolgáltatást" azonosítja. A szegmenst megcímezzük a google.com IP címével, hogy a router tudja, merre kell küldeni a tőlünk kapott csomagot (packet). A csomagunkat a default gatewaynek kell küldeni, hiszen azon keresztül mennek ki alhálózatunkból az üzenetek. Megcímezzük a csomagot a default gateway MAC-címével. Mostmár ez egy Ethernet keret. És az üzenetünk elküldhető állapotban van.
Mi történik a kerettel az út során?
-A switch (az ábrán „szinti rendező”) megnézi a keretben lévő MAC-címet és tudja, hogy az a default gateway-é. Hát elküldi neki. A default gateway (vagyis, a router) megkapja, látja, hogy neki van címezve a keret. Leszedi a keretet, ránéz a csomagra, és megtudja, hogy a 142.250.180.238-nak (azaz a google.com-nak) kell küldeni. Persze a router sem mindentudó, annyi információja van csupán, hogy merre kell továbbküldenie, hogy közelebb kerüljön a célhoz. És ez az út számtalan routeren vezeti keresztül szegény üzenetet, míg ténylegesen célba ér. De amint az üzenet és a szerver egymásra találnak, a többi már rájuk tartozik.
+A switch (az ábrán „szinti rendező”) megnézi (de nem változtat rajta) a keretben lévő MAC-címet és tudja, hogy az a default gateway-é. Hát elküldi neki. A default gateway (vagyis, a router) megkapja, látja, hogy neki van címezve a keret. Leszedi a keretet, ránéz a csomagra, és megtudja, hogy a 142.250.180.238-nak (azaz a google.com-nak) kell küldeni. Persze a router sem mindentudó, annyi információja van csupán, hogy merre kell továbbküldenie, hogy közelebb kerüljön a célhoz. És ez az út számtalan routeren vezeti keresztül szegény üzenetet, míg ténylegesen célba ér. Akár az is előfordulhat, hogy a csomagok különböző útvonalon érnek célba, akár egy kört is mehetnek, de az is előfordul, hogy elvesznek. Amint az üzenet és a szerver egymásra találnak, a többi már rájuk tartozik.
A szerver a megadott port alapján megkeresi a szolgáltatást, akinek szól, az majd értelmezi az üzenetet.
Hogy kicsit konkretizáljuk a megnevezéseket, az adatkapcsolati réteget szoktuk **Layer2**-nek, a hálózati réteget **Layer3**-nak is hívni.