LFCA: lugege põhivõrgu tõrkeotsingu näpunäiteid - 12. osa


Kui süsteemid puutuvad kokku probleemidega, nagu nad mõnikord juhtuvad, peate teadma probleemi lahendamise viisi ja taastama need normaalsesse ja toimivasse olekusse. Selles jaotises keskendume võrgu tõrkeotsingu põhioskustele, mis peaksid olema kõigil Linuxi süsteemiadministraatoritel.

Põhiline arusaam võrgu tõrkeotsingust

Enamasti on võrguadministraatorite ja sysadminide vahel suur vahe. Sysadminid, kellel pole võrgu nähtavust, süüdistavad tavaliselt võrguadministraatoreid katkestustes ja seisakutes, samas kui võrguadministraatorid ei suuda serveri teadmisi ebapiisavalt süüdistada sysadmini lõppseisundiseadme rikke korral. Süüdimäng ei aita siiski probleeme lahendada ja töökeskkonnas võib see kolleegidevahelisi suhteid vastandada.

Süsadministraatorina aitab võrgu tõrkeotsingu põhimõtteline mõistmine probleemid kiiremini lahendada ja aitab luua ühtlast töökeskkonda. Sel põhjusel oleme selle jaotise kokku pannud, et tuua välja mõned peamised võrgu tõrkeotsingu näpunäited, mis on võrguga seotud probleemide diagnoosimisel kasulikud.

Meie eelmises TCP/IP kontseptuaalse mudeli teemas, mis näitab andmete edastamist arvutis ja igas kihis leiduvaid protokolle.

Teine sama oluline kontseptuaalne mudel on OSI-mudeli (Open Systems Interconnection) mudel. See on 7-kihiline TCP/IP-raamistik, mis lagundab võrgusüsteemi ja arvutusfunktsioonid nagu iga kiht.

OSI-mudelis on need funktsioonid jaotatud altpoolt järgmistesse kihtidesse. Füüsiline kiht, andmesidekiht, võrgukiht, transpordikiht, seansikiht. Esitluskiht ja lõpuks rakenduskiht kõige ülaosas.

Võrgu tõrkeotsingust on võimatu rääkida ilma OSI mudelile viitamata. Sel põhjusel juhatame teid läbi iga kihi ja selgitame välja erinevad kasutatavad võrguprotokollid ning iga kihiga seotud vigade tõrkeotsingu.

See on ilmselt üks tähelepanuta jäetud kihte, kuid see on üks kõige olulisemaid kihte, mis on vajalikud igasuguse suhtluse toimumiseks. Füüsiline kiht hõlmab arvuti füüsilisi arvutivõrgu komponente, nagu võrgukaardid, Etherneti kaablid, optilised kiud jne. Enamik probleeme algab siin ja on enamasti põhjustatud järgmistest:

  • Ühendamata võrgu-/Ethernet-kaabel
  • Kahjustatud võrgu-/Ethernet-kaabel
  • Puuduv või kahjustatud võrgukaart

Selles kihis tulevad meelde järgmised küsimused:

  • "Kas võrgukaabel on ühendatud?"
  • "Kas füüsiline võrguühendus on üleval?"
  • "Kas teil on IP-aadress?"
  • "Kas saate pingida vaikelüüsi IP-d?"
  • "Kas saate DNS-serveri pingida?"

Võrguliideste oleku kontrollimiseks käivitage käsk ip:

$ ip link show

Ülaltoodud väljundist on meil 2 liidest. Esimene liides - lo - on tagasisideaadress ja seda tavaliselt ei kasutata. Aktiivne võrguliides, mis tagab ühenduse võrgu ja Internetiga, on liides enp0s3 . Väljundist näeme, et liidese olek on ÜLES.

Kui võrguliides on maas, näete olekut ALLA.

Sel juhul saate liidese üles tuua käsuga:

$ sudo ip link set enp0s3 up

Teise võimalusena võite käivitada allpool näidatud käsu ifconfig.

$ sudo ifconfig enp0s3 up
$ ip link show

Lihtsalt veendumaks, et teie arvuti on ruuterilt või DHCP-serverilt valinud IP-aadressi, käivitage käsk ifconfig.

$ ifconfig

IPv4-aadressi eesliide on parameeter inet, nagu näidatud. Näiteks on selle süsteemi IP-aadress 192.168.2.104, alamvõrgu või võrgumaskiga 255.255.255.0.

$ ifconfig

Teise võimalusena võite oma süsteemi IP-aadressi kontrollimiseks käivitada käsu ip address järgmiselt.

$ ip address

Vaikelüüsi IP-aadressi kontrollimiseks käivitage käsk:

$ ip route | grep default

Vaikelüüsi IP-aadress, mis enamasti on DHCP-server või ruuter, on näidatud allpool näidatud viisil. IP-võrgus peaksite saama vaikelüüsi pingida.

Kasutatavate DNS-serverite kontrollimiseks käivitage järgmine käsk systemd süsteemides.

$ systemd-resolve --status

Parem viis kasutatavate DNS-serverite kontrollimiseks on kuvatud käsu nmcli käivitamine

$ ( nmcli dev list || nmcli dev show ) 2>/dev/null | grep DNS

Nagu olete täheldanud, juhtub siin üsna suur osa võrgu tõrkeotsingutest.

Sisuliselt määrab andmesidekiht võrgus andmevormingu. Siin toimub andmeraamide suhtlus hostide vahel. Selles kihis on domineeriv protokoll ARP (Address Resolution Protocol).

