NetWorker is afhankelijk van de naamresolutie. Als de naamresolutie niet correct en volledig consistent is, kunnen zich problemen voordoen in veel van de bewerkingen van NetWorker. Aangezien NetWorker potentieel gevoelige data beheert, moet het de identiteiten van de hosts met wie het communiceert op verschillende manieren garanderen.
Elk aantal symptomen in NetWorker kan het gevolg zijn van naamresolutie in NetWorker:
- Foutmeldingen die problemen met het opzoeken van forward- of reverse-namen aangeven.
- Het is niet mogelijk om clients te onderzoeken tijdens een back-up.
- Clients kunnen niet handmatig opslaan op de server of herstellen.
- Problemen met het klonen of openen van Storage Node-apparaten.
- Browse- of mediadatabaserecordproblemen.
- Server- of storageknooppunt reageert niet meer bij het opstarten of tijdens normale werking.
- Onjuiste of geneste indexmappen.
- Verkeerd geconfigureerde clientfouten.
Naamresolutie vindt plaats door verschillende mechanismen en op verschillende niveaus:
- NetWorker-naamcache
- Cache voor lokale host-resolver
- Bestandsvermeldingen voor lokale hosts
- DNS-server lookups
Naamresolutiemethodiek
1. NetWorker Caching: NetWorker onderhoudt een interne naamcache en geeft soms geen omgevingswijzigingen weer die zijn aangebracht om problemen met naamomzetting te corrigeren zonder services opnieuw op te starten. NetWorker heeft ook een configureerbaar veld dat globaal is voor alle clientinstanties met de naam 'aliassen', die alle namen moeten weergeven die voor die client-instantie kunnen worden opgelost om problemen van meerdere typen te voorkomen. Als een vereiste naam aanwezig is in de interne cache van NetWorker, wordt deze daar gebruikt en wordt de host Resolver-cache niet geraadpleegd. De NetWorker server daemon (nsrd) kan de opgeloste naamcache dumpen in daemon.raw, de cache leegmaken of namen leegmaken en opnieuw omzetten:
- dbgcommand -n nsrd PrintDnsCache=1 (dump naar daemon.raw)
- dbgcommand -n nsrd FlushDnsCache=1 (flush)
- dbgcommand -n nsrd FlushDnsCache=9 (leegmaken en oplossen)
- Voor de bovenstaande opdrachten kan "-n procesnaam" of "-p PID" worden gebruikt. Als u de PID wilt gebruiken, moet u eerst andere opdrachten uitvoeren om de PID te verkrijgen; bijvoorbeeld "ps -ef | grep nsr" (Linux) of "tasklist | findstr nsr" (windows)
2. Resolver Cache: Alle hosts en besturingssystemen hebben een lokale resolvercache om de resolutie en snelheid van de host te ondersteunen zonder te vertrouwen op hostbestanden of DNS-servers. Deze cache wordt gecontroleerd volgens de normale naamomzettingsregels van het besturingssysteem en als de hostrecord bestaat (zelfs als deze oud of onjuist is), wordt deze gebruikt voordat een query wordt gedaan naar een andere databron. Resolver-cachevermeldingen worden bij de eerste 'geslaagde' oplossingspoging in de cache ingevoerd en blijven gedurende een vooraf bepaalde tijdsduur. Sommige besturingssystemen kunnen de inhoud van de resolver-cache weergeven (Windows-hosts kunnen bijvoorbeeld ipconfig /displaydns uitvoeren) en hebben allemaal een mechanisme om de cache te wissen of leeg te maken:
- Het leegmaken van DNS op Linux kan variëren, afhankelijk van de Linux-distributie en geïnstalleerde pakketten. Raadpleeg de documentatie van de leverancier.
- Windows: ipconfig /flushdns
3. Hostbestanden: Het legacy-mechanisme voor hostresolutie is om het IP-adres expliciet in te voeren, gevolgd door namen die op afzonderlijke regels naar dat adres willen worden omgezet, gescheiden door witte ruimte. Dit wordt standaard gecontroleerd vóór DNS in Windows, in Linux-resolutie kan de bronvolgorde meestal worden geconfigureerd in /etc/nsswitch.conf of /etc/netsvc.conf. Hosts-bestanden worden alleen geparseerd voor de eerste overeenkomende vermelding die wordt opgevraagd, dus elke tweede instantie van een IP-adres of hostnaam, kort of lang, zal nooit worden gevonden bij het oplossen van namen. Elke naam of IP mag slechts worden weergegeven zodra alle namen op dezelfde regel van het bijbehorende IP-adres moeten worden ingevoerd.
- Unix/Linux: /etc/hosts
- Windows: %systemroot%\System32\drivers\etc\hosts
OPMERKING: Hosts-bestanden kunnen beschadigd raken, zoals elk ander bestand. Wijzig bij twijfel de naam van het bestaande hostbestand, maak het nieuwe bestand, wis de resolver-cache en probeer het opnieuw.
4. Oplossing doorsturen: Als u wilt communiceren met een afwijkende host wanneer de naam wordt opgegeven, moet een host het IP-adres van de afwijkende host vinden voor TCP/IP-communicatie om deze te ontvangen; bij het gebruik van DNS moet de query worden uitgevoerd voor die hostnaam in de Forward Lookup-zone om het IP-adres op te halen. Meerdere DNS-hosts kunnen worden geconfigureerd voor gebruik door een client; gebruik ipconfig /all op Windows-systemen om DNS-namen te verkrijgen; op Linux/UNIX-besturingssystemen draagt /etc/resolv.conf doorgaans de dns-servervolgorde. nslookup is de meest gebruikte tool voor het opvragen van DNS en bestaat op alle platforms, maar wordt vaak misbruikt; om een query uit te stellen op de doorstuurzone:
- Voer nslookup uit zonder argumenten om de interactieve prompt in te voeren.
- Voer de naam iteratie in om op te zoeken en druk op Enter om de forward record op te halen van de DNS-server waarmee u hebt verbonden.
- Voer dezelfde naam twee keer meer in om te zien of de naamrecord stil is tussen verschillende hosts of dezelfde data retourneert.
- Herhaal hetzelfde proces voor elke instantie van een naam die door andere hosts kan worden aangeroepen of beschouw zichzelf als voor hetzelfde IP-adres.
- Herhaal hetzelfde proces voor elke andere DNS-server die de host is geconfigureerd voor gebruik door server next_dns_server te openen.
OPMERKING: Alle records die worden geretourneerd, moeten consistent zijn onder elkaar en consistent zijn met wat door de beheerder wordt begrepen om correct te zijn; en alle bekende namen moeten worden verantwoord en gecontroleerd.
5. Omgekeerde resolutie: Als u wilt communiceren met een afwijkende host wanneer het IP-adres wordt opgegeven, moet de host mogelijk de naam van de host vinden; bij het gebruik van DNS wordt de query uitgevoerd in de reverse lookup-zone om de hostnaam van het IP-adres in kwestie te vinden. Nogmaals, dit wordt vaak misbruikt, omdat het invoeren van nslookup IP_Address of zelfs het invoeren van het IP-adres in nslookup geen query geeft op de zone voor reverse lookup:
- Voer nslookup uit zonder argumenten om de interactieve prompt in te voeren.
- Voer set q=ptr in om het querytype te wijzigen in de omgekeerde zone.
- Voer het IP-adres in om het probleem ongedaan te maken en druk op Enter.
- Zorg ervoor dat de naam die wordt geretourneerd in de omgekeerde record overeenkomt met de naam/IP van de forward record.
[root@linux_a~]# nslookup linux_a
Server: 1.2.3.4
Address: 1.2.3.4#53
Name: linux_a.domain.com
Address: 5.6.7.8
[root@linux_a~]# nslookup 5.6.7.8
Server: 1.2.3.4
Address: 1.2.3.4#53
Name: linux_a.domain.com
Address: 5.6.7.8
[root@linux_a~]# nslookup
> set q=ptr
> 5.6.7.8
Server: 1.2.3.4
Address: 1.2.3.4#53
Non-authoritative answer:
8.7.6.5.in-addr.arpa name = linux_a.domain.com.
In het bovenstaande voorbeeld is duidelijk dat het uitvoeren van nslookup niet-interactively nooit query's uitvoert op de zone voor reverse lookup.
OPMERKING: NetWorker is sterk afhankelijk van een perfecte en consistente omgekeerde resolutie en een standaard forward resolution. Dit is onderdeel van het autorisatieproces en is op deze manier opzettelijk ontworpen om IP-spoofing of andere soorten aanvallen te voorkomen die bedoeld zijn om back-updata te stelen.
Resolutie
Alle NetWorker-hosts moeten gegarandeerd een consistente naamomzetting hebben, zowel vooruit als achteruit, voor elke host met wie ze communiceren (wat afhankelijk is van de rol van de datazone). Het is van cruciaal belang voor NetWorker-beheerders om ervoor te zorgen dat eventuele problemen met het oplossen van hostproblemen onmiddellijk en volledig worden opgelost.
Bij het oplossen van problemen met naamresolutie, of om ze uit te sluiten in uw NetWorker Data-zone:
1. Zoek alle hosts die betrokken zijn bij de mislukte bewerking - server, client(s) en mogelijk storageknooppunt(en), enz.
2. Bepaal voor elk van deze IP-adressen de lokaal geconfigureerde IP-adressen en alle verwachte op te lossen namen voor die IP's.
3. Configureer alle hosts om het hostbestand vóór DNS te gebruiken voor hostresolutie.
4. Aan het begin van het hosts-bestand van één host, configureert u één vermelding voor elke IP, met elke naam die overeenkomt met het op dezelfde regel.
5. Kopieer deze regels precies vanaf de eerste host naar de hostbestanden van de andere betrokken hosts.
6. Bewerk de NetWorker-clientobjecten om aliassen correct te hebben die overeenkomen met de gewenste IP's.
7. Sluit NetWorker af op alle betrokken hosts
8. Wis de resolvercache op elke host met behulp van het juiste besturingssysteemmechanisme
9. Start NetWorker opnieuw op en probeer de problematische bewerking opnieuw
om te bewijzen dat de naam door een bepaalde host wordt opgelost:
1. Maak vanaf de eerste NetWorker host (bijvoorbeeld de client) verbinding met de tweede (bijvoorbeeld de server) met behulp van
nsradmin -s remote_host -p nsrexec - laat de sessie open
2. Bepaal op dezelfde host het proces voor nsradmin (bijvoorbeeld Windows,
taaklijst | findstr nsradmin)
3. Voer netstat uit om de socket weer te geven die aan dat proces is gekoppeld (bijvoorbeeld Windows,
netstat -ao | findstr process_id)
4. Bepaal de verbindingssocket van die host (de meest linkse IP:-poortkoppeling in de uitvoer)
5. Voer op de externe host netstat -a uit en findstr/grep voor:calling_port_from_first_host (deze verschijnt nu aan de rechterkant)
6. De hostnaam die aan de linkerkant van de dubbele punt wordt weergegeven, is de naam van de eerste host die de tweede host de binnenkomende verbinding als
7 oplost. Voer opnieuw uit met de -n-switch die is toegevoegd aan de netstat-opdracht om het IP-adres van dezelfde socket te verifiëren, om te controleren of het IP/de route wordt verwacht
8. Dezelfde test omkeren om ervoor te zorgen dat de tweede host de eerste host binnen verwachte parameters oplost
Veel NetWorker-bewerkingen, zoals een savegroup, gebruiken meerdere afzonderlijke TCP-sockets - in het voorbeeld van de savegroup, één voor een controlesessie, één voor data en één voor het bijwerken van de index - als een sessie een inconsistente (technisch correcte) naam gebruikt, kan de bewerking mislukken.
- Round-robining wordt soms opzettelijk gebruikt en geconfigureerd, maar is meestal onverwacht en moet worden vermeden
- netstat -a onthult open/actieve TCP-sockets, die de door het besturingssysteem opgeloste naam van de afwijkende host onthullen. Dit kan worden gebruikt om problemen te identificeren
- Statische routering kan soms nodig zijn wanneer netwerkverkeer een onverwachte/ongewenste adapter gebruikt, wat later kan leiden tot problemen met naamresolutie.
Zie ook:
KB-463606:
Problemen met DNS en naamresolutie oplossen