NetWorker avhenger av navneløsing. Hvis navneløsingen ikke er riktig og helt konsekvent, kan det oppstå problemer i mange av NetWorkers operasjoner. Siden NetWorker administrerer potensielt sensitive data, må det sikre vertenes identitet som de samhandler med på ulike måter.
En rekke symptomer i NetWorker kan være et resultat av navneløsing i NetWorker:
- Feilmeldinger som angir problemer med oppslag for videresendt eller omvendt navn.
- Kan ikke undersøke klienter under sikkerhetskopiering.
- Klientene kan ikke lagre på serveren eller gjenopprette manuelt.
- Problemer med kloning eller tilgang til lagringsnodeenheter.
- Problemer med opptak av nettleser- eller mediedatabase.
- Server- eller lagringsnoden slutter å svare ved oppstart eller i løpet av den vanlige driften.
- Feilnavn eller nestede indekskataloger.
- Feilkonfigurerte klientfeil.
Navneløsing skjer med ulike mekanismer og på ulike nivåer:
- NetWorker-navnehurtigbuffer
- Hurtigbuffer for lokal verts løser
- Filoppføringer for lokale verter
- Dns-serveroppslag
Metodikk for navneløsing
1. NetWorker-hurtigbufring: NetWorker opprettholder en intern hurtigbuffer for navn og kan noen ganger ikke gjenspeile miljøendringer som gjøres for å løse problemer med navneløsing uten å starte tjenestene på nytt. NetWorker har også et konfigurerbart felt som er globalt for alle klientforekomster kalt Aliaser, som må gjenspeile alle navn som kan løses for denne klientforekomsten for å unngå problemer med flere typer. Hvis det finnes et påkrevd navn i NetWorkers interne hurtigbuffer, brukes det derfra, og hurtigbufferen for vertsløseren blir ikke registrert. NetWorker-server-daemonen (nsrd) har muligheten til å dumpe den løste navnebufferen i daemon.raw, tømme hurtigbufferen eller tømme og løse navn på nytt:
- dbgcommand -n nsrd PrintDnsCache=1 (Dump til daemon.raw)
- dbgcommand -n nsrd FlushDnsCache=1 (Tøm)
- dbgcommand -n nsrd FlushDnsCache=9 (Tøm og løs)
- For kommandoene ovenfor kan enten "-n process name" eller "-p PID" brukes. Hvis du vil bruke PID-en, må du først kjøre andre kommandoer for å hente PID- for eksempel "ps -ef | grep nsr" (Linux) eller "tasklist | findstr nsr» (windows)
2. Løse hurtigbuffer: Alle verter og operativsystemer har en lokal hurtigbuffer for løsninger for å hjelpe vertsoppløsning og -hastighet uten å stole på vertsfiler eller DNS-servere. Denne hurtigbufferen kontrolleres i henhold til vanlige regler for navneløsing for operativsystemet, og hvis vertsposten finnes (selv om den er gammel eller feil), brukes den før du spør etter en annen datakilde. Løse hurtigbufferoppføringer angis i hurtigbufferen ved det første vellykkede løsningsforsøket og blir værende i en forhåndsbestemt tidsperiode. Noen operativsystemer kan vise innholdet i løse hurtigbufferen (for eksempel Windows-verter kan kjøre ipconfig /displaydns), og alle har en mekanisme for å fjerne eller tømme den med makt:
- Tømming av DNS på Linux kan variere avhengig av Linux-distribusjon og installerte pakker. Se leverandørdokumentasjonen.
- Windows: ipconfig /flushdns
3. Vertsfiler: Den eldre mekanismen for vertsoppløsning er å eksplisitt angi IP-adressen, etterfulgt av eventuelle navn som er ønsket å løse denne adressen, på separate linjer, avgrenset av mellomrom. Dette kontrolleres før DNS som standard på Windows. Kilderekkefølge for Linux-oppløsning kan vanligvis konfigureres i /etc/nsswitch.conf eller /etc/netsvc.conf. Vertsfiler analyseres bare for den første samsvarende oppføringen som blir spurt om. Dermed vil en annen forekomst av en IP-adresse eller et vertsnavn, kort eller lang, aldri bli funnet når du prøver å løse navn. Hvert navn eller IP skal bare vises én gang, da alle navn skal angis på samme linje i den tilsvarende IP-adressen.
- Unix/Linux: /etc/hosts
- Windows: %systemroot%\System32\drivers\etc\hosts
MERK: Vertsfiler kan bli skadet, for eksempel alle andre filer – hvis du er i tvil, endrer du navnet på den eksisterende vertsfilen, oppretter den nye, tømmer hurtigbufferen for løsning og prøver på nytt.
4. Løsning for videresending: Hvis du vil kommunisere med en fremmed vert når navnet er oppgitt, må en vert finne ip-adressen til de fremmede vertene for TCP/IP-kommunikasjon for å kommuniseres; Når du bruker DNS, må spørringen utføres for det vertsnavnet i sonen forward lookup for å hente IP-adressen. Flere DNS-verter kan konfigureres slik at en klient kan bruke dem. på Windows-systemer bruker du ipconfig /all for å få DNS-navn. på Linux-/UNIX-operativsystemer, /etc/resolv.conf utfører vanligvis DNS-serverrekkefølgen. nslookup er det vanligste verktøyet for å spørre DNS og finnes på alle plattformer, men blir ofte misbruket; for å spørre etter sonen fremover:
- Kjør nslookup uten argumenter for å angi den interaktive ledeteksten.
- Skriv inn navnet på gjentakelsen du vil slå opp, og trykk på Enter for å hente videresendingsposten fra DNS-serveren du har koblet til.
- Skriv inn samme navn to ganger til for å se om navneposten er ringdistribusjon mellom ulike verter eller returnerer de samme dataene.
- Gjenta den samme prosessen for alle forekomster av ethvert navn som verten kan bli kalt av andre verter eller ansees som for samme IP-adresse.
- Gjenta den samme prosessen for alle andre DNS-servere som verten er konfigurert til å bruke, ved å angi server-next_dns_server.
MERK: Alle oppføringer som returneres, må være konsekvente mellom seg selv og i samsvar med det som forstås som riktig av administratoren. og alle kjente navn må gjøres rede for og kontrolleres.
5. Omvendt oppløsning: For å kommunisere med en fremmed vert når IP-adressen angis, kan det hende at verten må finne vertens navn. Når du bruker DNS, utføres spørringen mot den omvendte oppslagssonen for å finne vertsnavnet til den aktuelle IP-adressen. Dette misbrukes ofte, siden det å angi nslookup IP_Address eller til og med skrive inn IP-adressen i nslookup, ikke vil spørre etter sonen for omvendt oppslag:
- Kjør nslookup uten argumenter for å angi den interaktive ledeteksten.
- Angi angi q=ptr for å endre spørringstypen til omvendt sone.
- Skriv inn IP-adressen for å reversere problemet, og trykk på Enter.
- Kontroller at navnet som returneres i motsatt post samsvarer med navnet på videresendingsposten/IP-en.
[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 eksemplet ovenfor er det klart at kjøring av nslookup ikke-interaktivt aldri spør i sonen for omvendt oppslag.
MERK: NetWorker er svært avhengig av perfekt og konsekvent omvendt oppløsning samt standard løsning fremover – dette er en del av autorisasjonsprosessen og er utformet på denne måten bevisst for å forhindre IP-forfalskning eller andre typer angrep som er ment å stjele sikkerhetskopieringsdata.
Resolution (oppløsning)
Alle NetWorker-verter må garanteres at de har konsekvent navneløsing, både forover og omvendt, for alle verter som de kommuniserer med (som varierer avhengig av datasonerolle). Det er viktig for NetWorker-administratorer å sikre at eventuelle problemer med vertsoppløsning blir løst umiddelbart og fullstendig.
Når du feilsøker problemer med navneløsing, eller for å utelukke dem i NetWorker-datasonen:
1. Finn alle verter som er involvert i den mislykkede operasjonen – server, klient(er) og muligens lagringsnode(er) osv.
2. For hver av dem fastslår du IP-adressene som er konfigurert lokalt og alle forventede navn som kan løses for disse IP-ene.
3. Konfigurer alle verter til å bruke vertsfilen før DNS for vertsoppløsning.
4. I begynnelsen av vertsfilen konfigurerer du én enkelt oppføring for hver IP, med hvert navn som tilsvarer den på samme linje.
5. Kopier disse linjene nøyaktig fra den første verten til vertsfilene til de andre involverte vertene.
6. Rediger NetWorker-klientobjektene slik at de har aliaser som samsvarer med de ønskede IP-ene.
7. Slå av NetWorker på alle involverte verter
8. Tøm løsebufferen på hver vert ved hjelp av riktig operativsystemmekanisme
9. Start NetWorker på nytt, og prøv den problematiske operasjonen på nytt
for å bevise at navnet blir løst av en gitt vert:
1. Fra den første NetWorker-verten (for eksempel klienten) må du koble til den andre (for eksempel serveren) ved hjelp av
nsradmin -s remote_host -p nsrexec – la økten stå åpen
2. På samme vert må du bestemme prosessen for nsradmin (for eksempel Windows,
oppgaveliste | findstr nsradmin)
3. Kjør netstat for å vise kontakten som er tilknyttet denne prosessen (for eksempel Windows,
netstat -ao | findstr process_id)
4. Finn tilkoblingssokkelen fra verten (den venstre IP:port-sammenkoblingen i utdataene)
5. På den eksterne verten kjører du netstat -a og findstr/grep for :calling_port_from_first_host (den vises nå på høyre side)
6. Vertsnavnet som vises på venstre side av kolon, er navnet på den første verten som den andre verten løser den inngående tilkoblingen som
7. Kjør på nytt med -n-svitsjen lagt til i netstat-kommandoen for å kontrollere IP-en til den samme sokkelen, for å kontrollere om IP/ruten er forventet
8. Reverser den samme testen for å sikre at den andre verten løser den første verten i forventede parametere
Mange NetWorker-operasjoner, for eksempel en lagringsgruppe, bruker flere separate TCP-kontakter – i eksempelet for lagringsgruppen, én for en kontrolløkt, én for data og én for oppdatering av indeksen – hvis en økt bruker et inkonsekvent (adløp teknisk korrekt), kan det hende at operasjonen mislykkes.
- Ringdistribusjon brukes noen ganger med vilje og konfigureres – men er vanligvis uventet og unngås
- netstat -a vil se åpne/aktive TCP-kontakter, som viser navnet på den fremmede verten som er løst av operativsystemet. Dette kan brukes til å identifisere problemer
- Statisk ruting kan noen ganger være nødvendig når nettverkstrafikk bruker en uventet/uønsket adapter, noe som senere kan føre til problemer med navneløsing.
Se også:
KB-463606:
Feilsøke problemer med DNS og navneløsing