heinäkuu 2, 2020
Articles
Ei kommentteja

Mistä syistä puutteellinen ARP näkyy?

Kuten tässä viestissä mainittiin:

Syy epätäydellisen ARP: n havaitsemiseksi on se, että ”tälle osoitteelle lähetettiin ARP-pyyntö, mutta kyseistä osoitetta käyttävä isäntä ei ole käynnissä lähiverkossa, joten vastausta ei ole”

Jos monikerroksinen kytkin lähettää ARP-pyynnön palvelimelle eikä saa vastausta, ARP merkitään keskeneräiseksi kytkimen ARP-taulukossa.

Mutta mitä jos palvelin lähettää ARP-pyynnön vaihda, mutta et saa vastausta? Näkyykö palvelin ARP-taulukossa epätäydellistä ARP: tä ja kytkimessä ei näy merkintää?

Oletetaan, että yllä oleva on oikein, voimmeko sanoa, että jos näet keskeneräisen ARP-merkinnän paikallisessa laitteessa, ongelma on laitteen kanssa liitännän (tai kaapeloinnin) toisessa päässä? Vai onko joitain poikkeuksia?

Kommentit

  • Kuten @RonTrunk huomauttaa, kytkin on läpinäkyvä kerroksen 2 laite, joka ei tunne tai välitä noin kerroksen 3 (IP) osoituksesta, joten se ’ ei käytä ARP: tä tai vastaa siihen. Kytkintä voidaan hallita, joten kytkimen hallinta on kuin verkon isäntä, ja sillä on kerroksen 3 käyttöliittymä, joka käyttää ARP: tä ja reagoi siihen, mutta sillä ei ole mitään tekemistä kytkentätoiminnon kanssa, joka ei vieläkään tiedä mitään noin kerros 3. Älä sekoita ’ sekoittamaan kerroksen 3 laitteiden ARP: tä kytkinten MAC-osoitetaulukkoon. Monet ihmiset hämmentävät heitä.
  • Toimiiko kytkin L3-yhdyskäytävänä vai vain L2-kytkimenä?
  • @cpt_fink, kyllä ” switch ” Tarkoitin monikerroksista kytkintä (L3-yhdyskäytävä)

vastaus

Layer-3-kytkimessä kytkimen layer-3-moduuli on reititin, ja se toimii aivan kuten reititin, joka toimii kuten mikä tahansa muu ARP-isäntä. Kerros-3-kytkin on edelleen ensisijaisesti kerros-2-kytkin, ja kerros-2-kytkin toimii edelleen aivan kuten kerros-2-kytkin. Kerros-3-kytkimen kerroksen 3 ja kerroksen 2 osat ovat todella erillisiä. Taso 3 -rajapinnat (sekä virtuaalirajapinnat että kaikki fyysiset rajapinnat, jotka on määritetty kerrokseksi 3 rajapinnoiksi) käyttävät ARP-taulukkoa, mutta kerros 2 -rajapinnat käyttävät MAC-osoitetaulukkoa.

Kun isäntä, sisältäen reitittimen tai reititysmoduulin kerroksen 3 kytkimessä, lähettää ARP-pyynnön eikä saa vastausta, se merkitsee ARP-taulukon merkinnän incomplete.

Mutta entä jos palvelin lähettää ARP-pyynnön kytkimelle, mutta ei saa vastausta? Näkyykö palvelin ARP-taulukossa epätäydellistä ARP: tä, eikä kytkin näytä mitään merkintää?

Tämä riippuu. Jos isäntä lähettää ARP-pyynnön toiselle isännälle, myös reitittimelle, mutta se ei ole vielä saanut vastausta, isännän ARP-taulukon merkinnässä merkitään reitittimen IPv4-osoitteelle incomplete.

Mitä reitittimen ARP-taulukossa on, riippuu siitä, saiko reititin ARP-pyynnön vai onko reitittimessä jo ARP-taulukon merkintä isännälle.

  • Reitittimellä, jolla on nykyinen ARP-taulukon merkintä isännälle, on sama merkintä, kunnes reititin puhdistaa sen aikakatkaisun vuoksi. Aikakatkaisua ei vaadita RFC: llä, mutta RFC: llä on osio, joka käsittelee mahdollisuutta käyttää aikakatkaisua ARP-taulukkomerkintöihin, ja useimmat isännät tekevät tämän:

    Pöydän ikääntyminen ja / tai aikakatkaisut saattavat olla toivottavia. Näiden toteutus on tämän protokollan ulkopuolella.

  • Jos reititin ei koskaan saanut ARP-pyyntöä eikä sillä ollut merkintää isäntä, reitittimen ARP-taulukossa ei ole merkintää.
  • Jos reititin sai ARP-pyynnön isännältä, mutta vastaus isännälle katosi, reitittimellä on täydellinen ARP taulukon merkintä isännälle.

