makoto_fujimotoのblog

株式会社進角
代表 藤本信のブログです
どうぞよろしくお願いします

カテゴリ : ネットワーク

iptablesのパケットフィルタリングを使用したブリッジ型の簡易ファイアウォールを構築した際のメモです。NICをブリッジ構成とすることでHUBとして機能しますので、ネットワークゾーンを分ける必要がなく、クライアントの設定変更も必要としないので導入が簡単です。

【検証環境】
OS: CentOS 6.7
NIC: 二枚構成になっていて認識している状態
ネットワーク構成: [ RT ]----eth0[ Firewall (br0) ]eth1----[ Client ]
IPアドレス:
 Firewall 192.168.123.100 (ブリッジなので一つだけ)
  Client 192.168.123.101
  Router 192.168.123.254

【設定手順】

  1. NICのブリッジ設定
    ブリッジIDの登録
    # brctl addbr br0

  2. NICの設定
    # vi ifcfg-br0
    DEVICE=br0
    BOOTPROTO=none
    ONBOOT=yes
    ARPCHECK=no
    TYPE=Bridge
    IPADDR=192.168.123.100
    NETMASK=255.255.255.0

    # vi ifcfg-eth0
    DEVICE=eth0
    BOOTPROTO=none
    ONBOOT=yes
    ARPCHECK=no
    TYPE=Ethernet
    BRIDGE=br0


    # vi ifcfg-eth1
    DEVICE=eth1
    BOOTPROTO=none
    ONBOOT=yes
    ARPCHECK=no
    TYPE=Ethernet
    BRIDGE=br0

    # service network restart

    # ifconfig
    br0       Link encap:Ethernet  HWaddr 00:50:43:01:6B:D9
              inet addr:192.168.123.100  Bcast:192.168.155.255  Mask:255.255.255.0
              inet6 addr: fe80::250:43ff:fe01:6bd9/64 Scope:Link
              UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
              RX packets:19312 errors:0 dropped:0 overruns:0 frame:0
              TX packets:1414 errors:0 dropped:0 overruns:0 carrier:0
              collisions:0 txqueuelen:0
              RX bytes:1076922 (1.0 MiB)  TX bytes:259095 (253.0 KiB)
    eth0      Link encap:Ethernet  HWaddr 9C:B6:54:A9:DE:8D
              inet6 addr: fe80::9eb6:54ff:fea9:de8d/64 Scope:Link
              UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
              RX packets:19522 errors:0 dropped:0 overruns:0 frame:0
              TX packets:1634 errors:0 dropped:0 overruns:0 carrier:0
              collisions:0 txqueuelen:1000
              RX bytes:1450412 (1.3 MiB)  TX bytes:293545 (286.6 KiB)
              Interrupt:18
    eth1      Link encap:Ethernet  HWaddr 00:50:43:01:6B:D9
              inet6 addr: fe80::250:43ff:fe01:6bd9/64 Scope:Link
              UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
              RX packets:300 errors:0 dropped:0 overruns:0 frame:0
              TX packets:15111 errors:0 dropped:0 overruns:0 carrier:0
              collisions:0 txqueuelen:1000
              RX bytes:48752 (47.6 KiB)  TX bytes:931317 (909.4 KiB)
    lo        Link encap:Local Loopback
              inet addr:127.0.0.1  Mask:255.0.0.0
              inet6 addr: ::1/128 Scope:Host
              UP LOOPBACK RUNNING  MTU:65536  Metric:1
              RX packets:0 errors:0 dropped:0 overruns:0 frame:0
              TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
              collisions:0 txqueuelen:0
              RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

    # brctl show
    bridge name     bridge id                         STP enabled     interfaces
    br0                  8000.005043016bd9       no                     eth0
                                                                                        eth1

  3. ブリッジ疎通確認
    イーサケーブルですが、ファイアウォールのeth0をWAN側にeth1をClientに数珠つなぎした上で、iptablesのポリシー設定はすべてACCEPTにしておきます。
    (1) まずはClientからFirewallへ
    # ping 192.168.123.100
    PING 192.168.123.100 (192.168.123.100) 56(84) bytes of data.
    64 bytes from 192.168.123.100: icmp_seq=1 ttl=64 time=0.310 ms
    64 bytes from 192.168.123.100: icmp_seq=2 ttl=64 time=0.280 ms
    64 bytes from 192.168.123.100: icmp_seq=3 ttl=64 time=0.277 ms
    64 bytes from 192.168.123.100: icmp_seq=4 ttl=64 time=0.281 ms
    ・・・
    (2) ClientからFirewall越しのルーターへ
    # ping 192.168.123.254
    PING 192.168.123.254 (192.168.123.254) 56(84) bytes of data.
    64 bytes from 192.168.123.254: icmp_seq=1 ttl=255 time=0.399 ms
    64 bytes from 192.168.123.254: icmp_seq=2 ttl=255 time=0.269 ms
    64 bytes from 192.168.123.254: icmp_seq=3 ttl=255 time=0.270 ms
    64 bytes from 192.168.123.254: icmp_seq=4 ttl=255 time=0.280 ms
    ・・・
    Clientからファイアウォール越しにルータなどのIPアドレスにpingが通ればブリッジ設定はOKです。

  4. カーネルパラメータの変更
    パケットフォワードの許可とiptablesでブリッジのパケットを扱えるようにします。
    (1) /etc/sysctl.confに以下パラメータを追加
    net.ipv4.ip_forward = 1
    net.bridge.bridge-nf-call-ip6tables = 1
    net.bridge.bridge-nf-call-iptables = 1
    net.bridge.bridge-nf-call-arptables = 1
    (2) 設定を反映
    # sysctl -p

  5. iptablesの検証1
    取り急ぎFirewallのNIC間を流れるパケットの制御が有効か確かめるためにFORWARDチェインをすべてDROPしてみます。
    (1) /etc/sysconfig/iptablesを編集
    *filter
    :INPUT ACCEPT [0:0]
    :FORWARD DROP [0:0]
    :OUTPUT ACCEPT [0:0]
    COMMIT

    (2) iptablesの再起動
    # service iptables restart
    (3) Clientからpingが通らなくなったことを確認
    ping 192.168.123.100
    ping 192.168.123.254


  6. iptablesの検証2
    ping(ICMP)だけ通してみる
    *filter
    :INPUT ACCEPT [0:0]
    :FORWARD DROP [0:0]
    :OUTPUT ACCEPT [0:0]
    -A FORWARD -p icmp -j ACCEPT
    COMMIT
    # service iptables restart
    これでClientからFirewall越しにpingが通ればパケットフィルタリング制御が有効に働いていることになります。

  7. iptablesの実際的な設定
    社内LANなどで使用するパソコンが外部の不要なサービスにアクセスすることを防止するため、一般的に使用されるホワイトリストを登録する例です。
    *filter
    :INPUT ACCEPT [0:0]
    :FORWARD DROP [0:0]
    :OUTPUT ACCEPT [0:0]
    -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
    -A FORWARD -p icmp -j ACCEPT
    -A FORWARD -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT
    -A FORWARD -m state --state NEW -m tcp -p tcp --dport 443 -j ACCEPT
    -A FORWARD -m state --state NEW -m tcp -p tcp --dport 53 -j ACCEPT
    -A FORWARD -m state --state NEW -m udp -p udp --dport 53 -j ACCEPT
    -A FORWARD -m state --state NEW -m udp -p udp --dport 123 -j ACCEPT
    -A FORWARD -m state --state NEW -m tcp -p tcp --dport 110 -j ACCEPT
    -A FORWARD -m state --state NEW -m tcp -p tcp --dport 995 -j ACCEPT
    -A FORWARD -m state --state NEW -m tcp -p tcp --dport 587 -j ACCEPT
    -A FORWARD -m state --state NEW -m tcp -p tcp --dport 465 -j ACCEPT
    COMMIT
    # service iptables restart

  8. プロキシ―の設定について
    例えばマルウェア等のダウンロードを防止するために、HTTPプロキシ―によるゲートウェイ型のウィルスチェックソフトを併用することも可能です。この場合もブリッジ型ネットワーク構成であればクライアントのブラウザ設定を変える必要はありません。以下はこのFirewall自身をHTTPのウィルスチェックゲートウェイとする設定例です。
    (1) HTTPのプロキシサーバを立てる
    8080ポートを使用(ウィルスチェックソフトの設定になるので詳細は割愛)
    (2) NATの設定
    外部の80にリクエストが投げられると8080で動作するプロキシ(ウィルスチェック)が処理を行います。
    *filter
    :INPUT ACCEPT [0:0]
    :FORWARD DROP [0:0]
    :OUTPUT ACCEPT [0:0]
    -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
    -A INPUT -i lo -j ACCEPT
    -A INPUT -m state --state NEW -m tcp -p tcp --dport 8080 -j ACCEPT
    COMMIT

    *nat
    -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 8080
    COMMIT

