Behálózás

Előljáróban

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 és tudsz válaszolni az alábbi kérdésekre, akkor nem szükséges elolvasnod ezt. Azért átfutni mindenképp megéri:)

Kérdések

1. Milyen eszközöknek van MAC címe, hogyan tudod meg a saját eszközödét?
2. Milyen cím a default gateway, és mi történik, ha nincs beállítva?
3. Hogyan néz ki egy /8-as IP cím hálózati maszkja? Mi az első és utolsó cím, amit ki lehet osztani egy 192.168.0.0/24es alhálózatban?
4. Pingeled a 8.8.8.8-at, és válaszol. Pingeled a google.com-ot, és nem válaszol. Mi lehet a baj?
5. Milyen címmel címzünk layer 2-n? És layer 3-on?
6. Ki az a felfedező, aki keres neked egy IP címet?
7. 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?

Tudtad?

• 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, 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)

Jegyzet

Mindenki számára ismerős az alábbi helyzet:

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 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 multicastnak. További információért tekintsük meg az alábbi ábrát.

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.

Fizikai cím

Az első fontos, azonosításra szolgáló cím a MAC-cím (vagy fizikai cím, Media Access Control Address). Ez a cím a világon egyedi, minden, a hálózaton kommunikálni képes eszközhöz gyártásnál lesz hozzárendelve. Ez alapján az eszközünk egyértelműen azonosítható. Egy MAC-cím összesen 48 bites, 6 darab kettősponttal elválasztott hexadecimális szám, például:

01:23:45:67:89:AB

A saját MAC-címünket Linuxon az ip link , Windowson az ipconfig /all parancsokkal nézhetjük meg.

Van egy MAC-cím, amit egy eszköz sem kaphat meg. Ez az FF:FF:FF:FF:FF:FF. Ennek a címnek külön feladata van, mégpedig az, hogy ő a broadcast cím. Ha az üzenetben nem egy specifikus eszközhöz tartozó cél MAC-cím található, hanem a broadcast MAC-cím, akkor minden eszköz megkapja az alhálózaton belül.

A fentieknek köszönhetően, az eszközöd ismeri a szobatársad eszközének MAC-címét, és a neki szóló üzeneteket képes az ő saját MAC-címével megcímezni.

Logikai cím

De mi van akkor, ha egy másik emeleten, vagy akár másik kollégiumban lévő eszközzel szeretnél kommunikálni? Nem tudhatjuk a világ minden hálózati kártyájának fizikai címét. Konkrétabban csak azokét tudhatjuk, akik egy alhálózatban, broadcast domain-ben vannak velünk.
A következő felmerülő kérdés, hogy hogyan juthatunk messzebb, ki a hálózatunkból? Szükségünk van egy olyan címre, amivel alhálózatunkon kívülre is címezhetünk. Ez a cím az IP cím (vagy logikai cím, Internet Protocol).

Az IP cím teszi lehetővé, hogy bárkit és bármit elérjünk interneten keresztül, ugyanis tudatosan tervezve kapod, ellentétben a MAC címmel, amit beégettek az eszközbe. Egy IP cím összesen 32 bites, 4 darab 8 bites, ponttal elválasztott decimális szám, például:

152.66.169.42

A saját IP címünket Linuxon az ip address, Windowson az ipconfig /all parancsokkal nézhetjük meg.

Hálózatszámítás

A legkisebb létező IP cím a 0.0.0.0 (binárisan „csupa nulla”), a legnagyobb a 255.255.255.255 (binárisan „csupa egy”). Ezeket a címeket viszont nem osztjuk felhasználóknak, külön feladataik vannak. Jópár olyan IP cím (és címtartomány) létezik, amelyek bizonyos célokra vannak lefoglalva. Ezekről egy kicsit később még szó lesz.
Ahhoz, hogy megértsük, hogyan működik az IP-általi címzés, muszáj egy kicsit a felépítését boncolgatni.

Az IP címek nem csak eszközöket, de alhálózatokat is azonosítanak. Az alhálózaton belüli IP cím első X darab bitje a hálózati cím, a maradék pedig tetszőleges, az alhálózaton belül egyedi. Na de hogyan értsük ezt az „X darab bitet”, és hogyan is jelöl ez ki alhálózatot?

