Windows network状態の層別確認は短い一行でも扱えますが、入力の種類や版を確認しないまま本番へ使うと誤判定を招きます。この記事の結論は「network確認はUp adapter、IP/gateway/DNS、route、name resolution、対象TCP portの順で行います。ICMP失敗だけでofflineとせず、承認済みの業務endpointへTest-NetConnectionします。」。public siteへのpingだけでなくadapter、IP、route、DNS、TCP、applicationを順に切り分ける場合を対象に、確認結果から次の行動を選べる形で解説します。 確認ポイント：adapter、IP、DNS、TCPは独立した層なので、一つの成功だけで通信全体を正常とは判定しません。
NIC・IP・DNS・TCPを別レイヤーとして採取する
手順書の「対象」をwildcardのままにせず、実際の一覧へ展開してreviewします。Get-NetAdapter、Get-NetIPConfiguration、Resolve-DnsName、Test-NetConnectionがshell builtin、cmdlet、外部programのどれかも確認し、別実装のoptionを混在させません。
- Get-NetAdapterでphysical/virtualとStatusを確認する
- Get-NetIPConfigurationでIP、gateway、DNSを確認する
- Get-NetRouteでdefault routeとmetricを確認する
- 調査対象endpoint、port、expected protocolを決める
PowerShell診断commandを到達段階ごとに実行する
Get-NetAdapterで物理リンクを確認する
Get-NetAdapter | Select-Object Name,InterfaceDescription,Status,LinkSpeed,MacAddress,InterfaceIndexUpでもupper layer疎通は保証しません。
Get-NetIPConfigurationでaddressとgatewayを確認する
Get-NetIPConfiguration -Detailed | Select-Object InterfaceAlias,InterfaceIndex,IPv4Address,IPv6Address,IPv4DefaultGateway,DNSServerVPNとvirtual adapterを別に識別します。
Resolve-DnsNameで名前解決だけを検査する
$dnsConfig = Get-NetIPConfiguration -Detailed |
Where-Object { $_.DNSServer.ServerAddresses.Count -gt 0 } |
Select-Object -First 1
$server = @($dnsConfig.DNSServer.ServerAddresses)[0]
if (-not $server) { throw 'No configured DNS server was found.' }
Resolve-DnsName -Name 'www.microsoft.com' -Server $server -DnsOnly -ErrorAction Stop |
Select-Object Name,Type,IPAddress,NameHost,@{n='QueriedServer';e={$server}}public成功だけでinternal DNS正常とは判断しません。問い合わせ先を証跡へ残す例では、Get-NetIPConfigurationのDNSServer.ServerAddressesから$serverを明示し、-Serverへ渡した値をQueriedServerとして併記します。QueriedServerは実際の応答元を示す値ではありません。
Test-NetConnectionでTCP 443を検査する
Test-NetConnection -ComputerName 'www.microsoft.com' -Port 443 -InformationLevel Detailed対象とportは承認済みに限定します。
Get-NetRouteで選択候補の経路を読む
Get-NetRoute -AddressFamily IPv4 | Sort-Object RouteMetric | Select-Object -First 20 DestinationPrefix,NextHop,InterfaceIndex,RouteMetricdefault routeだけでなくlongest prefixを意識します。
接続不可を下位レイヤーから切り分ける
- ping失敗をnetwork全断とする
- public siteだけで社内疎通を判断する
- VPN adapterを見ない
- TCP成功をapplication正常とする
- 調査のためfirewallを無効にする
出力objectと終了状態を分けて保存する
PingはICMP policyで遮断されてもHTTPSは正常な場合があります。TcpTestSucceededはTCP handshakeでapplication responseやTLS/auth成功を保証しません。DNSはcache、hosts、NRPT、VPNの影響を受けます。adapter Up、gateway reachable、DNS、TCP、HTTPを別statusとして記録します。
読取診断とネットワーク設定変更を混ぜない
確認commandは読み取りですが、外部hostへの大量ping/port scanを行いません。設定変更、adapter restart、DNS cache clear、firewall無効化を最初の切り分けにしません。変更が必要ならIP、route、DNS、proxyのcurrent stateとremote接続の戻し方を保存し、out-of-band経路を確保します。
同じ宛先を再測定して時刻差を残す
同じendpointをDNS、Test-NetConnection、Invoke-WebRequest等で層別に確認し、InterfaceIndexとrouteを照合します。0件、timeout、name resolution error、TCP拒否を別codeへし、設定が前後で変わっていないことを確認します。
ネットワーク状態を正常と判定する条件
Get-NetAdapter、Get-NetIPConfiguration、Resolve-DnsName、Test-NetConnectionをInterfaceIndexと接続先で関連付けます。link Up、IPあり、DNS成功、TCP 443成功は別の層なので、ping失敗だけで全断とせず、どこまで成功したかを返します。
DNS・TCPをまとめて採取するコード
$dns=Resolve-DnsName -Name 'www.microsoft.com' -DnsOnly -ErrorAction Stop
$tcp=Test-NetConnection -ComputerName 'www.microsoft.com' -Port 443 -InformationLevel Detailed
[pscustomobject]@{Resolved=@($dns|Where-Object IPAddress).Count;Remote=$tcp.RemoteAddress;Interface=$tcp.InterfaceAlias;Source=$tcp.SourceAddress;Tcp443=$tcp.TcpTestSucceeded}このcodeは画面表示だけを見るための例ではありません。通常系では「対象interfaceがUpでIP/gateway/DNSを持ち、名前解決と指定TCP portが成功する」を確認し、0件と実行errorを別の結果として保存します。
正常・到達不能・command失敗を分類する
- 期待どおり：対象interfaceがUpでIP/gateway/DNSを持ち、名前解決と指定TCP portが成功する
- 0件・非適用：ICMP不可でもTCP成功ならReachableByTcpとして扱い、pingだけで失敗にしない
- 実行error：No adapter、APIPA、DNS error、routeなし、TCP timeout/refusedを層別stateにする
public siteだけで社内networkを判定せず、VPN/interface metricを確認します。調査のためにfirewall無効化、DNS cache clear、adapter restartを行いません。Test-NetConnectionのTcpTestSucceededとapplication HTTP healthも別です。
link断・DNS 0件・port拒否を試す
Get-NetIPConfiguration -Detailed | ForEach-Object { [pscustomobject]@{Alias=$_.InterfaceAlias;Index=$_.InterfaceIndex;IPv4=($_.IPv4Address.IPAddress -join ',');Gateway=($_.IPv4DefaultGateway.NextHop -join ',');DNS=($_.DNSServer.ServerAddresses -join ',')} }正常、DNSのみ失敗、TCP refused/timeout、ICMP block、VPN、APIPAをtestします。InterfaceIndex、route、明示したDNS問い合わせ先（QueriedServer）、remote/source address、TCP result/latencyを保存します。-Serverを省略した既定リゾルバー利用時は、Resolve-DnsNameの結果オブジェクトから実際の応答元を特定できないため、結果を応答元DNSとして記録しません。
PowerShellを使ったネットワーク状態の確認方法の証跡には、実行対象と取得時刻に加え、通常・0件・errorのどれへ分類したかを残します。通常系は「対象interfaceがUpでIP/gateway/DNSを持ち、名前解決と指定TCP portが成功する」、停止系は「No adapter、APIPA、DNS error、routeなし、TCP timeout/refusedを層別stateにする」を判断文としてそのまま作業票へ写し、担当者ごとの言い換えで意味が変わらないようにします。
network診断を定期化するときは、adapter、address、route、DNS、TCPの順を崩さず、各層の開始時刻・終了状態・採用した接続先を同じrun IDへ記録します。一つの総合booleanへ丸めず、最初に失敗した層と、その後を未実行にした理由を出力します。VPN接続の有無やdefault routeの切替を検知したrunは通常時のbaselineと分け、到達不能を帯域不足として通知しません。
コメント