Jotta ymmärtäisit ARP: n toiminnan, sinun tulee lukea RFC 826, An Ethernet Address Resolution Protocol – tai – Verkkoprotokollan osoitteiden muuntaminen 48 bittiseksi Ethernet-osoitteeksi lähetystä varten Ethernet-laitteella . Muista, että ARP toimii IPv4: llä, mutta ei IPv6: lla, jolla on ND (Neighbor Discovery) ARP: n sijaan.

Answer

Onnistunut ARP-tarkkuus vaaditaan, jotta kaksi IPv4-solmua voi kommunikoida yhteisellä layer-2-segmentillä (yleensä Ethernet).

Puutteellisilla ARP-pyynnöillä on kaksi perustavaa syytä.

  1. ARP-pyyntöön ei ole vastattu. Joko kohdesolmu ei ole saanut ARP-pyyntöä tai sen vastausta ei ole vastaanotettu. Kohdesolmu voi olla alhaalla.

  2. Lähdesolmun verkkomaskia ei ole määritetty oikein.Lähdesolmu ottaa huomioon kaikki kohteet omassa aliverkossaan paikallisessa tai on-linkissä: se odottaa pystyvänsä puhumaan heidän kanssaan suoraan Ethernet-liitännänsä kautta ilman yhdyskäytäväreitittimen apua.

    Kun esim. aliverkon 192.168.0.0/24 solmu on määritetty väärin 192.168.0.10/16 : lla, ja se pitää kohdetta kuten 192.168.16.1 paikallisena. Se ei yritä käyttää yhdyskäytävää, mutta yrittää suoraa ARP: tä, joka pysyy epätäydellisenä.

Onko lähde vai kohde / seuraava hyppysolmu reititin, monikerroksinen kytkin tai loppusolmulla ei ole väliä.

Vastaus

Kytkimen ARP-taulukkoa käyttää vain kytkimen hallintaliitäntä IP-liikenteelle itse kytkimen tuottama.

Muuten kytkimet tarkastelevat vain tason 2 tietoja. He eivät ymmärrä ARP: tä.

Kommentit

  • kyllä, tarkoitin monikerroksista kytkintä

Vastaa

Toinen mahdollinen syy – virheelliset dhcpcd-asetukset

Lisän tämän vastauksen, vaikka se ei (todennäköisesti) liity suoraan yllä olevaan kysymykseen, mutta sillä on merkitystä joissakin tapauksissa

Jos järjestelmän staattiset ip / dhcp-asetukset ovat virheelliset, tämä voi näkyä epäsuorana sivuvaikutuksena.

Minun tapauksessani minulla oli Linux-kone, johon muutin sijainteja ja muutin verkkoasetuksia ngs for.

Unohdin päivittää ne tiedostoon /etc/dhcpcd.conf, kun siirsin koneen takaisin.

Tämä on minun dhcpcd.conf 

interface eth0 static ip_address=192.168.1.8/24 static routers=192.168.1.254 #static routers=192.168.1.1 static domain_name_servers=127.0.0.1

Kun se oli ” rikki ”, kommentoin riviä static routers=192.168.1.254, ja alla olevaa riviä #static routers=192.168.1.1 ei kommentoitu.

Tämän vuoksi arp näytti virheellisen merkinnän (” epätäydellinen ”) osoite 192.168.1.1.

Vaikka muutin tätä järjestelmää vasta viikko sitten, sitten muutama päivä sitten, minulla ei ollut aavistustakaan, mikä vikaa sen kanssa. Sikäli kuin voisin kertoa, voisin liittää sen paikalliseen verkkooni, ssh siihen hyvin, eikä ip addr -palvelussa ilmennyt ongelmia. traceroute ei myöskään näyttänyt mitään hyödyllistä tietoa, se vain ehdotti, että kaikki kyselyt menisivät yhden hypyn kautta ” koneen isäntään ”. Ilmeisesti sillä ei ollut mitään järkeä ja se oli väärin, mutta se ei antanut minulle mitään viitteitä siitä, mistä kysymys oli – se tarkoitti, että kaikki kyselyt oli ratkaistu sama kone. Tämä kone tekee muuten DNS: n.