Minden IP címhez jár egy úgynevezett hálózati maszk (netmask). A hálózati maszk segítségével jelöljük ki az „első X bitet”. Nézzünk egy tetszőleges IP címet, mondjuk a 192.168.0.1-et. Ez binárisan felírva: 11000000.10101000.00000000.00000001

Ha erre a címre alkalmazunk egy hálózati maszkot, az azt jelenti, hogy bitenként „kimaszkoljuk” az alhálózat címét az IP címből. Ennek az a módja, hogy a (szintén binárisan felírt) maszkunkat AND-eljük az IP címünkkel. Egy maszk így néz(het) ki:

11111111.11111111.11111111.00000000 (decimálisan 255.255.255.0)
11000000.10101000.00000000.00000001 (ez a fent már említett IP cím)
11000000.10101000.00000000.00000000 ez pedig az eredmény ha elvégezzük az AND-et.

Tehát az alhálózat címe: 192.168.0.0

De mi határozza meg a maszk méretét, és mégis mi értelme ennek?

Az alhálózati cím méretét az alhálózatban elhelyezett eszközök száma határozza meg. Ha belegondolunk, minél több bit van fixen az alhálózat címének szentelve, annál kevesebb bit marad a cím egyedi részének, tehát annál kevesebb egyedi címet tudunk kiosztani. A példánkban az első 24 bit az alhálózat címzését szolgálja, tehát már csak 8 bit maradt, amit szét tudunk osztani a kapcsolódó eszközök közt. Ez 254 darab különböző IP címet jelent, hiszen 1 byteon (vagyis 8 darab biten) 2⁸ = 256 darab különböző szám írható le. (Annak az elveszett 2 címnek oka van, a legeslegelső kiosztható címet maga a hálózat kapja, a legeslegutoló pedig egy IP-beli broadcast cím).

Az első 24 bit. Így jelezzük gyakorlatban az IP címekhez tartozó alhálózati maszkot. Konkrétabban, egy IP cím korrekt megadása az alhálózat megadásával történik, így: 192.168.0.1/24. Tehát ez azt jelenti, hogy az IP cím első 24 bitje fix, az alhálózatot azonosítja, az utolsó 8 bit pedig szabadon felhasználható.

Tehát akkor mit jelent?

Ha csatlakozunk egy 192.168.0.0/24 hálózati maszkkal rendelkező alhálózatba, akkor kaphatunk 192.168.0.5, 192.168.0.85, de akár 192.168.0.222-es IP címet is, az utolsó byte akármilyen szám lehet 1 és 254 közt. Nem kaphatunk viszont 192.168.8.85-öset, hiszen az első 24 bit fix, azt nem változtathatjuk.

A félreértések elkerülés végett, a legeslegelső kiadható IP cím (ebben az esetben a 192.168.0.0) mindig az alhálózatot azonosítja, ezt nem osztjuk eszköznek. A hálózati maszkot jelző /24-es számot nem csak az alhálózatot azonosító IP cím mögé írjuk oda, de az ebből a tartományból kiosztott IP címek mögé is.

Ennek az egésznek a hálózat tervezésénél van értelme, hiszen minél kisebb egy alhálózat, annál kevesebb IP címre van szüksége, és nem pocsékolunk el rá feleslegesen többet, így is kevés van. Gondoljunk csak arra, hogy IP címből 2³², azaz körülbelül 4 milliárd különböző, kiosztható létezhet, emberből a Földön pedig (2020-as adat szerint) 7.753 milliárd van. Ha mindenkinek csak egyetlenegy eszköze is lenne az interneten, már akkor is régen kifutottunk a címekből.

Publikus és Privát IP címtartományok

De hogyan jut mégis elég IP cím mindenre úgy, hogy nem jut saját IP cím mindenkinek?

A helyzet az, hogy ellentétben a MAC-címekkel, IP címek kiosztása nem véletlenszerű, hanem a hálózat struktúrájának megfelelően vannak kiosztva. És nem is tartoznak az eszközhöz örökké, hálózatonként, de sokszor hálózatba kapcsolódásonként cserélődnek. Egy eszköznek csak akkor van IP címe, ha csatlakozik egy hálózathoz.

Ez nem azt jelenti, hogy ne lehetne a világon egyedi IP címünk. Ezt hívjuk publikus IP címnek. Aki a koliban lakik, kap is kettőt.

