Når hjemmesiden ikke åbner: DNS-fejlsøgning med PowerShell på Windows
En medarbejder forsøger at åbne et vigtigt webbaseret arbejdsprogram.
Browseren viser en fejl.
Medarbejderen prøver igen. Samme resultat.
En kollega kan godt åbne programmet, men på den første computer virker det stadig ikke.
Er internetforbindelsen nede? Er der problemer med DNS? Eller blokerer noget for forbindelsen?
Det er her, PowerShell kan være et nyttigt værktøj.
I denne vejledning gennemgår vi, hvordan du kan undersøge almindelige problemer med DNS og TCP-forbindelser på en Windows-computer.
Vi begynder med enkle kommandoer og slutter med et lille script, som samler resultaterne i en rapport.
Målgruppe: IT-administratorer, supportmedarbejdere og teknisk interesserede, som arbejder med Windows-netværk.
Forudsætninger: Eksemplerne er beregnet til Windows med PowerShell og de relevante Windows-moduler. Kommandoerne undersøger konfiguration og forbindelser. De ændrer ikke computerens DNS-indstillinger.
1. Hvad sker der, når du åbner en hjemmeside?
Forestil dig, at du skriver en webadresse i browseren.
Computeren skal normalt finde en IP-adresse, der hører til det angivne domænenavn.
Det er en af DNS-systemets vigtigste opgaver.
DNS står for Domain Name System.
Det fungerer som en del af internettets navneopslag og gør det muligt for programmer at finde relevante netværksadresser.
Men et fungerende DNS-opslag er ikke det samme som en fungerende forbindelse.
Hvis computeren kan finde IP-adressen, kan der stadig være problemer med netværket, firewallen eller tjenesten på serveren.
Derfor bør fejlsøgningen skelne mellem mindst to spørgsmål:
- Kan computeren finde en adresse til domænenavnet?
- Kan computeren oprette forbindelse til den ønskede tjeneste?
PowerShell kan hjælpe med begge dele.
2. Se hvilke DNS-servere computeren bruger
Det første skridt er at undersøge computerens DNS-konfiguration.
Åbn PowerShell på Windows, og kør:
Get-DnsClientServerAddress -AddressFamily IPv4
Kommandoen viser de konfigurerede IPv4 DNS-serveradresser for computerens netværksinterfaces.
Du kan blandt andet se interfacets navn og de registrerede DNS-serveradresser.
Hvis du vil undersøge et bestemt interface, kan du bruge:
Get-DnsClientServerAddress -InterfaceAlias "Ethernet"
Her forudsætter vi, at interfacet hedder Ethernet.
På din computer kan navnet være anderledes.
Det kan eksempelvis være Wi-Fi eller et navn, der er tilpasset virksomhedens netværk.
Du kan se de tilgængelige interfaces med:
Get-NetAdapter |
Select-Object Name, Status, InterfaceDescription
Hvis medarbejderen bruger en VPN-forbindelse, kan DNS-konfigurationen være mere kompleks.
Nogle virksomhedsmiljøer bruger eksempelvis forskellige DNS-servere til interne og eksterne systemer.
Derfor bør du ikke automatisk ændre DNS-serveren til en offentlig tjeneste, blot fordi et opslag fejler.
Undersøg først, hvordan netværket er beregnet til at fungere.
3. Test DNS-opslag med Resolve-DnsName
Windows PowerShell indeholder kommandoen Resolve-DnsName.
Den kan bruges til at undersøge, om DNS kan finde oplysninger om et domæne.
Prøv følgende eksempel:
Resolve-DnsName -Name "example.com" -Type A -DnsOnly
Her bruger vi example.com som testdomæne.
Parameteren -Type A beder om IPv4-adresser.
Parameteren -DnsOnly begrænser navneopslaget til DNS i stedet for at bruge andre navneopslagsmetoder som LLMNR eller NetBIOS.
Hvis opslaget lykkes, kan resultatet indeholde en eller flere IPv4-adresser.
Det fortæller os, at DNS-opslaget gav et svar.
Men det fortæller ikke, om hjemmesiden kan åbnes i en browser.
Det skal vi undersøge separat.
Hvad hvis DNS-opslaget fejler?
En DNS-fejl kan have flere forklaringer.
Det kan eksempelvis skyldes en forkert domæneadresse, problemer med DNS-serveren eller en netværkskonfiguration, som ikke fungerer efter hensigten.
Det kan også være et internt domæne, som kun kan slås op via virksomhedens eget netværk eller VPN.
Derfor bør du undersøge både navnet og den forventede netværksopsætning.
Hvis kun én computer har problemet, er det relevant at sammenligne dens konfiguration med en arbejdscomputer, hvor opslaget fungerer.
Det kan hjælpe med at indsnævre fejlen.
4. Test en bestemt DNS-server
Nogle gange er det nyttigt at undersøge, hvordan en bestemt DNS-server besvarer et opslag.
Du kan bruge parameteren -Server:
Resolve-DnsName `
-Name "example.com" `
-Type A `
-Server "192.0.2.53" `
-DnsOnly
IP-adressen 192.0.2.53 er kun en dokumentationsadresse.
Erstat den med IP-adressen på en DNS-server, som du har tilladelse til at teste.
Hvis opslaget fungerer gennem én DNS-server, men ikke gennem en anden, er det relevant at undersøge forskellen.
Det beviser ikke automatisk, at den ene server er defekt.
Forskellige DNS-servere kan have forskellige regler, zoner eller oplysninger.
Det er især relevant i virksomhedsmiljøer med interne domæner.
En intern adresse skal måske kun kunne findes via virksomhedens egne DNS-servere.
Derfor bør resultaterne altid vurderes i forhold til netværkets tilsigtede funktion.
5. DNS fungerer. Hvorfor åbner hjemmesiden stadig ikke?
Lad os antage, at DNS-opslaget lykkes.
PowerShell viser en IP-adresse.
Men medarbejderen kan stadig ikke åbne hjemmesiden.
Nu skal vi undersøge, om computeren kan oprette en TCP-forbindelse.
Det kan vi gøre med Test-NetConnection.
Prøv følgende:
Test-NetConnection `
-ComputerName "example.com" `
-Port 443
Port 443 bruges almindeligvis til HTTPS.
Kommandoen undersøger blandt andet, om en TCP-forbindelse til den angivne port kan oprettes.
Se især efter feltet:
TcpTestSucceeded
Hvis værdien er True, lykkedes TCP-forbindelsestesten.
Hvis værdien er False, kunne testen ikke etablere den forventede forbindelse.
Men vær forsigtig med fortolkningen.
En mislykket TCP-test betyder ikke nødvendigvis, at DNS er problemet.
Det kan også skyldes netværksregler, firewallindstillinger, en utilgængelig tjeneste eller andre forbindelsesproblemer.
Omvendt betyder TcpTestSucceeded = True ikke, at webapplikationen fungerer korrekt.
En server kan acceptere en TCP-forbindelse og stadig returnere en HTTP-fejl eller have problemer med selve applikationen.
Få flere oplysninger
Du kan anmode om et mere detaljeret resultat:
Test-NetConnection `
-ComputerName "example.com" `
-Port 443 `
-InformationLevel Detailed
Resultatet kan blandt andet indeholde den anvendte adresse, lokale netværksinterface og status for TCP-testen.
De oplysninger kan være nyttige, hvis forskellige computere oplever forskellige problemer.
6. Undersøg computerens lokale DNS-cache
Windows gemmer DNS-oplysninger midlertidigt i en lokal cache.
Det kan gøre gentagne opslag hurtigere.
Men det betyder også, at en computer i en periode kan bruge oplysninger, som allerede ligger lokalt.
Du kan se cacheindholdet med:
Get-DnsClientCache
Hvis du kun vil undersøge poster, der indeholder et bestemt domænenavn, kan du filtrere resultatet:
Get-DnsClientCache |
Where-Object {
$_.Entry -like "*example.com*"
} |
Select-Object Entry, Type, Data, TimeToLive
TimeToLive viser den resterende levetid for den pågældende cachepost.
Vær opmærksom på, at en post ikke nødvendigvis findes i cachen.
Et tomt resultat betyder derfor ikke automatisk, at DNS er defekt.
Det kan blot betyde, at der ikke findes en tilsvarende cachepost på det tidspunkt.
Skal man altid rydde DNS-cachen?
Nej.
Det er almindeligt at høre rådet om at rydde DNS-cachen som det første.
Men det er ikke nødvendigvis den bedste begyndelse.
Hvis du rydder cachen, ændrer du den lokale tilstand og kan fjerne oplysninger, som var nyttige under fejlsøgningen.
Det kan derfor være mere hensigtsmæssigt først at undersøge de aktuelle opslag og registrere resultaterne.
Hvis der efterfølgende er en konkret grund til at rydde cachen, bør det ske efter virksomhedens normale procedurer.
I denne vejledning holder vi os til diagnostiske kommandoer.
7. Saml kontrollerne i et PowerShell-script
Hvis du ofte undersøger DNS-problemer, kan det være praktisk at samle de grundlæggende kontroller i ét script.
Vi vil oprette et lille script, som:
- Modtager et domænenavn og et TCP-portnummer.
- Tester, om domænet kan findes via DNS.
- Registrerer eventuelle IPv4-adresser.
- Tester TCP-forbindelsen, hvis DNS-opslaget lykkes.
- Returnerer et PowerShell-objekt med resultaterne.
Gem følgende kode i en fil med navnet:
Test-DnsAndTcp.ps1
param(
[string]$HostName = "example.com",
[ValidateRange(1, 65535)]
[int]$Port = 443
)
$result = [ordered]@{
Tidspunkt = Get-Date -Format "yyyy-MM-dd HH:mm:ss"
Computer = $env:COMPUTERNAME
Domaene = $HostName
DNS_OK = $false
IPv4 = ""
TCP_Port = $Port
TCP_OK = $false
Bemaerkning = ""
}
try {
$addresses = @(
Resolve-DnsName `
-Name $HostName `
-Type A `
-DnsOnly `
-ErrorAction Stop |
Where-Object {
$_.Type -eq "A" -and $_.IPAddress
}
)
if ($addresses.Count -gt 0) {
$result["DNS_OK"] = $true
$result["IPv4"] = (
$addresses |
ForEach-Object { $_.IPAddress }
) -join ", "
}
else {
$result["Bemaerkning"] = "Ingen IPv4 A-poster fundet."
}
}
catch {
$result["Bemaerkning"] = "DNS-opslag mislykkedes."
}
if ($result["DNS_OK"]) {
try {
$tcp = Test-NetConnection `
-ComputerName $HostName `
-Port $Port `
-InformationLevel Quiet `
-WarningAction SilentlyContinue `
-ErrorAction Stop
$result["TCP_OK"] = [bool]$tcp
}
catch {
$result["Bemaerkning"] = "TCP-test kunne ikke gennemfoeres."
}
}
[PSCustomObject]$result
Sådan fungerer scriptet
Først definerer vi to parametre.
HostName indeholder det domæne, der skal undersøges.
Port angiver, hvilken TCP-port vi vil teste.
Hvis du ikke angiver værdier, bruger scriptet example.com og port 443.
Derefter opretter vi et objekt med oplysninger om tidspunkt, computer, domæne og resultater.
DNS-opslaget bliver udført inde i en try-blok.
Hvis opslaget returnerer en eller flere A-poster, registrerer scriptet de fundne IPv4-adresser.
Hvis opslaget fejler, bliver fejlen fanget, og resultatet viser, at DNS-testen ikke lykkedes.
TCP-testen bliver kun gennemført, når DNS-opslaget har fundet mindst én IPv4-adresse.
Det gør det lettere at forstå, hvorfor en TCP-test eventuelt ikke blev udført.
Bemærk, at TCP-testen bruger domænenavnet og dermed kan vælge en anden adresse, eksempelvis IPv6, hvis navnet også har AAAA-poster. Scriptet giver derfor et praktisk statusoverblik, men ikke en fuldstændig test af hver enkelt returneret IPv4-adresse.
Kør scriptet
Åbn PowerShell i den mappe, hvor filen er gemt.
Kør derefter:
.\Test-DnsAndTcp.ps1 `
-HostName "example.com" `
-Port 443
Scriptet forudsætter, at organisationens gældende regler tillader udførelse af den pågældende scriptfil.
Du bør ikke ændre virksomhedens sikkerhedspolitikker blot for at kunne gennemføre testen.
Hvordan skal resultatet læses?
Et vellykket resultat vil eksempelvis vise, at:
-
DNS_OKerTrue. -
IPv4indeholder en eller flere adresser. -
TCP_OKerTrue.
Det betyder, at de to grundlæggende kontroller lykkedes på testtidspunktet.
Det er ikke en garanti for, at hele webapplikationen fungerer.
Hvis DNS_OK er False, bliver TCP-testen sprunget over. Derfor må TCP_OK = False i den situation ikke fortolkes som et selvstændigt bevis på en netværksblokering.
Hvis DNS lykkes, men TCP-testen fejler, bør forbindelsen og den forventede tjeneste undersøges nærmere.
Scriptet er et startpunkt for fejlsøgning.
Det erstatter ikke en samlet analyse af netværk, applikation og sikkerhedspolitikker.
8. Eksporter resultaterne til en CSV-fil
Hvis supportafdelingen ønsker at dokumentere en undersøgelse, kan resultatet eksporteres til CSV.
Du kan eksempelvis gemme scriptets output i en variabel:
$report = .\Test-DnsAndTcp.ps1 `
-HostName "example.com" `
-Port 443
Derefter kan du vise resultatet:
$report | Format-List
Eller eksportere det til en CSV-fil i en eksisterende mappe:
$report |
Export-Csv `
-Path "$env:TEMP\dns-diagnostic.csv" `
-NoTypeInformation `
-Encoding UTF8
Filen kan bruges til at dokumentere testresultatet eller sammenligne undersøgelser fra forskellige tidspunkter.
Hvis virksomheden ønsker at samle rapporter fra flere arbejdscomputere, bør den også tage hensyn til, hvilke oplysninger der skal registreres.
Computernavne, interne domæner og netværksadresser kan være følsomme driftsoplysninger.
Rapporter bør derfor opbevares efter virksomhedens regler for adgang og informationssikkerhed.
9. Tre almindelige fejlscenarier
Lad os se på, hvordan kommandoerne kan bruges i praksis.
Scenario A: Kun én medarbejder har problemer
En medarbejder kan ikke åbne et internt program.
Kollegaerne kan godt.
Start med at undersøge computerens netværksinterface og DNS-konfiguration.
Sammenlign derefter DNS-opslag og forbindelsesresultater med en computer, hvor systemet fungerer.
Hvis konfigurationerne er forskellige, kan forskellen være relevant at undersøge.
Men ændr ikke indstillinger, før du forstår deres formål.
Scenario B: Alle medarbejdere har samme fejl
Flere computere kan ikke åbne et bestemt webbaseret system.
Hvis DNS-opslag fejler på tværs af mange enheder, kan det være relevant at undersøge den fælles DNS-infrastruktur.
Hvis DNS fungerer, men TCP-forbindelsen fejler, kan undersøgelsen i stedet fortsætte med netværksforbindelser og tjenestens tilgængelighed.
Det er også vigtigt at kontrollere, om problemet kun påvirker ét bestemt system.
At alle medarbejdere oplever samme fejl betyder ikke automatisk, at hele virksomhedens internetforbindelse er nede.
Scenario C: Problemet opstår kun med VPN
En medarbejder kan åbne almindelige hjemmesider, men ikke et internt virksomhedsprogram.
Problemet opstår især, når VPN-forbindelsen bruges.
Her er det relevant at undersøge, om det interne domæne bliver slået op gennem den korrekte DNS-infrastruktur.
Nogle virksomheder bruger separate DNS-regler til interne navne.
Hvis medarbejderens computer ikke bruger den forventede konfiguration, kan bestemte interne systemer være utilgængelige.
Det betyder ikke, at løsningen er at skifte til en offentlig DNS-server.
Tværtimod kan det skabe yderligere problemer med interne navne.
Undersøg virksomhedens godkendte VPN- og DNS-opsætning først.
10. Hvornår er problemet ikke længere et DNS-problem?
DNS bliver nogle gange mistænkt, fordi en hjemmeside ikke kan åbnes.
Men en browserfejl kan opstå på flere forskellige niveauer.
Hvis DNS-opslaget fungerer, og TCP-forbindelsen til port 443 også lykkes, er det relevant at undersøge andre forhold.
Det kan eksempelvis være:
- TLS-certifikater og sikker forbindelse.
- Proxyindstillinger.
- Webserverens svar.
- Applikationens loginfunktion.
- Browserens konfiguration.
- Fejl i den bagvedliggende webtjeneste.
Det er også muligt, at et program bruger andre porte eller protokoller end dem, der indgår i vores test.
Derfor er det vigtigt at vide, hvilken tjeneste der faktisk skal undersøges.
En teknisk test giver først mening, når den er knyttet til en konkret forventning.
11. IT Virksomhed Kolding – Fejlsøgning bør være en del af en god supportproces
Når virksomheder undersøger IT Virksomhed Kolding, kan behovet blandt andet handle om stabil IT-drift, netværk, cloudløsninger og hjælp til tekniske problemer.
HOUSE4IT A/S har adresse på Kokholm 1A i Kolding og arbejder med IT-support, IT-drift, netværk, Microsoft 365, IT-sikkerhed og rådgivning til erhverv.
Virksomheder kan læse mere om HOUSE4IT A/S og deres IT-løsninger til virksomheder og undersøge, hvilke serviceområder der passer til deres behov.
Teknisk fejlsøgning handler ikke kun om at finde en kommando, som giver et bestemt resultat.
Det handler også om at forstå virksomhedens netværk, dokumentere problemerne og vurdere dem i forhold til de systemer, medarbejderne er afhængige af.
En kort DNS-test kan være nyttig.
Men hvis problemerne vender tilbage, bør den underliggende årsag undersøges.
Det kan kræve en bredere gennemgang af netværkskonfiguration, VPN, firewallregler eller den berørte tjeneste.
12. Brug resultaterne til at forbedre supportarbejdet
Når et problem bliver løst, er det værd at dokumentere, hvad der faktisk var galt.
Det behøver ikke være en lang rapport.
En kort beskrivelse kan indeholde:
- Hvilket system der ikke fungerede.
- Hvilke medarbejdere eller enheder der var påvirket.
- Hvilke kontroller der blev gennemført.
- Hvad undersøgelsen viste.
- Hvilken ændring der eventuelt løste problemet.
Det kan gøre det lettere at håndtere lignende fejl senere.
Det er især nyttigt, hvis flere medarbejdere eller IT-leverandører deler ansvaret for support.
En god fejlbeskrivelse hjælper den næste person med at forstå situationen uden at skulle begynde helt forfra.
Afslutning: Begynd med at finde ud af, hvor forbindelsen fejler
Når en medarbejder siger, at internettet ikke virker, kan det dække over mange forskellige problemer.
Måske er hele netværksforbindelsen utilgængelig.
Måske fungerer forbindelsen, men navneopslaget fejler.
Eller måske er DNS og TCP-forbindelsen i orden, mens selve webapplikationen har problemer.
Med PowerShell kan du begynde at skelne mellem disse situationer.
Get-DnsClientServerAddress hjælper med at undersøge DNS-konfigurationen.
Resolve-DnsName tester DNS-opslag.
Get-DnsClientCache giver indblik i den lokale DNS-cache.
Og Test-NetConnection kan bruges til at undersøge TCP-forbindelsen til en bestemt port.
Ingen af kommandoerne giver hele svaret alene.
Men sammen kan de skabe et bedre udgangspunkt for en systematisk undersøgelse.
God fejlsøgning handler ikke om at prøve flest mulige løsninger. Den handler om at stille ét præcist spørgsmål ad gangen og bruge resultatet til at vælge det næste skridt.
Det gør supportarbejdet mere gennemskueligt, både for IT-afdelingen og for de medarbejdere, som venter på at komme videre med deres arbejde.
Top comments (0)