Proxy

皆さんこんにちは。胡田です。 いやー。久しぶりにほんのちょっとした当たり前の事でどハマリしてしまいました。しかも2度も。自戒を込めてこのエントリを書き残しておきたいと思います…。 事象例 複数の事象やそのバリエーションがあります。 - WinRMがホスト名では動作するが、FQDNでは動作しない。あるいはその逆。 - Windows Admin Centerにサーバーを追加する際に、ホスト名ではうまく動作するがFQDNでは動作しない。あるいはその逆。 - Test-ClusterがWinRMでの接続不可で失敗する。 - Enter-PSSession, Invoke-Command等がホスト名では動作するがFQDNでは動作しない。あるいはその逆。 チェックポイント winrmのリスナーがきちんと意図したとおりに登録されているか？ winrm enumerate winrm/config/Listener を実行し、リスナーの登録状況を確認し、意図する構成になっているかどうか確認します。 P L S i s C t : e A T P H E U C L \ n d r o o n R e i W e d a r s a L r s i r r n t t b P t t n e s n l r i e d s p = a e e f n o s o m d f i i w r 5 e i c n s = t 9 = x a g \ 8 t O s = 5 t = e n y r T s H u w h = t T e s u e T m m 1 m P a b 2 3 n p 7 2 r . > i 0 n . w t 0 i . n 1 r , m 1 e 7 n 2 u . m 1 e 7 r . a 1 t 1 e 2 . w 1 i 7 n 7 r , m / : c : o 1 n , f i f g e / 8 L 0 i : s : t f e c n 3 e 6 r : 5 d 9 e : 4 6 4 9 : c b d 5 % 5 例えば上記の例であればHTTPのリスナーのみが構成されています。HTTPSのリスナーは構成されていません。全てのIPアドレスで受け付けるように構成されています。ポート番号は5985です。 ...

