今般社内イントラネットの導入を受けて、取り組んだ内容について公開可能な情報を掲載していきます。
　これらの情報は、基本的に我々の環境内で多方面からの情報を元に、独自に取り組んだものであり、すべての環境で共通ではありません。もっとも重要な事は、ここで記載される事項が、我々管理スタッフの備忘録である事です。
　しかし、我々が取り組む際にもたとえばインターネットからはあまり多くの情報を得ることが出来ませんでした。よって、ここに「事例」として掲載し、今後取り組む方々に対し、少しでも役に立つ情報となれば幸いです。

1.環境
　
　○データベースサーバー(DSKW0000)は汎用機で処理された各種データを加工、あるいはそのままのデータをWebで参照出来るようにコンテンツを提供する。
　○Exchangeサーバー(DSKE0000)はExchangeの主機能である、メールとコンテンツ共有を提供。

2.目標
　その１：各拠点のクライアントから、インターネットへは上図の「インターネットルータ」を経由してアクセス出来る環境を構築する。
　その２：Exchangeサーバーで処理するメールは、インターネットサーバーDUSKIN1を経由して、外部とも送受信可能な環境を構築する。　

3.環境構築[インターネットへの接続]
　上図の構成で、拠点側のネットワークとデータベースサーバー及びExchangeサーバーとの通信は、同一ノードと判別できるようにIPを固定して実現している。
　拠点側IPは[192.168.90.*]から[192.168.94.*]まで。データベースサーバーは[192.168.90.4(セカンダリ192.168.1.200)]、Exchangeサーバーは[192.168.90.3(セカンダリ192.168.1.201)]である。
　ローカル・エリア・ネットワークは、すでに[192.168.1.0/24]で稼働中。
　インターネットルータのIPアドレスは[192.168.1.1]。
　拠点対向ルータのIPアドレスは[192.168.90.1]。セカンダリとして、[192.168.1.150]を設定。

　この環境で、静的経路情報をどこかで定義しないと、拠点からインターネットルータへは通信できない。
　イントラネット構築時点で、インターネットルータとして機能していた某社製ルータにこの経路情報を定義しようとしたが、失敗。NTTの協力を得て、グレードをあげてみるが、これも失敗。最終的にYAMAHAのRT102iを使用することで解決する。
　これは、拠点から「拠点対向ルータ」を経てProxyサーバーへ接続しようとしても、ノードが異なるため、パケットが宛先を認識できないためである。これを防ぐためには、どこかで「経路情報（ルーティングテーブル）」を持つ必要がある。

　今回は「インターネットルータ」の中で「静的経路情報（ルーティングテーブル）」を定義する。つまり、それぞれの拠点からの接続は、
ip lan route add net 192.168.90.0/26 192.168.1.250 3
ip lan route add net 192.168.90.192/26 192.168.1.250 3
ip lan route add net 192.168.90.64/26 192.168.1.250 3
　　　　　　｜　　　　　　　　　　　　　　　｜　　　　　　　　　　　　　
と定義した。メトリックが３になっているのは、特に理由は無いが、拠点対向ルータから見た場合には２になるのかも知れない。

　拠点の各クライアントは、Proxyサーバー(192.168.1.3)を経由して外部へ接続する。
　ProxyサーバーはFreeBSD3.5.1-RELEASEで構築しており、Squid2.3が動作中。ACL定義に拠点側のIPを加えただけである。

3.環境構築[外部とのメール送受信]
　インターネットメールは、すでにPC6と言うサーバーで実現しているが、万が一の事も考え、これとは別にメール中継用のサーバーとしてDUSKIN1を利用する事に決定。DUSKIN1はSMTPとPOP3がすでに稼働していたが、あくまでも内部管理用であった。これをインターネットへ接続できるように設定変更し、Exchangeのメールを中継させる。