Webサイトの立ち上げや運用をやっていると欠かせないのがドメインやDNSの知識です。

サイトの新規立ち上げ時にはそれほどややこしいことは無いのですが、特にサイトのリニューアルや移設あるいは業者移管を行う際には、様々な立場や知識の関係者が絡むことがありコミュニケーションに支障が出ることがあります。

例えば"ドメイン管理"と言っても、レジストラ(お名前.com等)でドメイン利用料を支払ったりWhois情報を管理するのか、あるいはDNSすなわちネームサーバのゾーン情報(ホスト名とIPアドレスが結びついた情報等)を管理するのか二つの意味にとらえられます。なおレジストラはJPRSが認定した指定事業者と呼ばれることもあります。

"ドメイン管理者"が対レジストラなのかゾーン情報まで管理しているのかはケースバイケースです。また"者"が業者を指しているのか個人を指しているかもあいまいです。

"DNSの変更"というのも良く飛び交う言葉ですが、我々システム業者側からするとIPアドレスなどのゾーン情報を変更するのか、DNSそのものを移転するのかがあいまいです。

もうややこしいですね

# あらためて、ここではDNS=ネームサーバーとします。

したがって、サイトリニューアルなどに伴って"ドメインの移設"を行う場合は、以下の点に留意しないと思わぬ障害につながったりします。この中で一点でも懸念があれば要確認する必要があります。