前回の記と事を書いて、「続きはその2で」…と言いながら４年以上の月日が流れてしまいました。4年…あまりにも長い月日なので、結局当時のことはもう通用せず意味が失われ……てはまったくいないのが現在です。 今でもきちんとActive Directoryを理解することは難しいですし、そのなかでDNSの扱いの理解が難しいことも変わりません。そもそもちょっとたったら知識が陳腐化してしまうようなことはどうでもいいことですしね。 というわけで、4年以上の歳月をあけて「その２」です。 でも、随分間が空いてしまったので自分でも何をその２で書こうとしていたのかよく覚えておりませんが…、とりあえず前回予告したとおりいくつか典型的なパターンを挙げてみましょう。 社内のActive Directoryにはインターネットには絶対に存在しないドメイン名をわりあて、社外（インターネット）の名前解決はそもそも行わせないパターン まずはこのパターンから見ていきましょう。これは「Active Directoryが使うDNS」と「インターネットの世界のDNS」が完全に分離されているパターンです。 この場合には具体例としては「test.local」というようなドメイン名がActive Directoryの使うドメイン名として割り当てられることになります。 xxx.localというドメインはインターネット上には絶対に存在し得ないドメイン名です。なぜならトップレベルドメインにlocalというのは存在しないからです。今後追加される可能性がゼロでは無いものの、その場合にも「local」が選択される可能性はほぼ0と言ってよいでしょう。 そして、社外の名前解決はクライアントに対して行わせないパターンですので、社内のネットワークは全てインターネットの世界とはつながらず、切り離して考えることが出来ます。 つまり、社内のDNSの世界は完全にActive Directory用として切り離されています。そのなかでドメインコントローラーを探したり、同じドメイン内の他のホストを探したりという動きにはActive DirectoryのDNSが使われることになります。 技術的にはインターネット上のDNSと同じ技術が使われているが、社内の閉じた世界、Active Directoryの閉じた世界でのみ使用されているため混乱する要素がありません。 しいて言うならば、この場合にどうやってインターネットにアクセスできるのか?ということが疑問としてでるかなと思います。 これにかんしては、このような構成をあえてとっている場合には「インターネットには管理対象のクライアントは完全にアクセスさせない」という構成にする、というのがまず一つあります。 インターネットに繋がることが当たり前の今日においてこれは違和感があるかもしれませんが、セキュリティ対策を完全に行おうと思えばインターネットへのアクセスがどのような形であれ行えてしまえばもうなんでもありの世界ですから、インターネットへのアクセス自体を完全にブロックさせるというのは一つの考え方としてはありなわけです。 このケースにおいては、Active Directoryでは技術的にDNSを使っているけれども、ただ単に技術的に同じものが使われているだけであって、完全に切り離されている。ということで理解してもらえればと思います。 社内のActive Directoryにはインターネットには絶対に存在しないドメイン名をわりあて、社外（インターネット）の名前解決はそもそも行わせない…けれども、Web閲覧は許可する インターネットへのアクセスはセキュリティ面を考慮してさせたくない…けれども、やはり完全に隔離するのも不便すぎるので、Web閲覧のみは許可する、というパターンがあります。 この場合には、ブラウザの設定として、Proxyサーバーを設定し、Web閲覧のみProxyを経由することでインターネットにアクセス可能とします。もう少し正確に書くと、「Proxyサーバーに閲覧したいWebサイトのアドレスを伝えて、コンテンツを代わりに取ってきてもらい、結果のみProxyサーバーから受け取る」という事になります。 この場合、DNSを用いたインターネット上の名前解決を行っているのはProxyサーバーのみであり、クライアント自身はDNSを用いてインターネット上の名前解決をする必要はありません。 ですから、クライアントが参照しているのはローカルのActive Directoryのドメインコントローラーが持つDNSであり、Proxyサーバーが参照しているのはインターネットホスト名が解決できる(Active DirectoryのDNSではない)DNSということになります。 内部の(Active Directoryの)名前解決ができるDNSと外部の（インターネットの)名前解決ができるDNSを完全に分離してしまい、そこは連携させず、クライアント自体は内部のDNSを参照させて、インターネットの世界からは分離させ、ブラウザでWebサイトを見る時だけProxyにお願いすることで（直接クライアント自身ではインターネットにアクセスしないことで）このような構成を可能としています。 うーん。まだまだパターンはありますね。続きは「その3」で…。（いつになることやら。）

かなり久しぶりに自宅に仕事を持ち帰ってしまいました。Office365のExchange Online周りのトラブル対応のスクリプトを書いたり動作確認したりするためにRemote PowerShellで接続しようとした所エラーが…。 New-PSSession : [ps.outlook.com] リモート サーバー ps.outlook.com への接続に失敗し、次のエラー メッセージが返されました WinRM は処理を完了できません。 指定したコンピューター名が有効であること、コンピューターにネットワーク経由でアクセスで きること、および WinRM サービスのファイアウォールの例外が有効になっていてこのコンピューターからアクセスできることを確認 してください。 既定では、パブリック プロファイルの WinRM ファイウォールの例外によって、同一のローカル サブネット内のリ モート コンピューターへのアクセスは制限されます。詳細については、about_Remote_Troubleshooting のヘルプ トピックを参照し てください。 発生場所 行:1 文字:16 $O365Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUr … CategoryInfo : OpenError: (System.Manageme….RemoteRunspace:RemoteRunspace) [New-PSSession], PSRemotin gTransportException FullyQualifiedErrorId : WinRMOperationTimeout,PSSessionOpenFailed ネットワーク的にはきちんとInternetに接続できてますし、IEでもきちんと外部サイトが見られる状態。Proxyは無し。Windowsファイアウォールも無効の状態でした。なぜなのかわからずTwitterでつぶやいていたら@genkiwさんにポイントを教えてもらえました。ありがとうございました！ @ebi 接続先はポータルでしょうか、Exchange Onlineでしょうか？ Proxyの設定（IEとwinhttp）とかサインインモジュールが古いとか、 Set-ExecutionPolicy RemoteSignedが実施されてないとか。 — 渡辺 元気さん (@genkiw) 11月 7, 2012 結局、WinHttpの設定がproxyを使用する設定のままになっており、proxyが無い環境なのでps.outlook.comに到達できない状態でした。 Vista以降ではコマンドプロンプトにて「netsh winhttp show proxy」にて現在の設定の表示、「netsh winhttp import proxy ie」にてIEからの設定の取り込みが可能です。これできちんと接続できるようになりました。接続方法はこちら。 ...