　まず、DUSKIN1がメールサーバーとして機能するようにせねばならない。通常当ドメインへメールを送信すると、PC6がその配信を管理する。従って、現在の状態では外部からDUSKIN1へ向けてメール送信してもPC6がエラー処理してしまう。
　そこで、サブドメインでもメール配信が可能なように設定変更する。
　(1)DNSの設定変更
　サブドメインのメールがDUSKIN1で処理されるように、MX(MailExchange)レコードを変更する。ちなみにDUSKIN1にはML2というホスト名を設定。

□正引zone設定
−−−−−−−−−−−−−−−−−
　DUSKIN1　　　IN　　A　　210.168.1.3
　　　　　　　　　IN　　MX10　　PC6
　ML2　　　　　IN　　MX10　　DUSKIN1
−−−−−−−−−−−−−−−−−

　次にPC6のSendmailがサブドメイン宛のメールを受信しないように設定。
−−−−−−−−−−−−−−−−−
　sendmail.cfの[Lower names which should be accepted]の項へ、
CY ml2
−−−−−−−−−−−−−−−−−
を定義。これでml2宛のメールはPC6は処理しない。

　次にDUSKIN1がml2を自分宛のメールとして処理できるように、sendmail.cfを修正。
−−−−−−−−−−−−−−−−−
# local host name without domain (defined automatically)
Dwml2

# default from-address (can be $j, $m or another generic address)
DSml2.$m
−−−−−−−−−−−−−−−−−

　ここまででPC-UNIX側の設定は一段落。続いてExchangeの設定。



　まず、ユーザーがイントラネットでメール配信できるドメインは、user@dske0000.mydomain.co.jpであるが、これはグローバルには見えないローカルなサブドメインである。
　そこでグローバルとやりとり可能なように、個人毎のメールアカウントの設定にグローバルなメールアドレスを追加する。


　SMTPが通常使用されるアカウント。smtpが今回設定したアカウント。これが受信用のアカウントとなるはず。

　この段階では、ExchangeからDUSKIN1(ml2)が見えていないため、DNSなどの設定を追加せねばならない。

DUSKIN1をHOSTとして登録し、さらにMXレコードを追加する。その上でml2のエイリアス（CNAME)を追加する。

　次にExchangeシステムマネージャから、SMTP仮想サーバーの設定に転送設定を追加する。



　SMTP仮想サーバーの設定でDUSKIN1とのルーティングに必要となると思われる情報を追加する。まずは「解決できない受信者を含むメールの転送先」へml2を指定。
　次に「配信タブ」から「詳細設定」を選択し、



　メール配信は、基本的に内部が優先されるが、内部に該当アカウントが無い場合だけ、「スマートホスト」へ転送するように設定する。

　次は「ルーティンググループ」。



　「最初のルーティンググループ」へ[ml2]を「SMTPコネクタ」として登録し、「このコネクタから次のスマートホストにすべてのメールを転送する」をチェックし、DUSKIN1(ml2)のIPアドレスを設定。
　「ローカルブリッジヘッドサーバー」は自サーバーである。



　「アドレススペース」に関しては、基本的に「すべてのアドレスを対象」とする目的で、上図のように、アドレス=*とするのが良いようである。どのみちメール送信では、内部の検索が優先されるため、この登録でも問題無いと考える。トラフィックは検証していない。



　「接続ルーティンググループ」へml2を登録する。これは必要なのかどうかは不明なのだが、実験中にメールが戻ってこなくなる現象を回避した際に採用した方法である。なお、この設定に先立って、ルーティンググループにml2を追加した。



　メール送信時にSMTPなのかESMTPなのか、どういう動作をさせるのかを設定せねばならないようだ。デフォルトでも問題ないように感じたが、送信セキュリティで「匿名アクセス」を許可しているため、若干細かな設定は見ておいた方が良いだろうと判断。


　ここまでの設定で、戻りのメールも処理されると確信していたが、実はそう簡単には行かなかった。