(1) レジストラを移管→する/しない
 →する場合は誰がどこに?
(2) ネームサーバを移管→する/しない
 →する場合は誰がどこに?
(3) ゾーン情報を更新→する/しない
 →する場合は誰がどのように?
(4) Whois情報を更新→する/しない
 →する場合は誰がどのように?
(5) ドメイン管理者(対レジストラ)を移管→する/しない
 →する場合は誰が?
(6) DNS管理者を移管→する/しない
 →する場合は誰がどのように?

                            する/しないの判断が難しい場合は弊社へ :-)

なお、企業で通常業務に使用している需要なドメイン名の料金支払いやDNS管理を誰がやっているか分からない状態は思わぬ経営リスク(失効や搾取や改ざん)になりかねませんので、経営層の方はドメイン管理者の所在は最低限掌握しておくことをおすすめします。

ロードバランサを導入するメリットは"サーバの負荷を減らすこと"と思っている方が多いようですが少し違いまして、役割りとしては配下のサーバに適切な負荷がかかるように制御することです。
最近いわゆるクラウドサービスで標準で使えるロードバランサの仕様を調べたら、ちょっとビジネス要件を満たせない仕様だったので、あらためて一般的なロードバランサ製品が実装している機能を整理してみました。

(1) 様々な指標でサーバの重みづけが設定できる
トラフィック、コネクション数、ロードアベレージなどを検知し動的に任意の配分が可能です。負荷以外にもラウンドロビン形式(巡回)での分散も可能です。

(2) サーバのヘルスチェック機能
サーバの様々な障害を検知して故障と判断したら自動的にトラフィックを流さないようにします。また一方のサーバの障害検知をトリガーとして待機サーバにトラフィックを切り替えるホットスペア機能などもあります。

(3) セッション維持機能
cookieやアクセス元のIPアドレスを使用してショッピングカートやユーザ認証状態が維持されるように通信中のサーバを保持し続ける機能があります。

(4) L7機能によってURL判別などができる
通信内容を判別してサーバの振り分けなどを行う機能です。例えばURLに/shop/という文字列があったらショップ専用のサーバにトラフィックを振り分けたりできます。

(5) HTTPS通信の際にアクセス元のソースIPアドレスが判別出来る
Spoof機能がないロードバランサではHTTPS通信時のソースIPアドレスが検知できず、ロードバランサのIPとなってしますので、アクセス元制限やログ解析、調査などに支障があります。

ダイナミックDNS(以下DDNS)とは動的にゾーン情報のIPアドレス等を書き換えることが出来るDNSの仕組みです。例えば固定IPアドレスを持たない家庭用ネットワークに一時的にホスト名を割り当てて外部との通信を手助けしたり、CDNサービスの負荷分散に利用されています。

また機器障害が発生した際の可用性を担保する仕組みとして、通常はロードバランサー等のヘルスチェック機能&切替機能を利用しますが、構成が複雑になり費用もかかるため、DDNSと監視システム等を組み合わせて障害発生時速やかに機器を切り替えてクライアントへの影響を最小限にするなどの応用も可能です。