今回は検証環境のネットワーク周りについて書きたいと思います。 検証時にやってはいけないこと 検証をする時には自由にサーバーを立てたりするわけですが以下のようなことをすると非常に大変なことになってしまいます。 - IPアドレスをバッティングさせてしまう きちんと通信できませんし、場合によってはもともと正しくそのIPアドレスを使っていた本来のホストが通信できなくなってしまうようなことにもなります。それが重要なサービスを行っているサーバーだったりすると……。 - DHCPサーバーを本番ネットワークで立ててしまう 検証用ネットワーク…のつもりで構成してあると、起動して間違ったDHCPサーバーからIPアドレスを受け取ってしまったホストがすべてきちんと通信できなくなります。私の所属する会社でも昔は新人が配属された直後に毎年のようにこの事故が起きてました…。 - ホスト名、ドメイン名をバッティングさせてしまう Windowsネットワークではホスト名やドメイン名は重複できません。特に同一セグメント内ではブロードキャストしてますので、ホスト名が重複しているというエラーが表示されちゃいます。同一セグメント内で同じドメイン名、特に同じBETBIOSドメイン名なんて作ってしまうとまともに動かなくなると思います。マニアックなところでは、ドメイン名と同じホスト名が存在してたりするとドメインに参加しているホストのすべてが起動するたびにホスト名の重複のエラーが表示されたりします。この時ホスト名同士が重複しているわけではないので原因を探すのにちょっと時間がかかったりします。 このようなことがありますので、検証用のネットワークはきちんと本番のネットワークから独立させようという話が出てきます。もちろん独立させるべきです。ただ、単純に独立させてしまうと今度は以下のような場面で不便です。 - Microsoft Updateを実行したいけどできない。 - 検証環境にファイルを持ち込んだり持ち出したりしたいけどできない。USBメモリ、UBS HDDは使用禁止だし…。 - 自分のPCからリモート接続できたら便利なのにできない…。 このようなことがあるので、検証環境を本番環境から安全に分離しつつ利便性を損なわない構成にしたくなります。 もっとも、セキュリティを最重視するのであればネットワークは完全に切り離されるべきですし不便であるべきです。部屋も別、携帯等の持ち込みも禁止……、というような環境もあります。私はそこまですると非効率すぎて逆に事故が増えるのではと思いますが…。 具体的な方法 いくつか具体的な対象方法を挙げてみます。 - 検証環境と本番環境の両方に接続するホストを作り、そのホスト上で必要なProxyを動作させる。ファイルの中継場所にする。 - 検証環境と本番環境の間にFWやNATを設け、必要な通信のみ行えるようにする。 - 検証環境からインターネットにアクセスする回線を別途設ける。 どれかひとつだけやればいいというわけでもなく、並行してやっても良いです。他にも色々なやり方があるとも思います。 また、検証環境が仮想環境上にある場合などはネットワーク的には完全に切り離しつつコンソールにアクセスすることが基本機能でできますね。最近はもうこういう環境の方が多いかもしれませんね。ただ、Hyper-Vのコンソールなどはコピペすらまともにできず酷いもんですが…。 よく使うソフト 私がよくつかうソフトを一応紹介しておきます。実はあまりよく調べて選んでいるわけではないのですが便利に使わせてもらっています。 DeleGate Home Page (www.delegate.org) Hyper-Vの物理ホストあたりにはProxyとしてDeleGateを仕込んでおくことが多いです。 BlackJumboDog ちょっとした検証の時にGUIでちょちょいっと設定して動かせちゃうので重宝します。Proxy以外にも色々なサーバーになれてしかもデバッグ表示が優れているので検証用途には重宝しています。