Ígértem, hogy még lesz szó a lefoglalt címekről. Mostmár, hogy ismerjük az alhálózati maszk fogalmát, beszélhetünk címtartományokról.

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ímeknek 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 ö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.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.

A default gateway nem a mi számítógépünk saját címe, hanem a legközelebbi olyan eszköz (tipikusan router) IP címe, ami tudja a mi, IP címmel ellátott csomagjainkat továbbítani más hálóztok felé. A számítógépünk a default gateway-nek címzi azokat a csomagokat, amelyeket ki szeretne juttatni a saját hálózatából.

Ez már egy bonyolultabb hálózat, több alhálózattal, ahol IP cím alapján címzünk.

Tehát ha felkeressük a google.com-ot, az eszközünk „valami varázslat” folytán megtudja a keresett oldal IP címét, és neki címzi az üzenetet. Ennek segítségével talál el az üzenet a megfelelő hálózatba. Mivel az eszközünknek fogalma sincs merre van ez a hálózat, a default gateway MAC-címére küldi. Később világosabb lesz, ígérem. És a “valami varázslat” is kézzel foghatóbbá válik majd.

Portok és szolgáltatások

De ezek előtt még át kell beszélni valamit, ami elsőre úgy tűnhet, nem ide tartozik, de mégis.

A számítógépünkön rengeteg olyan szolgáltatás, folyamat fut, amely hálózaton keresztül kommunikál. A Google-nek is több szolgáltatása van (például a HTTP, HTTPS). Honnan tudják a folyamatok, hogy melyik üzenet szól nekik, és melyik nem?

Erre valók a portok. A portok „sima” decimális számok, minden szolgáltatásnak van egy, vagy több sajátja. Különböző közismert szolgáltatásokat közismert portokon lehet elérni. Biztosan mindannyian találkoztunk már a HTTP-vel, ami a 80-as porton érhető el. Ennek a biztonságos változata a HTTPS a 443-as porton figyel. SSH sem ismeretlen, ő a 22-es porton ül (de ha mégis ismeretlenek ezek a dolgok ne aggódj, a későbbiekben lesz még szó róluk). Egy tetszőleges folyamat tetszőleges, „magas portot” (néhány nagyságrenddel nagyobb számot) kap.

Tehát, számítógépünk különböző folyamatokhoz különböző portokat társít, innen tudja, melyik hálózatról érkező üzenet melyik folyamatának jött.

Ha egy weboldalt szeretnénk megnézni, az előbbi „ha felkeressük a google.com-ot, az eszközünk „valami varázslat” folytán megtudja a keresett oldal IP címét, és neki címzi az üzenetet. Ennek segítségével talál el az üzenet a megfelelő hálózatba. Mivel az eszközünknek fogalma sincs merre van ez a hálózat, a default gateway MAC-címére küldi.” Kijelentésünket kiegészíthetjük azzal, hogy „és a 80-as porton keresi”.

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 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 modellt!! Úgy, hogy nem is beszéltünk róla.