BIND9にはDDNSの機能が組み込まれていますので、比較的簡単な設定で利用できます。
以下に設定方法を説明します(既に通常のDNS設定が済んでいることを前提としてます)。

  1. named.confの設定
    allow-update{}にゾーン情報の更新を許可するクライアント(ネットワーク)を設定します。
    allow-updateはDDNSを使用するゾーンのみゾーン宣言の中に記述します。
    プライマリDNSのゾーン宣言部に
        allow-update{ [更新許可クライアント]; };
        notify yes;
        also-notify { [セカンダリDNS]; };
        allow-transfer { [セカンダリDNS]; };
    を追加します。
    セカンダリDNSのゾーン宣言部には
        allow-update{ [プライマリDNS]; };
    を追加します。
    これでプライマリDNSで更新されたゾーン情報がセカンダリDNSに同期されます。

    プライマリDNS named.conf 修正箇所
    ゾーン情報
    zone "ddzone.shinkaku" {
        type master;
        file "ddzone.shinkaku.zone";
        allow-update{ [更新許可クライアント]; }; #ゾーン情報の更新許可クライアント
        notify yes;                              #ゾーン情報の更新通知を送る
        also-notify { [セカンダリDNS]; };        #ゾーン情報の更新通知先
        allow-transfer { [セカンダリDNS]; };     #ゾーン転送を許可
    };

    セカンダリDNS named.conf 修正箇所
    #ゾーン情報
    zone "ddzone.shinkaku" {
        type slave;
        masters { [プライマリDNS]; };
        file "slaves/ddzone.shinkaku.zone";
        allow-update{ [プライマリDNS]; };        #ゾーン情報の更新を許可
    };

  2. ゾーン情報ファイル、ディレクトリのパーミッション設定
    ゾーン情報ファイルは、namedユーザーが書込みができるようにパーミッションを変更します。また差分更新のための *.jnlファイル が生成されるので、ディレクトリも同様にパーミッションを変更します。

  3. ゾーン情報ファイルを手修正する場合の注意点
    DDNSはゾーン情報ファイルと *.jnlファイルの組で構成されています。したがって、ゾーン情報ファイルを手書き更新してnamedを再起動しただけではエラーが発生しますので、必ず *.jnlファイルを削除してからnamedを再起動します。

  4. セカンダリDNSへの変更情報の即時反映について補足
    プライマリDNSが変更されてもセカンダリDNSへの反映が遅れると不都合がありますので
    セカンダリDNSのゾーン宣言部にも必ず
      allow-update{ [プライマリDNS]; };
    を設定します。
    設定していない場合はプライマリDNSからのゾーン情報更新通知(notify)が送られてもゾーン情報は即時に更新されません。

  5. 動作確認方法
    ゾーン情報の更新にはnspdateコマンドを使用します。
    以下が実行例になります。
    -----------------------------------------------------------
    [root]# nsupdate
    > server ns.ddzone.shinkaku
    DNSレコードの登録
    > update add dev.ddzone.shinkaku 3600 IN A 192.168.1.101
    > send
    DNSレコードの削除
    > update delete dev.ddzone.shinkaku In A 192.168.1.101
    > send

    デバッグ時は-dオプションを使用します。

    nsupdateで更新したゾーン情報は即座にDNSに反映されますが、更新情報は *.jnl ファイルに差分として保存され、時間を置いてからゾーン情報ファイルに反映されます。
    この時、シリアルは自動的にカウントアップされます。

  6. クライアントのリゾルバキャッシュについて
    DNSのゾーン情報が更新されても一般的なクライアントPCにはホスト名とIPアドレスの情報を一定時間キャッシュする機能があることを意識する必要があります。したがって、閉じたネットワークシステムを構成する場合はこの設定も最適化することをお勧めします。

    検証はWindows7でしか行っておりませんが、Microsoftのサポートに新しい情報はありませんので、おそらくWindows8でも大丈夫かと思います。なおCentOS等のUNIX系OSにも同様のキャッシュ機能があります。

    Windows7のDNSリゾルバキャッシュについて
    -------------------------------------------------------------------------------
    Windows7ではDNSへの問い合わせ結果がキャッシュされ、頻繁にDNSへ問合せしないしくみになっています。DNSのゾーン情報を更新しても、クライアントPCに反映されない場合は、DNSリゾルバキャッシュのエントリを消去します。一度問い合わせたDNS情報を、再度問い合わせるまでのDNSリゾルバキャッシュの有効時間は、DNSのゾーン情報におけるいわゆるTTLが設定時間になります。
    -------------------------------------------------------------------------------

    【DNSリゾルバキャッシュを確認する】
    DNSリゾルバキャッシュの内容を確認したい場合は、
    コマンド プロンプトで
     ipconfig /displaydns
    と入力する。

    【DNSリゾルバキャッシュのエントリを消去する】
    一時的にDNSリゾルバキャッシュを消去したい場合は、
    コマンド プロンプトで
     ipconfig /flushdns
    と入力する。

    【DNSリゾルバキャッシュ機能自体を無効にする方法】
    「コントロールパネル」⇒「管理ツール」⇒「サービス」からDNS Client(DNS クライアント サービス)を停止します。

    【DNSリゾルバキャッシュの有効時間を任意に設定する】
    レジストリキー(MaxCacheTtl と MaxNegativeCacheTtl) を設定すれば、DNSリゾルバキャッシュの有効時間は MaxCacheTtl に設定した秒数になります。
    レジストリ
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNSCache\Parameters
    MaxCacheTtl      → リゾルバキャッシュ(秒)
    MaxNegativeCacheTtl  → 否定応答のキャッシュ(秒)

    (参考)
    Windows XP および Windows Server 2003 でクライアント側の DNS リゾルバ
    キャッシュ を無効にする方法
    http://support.microsoft.com/kb/318803/ja
    ※WindowsXP での設定方法ですが、Windows7 でも有効です。

アクセス元のIPアドレスによってある程度国を判別することが可能なので、国際対応していないWebサービスの"鎖国"を推奨している私ですが、JPNIC(日本ネットワークインフォメーションセンター)さんにその妥当性を質問してみました。

【質問1】
「IPアドレスより割り当てが行われた国を判別することが可能だと思いますが、例えば日本に割り当てられているブロックは 国内法が適用される日本領からのアクセスと補償されるもので しょうか?日本国に割り当てられたIPアドレスが海外で使用されている 可能性はないのでしょうか?」