今回は「インターネット」ではなくて、「イントラネット」に繋がらないというケースについて書いてみます。 今、Active Directoryで構成されたWindowsネットワーク(ドメイン名sample.lcoal)があるとして、そこにintraという名前のメンバサーバーがあり、そこでイントラサイトが稼働しているとしましょう。このときのURLは何になるでしょうか? - http://intra/ - http://intra.sample.local/ さて、どちらが正解でしょうか? 正解は、「どちらも正解」です。 「なんだ、それは」と思うかもしれませんが、これがなかなか奥深い話もあったりします。たとえば1のhttp://intra/というアドレスを使っている場合。クライアントの設定によってはつながったりつながらなかったりします。繋がる場合でも、名前解決の方法が異なったりします。ちょっと詳しく見てみましょう。 名前解決の手段は何か? まず、http://intra/というURLですが、実際にはintraというホストのIPアドレスを知らなくてはいけません。最終的にはTCP/IPで接続するわけですから。 名前解決の手段としては様々なものがある、という話は以前しました。 - 参考：[NETBIOS名とホスト名の違い](https://windowsadmin.ebisuda.net/2009/02/10/netbios%e5%90%8d%e3%81%a8%e3%83%9b%e3%82%b9%e3%83%88%e5%90%8d%e3%81%ae%e9%81%95%e3%81%84/) この場合intraを名前解決する方法は以下のパターンがあるわけです。 - hostsファイル(ホスト名) - DNS(ホスト名) - lmhostsファイル(NETBIOS名) - WINS(NETBIOS名) - ブロードキャスト(NETBIOS名) で、厄介なのが2に関してです。 ドメインサフィックス DNSとして考えたときに「intra.」なんていうホスト名はあり得ないわけです。本来は「intra.sample.local」です。なので「intra」を裏で「intra.sample.local」に変更してくれている仕組みが存在するわけです。 マイネットワーク→プロパティ→(対象NIC)→プロパティ→インターネットプロトコル(TCP/IP)→プロパティ→詳細設定→DNSタブ (なんてわかりづらい所にあるんでしょう…) - 「プライマリおよび接続専用のDNSサフィックスを追加する」 - 「プライマリDNSサフィックスの親サフィックスを追加する」 - 「以下のDNSサフィックスを順に追加する」 - 「この接続のDNSサフィックス」 そしてもう一か所あります。 マイコンピュータ→プロパティ→コンピュータ名タブ→変更→詳細 (なんてわかりづらい所にあるんでしょう…) - 「このコンピューターのプライマリDNSサフィックス」 - 「ドメインのメンバシップが変更されるときにプライマリDNSサフィックスを変更する」 これらの設定が"仕組み"になります。 勝手にドメインサフィックスが追加される理由 通常は以下のような流れで、勝手に適切なドメインサフィックスが追加されるようになっています。 - Active Directoryに参加する - 「ドメインのメンバシップが変更されるときにプライマリDNSサフィックスを変更する」が既定で有効であるため、ドメイン名(sample.local)が「このコンピューターのプライマリDNSサフィックス」として設定される - DNSを使った「intra」の名前解決の際に「プライマリおよび接続専用のDNSサフィックスを追加する」および「プライマリDNSサフィックスの親サフィックスを追加する」が有効であるので「intra.」だけではなくて「intra.sample.local」も検索される うまくいかないケース ここまでの説明が理解できれば、http://intra/ではアクセスできないケースがあることが理解できるのではないかと思います。 具体的なケースを示します。まず前提として以下のケースで、 - hostsファイルに記載されていない - lmhostsファイルに記載されていない - WINSが構成されていない - 対象サーバーと同一サブネットに無い(ブロードキャストでの名前解決はできない) これらすべてに加えて、以下のどれかの条件に当てはまる時です。 ...