　前述のSendmail側の設定変更後に、今回実験するアカウントに対して、[.forward]を設定した。これは、DUSKIN1が受信したアカウントのメールを、FreeBSDのUSERのメールボックスへ落とすのでは無く、[.forward]で設定したアカウントへ「転送する」と言う考えで行ったものだ。
　ところが何度実行しても、Exchangeへメールが届かない。Exchangeからは、DUSKIN1を経由して外へ飛ぶのに・・・

　この試行錯誤は二日間にわたった。

　その後、DUSKIN1へTelnetでログインし、手動でメール送信してみると妙な事に気がついた。
　#mail　-v　user
　として、該当ユーザーへメールを送り、[.forward]の動きを確認してみると、確かに.forwardは読み込まれるが、メールはLocalへ落ちる。何度やっても、.forwardをどのように設定しても同じなのである。

　そこで疑問を抱き、http://www.sendmail.org/を訪問してみる。
　ここで目にしたのは、
As of sendmail version 8.9, forwarding of SMTP messages is not permitted by default. For exsample, if you are on site A.COM, you will not accept mail from B.NET destined for C.ORG without arrangements.(/tips/relaying.htmlより引用)
との事である。デフォルトでは中継を許されていない。この設定を変更するためには、Relay自体をゆるめなくてはならないようである。そうなると「不正中継」も可能になる可能性がある。

　この時点で[.forward]の使用を断念し、spool_hostに切り替える。

　DUSKIN1のsendmail.cfを見直し、spool先を変更する。これで受信メールはLocalへ落ちない。
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
# lower names which should be accepted
CY dske0000
# users who require host.domain
CS root daemon news usenet postmaster MAILER-DAEMON
# default from-address (can be $j, $m or another generic address)
DSml2.$m
# spool host
DYdske0000.mydomain.co.jp
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

　以上のように、異なるノードからのインターネット接続、及びメール中継、転送を実現した記録です。
　なお、本文中には筆者の解釈の誤りなどが含まれている可能性があります。参照される方は、ご自身の環境と比較しながら、正確にステップを踏んで進められることを希望します。また、このサイトでの間違いを発見された方は、ご報告いただければ幸いです。


◎補足情報
　今回の環境構築に当たって、直接SMTPポートへ接続し、試験を行う事も多かったため、その手順を記録します。
　通常SMTPサーバーが動作しているサーバーへ接続し、コマンドを送り込むだけでメールの送信が可能。なおESMTPであれば、SMTPも可能。

　SMTP(SimpleMailTranferProtocol)はFTP(FileTransferProtocol)をベースに誕生したプロトコルであり、SMTPがRFC561によって定義されるまでは、FTPを使用してメッセージを転送先に単純なファイルとしてコピーしていたそうである。
　RFC680,724,733と改良が重ねられ、RFC822において現行の規格が定義されました。

　SMTPの基本ステップ
　1.利用者が送信者SMTP宛のメール要求を作成する。
　2.送信者SMTPは受信者SMTP宛の双方向転送チャネルを確立。
　3.送信者SMTPはSMTPコマンドを生成して受信者SMTPに送信する。
　4.受信者SMTPは応答コマンドを送信者SMTPに送信する。

　これをTelnet接続により、手動で実現する。
1.Telnet 192.168.1.201 25　としてTelnetを起動。
2.SMTPの反応を確認し、HELOコマンドを送信。
3.MAIL FROM:foo@hoge.co.jp　コマンドで送信者を示す。
4.OKを確認できたら、RCPT TO:foo　を送り、相手先を指定。
5.OKを確認できたら、DATAコマンド送信。
6.メッセージの待ち受けとなり、先頭にSubjectやMail formを入れて、本文をエントリ。終了は行頭に"."。
7.送信が確認できたら、QUITコマンドで終了。


◎本ページの作成にあたっては、
http://www.users.gr.jp/の「過去ログ検索」、
日経BPソフトプレス発行「MicrosoftExchange2000Serverオフィシャルマニュアル　上・下」を参考にさせていただきました。

トップへ戻る

11/June/2001