![Installer Docker og lær grundlæggende containermanipulation i CentOS og RHEL 8/7](/f/0407657c495c9b63bb3edc8de7a9172a.png?width=100&height=100)
Når systemer støder på problemer, som de nogle gange vil, skal du kende din vej uden om problemet og gendanne dem tilbage til en normal og fungerende tilstand. I dette afsnit fokuserer vi på grundlæggende netværksfejlfindingsevner, som enhver Linux -systemadministrator bør have.
I de fleste tilfælde er der en stor kløft mellem netværksadministratorer og sysadmins. Sysadmins, der mangler netværkssynlighed, vil normalt bebrejde netværksadministratorer for afbrydelser og nedetid, mens netværksadministratorer ikke vil have tilstrækkelig serverviden, vil ofte vende skylden for sysadmins for fejl i slutpunktet. Skyldspillet hjælper dog ikke med at løse problemer, og i et arbejdsmiljø kan dette modvirke relationer mellem kolleger.
Som en sysadmin hjælper en grundlæggende forståelse af fejlfinding af netværk med at løse problemer hurtigere og hjælper med at fremme et sammenhængende arbejdsmiljø. Det er af denne grund, at vi har sammensat dette afsnit for at fremhæve nogle af de
grundlæggende tip til fejlfinding af netværk det vil være praktisk, når der diagnosticeres netværksrelaterede problemer.I vores tidligere emne i LFCA -serien, vi kiggede på TCP/IP konceptuel model der viser overførsel af data i en computer og de protokoller, der findes i hvert lag.
En anden lige så vigtig konceptuel model er OSI model (Åben systemforbindelse) model. Det er en 7 -lags TCP/IP -ramme, der nedbryder et netværkssystem, og computing fungerer som hvert lag.
I OSI model, er disse funktioner segmenteret i følgende lag fra bunden. Fysisk lag, datalinklag, netværkslag, transportlag, sessionslag. Præsentationslag og endelig applikationslag øverst.
Det er umuligt at tale om netværksfejlfinding uden at henvise til OSI -modellen. Af denne grund vil vi lede dig gennem hvert lag og finde ud af de forskellige netværksprotokoller, der bruges, og hvordan du fejlfinder fejl forbundet med hvert lag.
Dette er sandsynligvis et af de mest oversete lag, men alligevel er det et af de mest essentielle lag, der kræves for enhver kommunikation. Det fysiske lag omfatter de fysiske pc -netværkskomponenter på en pc såsom netværkskort, Ethernet -kabler, optiske fibre osv. De fleste problemer begynder her og skyldes for det meste:
I dette lag er de spørgsmål, der kommer til at tænke på:
For at kontrollere status for dine netværksgrænseflader skal du køre ip kommando:
$ ip link show.
Fra output ovenfor har vi 2 grænseflader. Den første grænseflade - se
- er loopback -adressen og bruges normalt ikke. Den aktive netværksgrænseflade, der giver forbindelse til netværket og internettet, er enp0s3
grænseflade. Vi kan se på output, at tilstanden af grænsefladen er OP.
Hvis en netværksgrænseflade er nede, vil du se angiv NED produktion.
Hvis det er tilfældet, kan du bringe grænsefladen op ved hjælp af kommandoen:
$ sudo ip link sat enp0s3 op.
Alternativt kan du køre ifconfig kommando vist nedenfor.
$ sudo ifconfig enp0s3 op. $ ip link show.
Bare for at bekræfte, at din pc har valgt en IP -adresse fra routeren eller DHCP -serveren, skal du køre ifconfig kommando.
$ ifconfig.
Det IPv4 adresse er præfikseret af inet -parameteren som vist. For eksempel er IP -adressen for dette system 192.168.2.104 med et subnet eller netmaske af 255.255.255.0.
$ ifconfig.
Alternativt kan du køre IP-adresse kommando som følger for at kontrollere dit systems IP -adresse.
$ ip -adresse.
For at kontrollere IP -adressen til standardgatewayen skal du køre kommandoen:
$ ip rute | grep standard.
IP -adressen på standardgatewayen, som i de fleste tilfælde er DHCP -serveren eller routeren, er angivet som vist nedenfor. I et IP -netværk skal du være i stand til at pinge standardgatewayen.
For at kontrollere de DNS -servere, du bruger, skal du køre følgende kommando på systemd -systemer.
$ systemd-løse --status.
En bedre måde at kontrollere de anvendte DNS -servere er at køre nmcli kommando vist
$ (nmcli dev liste || nmcli dev show) 2>/dev/null | grep DNS.
Som du har observeret, sker der en ganske stor del af netværksfejlfinding her.
I det væsentlige bestemmer datalinklaget laget dataformatet på netværket. Det er her kommunikationen af datarammer mellem værter finder sted. Den dominerende protokol i dette lag er ARP ( Adresseløsningsprotokol).
ARP er ansvarlig for at opdage linklagsadresser og udfører kortlægning af IPv4-adresser på lag 3 til MAC-adresser. Normalt, når en vært kontakter standardgatewayen, er det sandsynligt, at den allerede har værtens IP, men ikke MAC -adresserne.
Det ARP protokol bygger bro mellem lag 3 og lag 2 ved at oversætte 32-bit IPv4-adresserne på lag 3 til 48-bit MAC-adresser på lag 2 og omvendt.
Når en pc slutter sig til et LAN -netværk, vil routeren ( standard gateway ) tildeler den en IP -adresse til identifikation. Når en anden vært sender en datapakke bestemt til pc'en til standardgatewayen, anmoder routeren ARP at se efter den MAC -adresse, der følger med IP -adressen.
Hvert system har sit eget ARP bord. For at kontrollere din ARP -tabel skal du køre kommandoen:
$ ip nabo show.
Som du kan bemærke, er routerens MAC -adresse udfyldt. Hvis der er et løsningsproblem, returnerer kommandoen ingen output.
Dette er det lag, du udelukkende arbejder med IPv4 adresser, der kender systemadministratorer. Det giver flere protokoller som f.eks ICMP og ARP som vi har dækket og andre som f.eks HVIL I FRED (Routing Information Protocol).
Nogle af de almindelige problemer omfatter fejlkonfiguration af enheder eller problemer med netværksenheder såsom routere og switches. Et godt sted at starte fejlfinding er at kontrollere, om dit system har valgt en IP -adresse som følger:
$ ifconfig.
Du kan også bruge ping -kommando for at kontrollere internetforbindelsen ved at sende en ICMP ekkopakke til Googles DNS. Det -c
flag angiver antallet af pakker, der sendes.
$ ping 8.8.8.8 -c 4.
Outputtet viser et positivt svar fra Googles DNS uden tab af pakker. Hvis du har en intermitterende forbindelse, kan du kontrollere, hvilket punkt pakkerne tabes ved hjælp af traceroute kommando som følger.
$ traceroute google.com.
Stjernerne angiver det punkt, hvor pakker tabes eller tabes.
Det nslookup kommando forespørger DNS om at få den IP -adresse, der er knyttet til et domæne eller et værtsnavn. Dette kaldes Forward DNS -opslag.
For eksempel.
$ nslookup google.com.
Kommandoen afslører de IP -adresser, der er knyttet til google.com -domænet.
Server: 127.0.0.53. Adresse: 127.0.0.53#53 Ikke-autoritativt svar: Navn: google.com. Adresse: 142.250.192.14. Navn: google.com. Adresse: 2404: 6800: 4009: 828:: 200e.
Det dig kommando er endnu en kommando, der bruges til forespørgsel på DNS -servere, der er forbundet med et domænenavn. For eksempel kan du søge efter DNS -navneservere:
$ dig google.com.
Transportlaget håndterer datatransmission vha TCP og UDP protokoller. Bare for at opsummere, TCP er en forbindelsesorienteret protokol, mens UDP er forbindelsesfri. Kørende applikationslytning på sockets, der består af porte og IP -adresser.
Almindelige problemer, der kan opstå, herunder blokerede TCP -porte, som kan kræves af applikationer. Hvis du har en webserver, og du vil kontrollere dens kørende tilstand, skal du bruge netstat eller ss kommando for at kontrollere, om webtjenesten lytter til port 80
$ sudo netstat -pnltu | grep 80. ELLER. $ ss -pnltu | grep 80.
Nogle gange kan en port være i brug af en kørende service i systemet. Hvis du vil have en anden tjeneste til at bruge den port, kan du blive tvunget til at konfigurere den til at bruge en anden port.
Hvis du stadig har problemer, skal du kontrollere firewallen og kontrollere, om den port, du er interesseret i, er blokeret.
Det meste af fejlfinding sker på tværs af disse 4 lag. Der foretages meget lidt fejlfinding i session-, præsentations- og applikationslagene. Dette er fordi de spiller en mindre aktiv rolle i funktionen af et netværk. Lad os dog hurtigt få et overblik over, hvad der sker i disse lag.
Sessionlaget åbner kommunikationskanaler kaldet sessioner og sikrer, at de forbliver åbne under dataoverførsel. Det lukker også derefter, når kommunikationen er afsluttet.
Også kendt som syntakslaget syntetiserer præsentationslaget data, der skal bruges af applikationslaget. Det beskriver, hvordan enheder skal kryptere, kode og komprimere data med det formål at sikre, at de bliver godt modtaget i den anden ende.
Endelig har vi applikationslaget, der er tættest på slutbrugerne og giver dem mulighed for at interagere med applikationssoftwaren. Applikationslaget er rigt på protokoller som HTTP, HTTPS, POP3, IMAP, DNS, RDP, SSH, SNMP og NTP for at nævne nogle få.
Ved fejlfinding af et Linux -system anbefales den lagdelte tilgang ved hjælp af OSI -modellen stærkt, startende fra det nederste lag. Dette giver dig indsigt i, hvad der går galt, og hjælper dig med at indsnævre problemet.