Windows Server Essentials の Remote Web Access（RWA / Anywhere Access）は社外アクセス用の印象が強いですが、社内LANからもブラウザーで利用できます。社内で開けない原因はURLそのものではなく「名前解決・NAT・証明書」のことが多いので、最短で解決できるURLと確認手順をまとめます。
結論：社内LANからは「内部FQDN + /remote」で開く
Windows Server Essentials の Remote Web Access（RWA / Anywhere Access）を社内ネットワーク（LAN内）から開きたい場合、基本はサーバーの内部ドメイン名（内部FQDN）を使って、次の形式でアクセスします。
| 用途 | 社内LANから入力するURL（基本形） | ポイント |
|---|---|---|
| RWAポータルを開く | https://<内部FQDN>/remote | HTTPS（443）でアクセス。内部名が名前解決できることが前提 |
たとえば、内部FQDNが wse2012.mydomain.local の場合は次のとおりです。
「社外用のURL（公開URL）と社内用のURLが違った気がする」という記憶は、多くの場合外部は公開ドメイン名（例：remote.example.com）、内部は内部FQDN（例：wse2012.mydomain.local）のどちらを入力するかで変わっていた、というのが正体です。
まず押さえる：Remote Web Access（Anywhere Access）で“URLが2種類に感じる”理由
RWAは、ブラウザーで開くポータル（/remote）を入口にして、次のような機能を提供します（環境・設定により表示や可否は変わります）。
- 共有フォルダーやファイルへのアクセス
- （設定済みの）社内PCへのリモートデスクトップ接続
- VPN（SSTPなど）を含む「Anywhere Access」関連機能
このとき、同じRWAでも名前の入口が複数存在し得ます。
- 内部FQDN：Active Directory / 社内DNSで解決される名前（例：server.company.local）
- 公開FQDN：インターネット向けに公開している名前（例：remote.company.com）
- サーバー名（NetBIOS名）：短い名前（例：WSE2012）
- IPアドレス：例：192.168.1.10（ただし証明書警告が出やすい）
社内LANからRWAが開けないときは、URLを探すよりも先に「その名前が社内で解決できるか」「HTTPSで証明書が一致するか」を確認すると、原因に最短で辿り着けます。
社内からアクセスするための「内部FQDN」の調べ方
内部FQDNが分からない場合でも、サーバー側・クライアント側どちらからでも確認できます。特に社内のDNS（AD DNS等）で名前解決できる正式名称を把握するのが重要です。
サーバー側（Windows Server Essentials）で確認する
- GUI：サーバーで「システム」→「コンピューター名」を確認
- コマンド：
hostnameで短いサーバー名を確認 - PowerShell：内部FQDN（ホストの完全修飾名）を確認
hostname
ipconfig /all
# PowerShell（管理者で実行推奨）
[System.Net.Dns]::GetHostByName($env:COMPUTERNAME).HostName
ipconfig /all では「DNSサフィックス」「IPv4アドレス」「DNSサーバー」など、RWAの社内アクセスに効く情報が一度に見られます。たとえばDNSサフィックスが mydomain.local、ホスト名が wse2012 なら、内部FQDNは wse2012.mydomain.local です。
クライアントPC側で確認する（名前解決できるかを先に見る）
社内LANからアクセスする端末が、内部FQDNを解決できなければ、ブラウザーにURLを入れても開けません。次を実行して確認します。
nslookup wse2012.mydomain.local
ping wse2012.mydomain.local
ここで「DNS request timed out」や、意図しないIPが返ってくる場合は、PCが参照しているDNSが社内DNSになっていない可能性が高いです（例：PCのDNSが8.8.8.8など外部DNSになっている、VPN設定でDNSが上書きされている、など）。
社内LANから https://<内部FQDN>/remote が開けないときのチェックポイント
社内アクセスがうまくいかないときは、原因を「名前解決」「通信（ポート）」「サーバー側設定」「証明書」に分解すると、切り分けが速くなります。
| チェック項目 | よくある症状 | 確認方法 | 対処の方向性 |
|---|---|---|---|
| 内部FQDNの名前解決 | ブラウザーが見つからない／接続できない | nslookup / ping | PCのDNS設定を社内DNSに、内部DNSにAレコード追加、DHCP配布DNSの見直し |
| TCP 443（HTTPS）が到達するか | タイムアウト／接続が拒否される | Test-NetConnection（またはtelnet相当） | サーバーFW、ネットワークACL、プロキシを確認。社内側で443を塞いでいないか |
| Anywhere Access（RWA）が有効か | /remote が404、または別ページへ | Dashboard → Settings → Anywhere Access | 有効化、ウィザードの再実行、IIS関連の状態確認 |
| 証明書（CN/SAN）一致 | 証明書警告、ログインできない、リダイレクトループ | ブラウザーの鍵アイコンで証明書の対象名を確認 | 証明書の対象名とアクセス名を揃える（後述）。可能なら社内外で同じFQDNを使う |
社内から「443が開いているか」をすぐ確認する
Windows 10/11 などのクライアントなら、PowerShellの Test-NetConnection が簡単です。
Test-NetConnection wse2012.mydomain.local -Port 443
TcpTestSucceeded : True になれば、少なくとも「社内端末 → サーバーの443」通信は成立しています。ここがFalseの場合は、URL以前にネットワーク（FW/ACL/ルーティング）の問題です。
「/remote」が404になる場合に疑うこと
名前解決も443到達も問題ないのに /remote が404（ページが見つかりません）になる場合は、次を疑います。
- Anywhere Access（Remote Web Access）が無効になっている
- ウィザード実行途中で失敗して、IIS側の構成が崩れている
- IISで別サイトが443を占有しており、正しいサイトに到達していない
Essentialsでは、管理用のDashboardから「Anywhere Access」を有効化するウィザードが用意されているため、まずはDashboard側の設定がONになっているかを確認し、必要なら再実行します。
公開URLが社内から通らない原因：NATループバック（ヘアピンNAT）
社外からは https://remote.example.com/remote で開けるのに、社内LANから同じURLを入れると開けない――この典型原因が、ルーターのNATループバック（ヘアピンNAT）非対応です。
内部PCが公開FQDN（remote.example.com）を引くと、通常はグローバルIP（WAN側IP）に解決されます。その状態で社内からWANへ回り込み、再び社内のサーバーへ戻す「折り返し転送」が必要ですが、ルーターが対応していないと、社内からのアクセスだけが失敗します。
NATループバックが怪しいかを切り分ける
- 社外（スマホの4G/5G）だと公開URLで開ける
- 社内Wi‑Fiに戻すと公開URLで開けない
- 社内では内部FQDN（server.local）だと開ける
この条件がそろうなら、URLの記憶違いではなく、ネットワーク側（ルーターの仕様・設定）の可能性が高いです。
社内外で同じURLにしたい場合の現実的な選択肢
運用面では「社内は内部FQDN、社外は公開FQDN」と2種類覚えるより、社内外で同じURL（公開FQDN）を使える方がトラブルが減ります。環境に合わせて次のいずれかを選びます。
| 方法 | 例 | メリット | デメリット／注意 | 向いている環境 |
|---|---|---|---|---|
| ルーターがNATループバック対応 | 社内からも https://remote.example.com/remote | 設定が少なく、URLが一つで済む | 機種依存。設定項目がない/不安定な場合も | 中小規模、ルーター更新が可能 |
| スプリットDNS（内部DNSで公開名を内部IPへ） | remote.example.com → 192.168.1.10 | URLを統一しつつ、社内通信は最短経路。証明書名も合わせやすい | 社内DNS（AD DNS等）の管理が必要 | ドメイン環境、運用を安定させたい |
| hostsで暫定対応 | PCのhostsに remote.example.com を内部IPで追記 | 検証・緊急対応が速い | 端末ごとに管理が必要で運用向きではない | 少数端末、短期の切り分け |
特におすすめなのはスプリットDNSです。理由はシンプルで、RWAのトラブル原因になりがちな「証明書の名前不一致」を避けやすく、社内外の手順を統一できるからです。
スプリットDNSの考え方（社内だけ公開名を内部IPに向ける）
公開FQDN（remote.example.com）は本来インターネット上ではグローバルIPを指しますが、社内DNS（AD DNS）では同じ名前を内部IPに解決させます。これにより、社内端末は社内経路でサーバーへ到達しつつ、URLは社内外で統一できます。
- 社内：remote.example.com → 192.168.1.10（内部IP）
- 社外：remote.example.com → xxx.xxx.xxx.xxx（グローバルIP）
DNSを触るのが難しい場合は、まずは内部FQDNでのアクセス（https://<内部FQDN>/remote）を確実に通し、安定運用したい段階でスプリットDNSへ移行すると失敗しにくいです。
証明書警告（名前不一致）を減らすポイント
社内LANから内部FQDNで開けたとしても、ブラウザーに「この接続ではプライバシーが保護されません」などの警告が出ることがあります。多くはアクセスしたホスト名と、サーバー証明書の対象名（CN/SAN）が一致していないことが原因です。
| アクセス名 | 証明書が remote.example.com のみ | 起きやすいこと | 対策 |
|---|---|---|---|
| wse2012.mydomain.local | 一致しない | 証明書警告が出やすい | 公開FQDNでアクセスする（スプリットDNS等）、SAN付き証明書を用意する |
| remote.example.com | 一致する | 警告が出にくい | 社内で remote.example.com を内部IPに解決させる（NATループバック or スプリットDNS） |
「内部FQDNで開く」という解決策は最も分かりやすく、切り分けもしやすい一方、証明書構成によっては警告が残ることがあります。運用で困る場合は、証明書の対象名に合わせて“アクセスする名前”を決めるのがコツです。
社内利用でも押さえたいセキュリティの基本
RWAは便利ですが、入口が一つ増える＝攻撃面も増える、という側面があります。社内LANから使う場合でも、次の基本を押さえておくと安心です。
- 不要ユーザーの無効化：退職者・テストアカウントを残さない
- 強力なパスワード：短いパスワードや使い回しは避ける
- アカウントロックアウト：総当たりを抑止（ポリシーで設定）
- 公開範囲の見直し：RDPやVPNなど「使っていない機能」を外向けに開けない
- 証明書期限の把握：切れると社内外で一斉に混乱しやすい
「社内から使えるようにする」だけに意識が向くと、つい公開設定が広くなりがちです。特に外部公開している場合は、社外からの入口を最小限にし、ログ監視や更新適用もセットで考えると安全です。
よくある質問
サーバー名（例：WSE2012）だけで https://WSE2012/remote は使えますか？
環境によっては開けます。ただし、短いサーバー名はDNSサフィックスが補完されるか、NetBIOS名前解決に依存することがあり、端末・ネットワークによって挙動がブレます。トラブルを減らすなら、まずは内部FQDN（例：wse2012.mydomain.local）で動作確認するのが安全です。
IPアドレス直打ち（https://192.168.1.10/remote）はダメですか？
開ける場合もありますが、証明書が「ホスト名」を前提に発行されていると、ほぼ確実に証明書警告（名前不一致）が出ます。切り分けの一手としては有効ですが、常用には向きません。
社内DNSが使えない端末（BYODやゲストWi‑Fi）から開きたい
その端末が参照するDNSが社内DNSでないと、内部FQDNは解決できません。ゲストWi‑Fiを業務LANから分離している場合は特に起きやすいです。運用としては、公開FQDN（remote.example.com）を社内でも使えるようにする（NATループバック or スプリットDNS）方が現実的です。
/remote の末尾は必須ですか？
多くの構成では、RWAポータルの入口が /remote になっています。トップ（https://<ホスト名>/）からリダイレクトされる環境もありますが、迷ったら/remote を付けてアクセスすると目的の画面に到達しやすいです。
まとめ：社内からの最短解は「内部FQDNで https://<内部FQDN>/remote」
Windows Server Essentials の Remote Web Access（RWA / Anywhere Access）を社内LANから開くURLは、基本的にhttps://<内部FQDN>/remoteです。開けない場合は、まず内部FQDNの名前解決と443到達をチェックし、次にAnywhere Accessの有効化と証明書を確認してください。
「社内外で同じ公開URLを使いたい」場合は、ルーターのNATループバック対応を確認しつつ、安定運用を狙うならスプリットDNSが有力です。URLの正解を思い出すだけでなく、仕組みまで押さえておくと、次に困ったときの復旧が格段に早くなります。
コメント