ARP vastutab linkikihi aadresside avastamise eest ja teostab 3. kihi IPv4-aadresside kaardistamise MAC-aadressidega. Tavaliselt, kui hosti võtab ühendust vaikelüüsiga, on tõenäoline, et tal on juba hosti IP, kuid mitte MAC-aadresse.

ARP-protokoll sillutab lõhe 3 ja kihi 2 vahel, teisendades 32-bitised IPv4-aadressid kihil 3 kuni 48-bitised MAC-aadressid kihil 2 ja vastupidi.

Kui arvuti ühineb LAN-võrguga, määrab ruuter (vaikelüüs) identifitseerimiseks talle IP-aadressi. Kui teine host saadab arvutisse määratud andmepaketi vaikelüüsile, palub ruuter ARP-l otsida IP-aadressiga kaasas olevat MAC-aadressi.

Igal süsteemil on oma ARP-tabel. ARP-tabeli kontrollimiseks käivitage käsk:

$ ip neighbor show

Nagu märkate, on ruuteri MAC-aadress asustatud. Lahendusprobleemi ilmnemisel ei tagasta käsk väljundit.

See on kiht, millega töötate eranditult süsteemiadministraatoritele tuttavate IPv4-aadressidega. See pakub mitmeid protokolle nagu ICMP ja ARP, mida oleme käsitlenud, ja teisi, näiteks RIP (Routing Information Protocol).

Mõned levinumad probleemid hõlmavad seadme valesti seadistamist või võrguseadmete, näiteks ruuterite ja lülitite, probleeme. Hea koht tõrkeotsingu alustamiseks on kontrollida, kas teie süsteem on valinud IP-aadressi järgmiselt:

$ ifconfig

Samuti saate Interneti-ühenduse kontrollimiseks kasutada käsku ping, saates ICMP-i kajapaketi Google'i DNS-ile. Lipp -c tähistab saadetavate pakettide arvu.

$ ping 8.8.8.8 -c 4

Väljund näitab Google'i DNS-i positiivset vastust pakettide kadumisega. Kui teil on katkendlik ühendus, saate käsu traceroute abil kontrollida, millises punktis paketid visatakse.

$ traceroute google.com

Tärnid tähistavad pakettide viskamise või kadumise punkti.

Nslookup käsk pärsib DNS-ilt domeeni või hosti nimega seotud IP-aadressi saamiseks. Seda nimetatakse DNS-i otsimiseks.

Näiteks.

$ nslookup google.com

Käsk näitab domeeniga google.com seotud IP-aadresse.

Server:		127.0.0.53
Address:	127.0.0.53#53

Non-authoritative answer:
Name:	google.com
Address: 142.250.192.14
Name:	google.com
Address: 2404:6800:4009:828::200e

Dig on veel üks käsk, mida kasutatakse domeeninimega seotud DNS-serverite päringuteks. Näiteks käimasolevate DNS-nimeserverite pärimiseks:

$ dig google.com

Transpordikiht tegeleb andmete edastamisega TCP ja UDP protokollide abil. Lihtsalt kokkuvõtteks võib öelda, et TCP on ühendusele suunatud protokoll, samas kui UDP on ühenduseta. Rakenduse käitamine kuulab pistikupesasid, mis koosnevad portidest ja IP-aadressidest.

Esineda võivad levinumad probleemid, sealhulgas blokeeritud TCP-pordid, mida rakendused võivad vajada. Kui teil on veebiserver ja soovite selle töötavat olekut kontrollida, kasutage käsku ss, et kontrollida, kas veebiteenus kuulab porti 80

$ sudo netstat -pnltu | grep 80
OR
$ ss -pnltu | grep 80

Mõnikord võib porti kasutada süsteemi töötav teenus. Kui soovite, et mõni teine teenus kasutaks seda pordi, võite olla sunnitud selle konfigureerima teise pordi kasutamiseks.

Kui teil on endiselt probleeme, kontrollige tulemüüri ja kontrollige, kas teid huvitav port on blokeeritud.

Enamik tõrkeotsingutest toimub nendes neljas kihis. Seansi, esitluse ja rakenduse kihtides tehakse väga vähe tõrkeotsinguid. Seda seetõttu, et neil on võrgu toimimisel vähem aktiivne roll. Omame siiski kiiresti ülevaate, mis nendes kihtides toimub.

Sessioonikiht avab seanssideks nimetatud suhtluskanalid ja tagab, et need jäävad andmeedastuse ajal avatuks. See sulgub ka siis, kui side on lõpetatud.

Tuntud ka kui süntaksikiht, sünteesib esitluskiht andmeid, mida rakendusekiht kasutab. Selles täpsustatakse, kuidas seadmed peaksid andmeid krüpteerima, kodeerima ja tihendama, et tagada nende hea vastuvõtmine teises otsas.

Lõpuks on meil rakendusekiht, mis on lõppkasutajatele kõige lähemal ja võimaldab neil rakendustarkvaraga suhelda. Rakenduskiht sisaldab rikkalikult protokolle nagu HTTP, HTTPS, POP3, IMAP, DNS, RDP, SSH, SNMP ja NTP.

Linuxi süsteemi tõrkeotsingul on kihiline lähenemine OSI-mudeli abil väga soovitatav, alustades alumisest kihist. See annab teile ülevaate valesti toimuvast ja aitab teil probleemini kitsendada.