「インターネットに繋がらない」という事象をテーマにして以下2つのエントリを書きました。 「インターネットに繋がらない」 - 初級編 「インターネットに繋がらない」 - Proxy編 今回はVPN編です。 VPN接続の場合にはさらに話が複雑になります。VPN接続の場合には以下の4つのパターンが存在することになります。 VPN接続ではない直接接続しているネットワークを使って直接インターネットに接続 VPN接続ではない直接接続しているネットワーク上のProxyをつかってインターネットに接続 VPN接続先のネットワークを使って直接インターネットに接続 VPN接続先のネットワーク上のProxyを使ってインターネットに接続 Proxyの設定をしていないときに1の経路になるのか、3の経路になるのかは、VPNの設定上でコントロールをします。 ここの「リモートネットワークでデフォルトゲートウェイを使う」というチェックボックスがまず1つ目のポイントです。 チェックが入っていなければ直接接続されているネットワークから別ネットワークにアクセスする(パターン1) チェックが入っていればVPN接続先のネットワークから別ネットワークにアクセスする(パターン3) もちろんどちらの場合にも「初級編」で解説した内容が当てはまりますが、1点注意点として、VPN接続時の参照DNSはVPN接続先のDNS設定よりも直接接続されているネットワーク上の設定が優先されるようです。(手元のWindowsXP SP3で確認) 次に、IEの中に「ダイアルアップと仮想プライベートネットワークの設定」という項目があります。 この中に「プロキシサーバー」の設定があります。ここが2つ目のポイントです。VPN接続先のProxyサーバーを使うにはここの部分にProxyの設定を入力する必要があります。ここに設定がなされていればパターン4になるわけです。 直接インターネット接続に出る経路とVPN経由の経路とであまりスピードが変わらないような場合には問題にならないかもしれませんが、特にダイアルアップ接続など帯域が細い経路が存在している場合には、きちんと帯域の太い経路からインターネットアクセスを行わせるように構成することが重要ですね。

