Amikor a rendszerek problémákkal szembesülnek, ahogy néha előfordulnak, ismernie kell a problémát, és vissza kell állítania azokat normál és működő állapotba. Ebben a részben az alapvető hálózati hibaelhárítási készségekkel foglalkozunk, amelyekkel minden Linux rendszergazda rendelkezhet.
A legtöbb esetben nagy a különbség a rendszergazdák és a rendszergazdák között. A rendszer láthatóságának hiánya miatt a rendszergazdák általában hibásak hálózati rendszergazdák a kimaradásokért és az állásidők, miközben a hálózati rendszergazdák nem rendelkeznek elegendő szerverismerettel, gyakran a rendszergazdák hibáztatják a végpont -eszköz meghibásodását. A hibáztató játék azonban nem segít a problémák megoldásában, és munkakörnyezetben ez ellentétes lehet a kollégák közötti kapcsolatokkal.
Rendszergazdaként a hálózati hibaelhárítás alapvető ismerete segít a problémák gyorsabb megoldásában és az összetartó munkakörnyezet kialakításában. Ezért állítottuk össze ezt a részt, hogy kiemeljünk néhányat
alapvető hálózati hibaelhárítási tippek ami hasznos lesz a hálózattal kapcsolatos problémák diagnosztizálásakor.Korábbi témánkban a LFCA sorozat, megnéztük a TCP/IP fogalmi modell amely az adatok számítógépen történő továbbítását és az egyes rétegekben található protokollokat mutatja.
Egy másik ugyanolyan fontos fogalmi modell a OSI modell (Nyílt rendszerek összekapcsolása) modell. Ez egy 7 rétegű TCP/IP keretrendszer, amely lebontja a hálózati rendszert, és a számítás minden rétegben működik.
Ban,-ben OSI modellben ezeket a funkciókat alulról kezdve a következő rétegekre tagolják. Fizikai réteg, adatkapcsolati réteg, hálózati réteg, szállítási réteg, munkamenetréteg. Bemutató réteg, és végül az alkalmazásréteg a tetején.
Lehetetlen beszélni a hálózati hibaelhárításról az OSI modellre való hivatkozás nélkül. Ezért végigjárjuk az egyes rétegeket, és megtudjuk a különböző hálózati protokollokat, valamint az egyes rétegekkel kapcsolatos hibák elhárítását.
Ez valószínűleg az egyik leginkább figyelmen kívül hagyott réteg, mégis az egyik legfontosabb réteg, amely szükséges a kommunikációhoz. A fizikai réteg magában foglalja a számítógép fizikai számítógépes hálózati összetevőit, például hálózati kártyákat, Ethernet -kábeleket, optikai szálakat stb. A legtöbb probléma itt kezdődik, és főként a következők okozzák:
Ebben a rétegben a következő kérdések merülnek fel:
A hálózati interfészek állapotának ellenőrzéséhez futtassa a ip parancs:
$ ip link show.
A fenti kimenetből 2 interfészünk van. Az első felület - lo
- a loopback cím, és általában nem használják. Az aktív hálózati interfész, amely kapcsolatot biztosít a hálózattal és az internettel enp0s3
felület. A kimeneten láthatjuk, hogy az interfész állapota FEL.
Ha a hálózati interfész nem működik, megjelenik a állapota LE Kimenet.
Ebben az esetben a kezelőfelületet a következő paranccsal hozhatja létre:
$ sudo ip link beállítása enp0s3.
Alternatív megoldásként futtathatja a ifconfig parancs lásd lent.
$ sudo ifconfig enp0s3 fel. $ ip link show.
Csak annak megerősítéséhez, hogy számítógépe kiválasztott egy IP -címet az útválasztóról vagy a DHCP -kiszolgálóról, futtassa a ifconfig parancs.
$ ifconfig.
Az IPv4 a címet az inet paraméter előtagja adja meg, az ábrán látható módon. Például ennek a rendszernek az IP -címe 192.168.2.104 alhálózatával vagy netmaszkjával 255.255.255.0.
$ ifconfig.
Alternatív megoldásként futtathatja a IP-cím parancsot a rendszer IP -címének ellenőrzéséhez.
$ ip cím.
Az alapértelmezett átjáró IP -címének ellenőrzéséhez futtassa a következő parancsot:
$ ip útvonal | grep alapértelmezett.
Az alapértelmezett átjáró IP -címe, amely a legtöbb esetben a DHCP -kiszolgáló vagy útválasztó, az alább látható módon jelenik meg. IP -hálózat esetén képesnek kell lennie az alapértelmezett átjáró pingelésére.
A használt DNS -kiszolgálók ellenőrzéséhez futtassa a következő parancsot rendszerezett rendszereken.
$ systemd-resolution-állapot.
A használatban lévő DNS -kiszolgálók ellenőrzésének jobb módja a nmcli parancs Látható
$ (nmcli dev lista || nmcli dev show) 2>/dev/null | grep DNS.
Amint megfigyelted, a hálózati hibaelhárítás hatalmas tömege történik itt.
Lényegében az adatkapcsolati réteg határozza meg a hálózat adatformátumát. Itt zajlik az adatkeretek kommunikációja a gazdagépek között. Ebben a rétegben az uralkodó protokoll a ARP ( Címfeloldási protokoll).
ARP felelős a linkréteg-címek felfedezéséért, és elvégzi a 3. réteg IPv4-címeinek MAC-címekre való leképezését. Általában, amikor a gazdagép kapcsolatba lép az alapértelmezett átjáróval, nagy valószínűséggel már rendelkezik a gazdagép IP -címével, de nem a MAC -címekkel.
Az ARP protokoll áthidalja a 3. és 2. réteg közötti szakadékot a 3. réteg 32 bites IPv4-címeinek 48-bites MAC-címre történő lefordításával a 2. rétegen és fordítva.
Amikor a számítógép csatlakozik a LAN hálózathoz, az útválasztó ( alapértelmezett átjáró ) IP -címet rendel hozzá az azonosításhoz. Amikor egy másik gazdagép a számítógéphez rendelt adatcsomagot küld az alapértelmezett átjáróhoz, az útválasztó kéri ARP keresse meg az IP -címhez tartozó MAC -címet.
Minden rendszer saját ARP asztal. Az ARP tábla ellenőrzéséhez futtassa a következő parancsot:
$ ip szomszédshow.
Amint észreveheti, az útválasztó MAC -címe ki van töltve. Ha feloldási probléma merül fel, a parancs nem ad vissza kimenetet.
Ez az a réteg, amellyel kizárólag dolgozik IPv4 a rendszergazdák által jól ismert címek. Több protokollt biztosít, mint pl ICMP és ARP amelyekre kiterjedtünk és mások, mint pl NYUGODJ BÉKÉBEN (Routing Information Protocol).
A leggyakoribb problémák közé tartozik az eszköz hibás konfigurálása vagy a hálózati eszközök, például útválasztók és kapcsolók problémái. Egy jó hely a hibaelhárítás megkezdéséhez az, hogy ellenőrizze, hogy a rendszer az alábbiak szerint választotta -e ki az IP -címet:
$ ifconfig.
Ezenkívül használhatja a ping parancs az internetkapcsolat ellenőrzéséhez küldjön egy ICMP visszhangcsomagot a Google DNS -hez. Az -c
zászló jelzi a küldött csomagok számát.
$ ping 8.8.8.8 -c 4.
A kimenet pozitív választ mutat a Google DNS -től, nulla csomagvesztéssel. Ha szakaszos kapcsolattal rendelkezik, a gombbal ellenőrizheti, hogy a csomagok melyik ponton kerülnek leadásra traceroute parancs alábbiak szerint.
$ traceroute google.com.
A csillagok azt a pontot jelzik, ahol a csomagok elvesznek vagy elvesznek.
Az nslookup parancs lekérdezi a DNS -t, hogy megkapja a tartományhoz vagy a gazdagépnévhez társított IP -címet. Ezt továbbító DNS -keresésnek nevezik.
Például.
$ nslookup google.com.
A parancs feltárja a google.com domainhez tartozó IP -címeket.
Szerver: 127.0.0.53. Cím: 127.0.0.53#53 Nem hiteles válasz: Név: google.com. Cím: 142.250.192.14. Név: google.com. Cím: 2404: 6800: 4009: 828:: 200e.
Az dig parancs egy másik parancs, amelyet a tartománynévhez tartozó DNS -kiszolgálók lekérdezésére használnak. Például a futtatott DNS -névszerverek lekérdezéséhez:
$ dig google.com.
A szállítási réteg az adatátvitelt használja TCP és UDP protokollokat. Csak összefoglalva, TCP egy kapcsolat-orientált protokoll, míg az UDP kapcsolat nélküli. A futó alkalmazás figyelése aljzatokon, amelyek portokat és IP -címeket tartalmaznak.
Gyakori problémák, amelyek előfordulhatnak, beleértve a blokkolt TCP -portokat, amelyeket az alkalmazások igényelhetnek. Ha rendelkezik webszerverrel, és szeretné ellenőrizni annak futási állapotát, használja a netstat vagy ss parancs hogy ellenőrizze, hogy a webszolgáltatás hallgatja -e a 80 -as portot
$ sudo netstat -pnltu | grep 80. VAGY. $ ss -pnltu | grep 80.
Előfordulhat, hogy egy portot a rendszer futó szolgáltatása használ. Ha azt szeretné, hogy egy másik szolgáltatás használja ezt a portot, akkor lehet, hogy kénytelenek lesznek beállítani egy másik port használatára.
Ha továbbra is problémái vannak, ellenőrizze a tűzfalat, és ellenőrizze, hogy az Önt érdeklő port le van -e tiltva.
A hibaelhárítás nagy része ezen a 4 rétegen történik. Nagyon kevés hibaelhárítás történik a munkamenet, a prezentáció és az alkalmazás rétegeiben. Ennek oka, hogy kevésbé aktív szerepet játszanak a hálózat működésében. Azonban gyorsan áttekintjük, mi történik ezekben a rétegekben.
A munkamenetréteg megnyitja a munkamenetnek nevezett kommunikációs csatornákat, és biztosítja, hogy azok nyitva maradjanak az adatátvitel során. A kapcsolat akkor is bezárul, ha a kommunikáció megszakad.
A szintaktikai rétegként is ismert prezentációs réteg szintetizálja az alkalmazásréteg által használt adatokat. Kifejezi, hogy az eszközöknek hogyan kell titkosítaniuk, kódolniuk és tömöríteniük az adatokat, annak érdekében, hogy a másik oldalon is jól fogadják azokat.
Végül az alkalmazásréteg áll a legközelebb a végfelhasználókhoz, és lehetővé teszi számukra az alkalmazásszoftverrel való interakciót. Az alkalmazásréteg olyan protokollokban gazdag, mint a HTTP, HTTPS, POP3, IMAP, DNS, RDP, SSH, SNMP és NTP, hogy csak néhányat említsünk.
A Linux rendszer hibaelhárításakor nagyon ajánlott az OSI modellt használó réteges megközelítés, kezdve az alsó rétegtől. Ez betekintést nyújt a hibákba, és segít a probléma szűkítésében.