【JPNIC回答】
"JPNICから分配されて日本国外で使用されているIPアドレスや、JPNIC以 外のレジストリ(APNIC, ARIN, RIPEなど)から分配されて日本国内で使用されているIPアドレスもあるかと存じます。"

【質問2】
「それでは分配されたIPアドレスに対して使用国の制約が無いので使用されている 国を断定はできないという理解でよろしいでしょうか?」

【JPNIC回答】
"ご認識の通りとなります。"


このやり取りで分かったことは、日本で発行されたIPアドレスが海外で使用されることもあれば、海外で発行されたIPアドレスが日本で使用される可能性もあるということです。これはレアケースだとは思いますがIPアドレスだけではアクセス元となる法治国家を断定できるものではないということですね。

とは言え、性善説で成り立ってきたインターネットの世界もオープン性は確保しつつ"不必要なものまで公開はしない"程度のコンセンサスがそろそろ必要な時期じゃないでしょうか。

ロードバランサ(LB)配下にあるサーバ間で通信したい場合にルーティングがうまくいかないことがあります。そのような場合にhostの名前解決ルールの定義によって解決する方法です。


--FW---LB---SW--+--WebServer1(192.168.150.11)  ↑
+--WebServer2(192.168.150.12) この間でFQDNによる
+--WebServer3(192.168.150.13) 通信が出来ない
+--WebServer4(192.168.150.14) ↓
LB
 ext: 210.*.*.123
 lan: 192.168.150.1
FQDN
 www.shinkaku.jp 210.*.*.123

WebServer間でFQDNによるHTTPリクエストを送る場合、宛先が一旦名前解決されてグローバルIPアドレスとなりますので直近のスイッチ経由でパケットは送られません。そしてロードバランサはExternalのインターフェースからWANに向かってしかパケットを送りませんのでLAN側からのリクエストには応答できません。

そこでサーバサイドから見たネットワークに少しおまじないを加えてあげます。


(1) まずhostsにローカルIPアドレスのFQDNを記載します
# vi /etc/hosts
------------------------
192.168.150.11 www.shinkaku.jp
192.168.150.12 www.shinkaku.jp
192.168.150.13 www.shinkaku.jp
192.168.150.14 www.shinkaku.jp
------------------------
これだけではまだhostsが使用されません

(2) 名前解決ルールを設定
# vi /etc/host.conf
------------------------
order hosts,bind
multi on
------------------------
1行目:名前解決にhostsファイルが優先されます。
2行目:同じFQDNが複数あった場合、複数のIPアドレスを返す設定です。

これらの設定でLBを介さずにサーバ間通信が出来るようになりますが、LBが持つ高度なヘルスチェックやフェイルオーバーならびにL7機能の恩恵を受けることはできません。


(追記:2014.4.30)
よく考えたらサーバでbind(named)を動かしてリゾルバDNSとしてローカルを参照するようにすれば同じようなことが出来そうですね。何と言ってもDNSラウンドロビンが使えるのである程度の負荷分散にもなります。

1台のサーバーで複数のネットワークカードを使用して冗長構成などを行う場合、スタティックルーティング設定だけではパケットの経路が定まらない場合があります。この様なケースではポリシーベースルーティング(ルーティングルール)設定を行う必要があるようです。マルチホーミングとも呼ばれています。

以下のようなネットワーク構成を例にCentOSの設定方法を説明します。
rule_route

それぞれのNICには異なるサブネットの固定IPアドレスが設定されていて、デフォルトゲートウェイが未設定になっていることを前提とします。またL3スイッチにより各VLAN間のルーティングが設定されていることも前提とします。

1. HOST Aにスタティックルーティングを追加
# vi /etc/sysconfig/network-scripts/route-eth0
192.168.102.0/24 via 192.168.101.1 dev eth0
192.168.103.0/24 via 192.168.101.1 dev eth0

# service network restart

# route
------------
Destination    Gateway        Genmask         Flags Metric Ref    Use Iface
192.168.102.0  192.168.101.1  255.255.255.0   UG    0      0        0 eth0
192.168.101.0  *              255.255.255.0   U     0      0        0 eth0
192.168.103.0  192.168.101.1  255.255.255.0   UG    0      0        0 eth0
ink-local      *              255.255.0.0     U     1002   0        0 eth0
------------

2. HOST BにHOST Aへの経路(スタティックルーティング)を追加
# vi /etc/sysconfig/network-scripts/route-eth0
192.168.101.0/24 via 192.168.102.1 dev eth0

# vi /etc/sysconfig/network-scripts/route-eth1
192.168.101.0/24 via 192.168.103.1 dev eth1

# service network restart
経路に問題がある旨のメッセージが出ます。宛先のネットワークが重複しているので一方の経路定義しか有効になりません。
ping結果
HOST A → HOST B (192.168.102.20) OK
HOST A → HOST B (192.168.103.20) NG

3. ルーティングルールの設定
いろいろ調べた結果、ルーティングに条件設定を行う方法が分かりましたので、以下にHOST Bへの設定手順を説明します。

