DNS

シリーズ記事の11個目です。M365フルクラウド環境を検証目的で構築しています。下記の記事も合わせてどうぞ！ Windows10をAzure ADに参加させる！【M365フルクラウド環境検証 その1】 | Microsoft Cloud Administrators- Azure ADにドメインを追加してユーザーIDをわかりやすくする！【M365フルクラウド環境検証 その2】 | Microsoft Cloud Administrators- M365 E5検証ライセンスを申し込む【M365フルクラウド環境検証 その3】 | Microsoft Cloud Administrators- Intuneへの登録を行う【M365フルクラウド環境検証 その4】 | Microsoft Cloud Administrators- Windows10のデバイス構成プロファイルを作成して割り当てる！BitLockerでディスク暗号化【M365フルクラウド環境検証 その5】 | Microsoft Cloud Administrators- コンプライアンスポリシーを作成して割り当てる！【M365フルクラウド環境検証 その6】 | Microsoft Cloud Administrators- 「条件付きアクセス」で「ベースラインポリシー」を設定する！【M365フルクラウド環境検証 その7】 | Microsoft Cloud Administrators- 条件付きアクセスポリシーを設定してMFAとポリシー準拠デバイスを必須とする！【M365フルクラウド環境検証 その8】 | Microsoft Cloud Administrators- Microsoft Defender ATPを実装する！【M365フルクラウド環境検証 その9】 | Microsoft Cloud Administrators- Office Pro PlusをIntuneから配布する！【M365フルクラウド検証環境 その10】 | Microsoft Cloud Administrators ここまで触れていなかったのですが、読者の方から「Exchange Onlineで使うドメインの設定はどうなっているか?既存のメールシステムとの関係はどうなっているのか？」という質問を頂きました。ここまでの記事の内容と同じことを自分の環境で行ったときに、メール配送はどうなっているのか?という話ですね。 というわけで今回はExchange Online側の話を少し確認します。 Exchange Onlineの「ドメイン」設定 下記の図はAzure ADにドメインを追加してユーザーIDをわかりやすくする！【M365フルクラウド環境検証 その2】 | Microsoft Cloud Administratorsの記事の操作でAADにドメインを追加し、規定のドメインとしたときの、Exchange管理センターの状態です。 ...

前回の記事( Windows10をAzure ADに参加させる！【M365フルクラウド環境検証 その1】 | Microsoft Cloud Administrators )ではAADにWin10をAAD Joinさせて、AAD上のIDで直接Win10にサインインができるようにしました。 Win10で直接、職場または学校アカウントでサインイン これはこれで素敵なのですが、AADの規定のドメイン名は「xxxxxxxxx.onmicrosoft.com」という形式であり、ちょっと長いですし、やはり企業用途であれば独自ドメインを使いたいですよね。そうすればユーザーもわかりやすく短いユーザーIDを使ってWin10にログインすることも可能になります。 ということで今回はAADにドメインを追加してユーザーIDを変更してみます。このときに既存のユーザーおよびユーザープロファイル上のファイル等に影響が出るのか、出ないのかも確認します。 現状確認 まず、現状を確認しておきましょう。 初期状態でローカルにユーザーが1つあり、その状態からAADに参加し、AAD上のユーザーで一度サインインした状態のWin10があります。 もちろんローカルユーザーはビルトインのユーザー群と当初に作成した1ユーザーのみであり、AADのユーザーは表示されていません。 ログインしているユーザーはAzure AD上のユーザーです。 環境変数を確認してみます。 C : \ U s e r s \ m e b i s u d a > s e t A L L U S E R S P R O F I L E = C : \ P r o g r a m D a t a A P P D A T A = C : \ U s e r s \ m e b i s u d a \ A p p D a t a \ R o a m i n g a s l . l o g = D e s t i n a t i o n = f i l e C o m m o n P r o g r a m F i l e s = C : \ P r o g r a m F i l e s \ C o m m o n F i l e s C o m m o n P r o g r a m F i l e s ( x 8 6 ) = C : \ P r o g r a m F i l e s ( x 8 6 ) \ C o m m o n F i l e s C o m m o n P r o g r a m W 6 4 3 2 = C : \ P r o g r a m F i l e s \ C o m m o n F i l e s C O M P U T E R N A M E = D E S K T O P - 7 J O 0 T J G C o m S p e c = C : \ W I N D O W S \ s y s t e m 3 2 \ c m d . e x e D r i v e r D a t a = C : \ W i n d o w s \ S y s t e m 3 2 \ D r i v e r s \ D r i v e r D a t a F P S _ B R O W S E R _ A P P _ P R O F I L E _ S T R I N G = I n t e r n e t E x p l o r e r F P S _ B R O W S E R _ U S E R _ P R O F I L E _ S T R I N G = D e f a u l t H O M E D R I V E = C : H O M E P A T H = \ U s e r s \ m e b i s u d a L O C A L A P P D A T A = C : \ U s e r s \ m e b i s u d a \ A p p D a t a \ L o c a l L O G O N S E R V E R = \ D E S K T O P - 7 J O 0 T J G N U M B E R _ O F _ P R O C E S S O R S = 4 O n e D r i v e = C : \ U s e r s \ m e b i s u d a \ O n e D r i v e O S = W i n d o w s _ N T P a t h = C : \ P r o g r a m F i l e s ( x 8 6 ) \ C o m m o n F i l e s \ O r a c l e \ J a v a \ j a v a p a t h ; C : \ W I N D O W S \ s y s t e m 3 2 ; C : \ W I N D O W S ; C : \ W I N D O W S \ S y s t e m 3 2 \ W b e m ; C : \ W I N D O W S \ S y s t e m 3 2 \ W i n d o w s P o w e r S h e l l \ v 1 . 0 \ ; C : \ W I N D O W S \ S y s t e m 3 2 \ O p e n S S H \ ; C : \ P r o g r a m F i l e s \ I n t e l \ W i F i \ b i n \ ; C : \ P r o g r a m F i l e s \ C o m m o n F i l e s \ I n t e l \ W i r e l e s s C o m m o n \ ; C : \ P r o g r a m F i l e s \ T o r t o i s e G i t \ b i n ; C : \ P r o g r a m F i l e s \ G i t \ c m d ; C : \ U s e r s \ m e b i s u d a \ A p p D a t a \ L o c a l \ M i c r o s o f t \ W i n d o w s A p p s P A T H E X T = . C O M ; . E X E ; . B A T ; . C M D ; . V B S ; . V B E ; . J S ; . J S E ; . W S F ; . W S H ; . M S C P R O C E S S O R _ A R C H I T E C T U R E = A M D 6 4 P R O C E S S O R _ I D E N T I F I E R = I n t e l 6 4 F a m i l y 6 M o d e l 6 9 S t e p p i n g 1 , G e n u i n e I n t e l P R O C E S S O R _ L E V E L = 6 P R O C E S S O R _ R E V I S I O N = 4 5 0 1 P r o g r a m D a t a = C : \ P r o g r a m D a t a P r o g r a m F i l e s = C : \ P r o g r a m F i l e s P r o g r a m F i l e s ( x 8 6 ) = C : \ P r o g r a m F i l e s ( x 8 6 ) P r o g r a m W 6 4 3 2 = C : \ P r o g r a m F i l e s P R O M P T = $ P $ G P S M o d u l e P a t h = % P r o g r a m F i l e s % \ W i n d o w s P o w e r S h e l l \ M o d u l e s ; C : \ W I N D O W S \ s y s t e m 3 2 \ W i n d o w s P o w e r S h e l l \ v 1 . 0 \ M o d u l e s P U B L I C = C : \ U s e r s \ P u b l i c S E S S I O N N A M E = C o n s o l e S y s t e m D r i v e = C : S y s t e m R o o t = C : \ W I N D O W S T E M P = C : \ U s e r s \ m e b i s u d a \ A p p D a t a \ L o c a l \ T e m p T M P = C : \ U s e r s \ m e b i s u d a \ A p p D a t a \ L o c a l \ T e m p U S E R D O M A I N = A z u r e A D U S E R D O M A I N _ R O A M I N G P R O F I L E = A z u r e A D U S E R N A M E = m e b i s u d a U S E R P R O F I L E = C : \ U s e r s \ m e b i s u d a w i n d i r = C : \ W I N D O W S きちんとユーザーのドメインはAzureADと表示されていますね。さらに、プロファイルはC:\Users\mebisuda にセットされています。 ...