OSI Modell

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, 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éteggel 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.
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 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 (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. A tipikus layer2-es hálózati eszköz a switch, ami nem néz bele az IP címekbe, csakis fizikai, azaz MAC-címek alapján küldi tovább a keretet. A tipikus layer3-as hálózati eszköz a router, ami az alhálózat „kilépési pontja”(default gateway), és IP címek szerint továbbítja az üzeneteket megfelelő irányba.

Jobb esetben senki nem nézi az üzenet nem rá tartozó rétegeit.

ARP

Egymás megismerése egy nagyon fontos lépés az életünkben. Erre jól bevált módszereink vannak. Főleg a MAC címek világában. Az ARP (Address Resolution Protocol) egy olyan “2.5-ik rétegbeli” protokoll, aminek segítségével megtudhatjuk a velünk egy alhálózatban levő eszközök MAC címét úgy, hogy csak az IP címük van a tulajdonunkban . Tehát, az ARP IP címhez MAC-címet rendel. Az ARP segítségével megszerzett MAC-címeket a gépünk egy táblázatban tárolja, ezt ARP-táblának (másnéven ARP-cache-nek) hívjuk. Az eszközünk ezt a táblát használja arra, hogy cél-MAC-címmel címezze az elküldendő keretet. Ha nem talál számára megfelelőt, ARP kérést intéz.
Azért mondjuk 2.5-nek, mert kapcsolatot teremt a Layer2-es (MAC) és Layer3-as (IP) címek közt.

Felsőbb rétegek

Igaz, hogy azt mondtam, nem beszélünk a felsőbb rétegbeli dolgokról, de a gyakorlat miatt mégis meg kell említeni néhány szolgáltatást, protokollt.

HTTP(S)

Amivel egy átlagos felhasználó is találkozik, az a HTTP(S) (Hypertext Transfer Protocol), weboldalakkal(például HTML dokumentummal) szolgálja ki a felhasználót. Az „S” a biztonság ebben.

Webszerver

A webszerver fogalma szintén elengedhetetlen a gyakorlathoz. A webszerver nem meglepő módon webes tartalmat szolgál ki (http, https). Rákeresünk az almafa.hu-ra, és megjelenik a weboldala. Az almafa.hu mögött ül egy szerver, aki állandóan arra figyel, ki kéri el tőle a tartalmat. A port amin figyel, általában a 80-as számú. Ha a gépünk DNS segítségével feloldja az almafa.hu IP címét, és kérést intéz annak 80-as portára, megkapja a weboldalt.

DHCP

Amivel egy átlagos felhasználó szintén találkozik, csak nem tud róla, az a DHCP (Dynamic Host Configuration Protocol).

Ez a protokoll felelős azért, hogy a DHCP szerver osszon IP címet minden, hálózatba kapcsolódott eszköznek. A folyamat (üzenetváltások sorozata), ahogyan címet kap tőle, a DORA.

Azért feloldanám a betűket.

D: Discover – a gép küldd egy broadcast üzenetet (tehát mindenkinek, aki egy alhálózaton van vele), hogy valaki adjon neki IP címet
O: Offer – jobb esetben a DHCP szerver ezt meghallgatja, és küldd neki egyet
R: Request – a gép elfogadja, és kéri a szervertől a továbbiakat
A: acknowledge – a szerver elküldd minden információt, és elfogadja, hogy a szóban forgó IP cím már a gépünkké.

„Netes” Parancsok

Nekünk is vannak eszközeink arra, hogy mélyebben belemenjünk ebbe saját rendszerünkön.

Legfontosabb „netes” parancsok:

• Linuxon ip a / ip l , windowson ipconfig /all a MAC és IP címeink kiderítéséhez
• ping [ip cím vagy domain név]: Layer3-as kapcsolat tesztelésére szolgál.
• traceroute [ip cím vagy domain név]: végigköveti a csomag útját, kiírja, milyen hálózati eszközökön ment keresztül az üzenetünk.
• dhclient [interface]: a beírt interfésznek kér a DHCP szervertől egy IP címet
• nslookup [ip cím vagy domain név]: DNS kérés indít, IP címet lefordítja domain névre, domain nevet lefordítja IP címre
• tcpdump (vagy wireshark): mindkét program a számítógépünkről kimenő, vagy arra érkező üzenetek elkapására szolgál. A tcpdump-al ellentétben a Wireshark-nak van grafikus felülete, látványosan ki lehet bontani benne rétegenként az üzeneteket.
• ip route: megmutatja az eszköz routing tábláját
• arp: megmutatja az eszköz arp tábláját
• curl [ip cím vagy domain név]: lekéri az ip címhez tartozó webes tartalmat
• netstat -tupln: (tcp udp process listener no-resolve) ez minden amit tudi kell

SSH

És még egy utolsó dolog, mi az az SSH?

Az SSH (Secure shell) titkosított távoli asztali kapcsolat. Ha egy gépen van SSH szerver, arra jó eséllyel lehet SSH-zni. Ez a szerver alapértelmezetten a 22-es porton hallgatja, ki kíván kapcsolatot létesíteni(ezt a portot általában nagyobbra állítjuk a saját eszközeinken, hogy illetékteleneknek ne legyen olyan könnyű megtalálni). SSH-zni az ssh felhasznalo@domain -el lehet, a felhasználót le lehet hagyni, a domain nevet lehet írni IP cím formájában.

~ Írta: László Dorottya (Dodó)