経路テーブルIDの登録
# vi /etc/iproute2/rt_tables
以下の行を追加
200     rule102
201     rule103

ルールファイルの作成
# vi /etc/sysconfig/network-scripts/rule-eth0
from 192.168.102.20 table rule102
「192.168.102.20からの要求があったらrule102に従いなさい」というルールを定義

# vi /etc/sysconfig/network-scripts/rule-eth1
from 192.168.103.20 table rule103
「192.168.103.20からの要求があったらrule103に従いなさい」というルールを定義

ルーティングファイルの修正
# vi /etc/sysconfig/network-scripts/route-eth0
192.168.101.0/24 dev eth0 src 192.168.102.20 table rule102  ...(1)
default via 192.168.102.1 table rule102  ...(2)
(1) 「192.168.101.0/24ゾーンを参照する元ホストがeth0の192.168.102.20だったらrule102に従いなさい」というポリシーを定義
(2) 「rule102のデフォルトゲートウェイは192.168.102.1ですよ」という意味

# vi /etc/sysconfig/network-scripts/route-eth1
192.168.101.0/24 dev eth1 src 192.168.103.20 table rule103
default via 192.168.103.1 table rule103


ネットワークの再起動
# service network restart
エラーが出なければ矛盾は解消されたはずです。
双方のサーバからそれぞれのIPアドレスに対してpingが通れば完了です。

4. まとめ
通常のルーティングテーブルにはルール設定情報は反映されません
# route
------------
Destination    Gateway        Genmask         Flags Metric Ref    Use Iface
192.168.102.0  *              255.255.255.0   U     0      0        0 eth0
192.168.103.0  *              255.255.255.0   U     0      0        0 eth1
ink-local      *              255.255.0.0     U     1002   0        0 eth0
ink-local      *              255.255.0.0     U     1003   0        0 eth1
------------

ルーティングルールの確認方法はこちらになります
# ip rule
0:      from all lookup local
32764:  from 192.168.102.31 lookup rule102
32765:  from 192.168.103.31 lookup rule103
32766:  from all lookup main
32767:  from all lookup default

# ip route show rule102
192.168.101.0/24 dev eth0  scope link  src 192.168.102.20
default via 192.168.102.1 dev eth0

# ip route show rule103
192.168.101.0/24 dev eth1  scope link  src 192.168.103.20
default via 192.168.103.1 dev eth1

現在利用しているISPが提供するホスティングやサービス面に不満があって、新たなISPに引っ越しすることは良くありますが、移行手順や設定に問題があると長時間にわたりメールが使えなくなったり、 ホームページが閲覧できなくなり、業務に支障が出ることがあります。

サーバを引っ越しすることで、OSを始めとするミドルウェアの環境が変わり、アプリケーションすなわちコンテンツやプログラムの互換性問題が起きる可能性があることは周知されていますが、引っ越しに伴うドメイン管理やネームサーバ管理の移行については少しおざなりにされがちです。また引っ越し期間中は費用も新旧重複してかかりますので、なるべく短期間に済ませたいものです。

弊社ではたびたびサーバの引っ越しを業務として請け負っておりますが、以下の手順を基本とすることでサーバ引っ越しに伴う問題を軽減することができます。

与件例
・W社のVPSからS社のVPSにサーバを移管する
・ドメイン管理業者(レジストラ)も移管したい
・上記に伴いネームサーバ(DNS)の移管が必要


(1)
現状のISP(プロバイダ)への解約通知

ISPサービスの解約は約款上1ヶ月から数ヶ月前の通知が必要とされていることが多いので、サーバの引っ越しが決定したら、まず真っ先に実施したいタスクです。

(2)
ドメインの管理業者(レジストラ)移管
レンタルサーバ契約とドメイン管理サービスがセットになっていて解約を余儀なくされたり、移管作業をスムースに行うために任意のタイミングでWhois情報を書き換える必要があります。したがってコントロールパネルでドメイン情報の管理が容易に行えるドメイン管理業者へ移管することをお勧めします。経験的にはISPやホスティング系よりドメイン登録に特化したサービス業者をお勧めします。この時点で気を付けたいのは、レジストラ移管が済むまでWhois情報のネームサーバは書き換えを行わないことです。

(3) 新DNSの設定
私の経験上、Webやメールのサービスを行うサーバとネームサーバ(DNS)は共存しないことを推奨しています(危機意識の低いDNS構成)。なお上記の移管先レジストラの選定条件として、DNSサービスがセットになっているサービスをお勧めします。それを前提として新たなDNSの設定ですが、ゾーン情報に定義するIPアドレスはNSを除き、現行サーバを指したままとしてください。NSにはこのレジストラが提供するDNSサービスのホスト名を定義しておきます。またDNSのIPアドレス書き換えに備えてTTLを少し短めにしておくとよいでしょう(3600以下)。