前回の記と事を書いて、「続きはその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」で…。（いつになることやら。）

IPアドレスの変更に伴い、DNSの静的エントリ(Aレコード)を手動で変更したにもかかわらず、しばらく時間がたつと古いアドレスに戻ってしまう…という現象がありました。 現象が発生していたのはドメインコントローラー兼、DNSサーバーでした。もちろんOSとしては新しいIPアドレスに設定されており、動作もDNSレコードを手動で書き換えた直後は問題なし。原因がわからなくて結構悩んでしまったのですが結局DNSサーバーに対してDNSに登録するサービスを固定的に指定しており(HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters\PublishAddresses )、そのIPアドレスを変更していなかったのが原因でした。 - [接続のアドレスを DNS に登録しないように設定しても、ホストの A レコードが登録される](http://support.microsoft.com/kb/275554/ja) 複数のNICをもつシステムだったこともあり、クライアントからアクセスできないIPアドレスがDNSサーバーに登録されてしまうことを防ぐために行った設定がきちんと把握、変更されていなかったということになります。検証環境で緩く運用されており、きちんと構成管理していないような環境だとこの手の細かい設定を後追いで確認するのはなかなか手間ですね…。

今回はActive DirectoryとDNSについての話をしてみようと思います。Windowsネットワークを構築する上ではある程度の規模以上ではActive Directoryの構築、理解は事実上必須となり、Active Directoryを構築する上ではDNSの利用が必須になります。そしてDNS周りの設計が一番技術的に難易度が高く理解が難しいところです。ひとつずつ解説してみたいと思います。 Active DirectoryにはなぜDNSが必要なのか Active DirectoryにはDNSが必須です。DNSがないときちんと動きません。これはなぜかというと、端的には「DNSをつかってドメインコントローラーを探すから」ということになります。ただ、「DNSを使ってドメインコントローラーを探す」と言われてもピンと来ないかもしれません。イメージを持ってもらうために実際のDNSレコードを覗いてみましょう。 以下はad.localというシングルフォレストシングルドメイン環境に、dc01.test.local, dc02.test.localという2台のDCが存在している状況です。バージョンはWindows Server 2022ですが、Windows Server 2003以降であれば基本的に同じ構造になっているはずです。 _msdcs.ad.localというゾーンにdc01, dc02のGUIDがCNAMEで登録されています。 展開していくと、サイト名にひもづくようなレコードがありSRVレコードにdc01, dc02の値が見えます。 違う場所にも同じようなレコードがあります。 以下同様にまだまだたくさんあります。 pdcのところにはdc01だけしか無かったりします。これはPDCエミュレーターというFSMOの役割を持っているのは(この場合はdc01という)単一のサーバーだけだからです。 _msdcs.test.localゾーンではないtest.localゾーンにも同じようなレコードがあることが確認できます。 本筋からずれてしまうので、ここで個々のレコードの意味を説明することはしませんが、見てもらったようにDNSの中に一定のルールに従ってSRVレコードが作成されていることがわかります。クライアントはこれらのレコードを参照しながらActiveDirectory環境で動作します。そしてドメインコントローラー同士もDNSのレコードを参照してお互いに通信したりします。DNSがないとドメインに参加もできないし、ドメインにログオンもできないほどDNSはActiveDirectory内で大切なサービスです。 インターネットのDNSとActiveDirectoryのDNSの関係について ところでDNSと言えばまず思いつくのはActiveDirectory用のDNS…よりも先にインターネットで使われているDNSが思いつくと思います。世界中にある無数のホストの名前解決を行ってくれている階層、分散管理のシステムです。 Domain Name System - Wikipedia このDNSとActiveDirectoryで使われるDNSとは同じものなのか、違うものなのか?このあたりは中々複雑な状況があります。 ActiveDirectoryが登場する前からインターネットは存在し、そのなかでDNSは使われていました。- ActiveDirectoryは名前解決の仕組みとしてインターネットという大規模システムで使われてもうまく動作しているDNSという仕組みを採用しました。- マイクロソフト実装のDNS(以降MSDNSと書きます)をインターネット上のDNSとして構成することも(やれば)できます。- インターネット上のDNSとして多く使われているBINDをActiveDirectory用のDNSとして構成することも(やれば)できます。 ここまではまぁよいかと思います。MSも独自のDNS実装を作ったけれども、BINDであろうとMSDNSであろうとDNSはDNSなのでどのような用途にも構成すれば使えますよ、ということです。 難しくなってしまうのは以下のあたりの要素があるからです。 インターネット上のドメイン名と同じドメイン名(たとえばgoogle.comドメイン)をActiveDirectoryのドメイン名にすることができてしまいます。(ただし通常これはやらない方がいいです。)- インターネット上のDNSをそのままActiveDirectoryのドメイン名とし、インターネット上にすべて公開することができてしまいます。(ただし、これは絶対にやらない方がいいです。)- ActiveDirectoryのDNSはインターネットの世界とは完全に切り離して構成することが可能です。(これは推奨される構成です。)- ActiveDirectoryのDNSはインターネットの世界とは切り離して構成しつつ、それでもインターネット上のホストの名前解決をActiveDirectoryに参加しているクライアントにさせたい場合には、ActiveDirectoryのDNSがインターネット上のホストの名前解決を可能となるように構成可能です。(これはしばしば行われる構成です。) さらに混乱に拍車をかけるのは、ActiveDirectory以外にそもそも社内に独自のDNSの空間があって、そこに対してActiveDirectoryを追加するようなケースです。 既存DNSの名前解決をActiveDirectoryのDNSにもさせたい。- 既存DNSの名前解決をActiveDirectoryのDNSにはさせたくない。- 既存DNSの名前解決をActiveDirectoryのDNSにもさせつつ、インターネット上のホストの名前解決もできるようにしたい。- 既存DNSの名前解決をActiveDirectoryのDNSにはさせたくないが、インターネット上のホストの名前解決はできるようにしたい。- 既存DNSに問い合わせた場合にもActiveDirectory上のホストの名前解決はさせたい。- 既存DNSに問い合わせた場合にはActiveDirectory上のホストの名前解決はさせたくない。 まだまだバリエーションは増やそうと思えば増やせますね。 さらにここで社内の独自のDNSの名前空間がインターネット上のドメイン名と重複しているような場合…さらに混乱できる構成となってしまいます…。私も新人で、「DNSってインターネットの世界で名前解決に使うやつでしょ?」という認識だったころにこのあたりの話を聞いて大混乱したのをよく覚えています。ただ、実際のところ取りうる組み合わせは多数ありますが、実際にお勧めできる設計のパターンとしてはそんなに多くないのでそれらをこれから具体的に説明してみたいと思います。 長くなってしまったので、続きは「Active DirectoryとDNSについて その2」で。 Active DirectoryとDNSについて その2 | Windowsインフラ管理者への道 (ebisuda.net)

このエントリでは典型的なWindowsクライアント、Windowsサーバーのトラブルシューティング時の確認ポイントやよくある問題についてまとめてみようと思います。 ログ確認 - イベントログ アプリケーション - システム - (監査)※監査ログを追う機会は比較的少ない - アプリケーションのログ デバッグモード、診断ログ的なものがあれば有効にする - 循環したり、切り捨てられるものが多いのですぐに回収する ダンプ - ダンプファイル確認 再現 - 再現性の有無を確認する - 再現手順を探す 設定差異 - 問題が発生する状況を確認する(問題発生時と未発生時) 端末 - ユーザー - OSバージョン - SPバージョン - 修正パッチ - ブラウザ(違うブラウザでの切り分け) - 導入ソフトウェア、アドオン 特にウイルス対策ソフトウェア(無効、除外による切り分け) - ログオンDC - ログオンサイト - ドメイン - ネットワーク設定 SNP - GW - DNS - NetBIOS over TCP/IP - WINS - IPv6 - コンポーネント - Windows FireWall パフォーマンス確認 - CPU - メモリ - ディスク - リーク メモリーリーク - ハンドルリーク 環境確認 - ネットワークトラフィック ブラックホールルーター問題 - SNP - ジャンボフレーム - DC複製状況 repadmin - GPO適用状況 gpresult - VSS動作状況 vssadmin list writers 問題発生時の動作確認 - ProcessMonitor - TCPコネクション状態 TCPポート枯渇 - パケットキャプチャ ...

今回は独自ドメインの取得についての話です。Webサイトを立ち上げるにしても、メールを利用するにしても必ず必要になってくる話です。 企業であれば独自ドメインを取得しないということはほぼ考えられませんので、ここではサーバー管理者を目指す人が個人のスキルアップ、あるいは個人の趣味のためにドメインの取得を行うべきかどうかを考えてみます。 ### ドメイン取得のメリット まず、独自ドメイン自体を取得するメリットについて考えてみます。 - サイト、メールアドレスについて覚えてもらいやすいものを利用することが出来る。 - ドメインを取得しておけば、そのインフラを乗り換えた場合(プロバイダの変更、レンタルサーバー業者の変更、クラウドへの移行等)でも、利用者にそれを気づかせないことが出来る。特に、Webサイトに外部からリンクを貼ってもらった場合にそれを有効に保つことが出来る。 ### ドメイン取得のデメリット - 費用がかかる - DNSサーバーの用意、管理が必要(ただしDNSサーバー自体をレンタル可能なサービスもある) - 固定IP前提のものも多いため、その費用も必要となる事が多い ### 費用について ドメインの取得には費用がかかります。ドメイン名の取得については、ドメイン名取得サービス業者を利用する事がほとんどです。例えば、ドメイン取得代行業者として有名なお名前.comの取得費用、更新費用はこちらにあります。 - [ドメイン取るなら お名前.com：料金一覧](http://www.onamae.com/service/d-price/) これをみると、ドメインによってかなりの金額の違いがありますが、月あたりの費用としては100円未満のものから高くても1000円程度と、たいした金額では無い事がわかります。 ドメイン名を取得するメリット、取得しない場合のデメリットを比較した場合に、企業であれば独自ドメイン名を取得しない理由はほぼ無いと言えるでしょう。 個人でもこの程度であれば払おうという人も多いとは思います。 ダイナミックDNSサービス 個人の勉強のためであれば、特に独自ドメインを取得せずとも、自宅にサーバーを立ち上げる際に、ダイナミックDNSサービスを利用者するという選択肢もあります。これであれば、費用を全くかけないことも可能です。 ダイナミックDNSサービスには以下のようなものがあります。 - [DynDNS.com - Free Domain Name, Managed DNS, Email Services](http://www.dyndns.com/) - [Dynamic DO!.jp - ダイナミックDNS -](http://ddo.jp/) - [無料ダイナミックDNS(DDNS)サービス - ieServer.Net](http://ieserver.net/) これらは、ドメイン名こそは決められたものしか利用できませんんが、その中でホスト名を自由に選択でき、そのレコードに対してのIPアドレスを任意で設定できます。 これを使えば、固定IPを持っていない普通のインターネットプロバイダの普通のプランでも、サーバーを立ち上げたうえで、ホスト名でのアクセスが可能となります。追加費用無しで簡単にサーバーを立ち上げるにはこの方法が1番簡単です。 ちなみに、このようなダイナミックDNSの仕組みを提供している、ドメイン名取得業者も存在します。 私の場合 実は、このサイト自体もアドレスバーのホスト名をみてもらえばわかるとおり、dyndns.comの無料サービスを使っています。使い始めてもう9年ほどになります。(dyndns.comさんありがとう。) インターネットの契約プランも固定IPのものではないごく一般的なものです。特に追加費用もかけずに、サーバー用のPCを1台用意するだけで、Webサーバーをはじめとした様々なサーバーを立ち上げています。(この部分すら無料で済ませることも可能です。) 個人の勉強であれば、費用もかからず、お手軽なこの方法を私はおすすめします。ただ、この方法のリスクとしては、「利用しているサービスが終了してしまった場合に影響が大きい」というものがあります。 無料サービスを利用するリスク 無料サービスを利用する場合、もちろん自分が取得したドメイン名ではないので、そのサービスが終了してしまうと、そのドメイン名を使い続けることができない可能性が非常に高いです。 この場合、外部からリンクをを貼ってくれているサイトのすべてに連絡くしてリンクをを書き換えてもらうわけにも行かないでしょうから、過去の外部からのリンクをかなりの部分で諦める必要が出てきてしまいます。これにより、検索エンジンからの評価がかなり低くなることは避けられません。また、新しいドメイン名に変更になることで、検索エンジンからの使用期間に応じた評価も低くなります(検索エンジンは長く使われているドメインを高く評価します)。 このように、サイトに対して集客をしたい、特にこれにより、検索エンジンからの評価がかなり低くなることは避けられません。また、新しいドメイン名に変更になることで、検索エンジンからの使用期間に応じた評価も低くなります(検索エンジンは長く使われているドメインを高く評価します)。 このように、サイトに対して集客をしたい、特に何か収益を上げるようなことをしたい場合にはリスクを避けるためにはじめから独自ドメイン名を取得しておくと良いと思います。

今回はマルチホーム構成時の注意点についてです。マルチホームというのは要するにNICが2つ以上あって、複数のネットワークに足を出している状態のことです。結構な頻度でマルチホーム構成を選択し、やってはいけない構成でトラブルに遭遇するケースを見ています。しっかり抑えておきましょう。 デフォルトゲートウェイは1つだけ まず、一番初めに理解してほしいのは「デフォルトゲートウェイを2つ以上設定してはいけない」ということです。よく理解していない人は多くのケースで2つNICがあったら2つゲートウェイを設定してしまうようです。 でも、ちょっとよく考えてみてください。デフォルトゲートウェイというのは、自分が所属していないネットワークに向かって通信するときにパケットを投げる相手ですよね?それが2つ設定されていたら、どっちに投げたらいいんでしょう?困ってしまいますよね? どっちに投げてもきちんと相手まで届く構成であれば問題がおきないこともあるでしょうけれども、やはりこれはよくない構成です。場合によっては通信できないことになるでしょう。 - デフォルトゲートウェイは1つだけ設定する(1つのNICだけで入力し、ほかのNICでは空白にしておく) - 必要な経路に関してはスタティックルートを記述する このようにしておかなくてはいけません。 スタティックルートを記述 スタティックルートの記述･･･といってピンとこない方も多いかもしれませんね。基本的にNICが1つであれば必要ない設定ですから。でも2つ以上になったら、「このネットワークアドレスに向けての通信は、こっちの足からあのルーターに投げる」ということをしっかりと記述してあげる必要があります。 Windowsではこの設定は「route」コマンドで実施できます。経路の追加はroute addコマンドです。コマンドの説明は例のごとく@ITにお願いしちゃいます。 - [route - ルーティングテーブルの表示／設定を行う](http://www.atmarkit.co.jp/fnetwork/netcom/route/route.html) 注意点としては、再起動しても消えないように設定するには-pオプションをつける必要があることです。route printコマンドで経路情報を表示した際に、きちんと追加した経路が「Persistent Routes」として表示されることを確認しておきましょう。そうでないと、うまくいったと思っていたら1月くらいたって再起動したらまたおかしくなったなんていうことになってしまいます。 DNSを2つ以上設定しない またデフォルトゲートウェイの次に気をつけてたいのはDNSの設定です。特にInternet側とIntranet側なんていうようにNICが分かれていた場合、Internet側のNICにはインターネットの名前解決ができるDNSを、Intranet側のNICには社内のDNSを設定したくなる人も多いかと思います。 でも、よく考えてみてほしいのですが、両方に問い合わせるわけにはいきませんよね。もしも両方のDNSに同じドメインが存在したりしていたうえに異なるレコードが登録されているような場合には(これはありえないことではありません)、通信しようとするたびに名前解決の結果が異なるようなことにもなってしまいます。これはやはりだめです。 DNSに関してはどれが正解ということはないです。そのホストの必要に応じて、正しいDNSを参照させる必要があります。「両方のDNSを参照したい」と思ってしまうのなら、それはDNSの設計、構成が間違っている可能性があります。場合によってはhostsファイルを併用してもいいでしょう。 DNSへの登録に気をつける マルチホームの場合にはDNSへの登録にも気をつけてください。特に何も考えないと、ホストについている2つ以上のIPアドレスをすべて登録して、ラウンドロビンになってしまいます。特にDCでこれをやってしまうとかなりクリティカルな障害にもつながってしまいますので、特に気をつけてください。 DCに関してはマルチホーム時のマスタブラウザの問題もあるのでそもそもマルチホームにしないほうが良いです。でも、それでもどうしてもDCをマルチホームにしたいのであれば、Aレコードの自動登録をやめさせる必要があります。DCはNetlogonサービスが定期的に自身のDCとして動作するためのレコードをDNSに定期的に登録に行くようになっているからです。このあたりの手順は以下のKBを参考にしてください。 - [Active Directory communication fails on multihomed domain controllers](http://support.microsoft.com/?scid=kb%3Ben-us%3B272294&x=7&y=17) その他まだまだありますが･･･ 今回紹介したこと意外にもマルチホーム構成の時の注意点は色々あります。特にDMZとLANに足をだしていて、DMZ側のIPでサービスを提供しているようなときに、入力と出力で使うNICが異なるようになってしまったりとか･･･。2つ経路があるときに意図的に片方のネットワークを使わせようと思ってもうまくいかなかったりとか･･･。バックアップ専用のネットワークを作ろうとしたりするときとか･･･。 このあたりはちょっと複雑になりすぎるので、また機会を改めて解説させてもらおうと思います。とりあえず今回紹介した注意事項が基本中の基本ですので、まずはここから気をつけていってみていただければと思います。 参考URL - [マルチホーム コンピュータのデフォルト ゲートウェイ設定](http://support.microsoft.com/kb/157025/ja) - [[NT]同一ネットワークに複数のアダプタを接続した場合の障害](http://support.microsoft.com/kb/175767/) - [マルチホーム化されたブラウザに関する問題](http://support.microsoft.com/kb/191611/ja)

メール送信の仕組みを知りたい方はこの記事をどうぞ。コマンドプロンプト、バッチファイル等から自動的にメールを送信したい方はこちらをどうぞ。 今回は電子メールのお話です。メールはインターネット経由で世界中と送受信できるすばらしい仕組みなのですが、基本的な仕組みはかなりシンプルになっています。それを実感するために、メールクライアントを使用せずに、コマンドプロンプトだけでメールを送信してみましょう。仕組みを体感できますし、トラブルシュートの際にも有効に使えますよ。 ここでは、例として私のgmailのアドレスであるebibibi@gmail.comにメールを送ってみようと思います。(自分のメールアドレスで実験してみてください) メールサーバーを探す まずはじめにメールサーバーを探します。メールをどこに送ればとどくか、ということですね。これはDNSにMXレコードとして記述されています。 「set type=mx」として、MXレコードを指定した上で「gmail.com」というドメインのMXレコードを検索します。 コマンドの実行結果から以下の5台のメールサーバーが存在していることがわかりました。 - gmail-smtp-in.l.google.com - alt1.gmail-smtp-in.l.google.com - alt2.gmail-smtp-in.l.google.com - alt3.gmail-smtp-in.l.google.com - alt4.gmail-smtp-in.l.google.com どのサーバーに送信してもメールは届くはずですが、MX preferenceの値が低いものほど優先的に送信するという決まりになっていますので、ここではMX preferenceがいちばん低い5になっている「gmail-smtp-in.l.google.com」にメールを送ることにします。 メールサーバーへの接続 メールサーバーにメールを送信するにはまずTCPのコネクションを張らなくてはいけません。ポートはSMTPプロトコルの25番ポートです。 telnetコマンドで25番ポートに接続します。 SMTPでのメール送信 接続できたらSMTPプロトコルでメールを送信します。SMTPプロトコルは人間が手でメールを送れるくらいシンプルなものです。 以下の例はRFC的に正しくない部分も含まれていますが、メールの送信自体はできます。まずはまねをして体感してみてください。 以下のようにきちんとgmailに届きました。 SMTPプロトコルの詳細はRFCで定義されていますので、興味がある人は見てみるとよいでしょう。 - http://www.ietf.org/rfc/rfc2821.txt かんたんな説明 やり取りの中身をもう少し詳しく見てみます。 まず接続すると相手のSMTPサーバーのバナーが表示されます。 2 2 0 m x . g o o g l e . c o m E S M T P 5 s i 1 0 3 9 1 9 7 8 y w l . 2 8 次にこちらから相手のサーバーに挨拶をします。 ...

今回は「インターネット」ではなくて、「イントラネット」に繋がらないというケースについて書いてみます。 今、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が構成されていない - 対象サーバーと同一サブネットに無い(ブロードキャストでの名前解決はできない) これらすべてに加えて、以下のどれかの条件に当てはまる時です。 ...

今回は「NETBIOS名」と「ホスト名」について解説します。「NETBIOS名」と「ホスト名」が混ざってしまいよく理解できていない人はかなり多いです。いざという時のトラブルシュートで差が出ますのでしっかり理解しましょう。 Windowsネットワークの歴史 NETBEUIの時代 「NETBOIS名」のことをよく理解するためにはWindowsネットワークの歴史を知らなくてはいけません。 まず、今のTCP/IP全盛の時代からすると信じられないかもしれませんが、初めてWindowsにネットワーク機能が標準搭載されたWindows95では規定のプロトコルはTCP/IPでは無くてNETBEUIというものでした。そしてNETBEUIはNETBIOSというAPIを利用しています。 NETBEUIはTCP/IPとは全く異なる考え方のプロトコルです。IPアドレスなんてありません。ルーティングもしません。名前だけ決めておけばアクセスできる。そんなプロトコルです。考え方は非常にシンプルです。 このNETBIOSのAPIを利用するために「コンピューターにつける名前」が「NETBIOS名」です。 Windows95, 98の時代にはコンピューターにコンピューター名(=NETBIOS名)だけつけておいて、あとはEthernetで接続(レイヤ1で接続)だけしておいてあげれば「\コンピューター名」という形式で他のコンピューターにアクセスしてファイル共有やプリンタ共有を利用することができました。 「NETBEUI時代に使っていたコンピューター名」が「NETBIOS名」です。 NETBEUIの限界 NETBEUIは現在ではほぼ使われていません。なぜ使われていないのかというと以下の点で現在のネットワーク環境に合わなくなってしまったからです。 - ルーティング機能が無いため大規模なネットワークには向かない - インターネットが普及し、NETBEUIとの相互接続性に問題がある 95, 98の時にはファイルやプリンタの共有のためにはNETBEUIプロトコルを使って、インターネット接続にはTCP/IPを使って･･･と、複数のプロトコルスタックを使うようなこともありました。今では用途別に複数のプロトコルスタックを使い分けるということはもうほぼありません。 TCP/IPへの移行 Windowsネットワークもインターネット普及の流れに乗るためにTCP/IPを標準のプロトコルに採用します。時代の流れです。ですが、単純にTCP/IPに移行してしまうと今まで使っていたNETBIEUI+NETBIOSのAPIをつかったWindowsファイル共有やプリンタ共有が使えなくなってしまいますし、Windowsネットワークの特徴であった「とりあえず名前だけ決めておけば繋がる」という利点が失われてしまいます。 そこでマイクロソフトがとったのはTCP/IPの上でNETBIOSのAPIを使えるようにする、という戦略です。これをNETBIOS over TCP/IPといいます。TCP/IP上でNETBOISを使えるようにしたわけです。これにより、NETBIOSのアプリケーションそのままに、TCP/IPを使って複数セグメントに分かれた大規模なネットワークにも対応可能になりました。 このNETBIOS over TCP/IPの機能があるため、何も設定していない状態で「ping コンピューター名」に応答が返ってくるわけです。 複数セグメントになったことで起きる問題 NETBIOS over TCP/IPによって複数セグメントに対応し、大規模なネットワークに対応できるようになりました。ですが、もともとNETBEUIは「ブロードキャスト」を多様することで簡単に接続できるようになっていたため、複数セグメントに分かれてしまうとNETBIOSのAPIがきちんとネットワーク全体で使えない、という問題が出てきてしまいます。 この問題を解決するために、セグメントを越えるために、出てきた技術がWINSです。各コンピューターがNETBIOS名とIPアドレスの対応付けをWINSサーバーに登録しておき、利用したい場合にはWINSサーバーに問い合わせることで、セグメントを越えることができるようになりました。 また、lmhostsファイルというファイルにもNETBIOS名とIPアドレスの対応付けを書くことができるようになっています。 WINSサーバーを使うかlmhostsファイルにそれぞれ記述することでセグメントを越えることが出来るようになっています。 NETBIOS名 ここまで見てきたようにNETBIOS名というのはもともとTCP/IPとは別のNETBEUIというプロトコルスタック上で使われていた名前です。WindowsがNETBEUIからTCP/IPに乗り換える際に、過去の遺産を持ってきた、そういう構造になっています。ですからはじめからプロトコルスタックにTCP/IPを採用していたUNIX系のOSではNETBIOS名という考え方は存在しません。 基本的には自分のNETBIOS名をコンピューターは知っていて、それが(ブロードキャストで)呼ばれたら変事をするような仕組みになっています。 UNIX系ネットワーク(TCP/IP)の歴史 hostsファイル TCP/IPでは他のコンピューターと通信する際にはIPアドレスを利用します。 IPアドレスを人間が全て記憶することは難しいため、hostsファイルにIPアドレスとそれにつけるコンピューターの名前(=ホスト名)を記述し、管理していました。全てのコンピューターにhostsファイルを記述する、というのがもっとも原始的な形態です。 個別のhostsファイルにホスト名とIPアドレスの対応付けを全て記述していたのでは、ネットワークにコンピュータが1台増えただけで、既存のコンピューター上の全てのhostsファイルを更新して回る必要が発生してしまいます。同じようにIPアドレスを変更したい、ホスト名を変更したいと思った場合も同様です。 このようにhostsファイルだけでは小規模なネットワークならともかく、大規模なネットワークでは事実上管理できません。 DNS hostsファイルの問題を解決する仕組みとして考え出されたのがDNSです。クライアントはDNSサーバーに問い合わせて、ホスト名とIPアドレスの変換を行います。 ただし、この際に単純にhostsファイルに記載されていたものをDNSサーバー上に登録しただけでは何百、何千、何万というレコードを1台のサーバーで管理しなくてはいけなくなります。DNSはインターネット上でも使われていますが、インターネット上のホストとなると何百万、何千万、何億という単位です。これを1台で全て管理したり、冗長化のために複数台にコピーしたり、というのはかなり効率が悪いです。 さらにもしかしたら全く同じ名前を持っているホストが存在しているかもしれません。この場合どちらかのレコードのみを登録するわけにもいきませんのでどちらかの名前を変更しなくてはいけなくなってしまいます。 そこでDNSには、このような問題を解決するためのしくみとして、「ドメイン」という概念が導入されています。「ドメイン」ごとにレコードを管理し、ホスト名のあとにドメイン名までつけて1つのホストを表します。たとえばこのブログが稼動しているサーバーはdyndns.bizというドメイン上のebiというホストです。ebi.dyndns.biz.というのが完全修飾ドメイン名(FQDN)になります。(※完全修飾ホスト名とは言わずに、完全修飾ドメイン名といいます。) ちなみにWINSにはこのような「ドメイン」という考え方は存在しませんので上記の問題をそのまま抱えています。ですので、マイクロソフトもWINSには見切りをつけていて、廃止の方向に向かっています。 ホスト名 見てきたように「ホスト名」はhostsファイルおよびDNSにて管理され、ドメインという概念を含んだものです。 NETBIOS名とは異なり、自分のホスト名に対してそのIPアドレスを返答するような仕組みは備わっていません。 Active DirectoryでDNSを導入 マイクロソフトはWindows2000でActive DirectoryというWindowsネットワークを管理する新しい仕組みを導入し、その中で名前解決の仕組みにDNSを導入します。ここから本格的にWindowsネットワークでもTCP/IP+DNSという仕組みを採用したわけです。 ですが、過去の資産を継承するためにNETBIOSの仕組みも存続させます。NETBIOS over TCP/IPも搭載していますし、NETBIOS名の名前解決の仕組みとしてWINSも健在です。 このようにして、WindowsネットワークはNETBIOS名とホスト名が混在するややこしい状態になりました。 ポイント - lmhostsファイルとhostsファイル、WINSとDNSとが技術的には対応付けられる。ただし、その技術が必要となってきた経緯は異なる。 - ホスト名はTCP/IP,Unixの文化から来ている。 - NETBIOS名はNETBEUI(プロトコルスタック)+NETBIOS(API)という過去の技術を継承しているために残っている。TCP/IPへとプロトコルスタックを変更する際にNETBIOS over TCP/IPという技術が導入され、これによりTCP/IPネットワーク上でNETBIOS(API)が利用できる。 - NETBIOS名とホスト名が混在しているのはWindowsネットワークだけ。 参考 - [Insider's Computer Dictionary [NetBEUI] － ＠IT](http://www.atmarkit.co.jp/icd/root/14/5787514.html) - [DNSの仕組みの基本を理解しよう](http://www.atmarkit.co.jp/fnetwork/rensai/dns01/dns01.html) - [＠IT：基礎から学ぶWindowsネットワーク](http://www.atmarkit.co.jp/fwin2k/serial/index/index.html#baswinlan)

ホスト名、それに対応するIPアドレス。それがどのようにホスト上にキャッシュされるのかについて見てみます。なお、ここではNETBIOS名に関しては言及しません。ホスト名限定の話です。 キャッシュする様子を見てみる まずは単純にホストに対してpingを実行する、というケースに対し、このときの動きをキャッシュを含めてみてみましょう。 まず、キャッシュを確認してみます。コマンドは「ipconfig /displaydns」です。 C : \ D o c u m e n t s a n d S e t t i n g s \ A d m i n i s t r a t o r > i p c o n f i g / d i s p l a y d n s W i n d o w s I P C o n f i g u r a t i o n 1 . 0 . 0 . 1 2 7 . i n - a d d r . a r p a R e c o r d N a m e . . : 1 . 0 . 0 . 1 2 7 . i n - a d d r . a r p a . R e c o r d T y p e . . : 1 2 T i m e T o L i v e . : 4 8 8 3 5 4 D a t a L e n g t h . . : 4 S e c t i o n . . : A n s w e r P T R R e c o r d . : l o c a l h o s t l o c a l h o s t R e c o r d N a m e . . : l o c a l h o s t R e c o r d T y p e . . : 1 T i m e T o L i v e . : 4 8 8 3 5 4 D a t a L e n g t h . . : 4 S e c t i o n . . : A n s w e r A ( H o s t ) R e c o r d . . : 1 2 7 . 0 . 0 . 1 .csharpcode, .csharpcode pre { font-size: small; color: black; font-family: consolas, “Courier New”, courier, monospace; background-color: #ffffff; /white-space: pre;/ } .csharpcode pre { margin: 0em; } .csharpcode .rem { color: #008000; } .csharpcode .kwrd { color: #0000ff; } .csharpcode .str { color: #006080; } .csharpcode .op { color: #0000c0; } .csharpcode .preproc { color: #cc6633; } .csharpcode .asp { background-color: #ffff00; } .csharpcode .html { color: #800000; } .csharpcode .attr { color: #ff0000; } .csharpcode .alt { background-color: #f4f4f4; width: 100%; margin: 0em; } .csharpcode .lnum { color: #606060; } キャッシュ上にはlocalhostとローカルループバックの逆引きのレコードしか登録されていません。 ...

「インターネットに繋がらない」という事象をテーマにして以下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 ...

「インターネットに繋がらない！」という発言をよく聞きます。テクノロジーを理解していないお客さんならともかく、プロとしてはこのような発言はしたくないものです。「インターネットに繋がらない」時には具体的にどのようなことが原因として考えられるのか考えてみます。 ※ここでは「インターネットに繋がる」という言葉の正確さに関しては議論しないことにします。 大まかな流れとその確認確認ポイント 通常お客さんが「インターネットに繋がらない」と言ったときにはブラウザでWeb上のコンテンツを表示できなくなったときでしょうから、そのときの大まかな流れを見てみます。 PCが起動する 有線または無線にてEthernetに接続する 固定またはDHCPにてTCP/IPの設定がなされる ブラウザにてURLが指定される DNSにホスト名に対応するIPアドレスを問い合わせ、回答を得る 該当のWeb Serverに接続する Web Serverからコンテンツを得る ブラウザにコンテンツを表示する これはかなり大まかな流れであって、実際にはまだまだいくらでも細かく処理を記述することが可能ですが、最低この程度の粒度では事象を抑えてもらいたいです。 このレベルでの確認ポイントは以下です。 きちんとケーブルが刺さっているか IPアドレス、サブネットマスク、デフォルトゲートウェイ、DNSの設定がきちんとなされているか DNSでの名前解決(ホスト名からIPアドレスへの変換)がきちんとなされているか 該当のWeb Serverに接続できているか コンテンツを得られるか それぞれ確認方法を紹介してみましょう。 きちんとケーブルが刺さっているか これはどうやって確認すればいいかというと････。目で見て確認してください(笑)。でも、せっかくなのでコマンドで確認する方法も紹介しましょう。 このように「ipconfig」というコマンドを使うとネットワークの状態を見ることができます。今、上の図ではきちんとIPアドレス等が表示されているので、この状態であれば「ケーブルがきちんと刺さっている」と言うことがわかります。ケーブルがきちんと刺さっていない場合にはここには「media disconnected」と表示されます。このように表示された場合にはケーブルが刺さっていない状態ですので、ケーブルの確認をしてください。 IPアドレス、サブネットマスク、デフォルトゲートウェイ、DNSの設定がきちんとなされているか ケーブルが刺さっていることを確認したら次はIPアドレス、サブネットマスク、デフォルトゲートウェイ、DNS等のTCP/IPの設定がきちんとなされているかを確認します。これも先ほどと同じく「ipconfig」コマンドで確認できるのですが、「ipconfig」コマンドだけではDNSの設定が確認できないので「ipconfig /all」コマンドを実行することで確認します。 ここできちんとIPアドレス(IP Address)、サブネットマスク(Subnet Mask)、デフォルトゲートウェイ(Default Gateway)、DNS(DNS Servers)が設定されていることを確認します。 ここでこれらのパラメータを自分で設定している人(固定的に設定している人)と自動的に設定している人とで若干確認、修正方法が異なります。 固定になっているのか、自動になっているのかの判別は上記コマンド結果の「Dhcp Enabled」の部分がYesになっているかNoになっているかでわかります。上記のサンプルではDHCPが有効になっていて、DHCPサーバー(192.168.1.254)からTCP/IPの設定を自動取得していることがわかります。 固定で設定している場合には「インターネットプロトコル(TCP/IP)」のプロパティから手動で値を設定、修正します。 自動になっている場合にはDHCPサーバーがきちんと稼動して、正しい設定を配布してくれている必要があります。自動的に取得する設定になっているにもかかわらず「169.254.x.x」、あるいは「0.0.0.0｣というアドレスになっている場合には正常にDHCPサーバーから設定を取得できていない状態です。DHCPサーバーの正常動作を確認するか、あるいは固定で設定してしまうかなどの対応が必要です。 参考：APIPA - Wikipedia そもそもどんな値を設定すればいいのか、設定されていればいいのかわからない人はTCP/IPの基礎を勉強しなくてはいけないですね。後日書く予定です。 ここまでの設定の確認としては、「デフォルトゲートウェイまでのpingが通ることを確認する」という方法が有効です。 「ping デフォルトゲートウェイのIPアドレス」を実行して、Pingに対してReplyがあることを確認しましょう。 DNSでの名前解決(ホスト名からIPアドレスへの変換)がきちんとなされているか 次にDNSでの名前解決がきちんとなされているかの確認方法です。「nslookup」というコマンドをつかって「nslookup ホスト名」とすることで調べられます。「ホスト名」というのはURLのうち下の例で言うとxxxx.xxx.xxの部分です。 「http://xxxx.xxx.xx/yyy/xxx/」 http://の直後からはじめの「/」の前までの部分ですね。 このようにホスト名からIPアドレスへの変換がうまくいっている必要があります。そもそもここでスペルミスなどをすると以下のように答えが返ってきません。 ここがうまくいかない場合には以下の2つの可能性があります。 TCP/IPの設定でDNSの設定を間違えている(正しいDNSサーバーを利用していない) 接続しようとしている先のサイトの情報を保持しているDNSサーバーに障害が起きている どちらなのかを判断するためには、その他のホスト名の名前解決ができるかどうかを調べましょう。私はいつも「www.google.com」が解決できるかどうか試しています。 ここまでのこと(ケーブル、TCP/IP設定、DNS)を一度に試す方法があります。それは「ping www.google.com」を実行することです。 ケーブルが繋がっていなければPingに応答があるわけはありませんし、TCP/IPの設定がただしいからgoogleのサーバーまで通信できています。また、www.google.comをDNSをつかってIPアドレスに変換できているからPingが打てているのです。www.google.comのホストはきちんとpingのReplyを返してくれるので確認が取れるわけです。 該当のWeb Serverに接続できているか ここまでの確認でクライアント側のTCP/IPおよびDNSの設定は問題ないことがわかりました。もう少し上の層に視点を切り替えていきます。まずは、該当のWeb Serverに接続できているかどうかです。 ...