「インターネットに繋がらない」 - 初級編では直接、インターネットに接続されている環境での処理の流れを見てもらいました。今度は別のバリエーションとして、直接はインターネットに接続されておらず、Proxyを経由してインターネット上のWebサイトを閲覧するようなケースを考えてみます。 一般家庭でProxyを利用しているようなケースは極稀でしょうけれども、企業では様々な理由からProxyを利用しないとWebサイトの閲覧ができないように構成していることもあります。特にセキュリティに気を使っている企業ではProxyの利用は当たり前です。あとは、サイトを閲覧する際に実IPを隠すためにあえてProxyを利用するようなケースもあるかとは思いますが今回はそのあたりに関しては扱いません。例の如く別エントリにて解説予定です…。 Proxy接続の場合には通常の直接インターネットへ接続(Webサイトの閲覧)をする場合と比較すると以下のようなプロセスの違いがあります。 直接 Proxy経由 1．PCが起動する 2．有線または無線にてEthernetに接続する 3．固定またはDHCPにてTCP/IPの設定がなされる 4．ブラウザにてURLが指定される 1．PCが起動する 2．有線または無線にてEthernetに接続する 3．固定またはDHCPにてTCP/IPの設定がなされる 4．ブラウザにてURLが指定される 5．DNSにホスト名に対応するIPアドレスを問い合わせ、回答を得る 6．該当のWeb Serverに接続する 7．Web Serverからコンテンツを得る 8．ブラウザにコンテンツを表示する 5．Proxyサーバーに接続する 6．Proxyサーバーからコンテンツを得る 7．ブラウザにコンテンツを表示する 大きな違いは以下の2点です。 DNSを使用した”名前解決”を実行しない(必要ない) 接続するのは常にProxyサーバー Proxyサーバーを利用する場合には、Proxyサーバーに実際のコンテンツの取得をお願いする形になります。つまりProxyサーバーは「直接」の場合の5,6,7の動作を行い、その結果をPCに渡してくれるわけです。 トラブルシュートの方法 トラブルシュートとしては、Proxyサーバーの設定およびProxyサーバーへの接続があります。 Internet Explorerの場合には「ツール」→「インターネットオプション」→「接続」タブ→「LANの設定」からProxyの設定を行います。 Proxyへの接続がきちんとできているかを確かめるには、「telnet Proxyサーバー ポート番号」を実行するとよいでしょう。コマンドを実行して、画面が真っ暗になれば接続できています。 「ローカルアドレスにはプロキシサーバーを使用しない」の意味 Proxy環境の場合によく問題になるのは「ローカルアドレス」という言葉の意味です。普通に「ローカルアドレス」と聞くと同一セグメントのIPアドレスなり、プライベートアドレスなりといったものを連想すると思いますが、これはそういう意味ではなくて「名前に.(ドット)が含まれていないもの」という意味になっています。通常WindowsネットワークではPC名のみで近くのサーバーへの接続(名前解決)ができるため、このような判断基準になっているのだろうと思います。 具体例をあげましょう。Proxyサーバーを利用し、かつ「ローカルアドレスにはプロキシサーバーを使用しない」のチェックが入っているとします。 pcname(ホスト名) pcname.test.local(FQDN) 192.168.1.1 上記の3つが全く同じホストを指している場合、1はホストに対して直接のアクセス、2と3はProxyサーバー経由のアクセスということになります。単純に.(ドット)が含まれているかどうかが判断基準です。 よく2や3の場合でも同じサブネットなんだからProxyサーバー経由ではなく直接接続してくれると勘違いしてしまうケースがあるので、きをつけてください。 2や3の入力方法でも直接接続させたい場合には除外設定を行えばよいです。 そもそもProxy接続をしなければいけないことをどのように知るのか Proxy接続が必要な環境であること自体を知る、あるいは直接接続はできないと判断するにはどうすればいいでしょうか。これはDNSの確認とHTTPポートでの接続の可否で判断できます。 外部のホスト名の名前解決ができるか まず、DNSに関して。DHCPなり固定IPなりできちんとしたDNSを割り振られていることを前提とします。この状態でnslookupにて外部ホストの名前解決ができるかどうかを確認します。 上記のように名前解決ができるようであれば、自らWebサイトへの接続が試行できるので、Proxyは必要ない環境の可能性が高いです。逆にここで名前解決ができないようであればProxyが必須の環境であるということがわかります。あるいは完全にインターネット上のホストへのアクセスができないか、です。 外部のホストに接続できるか 名前解決ができる環境であれば直接Webサイトへの試行を行うことができます。Webサーバーへの接続はtelnetでHTTPポートへの接続で試すことができます。 名前解決ができても外部ホストに接続できない場合や逆に名前解決ができなくても外部ホストに接続ができる場合などもあり得ます。ですが基本的には両方うまくいかなければProxy接続が必要な環境だ、ということがいえます。 Proxyの設定に関する注意点 ちなみにWindows上のアプリケーションの場合にはインターネットアクセスの際にIEのProxyの設定を参照するものも結構あるので注意が必要です。特に規定のブラウザをIE以外のブラウザに変更しているときには注意が必要です。IEのProxy設定にも設定を入れておきましょう。 また、サービスで動作しているプロセスがProxy設定を必要とするケースがあります。この場合には該当アカウントのプロファイル上でIEのProxy設定を行う必要があるものもあるので注意が必要です。 さらに、IEのProxyを見ないでWinHTTPの設定を見るアプリケーションもあります。さらにはIEでアクセスするくせにWinHTTPの設定を見るようなものも存在していますので(Microsoft Update等)、proxycfgコマンドでの設定が必要なケースもあります。このあたりには注意が必要です。 参考：How the Windows Update client determines which proxy server to use to connect to the Windows Update Web site ...