(4) ネームサーバの切替え
新レジストラのドメイン情報管理画面でwhois情報のネームサーバの書き換えを行います。ネームサーバには(3)で記述したNSのホスト名をプライマリとセカンダリともに指定します。この作業を行うことで当該ドメインのネームサーバが新しく設定した方に切り替わります。このWhois情報の書き換えがインターネット全体に波及するには1~2日かかるようです。

(5) レンタルサーバの申込み
最近のレンタルサーバはオンライン上での申込みから利用開始までに、当日中や一両日中に設定が完了することが多いので、あまり契約を急ぐ必要はありません。早く契約してしまうとそれだけ現行サーバとの重複期間が長くなり料金が無駄になります。なお専用サーバでも概ね1週間以内程度で利用できるかと思います。

(6) レンタルサーバの設定
詳細はケースバイケースなので割愛します。
 

(7) アプリケーション(サイト)の移設・動作検証
詳細はケースバイケースなので割愛します。この段階ではDNSがまだ現行サーバに向いていますが、PCのhostsファイルを記述して新サーバのIPアドレスに強制的に書き換えを行うことで、本番に近いテストが可能です。
 

(8) サーバへIPアドレスを切り替え

十分なテストを行ったのち、いよいよ新サーバへIPアドレスを切り替えます。(3)でDNSのTTLを短縮してあれば、比較的すぐに新しいサーバへのアクセスが出来ると思われます。ちなみに慎重を期すならば、サーバ切替直後はサービス公開を関係者のみに限定し、最終チェックを行ったのちに一般公開するのが安全ですね。

前回のエントリーではドメイン名やIPアドレスを元に公開情報から様々な情報が得られる事を書きましたが、例えば衆議院選を前にして、未来の党が運営していると思われる以下のサイトでアンケート投票が実施されています。
http://www.pre-sousenkyo.com

試しにwww.pre-sousenkyo.comをDNSに問い合わせすると

IPアドレス
46.51.255.232

逆引き
ec2-46-51-255-232.ap-northeast-1.compute.amazonaws.com

ネームサーバ
pre-sousenkyo.com. 117069 IN NS ns-214.awsdns-26.com.
pre-sousenkyo.com. 117069 IN NS ns-1385.awsdns-45.org.
pre-sousenkyo.com. 117069 IN NS ns-631.awsdns-14.net.
pre-sousenkyo.com. 117069 IN NS ns-2026.awsdns-61.co.uk.

という情報が得られ、米国Amazon Web ServiceのEC2というクラウドサービスを用いていることが一目瞭然です。

今度はドメイン名をwhois検索してみます
Domain Name: PRE-SOUSENKYO.COM
Registrar: GMO INTERNET, INC. DBA ONAMAE.COM
Whois Server: whois.discount-domain.com
Referral URL: http://www.onamae.com
Name Server: NS-1385.AWSDNS-45.ORG
Name Server: NS-2026.AWSDNS-61.CO.UK
Name Server: NS-214.AWSDNS-26.COM
Name Server: NS-631.AWSDNS-14.NET
Status: ok
Updated Date: 01-dec-2012
Creation Date: 23-nov-2012
Expiration Date: 23-nov-2013

ドメインはお名前.comでおなじみのGMO社にて11/23に取得されているようです。

GMO社のwhoisでさらに情報を見てみましょう

Domain Handle: None
Domain Name: pre-sousenkyo.com
Created On: 2012-11-23 16:55:05.0
Last Updated On: 2012-12-02 00:28:33.0
Expiration Date: 2013-11-23 16:55:05.0
Status: ACTIVE
Registrant Name: Whois Privacy Protection Service by onamae.com
Registrant Organization: Whois Privacy Protection Service by onamae.com
Registrant Street1: 26-1 Sakuragaoka-cho
Registrant Street2: Cerulean Tower 11F
Registrant City: Shibuya-ku
Registrant State: 13
Registrant Postal Code: 150-8512
Registrant Country: JP
Registrant Phone: 03-0364-8727
Registrant Fax:
Registrant Email: proxy@whoisprotectservice.com
  ・
  ・
  ・
  ・

Registant(登録者情報)にお名前.com(GMO社)の所在地のセルリアンタワーが出てきました。これはドメインの登録者や管理者情報を匿名化するオプションサービスを利用しているということです。つまりドメインの名義が「分からないことが分かった」ということが言えます。ドメイン情報を秘匿化することは、信頼されたWebサイトを証明するSSLサーバ証明書を運用する段階においては若干微妙ですが、現在は個人情報を扱っている様子もないので由としているようです。

運営主体が分からないサイトで、匿名ながら有権者としての意思を示したり、集計結果を見せられるのはちょっと慎重に判断した方がよいかもしれませんね。


注:12月5日一部加筆修正しました。

インターネットを不正利用した犯罪が後を絶ちませんが、最近では他人のPCに成りすまして違法行為を行って警察の誤認逮捕を招き、冤罪に発展しかねない事件も発生しています。
サイバー犯罪事件の報道で、一般的に報じられるようになってきたIPアドレスですが、インターネットへのアクセス元情報だけではなく、様々な情報が読み取れる場合があります。

