NetWorker afhænger af navnefortolkningen. Hvis navnefortolkningen ikke er korrekt og helt konsistent, kan der opstå problemer i mange af NetWorker's handlinger. Da NetWorker administrerer potentielt følsomme data, skal det sikre identiteten af værterne, som den interagerer med på forskellige måder.
Et vilkårligt antal symptomer i NetWorker kan skyldes manglende navnefortolkning i NetWorker:
- Fejlmeddelelser, der angiver problemer med frem- eller omvendt navneopslag.
- Manglende evne til at teste klienter under sikkerhedskopiering.
- Manglende evne for klienter til manuelt at gemme på serveren eller gendanne.
- Problemer med kloning eller adgang til Storage Node-enheder.
- Problemer med registrering af browser- eller mediedatabase.
- Server- eller storagenoden holder op med at reagere ved opstart eller under normal drift.
- Indeksbiblioteker med forkert navn eller indlejrede indeks.
- Fejl i konfigureret klient.
Navnefortolkning sker via forskellige mekanismer og på forskellige niveauer:
- NetWorker-navnecache
- Lokal værts resolver cache
- Lokale værter-filposter
- DNS-serversøgninger
Metode til navnefortolkning
1. NetWorker-cachelagring: NetWorker opretholder en intern navnecache og afspejler nogle gange ikke miljømæssige ændringer, der er foretaget for at løse navnefortolkningsproblemer uden genstart af tjenester. NetWorker har også et konfigurerbart felt, som er globalt for alle klientforekomster kaldet "Aliases", som skal afspejle alle navne, der kan løses for den pågældende klientforekomst, for at undgå problemer med flere typer. Hvis et påkrævet navn er til stede i NetWorker's interne cache, bruges det derfra, og værtens Resolver-cache ikke er opbrugt. NetWorker Server Daemon (nsrd) har mulighed for at dumpe sin løste navnecache i daemon.raw, tømme cachen eller rydde og løse navne igen:
- dbgcommand -n nsrd PrintDnsCache=1 (Dump to daemon.raw)
- dbgcommand -n nsrd FlushDnsCache=1 (Flush)
- dbgcommand -n nsrd FlushDnsCache=9 (Tøm og afhjælp)
- For ovenstående kommandoer kan enten "-n process name" eller "-p PID" bruges. For at bruge PID skal du køre andre kommandoer først for at hente PID. f.eks. "ps -ef | grep nsr" (Linux) eller "opgaveliste | findstr nsr" (Windows)
2. Afhjælpning af cachehukommelse: Alle værter og operativsystemer har en lokal afhjælpningscache til at hjælpe med værtsopløsning og -hastighed uden at være afhængige af hverken værtsfiler eller DNS-servere. Denne cache kontrolleres efter normale regler for operativsystemnavn, og hvis værtsposten findes (selvom den er gammel eller forkert), bruges den før forespørgsel om en anden datakilde. Løsningscacheposter indtastes i cachen ved det første "vellykkede" opløsningsforsøg og forbliver i et forudbestemt tidsrum. Nogle operativsystemer kan vise deres Resolver Cache-indhold (f.eks. kan Windows-værter køre ipconfig/displaydns), og alle har en mekanisme til at få ryddet eller ryddet det:
- Rydning af DNS på Linux kan variere afhængigt af Linux-distribution og installerede pakker. Se leverandørdokumentationen.
- Windows: ipconfig/flushdns
3. Værtsfiler: Den nedarvede mekanisme til værtsopløsning er eksplicit at indtaste IP-adressen efterfulgt af eventuelle navne, der ønskes løst til den pågældende adresse, på separate linjer afgrænset af mellemrum. Dette kontrolleres før DNS som standard på Windows, i Linux kan kilderækkefølgen for Linux-opløsning normalt konfigureres i /etc/nsswitch.conf eller /etc/netsvc.conf. Værtsfiler parses kun for den første tilsvarende post, der forespørges - så vil enhver anden forekomst af en IP-adresse eller et værtsnavn, kort eller lang, aldrig blive fundet, når du forsøger at fortolke navne. Hvert navn eller IP bør kun vises én gang, da alle navne skal indtastes på samme linje i den tilsvarende IP-adresse.
- Unix/Linux: /etc/hosts
- Windows: %systemroot%\System32\drivers\etc\hosts
BEMÆRK: Værtsfiler kan blive ødelagte, som enhver anden fil . Hvis du er i tvivl, skal du omdøbe den eksisterende værtsfil, oprette den nye, rydde Resolver Cache og forsøge igen.
4. Videresendelsesløsning: Hvis du vil kommunikere med en fremmed vært, når navnet angives, skal en vært finde ud af, at eksterne værters IP-adresse for TCP/IP-kommunikation kan opstå; Når du bruger DNS, skal forespørgslen udføres for det pågældende værtsnavn i fremsøgezonen for at hente IP-adressen. Flere DNS-værter kan være konfigureret til brug af en klient. på Windows-systemer skal du bruge ipconfig /all til at hente DNS-navne; på Linux/UNIX-operativsystemer /etc/resolv.conf overfører normalt DNS-serverordren. nslookup er det mest almindelige værktøj til at forespørge DNS og findes på alle platforme, men bliver ofte misbrugt; for at forespørge på videresendelseszonen:
- Kør nslookup uden argumenter for at indtaste den interaktive prompt.
- Indtast navnet gentagelse for at søge, og tryk på Enter for at hente videresendelsespost fra den DNS-server, du har oprettet forbindelse til.
- Indtast det samme navn to gange mere for at se, om navneposten round-robining uovervåget mellem forskellige værter eller returnerer de samme data.
- Gentag den samme proces for enhver forekomst af et navn, som værten kan kaldes af andre værter, eller anse sig selv for at være den samme IP-adresse.
- Gentag den samme proces for alle andre DNS-servere, som værten er konfigureret til potentielt at bruge, ved at indtaste next_dns_server.
BEMÆRK: Alle poster, der returneres, skal være konsistente indbyrdes og i overensstemmelse med, hvad der forstås som korrekt af administratoren; og alle kendte navne skal tages i betragtning og kontrolleres.
5. Omvendt opløsning: Hvis du vil kommunikere med en fremmed vært, når IP-adressen angives, skal værten muligvis finde værtens navn. Når du bruger DNS, udføres forespørgslen i zonen Omvendt opslag for at finde værtsnavnet på den pågældende IP-adresse. Dette sker igen ofte forkert, da indtastning af nslookup IP_Address eller indtastning af IP-adressen i nslookup ikke forespørger på den omvendte søgezone:
- Kør nslookup uden argumenter for at indtaste den interaktive prompt.
- Indtast set q=ptr for at ændre forespørgselstypen til den omvendte zone.
- Indtast IP-adressen for at foretage en omvendt afhjælpning, og tryk på Enter.
- Sørg for, at det navn, der returneres i den omvendte post, svarer til forward record-navnet/IP-adressen.
[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.
I ovenstående eksempel er det klart, at kørsel af nslookup ikkeinteraktivt aldrig forespørger den omvendte søgezone.
BEMÆRK: NetWorker er meget afhængig af perfekt og konsistent omvendt opløsning samt standardforsendelsesopløsning - dette er en del af godkendelsesprocessen og er designet på denne måde til at forhindre IP-spoofing eller andre typer angreb, der er beregnet til at hemmeliggøre sikkerhedskopieringsdata.
Opløsning
Alle NetWorker-værter skal garanteres at have ensartet navnefortolkning, både fremad og tilbage, for alle værter, som de kommunikerer med (som varierer afhængigt af datazonerollen). Det er kritisk for NetWorker-administratorer at sikre, at eventuelle problemer med værtsopløsningen løses med det samme og helt.
Ved fejlfinding af navnefortolkningsproblemer eller for at udelukke dem i din NetWorker-datazone:
1. Find alle værter, der er involveret i den fejlbe mislykkede handling – Server, Klient(e) og eventuelt Storage Node(s) osv.
2. For hver af disse bestemmer du IP-adresserne, der er konfigureret lokalt, og alle forventede gensolvable navne for disse IP'er.
3. Konfigurer alle værter til at bruge værtsfilen før DNS til værtsopløsning.
4. I begyndelsen af en værters værtsfil skal du konfigurere en enkelt post for hver IP, hvor hvert navn svarer til den på samme linje.
5. Kopier linjerne nøjagtigt fra den første vært til værtsfilerne for de andre involverede værter.
6. Rediger NetWorker-klientobjekterne, så de har aliasser korrekt svarende til de ønskede IP'er.
7. Luk NetWorker ned på alle involverede værter
8. Ryd Resolver Cache på hver vært ved hjælp af den relevante operativsystemmekanisme
9. Genstart NetWorker, og forsøg den problematiske handling igen
For at bevise, at navnet blev løst af en given vært, skal du bruge denne test:
1. Fra den første NetWorker-vært (f.eks. klienten), skal du oprette forbindelse til den anden (for eksempel serveren) ved hjælp af
nsradmin -s remote_host -p nsrexec - forlad sessionen åben
2. På samme vært skal du bestemme processen for nsradmin (f.eks. Windows,
opgaveliste | findstr nsradmin)
3. Kør netstat for at vise den sokkel, der er tilknyttet den pågældende proces (f.eks. Windows,
netstat -ao | findstr process_id)
4. Bestem tilslutningssoklen fra den pågældende vært (den længst til venstre IP:port-parring i outputtet)
5. På fjernværten - kør netstat -a og findstr/grep til :calling_port_from_first_host (vises nu i højre side)
6. Værtsnavnet, der vises på venstre side af kolonet, er navnet på den første vært, som den anden vært fortolker den indgående forbindelse som
7. Kør igen med switchen -n føjet til kommandoen netstat for at kontrollere IP'en for den samme sokkel for at kontrollere, om IP/route forventes
8. Omgøre den samme test for at sikre, at den anden vært løser den første vært inden for forventede parametre