More

    Az ügyfelek helytelen beállításokat (IP-címeket) kapnak a DHCP-n keresztül

    Mi a teendő az ok kiderítéséhez és a probléma megoldásához 2020. november 11. 5 perc 5550https: //d2xzmw6cctk25h.cloudfront.net/post/2436/og_image/937798a9599f5339e64a422c8c4d2dda.png

    A másokkal való kommunikáció érdekében a hálózat minden eszközének négy alapvető beállítással kell rendelkeznie a hálózati adapteren – IP-cím, maszk, alapértelmezett átjáró és DNS-kiszolgáló címe (bár ez utóbbi valójában nem kötelező). A hálózati beállítások kiosztásának két fő módja van – statikusan (manuálisan) és dinamikusan (automatikusan DHCP-n keresztül egy DHCP-szerverről).

    A második lehetőség gyakran sokkal kényelmesebb, mert a beállításokat nem kell kézzel írni. De bizonyára sokaknak olyan helyzettel kellett megküzdeniük, amikor egy kliens eszköz egy teljesen más IP-címet kapott a helyes beállítások helyett a DHCP-szervertől. És akkor nagyon fontos megérteni, miért történik ez, és hogyan lehet mindent gyorsan kijavítani. A bejegyzésben ezt kitérem.

    Tünetek

    Általában minden az internet meghibásodásával vagy a helyi hálózati erőforrásokhoz való hozzáférés hiányával kapcsolatos panaszokkal kezdődik. Néha elég, ha csak a kliens oldalon végezzük a diagnosztikát, de a szerver felől is szükség lehet teljes diagnosztikára. Kezdjük az első lehetőséggel.

    Ügyféloldali diagnosztika

    A folyamat megértése érdekében az első lépés természetesen annak ellenőrzése, hogy az ügyfél fizikailag csatlakozik-e vezetékes vagy vezeték nélküli hálózathoz. Ha igen, akkor itt az ideje, hogy elkezdje ellenőrizni a kliens eszköz hálózati beállításait az ipconfig / all (a Windows parancssorban), az ifconfig vagy az ip addr (a Linux terminálban) használatával.

    A parancs kimenete megmutatja az aktuális IP-címet és a hálózati adapter egyéb beállításait (vagy az összes adaptert, ha egynél több van). Ugyanakkor, ha a hálózati adapteren nincs helyes IP-cím, akkor a beállításainak kevés lehetősége lehet.

    1. opció. A jelenlegi IP-cím 169.254.X.X

    Valószínűleg a Windows az ügyfélgépre van telepítve. Ez azt jelenti, hogy az ügyfél valóban nem tudta megszerezni a hálózati beállításokat, mert a DHCP-szerver nem válaszolt, és a címet az APIPA (Automatic Private IP Addressing) szolgáltatás generálta a 169.254.0.0 – 169.254.255.255 tartományból. Ha az ügyfél Linux gép, akkor a cím formátuma 0.0.0.0 lehet, vagy egyáltalán hiányozhat.

    Talán a legkézenfekvőbb művelet egy ilyen helyzetben az, ha megpróbálja újra megszerezni az IP-címet a DHCP-kérelem újbóli elküldésével, és egyúttal ellenőrizze, hogy a DHCP-kliens fut-e az eszközön. Ez többféle módon történhet:

    • 10-30 másodpercre csatlakozzon a hálózathoz, és csatlakozzon újra;
    • indítsa újra az eszközt;
    • egymás után hajtsa végre a parancsokat. A Windows parancssorából: ipconfig / release , majd ipconfig / uu . Linux terminálon: dhclient -v -r , majd dhclient vagy dhcpcd -k , majd dhcpcd ().

    A hibák és / vagy figyelmeztetések megjelenítésekor először ki kell küszöbölnie azokat – például ha a DHCP kliens nem fut, akkor először engedélyeznie kell azokat. Ezt követően újra ellenőriznie kell a beállításokat. Ha az eredmény nem változik, ellenőrizze a hálózati illesztőprogram és a TCP / IP protokoll verem működését. Ennek legegyszerűbb módja a ping 127.0.0.1 parancs (az úgynevezett belső visszacsatolási teszt). Ha a parancs végrehajtásának eredményeként válasz érkezik a saját hálózati adapteréről, akkor az ügyféloldali diagnosztikát befejezettnek tekintheti, és folytathatja a DHCP-kiszolgálóoldali diagnosztikával.

    OLVASS TOVÁBB:  Python fejlesztő: mi a teendő, ha megtanultad az alapokat

    2. opció. Az aktuális IP-cím nem a 169.254.0.0 – 169.254.255.255 tartományba esik, de nem tartozik azon címek tartományába sem, amelyeket a DHCP-kiszolgálónak ki kell adnia

    Mint tudják, nem történnek csodák. Ha az ügyfél által kapott beállítások nem a hálózat megbízható DHCP-kiszolgálójától származnak, akkor valaki más terjeszti őket. Aki véletlenül vagy szándékosan a saját konfigurációjával rendelkező DHCP-szervert csatlakoztatott a hálózathoz. Talán ez egy közönséges Wi-Fi útválasztó, amelyhez a kábelt tévesen csatlakoztatták az egyik LAN porton keresztül. Ezután az a feladata, hogy megtaláljon egy nem megbízható DHCP-kiszolgálót, és megakadályozza az ilyen kísérleteket a jövőben.

    OLVASS TOVÁBB:  Python fejlesztő: mi a teendő, ha megtanultad az alapokat

    Itt emlékeznie kell a DHCP protokoll működésére. Az ügyfél sugárzási kérelmet küld (DHCPDISCOVER), amelyet a hálózat összes DHCP-kiszolgálója megkap és visszaküldi IP-ajánlatait (DHCPOFFER). Ebben az esetben az ügyfél elfogadja az első kapott ajánlatot (DHCPOFFER), valószínűleg a legközelebbi DHCP-szervertől, és a többit elutasítja.

    Nyilvánvaló, hogy a megbízható DHCP szerver ajánlata később érkezik, valószínűleg azért, mert távolabb áll az ügyféltől. A további diagnosztika érdekében telepítenie kell egy hálózati forgalomelemzőt ( Wireshark vagy tcpdump ) az ügyfél eszközére, be kell indítania, a forgalmat szűrve a DHCP protokoll típusa vagy a 67–68-as portok szerint, és meg kell keresnünk a DHCP válaszokban az őket küldő DHCP-kiszolgáló IP- és MAC-címét:

    Az ügyfelek helytelen beállításokat (IP-címeket) kapnak a DHCP-n keresztül

    Akkor az ügy kicsi. Először is használhatja a macvendors.com vagy hasonló szolgáltatást, és a MAC-cím alapján meghatározhatja ennek az eszköznek a gyártóját. A Wireshark rendelkezik ilyen funkcióval. Másodszor, ha vannak felügyelt kapcsolók a hálózatban, akkor MAC alapján keresse meg, melyik kapcsoló melyik portjához van csatlakoztatva ez az eszköz. A nem megbízható DHCP-kiszolgáló semlegesítése után az ügyfél valószínűleg meg tudja kapni a megfelelő beállításokat. Az ilyen események jövőbeni megelőzése érdekében ajánlott a DHCP támadás elleni védekezési módszereket a hálózati berendezésen telepíteni.

    3. opció. A jelenlegi IP-cím helyes, de még mindig nincs hozzáférés az internethez és más hálózati erőforrásokhoz

    Ha igen, akkor érdemes visszatérni nemcsak az IP-cím, hanem az összes többi beállítás ellenőrzésére is. Különösen a maszk, az alapértelmezett átjáró cím és a DNS-kiszolgálók címeinek ellenőrzésére, mivel az eszköznek az átjárón keresztül kell kommunikálnia más hálózatokkal, és a DNS-kiszolgálók segítségével a domainneveket IP-címekké alakítja.

    OLVASS TOVÁBB:  A Fullstack JavaScript fejlesztési kar megnyitása

    Emlékeztetni kell arra, hogy a DHCP szerver szelektíven terjesztheti a beállításokat, és maga az ügyfél is szelektíven alkalmazhatja őket. Például csak az IP-címet, a maszkot és az átjárót. Ez inkább kivétel, de ebben az esetben a DNS-címeket kézzel kell regisztrálni. Sokkal rosszabb, ha a DHCP-kiszolgáló DNS-kiszolgáló címének beállításait figyelmen kívül hagyják pusztán azért, mert harmadik féltől származó szoftverek vagy helytelen statikus beállítások felülírják őket. Ez is megtörténik.

    Szerveroldali diagnosztika

    Tehát az ügyféloldali diagnosztika azt mutatta, hogy nem találtak problémát. A DHCP szerver megvalósításától függetlenül mostantól számos feltételezést kell tesztelnie lépésről lépésre, kezdve a legegyszerűbbel és a legkézenfekvőbbel.

    A DHCP szolgáltatásként fut?

    Az operációs rendszertől, a disztribúciótól és a DHCP szerver megvalósításától függően ezt különböző módon lehet ellenőrizni. Ha a szolgáltatás le van állítva, és hibák vannak a konfigurációs fájlokban, akkor nem indul el. Ez az első kiindulópont. Ha a szolgáltatás fut, folytassa a következő lépéssel.

    Az ügyfelek kérései érkeznek a DHCP-kiszolgálóra?

    Ennek megállapításához újra futtatnia kell a Hálózati forgalom elemzőt. Ezúttal a szerveren. A tcpdump, a dhcpdump vagy a Wireshark futtatása után a szerveren egy olyan ügyfélnek, akinek problémái vannak a cím megszerzésével, meg kell próbálnia újra megkeresni a cikk elején leírt bármely módszerrel. Ha a DHCP-kiszolgáló normálisan működik, kéréseknek és válaszoknak kell lenniük. De a dolgok eltérhetnek.

    Nincs kérés vagy válasz?

    Tegyük fel, hogy van legalább egy kliensünk, amely nem tudja megszerezni a beállításokat, és a tőle kapott kérésnek mindenképpen meg kellett volna érkeznie a szerverre. Ha ez nem történik meg, akkor nyilvánvaló, hogy az ügyfél vagy maga nem küldi el a kérést, vagy a kérelem különféle okokból nem jut el a szerverhez. Lehet, hogy blokkolva van a köztes hálózati berendezésen, vagy a DHCP kérések továbbítása a dhcp_relay nem működik megfelelően a hálózaton.
    Ennek ellenőrzéséhez az első esetben visszatérhet az ügyféloldali diagnosztikához és nyomon követheti a hálózati forgalomelemző segítségével, hogy az ügyfél DHCP-kérést küld. A másodikban ellenőrizze a köztes hálózati berendezés beállításait.

    OLVASS TOVÁBB:  A GeekBrains öregdiák projektjei: TravelKeeper szolgáltatás

    Van kérés (ek), nincs válasz (ok)?

    A legegyszerűbb és legkézenfekvőbb ok ebben az esetben az, hogy az ingyenes címek gyűjteménye véget ért. Könnyű ezt ellenőrizni magán a DHCP-kiszolgálón a kiosztott IP-címek (bérbeadások) listája segítségével. Ha valóban ez a helyzet, fontolja meg ezt: ideje lenne növelni a szerveren használható IP-címek készletét. A probléma orvoslásához törölheti az ügyfeleknek bérelt meglévő címek listáját, csökkentheti a bérleti időt és újraindíthatja a DHCP szolgáltatást. De a gyors döntések nem mindig segítenek, és ennek sokkal több oka lehet. Ebben az esetben részletesen meg kell tekintenie a naplókat, valamint a kiszolgáló konfigurációjának utolsó változtatásait.

    Friss cikkek

    A YouTube lehetővé tette a bloggereknek, hogy kiválasszák saját URL-jüket

    De évente legfeljebb háromszor változtathatja meg. A Search Engine Land külföldi kollégái az új lehetőségről beszéltek a YouTube-csatorna beállításaiban. Mostantól a videohoszting felajánlja...

    A Yandex egy új blokkot tesztel a keresési eredmények között

    A Google-on "Az emberek is keresnek" analógia alapján készül. Olvasónk, Vitya Smertny megosztotta a pr-cy csapattal egy megfigyelést a Yandex keresési eredményeinek új...

    Fontos a héten: TOP-20 orosz ajkú YouTube blogger

    A levegőben rendszeres Likeney-emésztés folyik a legfontosabb friss és okos tartalommal. Ebben az epizódban a TOP 20 orosz ajkú YouTube bloggert fogjuk megvitatni a...

    Mítoszok a társult programok bevételeiről

    „Próbáltam linkeket beilleszteni, egy hét alatt több tucat konverziót, egyetlen akciót sem! Inkább a YAN-tól teszek fel hirdetéseket, mint korábban. Legalább lesz pénz. "...

    Mesterkurzus: hatékony reklám elindítása a Yandex Advertising Network-ben (YAN)

    Január 21-én tartották a "Master Class: Hatékony reklám elindítása a Yandex Advertising Network (YAN)" című webináriumot. A webes szemináriumot Nikita Kravchenko, a fizetett...

    Kapcsolódó történetek

    HOZZÁSZÓLOK A CIKKHEZ

    Kérjük, írja be véleményét!
    írja be ide nevét

    Maradjon op - Ge a napi híreket a postaládájában