LFCA: Lær grunnleggende nettverksfeilsøkingstips – del 12
Når systemer støter på problemer, som de noen ganger vil, må du kjenne deg rundt problemet og gjenopprette dem tilbake til en normal og fungerende tilstand. I denne delen fokuserer vi på grunnleggende nettverksfeilsøkingsferdigheter som enhver Linux-systemadministrator bør ha.
Grunnleggende forståelse av nettverksfeilsøking
I de fleste tilfeller er det et stort gap mellom nettverksadministratorer og systemadministratorer. Sysadmins som mangler nettverkssynlighet vil vanligvis klandre nettverksadministratorer for avbrudd og nedetider, mens nettverksadministratorer vil utilstrekkelig serverkunnskap ofte gi systemadministratorer skylden for feil på endepunktenheter. Men skyldspillet hjelper ikke med å løse problemer, og i et arbeidsmiljø kan dette motvirke relasjoner mellom kolleger.
Som systemadministrator vil det å ha en grunnleggende forståelse av nettverksfeilsøking bidra til å løse problemer raskere og bidra til å fremme et sammenhengende arbeidsmiljø. Det er av denne grunn at vi har satt sammen denne delen for å fremheve noen av de grunnleggende nettverksfeilsøkingstipsene som vil være nyttige når du diagnostiserer nettverksrelaterte problemer.
En oppsummering av TCP/IP-modellen
I vårt forrige emne av LFCA-serien så vi på den konseptuelle modellen TCP/IP som viser overføring av data i en datamaskin og protokollene som finnes i hvert lag.
En annen like viktig konseptuell modell er OSI-modellen (Open Systems Interconnection)-modellen. Det er et 7-lags TCP/IP-rammeverk som bryter ned et nettverkssystem, og databehandling fungerer som hvert lag.
I OSI-modellen er disse funksjonene segmentert i følgende lag fra bunnen. Fysisk lag, datakoblingslag, nettverkslag, transportlag, øktlag. Presentasjonslag, og til slutt Application Layer helt øverst.
Det er umulig å snakke om nettverksfeilsøking uten å referere til OSI-modellen. Av denne grunn vil vi lede deg gjennom hvert lag og finne ut de ulike nettverksprotokollene som brukes og hvordan du feilsøker feil knyttet til hvert lag.
Lag 1: Fysisk lag
Dette er sannsynligvis et av de mest oversett lagene, men det er et av de mest essensielle lagene som kreves for at enhver kommunikasjon skal finne sted. Det fysiske laget omfatter de fysiske PC-nettverkskomponentene til en PC som nettverkskort, Ethernet-kabler, optiske fibre osv. De fleste problemene begynner her og er hovedsakelig forårsaket av:
- Frakoblet nettverks-/ethernetkabel
- Skadet nettverk/ethernet-kabel
- Manglende eller skadet nettverkskort
I dette laget er spørsmålene som dukker opp:
For å sjekke statusen til nettverksgrensesnittene dine, kjør ip-kommandoen:
ip link show
Fra utgangen ovenfor har vi 2 grensesnitt. Det første grensesnittet – lo – er loopback-adressen og brukes vanligvis ikke. Det aktive nettverksgrensesnittet som gir tilkobling til nettverket og internett er enp0s3-grensesnittet. Vi kan se fra utdataene at tilstanden til grensesnittet er OPP.
Hvis et nettverksgrensesnitt er nede, vil du se tilstand NED-utgangen.
Hvis det er tilfelle, kan du få opp grensesnittet ved å bruke kommandoen:
sudo ip link set enp0s3 up
Alternativt kan du kjøre ifconfig-kommandoen vist nedenfor.
sudo ifconfig enp0s3 up
ip link show
Bare for å bekrefte at PC-en din har valgt en IP-adresse fra ruteren eller DHCP-serveren, kjør ifconfig-kommandoen.
ifconfig
IPv4-adressen er prefikset av inet-parameteren som vist. For eksempel er IP-adressen for dette systemet 192.168.2.104 med et undernett eller nettmaske på 255.255.255.0.
ifconfig
Alternativt kan du kjøre kommandoen ip-adresse som følger for å sjekke systemets IP-adresse.
ip address
For å sjekke IP-adressen til standard gateway, kjør kommandoen:
ip route | grep default
IP-adressen til standard gateway, som i de fleste tilfeller er DHCP-serveren eller ruteren, er angitt som vist nedenfor. I et IP-nettverk bør du kunne pinge standard gateway.
For å sjekke DNS-serverne du bruker, kjør følgende kommando på systemd-systemer.
systemd-resolve --status
En bedre måte å sjekke DNS-serverne som er i bruk, er å kjøre nmcli-kommandoen vist
( nmcli dev list || nmcli dev show ) 2>/dev/null | grep DNS
Som du har observert, skjer en ganske stor del av nettverksfeilsøking her.
Layer 2: Data Link Layer
I hovedsak bestemmer datalinklaget dataformatet på nettverket. Det er her kommunikasjonen av datarammer mellom verter foregår. Den dominerende protokollen i dette laget er ARP (Address Resolution Protocol).
ARP er ansvarlig for å oppdage lenkelagsadresser og utfører kartlegging av IPv4-adresser på lag 3 til MAC-adresser. Vanligvis, når en vert kontakter standard gateway, er sjansen stor for at den allerede har vertens IP, men ikke MAC-adressene.
ARP-protokollen bygger bro mellom lag 3 og lag 2 ved å oversette 32-biters IPv4-adresser på lag 3 til 48-biters MAC-adresser på lag 2 og omvendt.
Når en PC kobles til et LAN-nettverk, tildeler ruteren (standard gateway) den en IP-adresse for identifikasjon. Når en annen vert sender en datapakke destinert til PC-en til standardgatewayen, ber ruteren ARP om å se etter MAC-adressen som følger med IP-adressen.
Hvert system har sin egen ARP-tabell. For å sjekke ARP-tabellen din, kjør kommandoen:
ip neighbor show
Som du kan legge merke til, er ruterens MAC-adresse fylt ut. Hvis det er et løsningsproblem, returnerer kommandoen ingen utdata.
Lag 3: Nettverk/Internett-lag
Dette er laget du utelukkende arbeider med IPv4-adresser som er kjent med systemadministratorer. Den gir flere protokoller som ICMP og ARP som vi har dekket og andre som RIP (Routing Information Protocol ).
Noen av de vanlige problemene inkluderer feilkonfigurering av enheten eller problemer med nettverksenheter som rutere og svitsjer. Et godt sted å starte feilsøking er å sjekke om systemet ditt har valgt en IP-adresse som følger:
ifconfig
Du kan også bruke ping-kommandoen til å sjekke internettforbindelsen ved å sende en ICMP-ekkopakke til Googles DNS. -c-flagget angir antall pakker som sendes.
ping 8.8.8.8 -c 4
Utdataene viser et positivt svar fra Googles DNS med null pakketap. Hvis du har en intermitterende tilkobling, kan du sjekke hvilket punkt pakkene blir droppet ved å bruke traceroute-kommandoen som følger.
traceroute google.com
Stjernene indikerer punktet der pakker blir droppet eller tapt.
Kommandoen nslookup spør DNS for å få IP-adressen knyttet til et domene eller vertsnavn. Dette omtales som Forward DNS-oppslag.
For eksempel.
nslookup google.com
Kommandoen avslører IP-adressene knyttet til google.com-domenet.
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-kommandoen er enda en kommando som brukes for å spørre etter DNS-servere knyttet til et domenenavn. For eksempel, for å spørre DNS-navneserverne kjøres:
dig google.com
Lag 4: Transportlag
Transportlaget håndterer dataoverføring ved hjelp av TCP- og UDP-protokoller. Bare for å oppsummere, TCP er en tilkoblingsorientert protokoll mens UDP er tilkoblingsløs. Kjørende applikasjon lytte på sockets som består av porter og IP-adresser.
Vanlige problemer som kan oppstå, inkludert blokkerte TCP-porter som kan kreves av applikasjoner. Hvis du har en webserver og du vil verifisere dens kjørestatus, bruk netstat- eller ss-kommandoen for å sjekke om webtjenesten lytter til port 80
sudo netstat -pnltu | grep 80
OR
ss -pnltu | grep 80
Noen ganger kan en port være i bruk av en kjørende tjeneste i systemet. Hvis du vil at en annen tjeneste skal bruke den porten, kan du bli tvunget til å konfigurere den til å bruke en annen port.
Hvis du fortsatt har problemer, sjekk brannmuren og kontroller om porten du er interessert i er blokkert.
Det meste av feilsøkingen vil skje på tvers av disse 4 lagene. Svært lite feilsøking gjøres i økten, presentasjonen og applikasjonslagene. Dette er fordi de spiller en mindre aktiv rolle i funksjonen til et nettverk. La oss imidlertid raskt få en oversikt over hva som skjer i disse lagene.
Lag 5: Sesjonslag
Sesjonslaget åpner kommunikasjonskanaler referert til som sesjoner og sikrer at de forblir åpne under dataoverføring. Den lukkes også når kommunikasjonen er avsluttet.
Lag 6: Presentasjonslag
Også kjent som syntakslaget, syntetiserer presentasjonslaget data som skal brukes av applikasjonslaget. Den forklarer hvordan enheter skal kryptere, kode og komprimere data med det formål å sikre at de blir godt mottatt i den andre enden.
Lag 7: Applikasjonslag
Til slutt har vi applikasjonslaget som er nærmest sluttbrukerne og lar dem samhandle med applikasjonsprogramvaren. Applikasjonslaget er rikt med protokoller som HTTP, HTTPS, POP3, IMAP, DNS, RDP, SSH, SNMP og NTP for å nevne noen.
Konklusjon
Når du feilsøker et Linux-system, anbefales den lagdelte tilnærmingen ved å bruke OSI-modellen på det sterkeste, fra det nederste laget. Dette gir deg innsikt i hva som går galt og hjelper deg med å begrense problemet.