Ei liity suoraan OP-kysymykseen, mutta voi olla erittäin hyödyllinen muille, joilla on tämä ongelma tulevaisuudessa, ja tämä on ainoa tapa, jonka olet tähän mennessä löytänyt diagnosoi se, koska mikään muu ei vaikuta olevan väärin!

Vain joitain huomautuksia siitä, miten diagnosoin tämän

  • Kun käytät tätä konetta DNS-palvelimena muille koneen verkko, nämä koneet eivät pystyneet ratkaisemaan ulkoisia DNS-pyyntöjä
  • Voisin siirtyä DNS-palvelimeen (mikä odotetaan, koska sen IP on asetettu staattiseksi, ja kytkin / reititin odottaa myös näkevänsä koneen tämän kanssa staattinen IP kytketty paikalliseen ethernet-verkkoon kytkimen kautta).
  • Ensimmäinen asia, joka ilmoitti ongelmasta, oli sudo apt update. (Koska tämä on DNS-palvelin, sillä ei ole graafista käyttöliittymää, ja siksi vaikka jonkin selaimen kaltainen käyttö olisi osoittanut tämän ongelman paljon aikaisemmin tai verkon työpöydän lokeron kuvakkeesta, siinä ei ole mitään näistä asioista.)
  • ping 8.8.8.8 epäonnistui myös, mutta ssh ja paikallisten koneiden pingointi olivat kunnossa
  • Tarkistin div> kaikki näissä direissä olevat tiedostot olivat kuitenkin tyhjiä / asetettu oletusarvoihin, koska DNS-ohjelmisto hallitsee näitä.
  • DNS-ohjelmistossa ei ollut virheitä / varoituksia, kun muodostettiin yhteys DNS-palvelimeen toimitetun verkkoliitännän kautta / li>
  • Aloin tarkistaa asioita, kuten ip addr (ei ongelmia) ja arp. Sanoin jo traceroute ei ilmoittanut ongelman mahdollisuutta, mutta osoitti jotain outoa meneillään.
  • Syiden etsiminen syistä, miksi arp voi olla puutteellinen merkintä, ohjasi minua oikealla linjalla
  • Löysin tämän kysymyksen ( https://serverfault.com/questions/765380/when-do-stale-arp-entries-become-failed-when-never-used ) ja aloin tutkia arp-merkintöjen poistamista
  • Poistan merkinnän arp -d 192.168.1.1
  • Se kuitenkin palasi jatkuvasti
  • Yritin muodostaa yhteyden paikallisen verkkoni 192.168.1.1 -palveluun toisesta kone, mutta en ollut yllättynyt, etten voinut tehdä tätä tai pingata sitä, koska verkossani ei ole koneita tällä osoitteella.
  • Yleensä tämä osoite olisi yhdyskäytäväsi / Internet-palveluntarjoajasi osoite kotisovellukset
  • Tämä muistutti minua siitä, että olin asettanut verkkosovittimen toiseen sijaintiin osoitteeseen 192.168.1.1 ja että tähän osoitteeseen liitetty tietokone käytettiin reitittimenä verkkojen yhdistämiseen 192.168.0.X ja 192.168.1.X
  • Alkuperäinen sijainti on verkossa 192.168.1.X, muutin sijaintini 192.168.0.X
  • Koska suurin osa 192.168.1.X/24 verkot käyttävät oletusyhdyskäytävänä 192.168.1.1, koska IP-osoite ei herättänyt aluksi epäilyksiä eikä se näyttänyt olevan ” outo ” jostain syystä
  • Vaihdoin kuitenkin oletusyhdyskäytävän kohdassa dhcpcd.conf kuten yllä on kuvattu ja ongelma on ratkaistu
  • Oppitunti, kun luot outoa tietokoneiden välistä verkkoa väliaikaisesti sivuston ulkopuolelle, anna reitittimen sovittimelle / NIC: lle outo staattinen IP, kuten 192.168.1.50 – mikä saattaa auttaa muistuttamaan itseään tai osoittamaan jotain tavallisesta poikkeavaa, asetetaan asetustiedostoon jonnekin

kommentit

  • Valitettavasti isäntä / palvelin-kokoonpanot ovat tässä aiheen ulkopuolella, mutta ne voidaan hoitaa bussien palvelinvirheillä verkkoon.

Vastaa

Sähköpostiosoitettasi ei julkaista. Pakolliset kentät on merkitty *