以下は公開情報だけから読み取ることができる情報です。

【おおよその地域】
DNSを使ってIPアドレスからサブドメイン名への変換を行うことを"逆引き"と言いますが、変換したサブドメイン名には人間が判別しやすいような地域名が含まれる場合があります。
例: p1234-ipbf5678ykh.tokyo.ocn.ne.jp
この例では"ykh"が横浜の略称であることが推測できます。

【どこの会社か】
上記と同様に、サブドメイン名に会社名が含まれていることがあるので、どこの会社からアクセスしてきたかがわかります。
例: gw1.shinkaku.co.jp

【契約プロバイダや回線種類】
個人やSOHOなどで契約しているインターネット回線は、ドメイン名がプロバイダ名となっている場合が多いです。またipbfという文字が含む場合は経験上Bフレッツサービスを利用していることも推測できます。またftthという名称も光回線を使用している場合によく目にします。

【どこの国か】
IPアドレスは大小のブロック単位でそれぞれ決まった国に割り振られているので、以下の情報と突き合わせを行うと、どこの国からアクセスがあったのかわかります(長いリストなので閲覧注意)。
http://ftp.arin.net/pub/stats/arin/delegated-arin-extended-latest
http://ftp.ripe.net/pub/stats/ripencc/delegated-ripencc-extended-latest
http://ftp.lacnic.net/pub/stats/lacnic/delegated-lacnic-extended-latest
http://ftp.afrinic.net/pub/stats/afrinic/delegated-afrinic-extended-latest
http://ftp.apnic.net/stats/apnic/delegated-apnic-latest
ただしインターネット犯罪者は、巧妙にいくつかの国やサーバを経由して犯行を行うので、必ずしも記録されているIPアドレスの国にいるとは限りません。

と、この位は少しインターネットに絡んだ仕事をしている方であれば知っている知識だと思います。次の情報あたりからは少しスパイ活動っぽくなりますので、くれぐれも悪用しないようにお願いします。

【サーバ・ネットワーク運用会社】
公開されているURLやメールアドレスを構成するドメインをwhoisという公開データベースに照会を行うと、実にたくさんの情報が得られます。この情報の中で、Nameserverというパートに登録されているDNSサーバの所在によってはサービスプロバイダとは別の運用管理業者がいることがわかります。

【システム開発を行った会社】
whois情報からドメイン取得を行った会社やDNSを運営管理している会社の技術者情報から開発会社が推測できることがあります。

【利用しているホスティングサービス】
ホームページアドレスからIPアドレスを正引きし、そのIPアドレスの保有者を調べるとインターネットサービスプロバイダが判明します。このIPアドレスをさらに逆引きしてみると、ホスティングサービス名が推測できるサブドメイン名が返ってくることがあります。またそのサービスプロバイダのホームページを確認しても大体検討がつきます。

【Webサーバの台数】
アクセス数の多いサイトではWebサーバを複数台稼働して負荷を分散しますが、実際に何台使用しているかは技術ノウハウやセキュリティ上の観点で門外不出の情報になっていて、めったなことでは公開されません。しかしサブドメイン名をnslookupやdig等のツールを使って調査すれば、複数のIPアドレスが定義されていること分かることがあり、サーバ台数を予測できることがあります。またwwwの後に連番でwww1..2..3などと管理上の別名が割り振られていることがあるので、それをたどっても台数を推測することが可能です(ただし、ロードバランサやリバースプロキシを使用していたり、最近のクラウドサービスを利用している場合は実体がなかなか分かりにくくなっています)。

【サーバが会社内に設置されているか】
大体推測できますが、この調査方法の開示は自粛します。。

【責任者が誰か】

whois情報には登録者、ドメイン管理者、経理担当者、技術担当者などの個人情報が記録されているので誰がドメインや開発・運用の責任者かわかることがあります。ただしこれらの情報を元にSPAMメールを送ったり悪用する輩がいるので、匿名化を行うオプションサービスをドメイン取得会社が提供しています。

【広告代理店】
Webキャンペーンなどは訴求目的のドメイン名を使い捨てで都度取得することがあり、ドメイン管理についても広告代理店にお任せになっている場合があります。またドメインの名義はエンドクライアントになっていても、SSLサーバ証明書の取得は工期の都合から代理店や制作会社の名前で行っていることがあります(ブラウザで証明書を詳しく見るとわかります)。

【メールサーバ情報】
Eメールの仕組み上、ドメインのDNS情報の中でも"MXレコード"は公開されているので、記述を見ればゲートウェイサービスを使用していたり、googleのサービスを使用していることがわかります。


このように、ドメインやIPアドレスの公開情報だけでも様々なビジネス情報やドメスティック情報が入手出来たり推測が可能です。弊社では競合調査、見込み客調査、サーバ移管準備、セキュリティ対策などに活用しています。


続編「ドメイン名やIPアドレスから分かること2」
http://blog.shinkaku.co.jp/archives/20672756.html

このページのトップヘ