DigiLoog

続きを読む »

ns-labの自鯖群は仮想含めて20台程動いており(2017年9月末現在)、
流石にこれ全台を切り替えるのはやりたくないので、
Internetに公開しているWebサーバのみ公的なSSL証明書に切り替えた。
全部を切り替えても良かったが、認証局のノウハウも貯めたいしオレオレは残す事に

そんでもって、結構悩んだのがワイルドカード証明書を購入するか、
Let’s Encryptでドメイン証明書で運用するかの2択。
ワイルドカード証明書を買っておくと、メールサーバとかもSSL対応出来るし美味しいのだが、
流石に年間1万払うのはしんどい事もあり、相当悩んだ結果Let’s Encryptにした。
ちなみに、Let’s Encryptも2018年にワイルドカード証明書の発行をスタートするらしいので、
発行スタートした際に改めて切り替えを検討する予定。

あと、Let’s Encryptを使う場合Certbotとかで証明書の自動更新をしておかないと、
証明書期限の関係で実運用が厳しいのだが、毎度お馴染みのperlでスクリプトを作成し、
証明書発行・ロードバランサへの転送・証明書適用の一連作業を全自動にしてみた。

………

ちゃんとしたSSL証明書を発行したなら、DNS CAAもやりたかったので、
ns-labのInternet向けDNSサーバにCAAレコードを追加。
CAAレコードにはLet’s Encryptとオレオレ認証局を追加した。

オレオレ認証局を追加するのは微妙な所もあるのだが、
実運用している場面もあるので問題なかろう。

………

ちなみに、SSL Reportを走らせて見たら『A+』の評価をゲット。
今回は本気で設計・脆弱性潰しを行いつつ、CAA対応とかオプションもやったので、
意図せずに高得点を取得出来たのかもしれない。

« 続きを隠す

続きを読む »

「なんでここまで本気出した」だって？
好きなゲームブランドのWebサイトに接続出来ないの悲しいじゃないですか！

と前置きは置いといて調査結果と解決方法から。
今回エラーになっていたのは、
恐らく「www.lumpofsugar.co.jp」の稼働しているレンタルサーバで実施している(筈の)、
セッション数制限に引っかかり、Webサーバ側でTCPコネクションをDROPされていた。
ただ、推測の域を出ないので真相は闇の中へ…

………

～ Phase.0 状況整理 ～

今回は、自鯖Proxy越しにアクセスが微妙に出来ないのが問題なので、
到達目標は『自鯖Proxy越しに “www.lumpofsugar.co.jp” にアクセスする』事とした。
また、自鯖環境をフル活用して被疑ポイントの特定を行う事に。

～ Phase.1 NW回線切分 ～

まず、真っ先に疑ったのはNW回線とMTS/MSSの設定ミス。
という事で、VPN越しに筆者の所有する下記回線からアクセスしてみたが、
どのキャリアでもProxy越しにアクセスすると全部アウトという事がわかった。

よって、NW回線は問題ではなくProxy有無が問題の可能性が強くなった。
その為、以後の切り分けは全てメイン回線(NTTPC)のみで実施した。

～ Phase.2 Proxy切り分け ～

次に自鯖のProxy構成を疑った。
“ns-lab BB”のアクセスProxyは、HAProxyをLSLB(ロードバランサ)代わりに下図のような構成になっている。
なので、TCPコネクション・SSLセッション維持で不具合が出たのではと疑った。

LBSBはアクティブ・スタンバイで確実に片寄せしているのでセッションは問題無し。
Proxy指定はPACファイルで実施しており、PAC配布用のWebサーバも稼働している。
PAC配布についてセッション維持はどうでも良いのでラウンドロビンで制御。
ProxyはX-Forwarded-ForのクライアントIPアドレス元に、
ソースハッシュで分散しているのでセッション維持の被疑対象外。

という事で被疑箇所を減らす為、HAProxyを外しProxy直指定でWebサイトの確認を行ったが、
Webサイトを見る事はやはり出来なかった。
状況整理と上記切り分けを実施した事で、Proxy直指定でも駄目な事から被疑箇所はProxyに限定化する事が出来た。

そもそも、対象がHTTPなのでセッション維持は必要無いだろうし、
上記構成のままソフマ○プでエ○ゲ購入とかも出来ているので、コネクション管理・セッション維持は問題無いだろう。

～ Phase.3 パケットキャプチャ ～

という事で、いよいよProxyが怪しくなってきた。
ここまで来たらパケット直視した方が楽なので、久々にtcpdumpとwiresharkを起動。
ClientPCとProxyの2箇所で同時に、
www.lumpofsugar.co.jpのindex.htmlを閲覧した時のパケットキャプチャを実施してみた。

[左]：Proxy未設定で直接Webサイト閲覧
[右]：LSLBを使わずProxyを直指定でWebサイト閲覧

キャプチャは、LocalCache・Cookieとかも全消去して環境を出来る限り揃えた状態で実施。
結果、なんとなく方向性の見える結果が出てきた。
今回重要なのは、右側のProxy利用時はTCP Retransmissionが出ている点。
ざっくり言うと、www.lumpofsugar.co.jpからACKが返ってこなかった為、TCP再送要求が発生していた。

コレが判ればしめた物。後はキャプチャ結果を解析していけば良い。
という事で同様のパケットキャプチャを数回実施して、3日程パケットをみつづけてみた。
結果、www.lumpofsugar.co.jpへ接続しに行った時のみ、次の特長が発生している事が判明した。

1. Proxy有無に関係無く「TCP Retransmission」が発生するがProxy越しの方が圧倒的に多い
2. Proxy無しの場合、最初にTCPコネクションを数発張った後、エラーが出つつもデータを受信している
   Proxy有りの場合、最初にTCPコネクションを20発位張って、データを取得しようとしている
3. Proxy有りの場合、HTTP/503、HTTP/504の応答が多かった

ここでなんとなく思い当たる節が。

以前、別件でTCPコネクション過多によるWebサーバ応答不能のデバッグをやった事があった。
その時は、Webサーバ側に仕込んであったIPアドレス毎のセッション数制限に引っかかり、
Webサーバ側で遮断・ACKも返さなくなった為、クライアント側ではパケットが途中で破損してしまい、
HTTP/503などエラーが表示されてしまう事例があった。

『今回もコレなんじゃ…？』と思い、クライアントPCの同時コネクション数を一時的に上げてみた所、
Proxy有りの場合と同じく、エラー状況を再現出来た。と、言ってもProxy有り程の顕著な物では無かったが…
ともあれ、状況の再現性を確認出来たので後はコレを解決出来る手段を見つけるだけとなった。

～ Phase.4 打開策検討 ～

次は「Proxy越しにアクセス出来る」様にしないといけないので、
ProxyでoutboundのTCPコネクション数をClientPC(Win10-1703)程度まで減らす制御出来るのか調査。
というのも、Proxyでは受信したデータを一度蓄積した後、
一気にTCPコネクションを張りに行っている(様な)挙動をしていた事から、
「IPアドレス・ドメイン毎のTCPコネクション数を制御出来れば何とかなるのでは？」と考えた為。

今回、物は試しで、Proxyは「Squid / Delegate / WinGate」の3種類、
OSは「Linux(CentOS7) / Windows(WindowsServer2012R2)」の2種類、
LinuxについてはkernelのTIME_WAIT時短設定なども実施してみた。

が力及ばず、自分の知識・技術では実現出来なかった出来なかった (´・ω:;.:…
自分がテストしたが出来なかったのは下記の通り。
Proxyに詳しい御方、やり方知っていたら教えて下さい…

• Squid
  [pipeline_prefetch on/off]
  [half_closed_clients on/off]
  [detect_broken_pconn on/off]
  [client_persistent_connections on/off]
  [server_persistent_connections on/off]
  　
• Delegate
  ※細かいオプション知らないので接続テストのみ。が、あえなく撃沈
  　
• WinGate
  ※そもそも使い方がよく判らないのでProxy越しに見れるかのみ。が、あえなく撃沈

～ Phase.5 ワークアラウンド ～

結局の所、自力では解決出来なかったので今回は諦めた (´；ω；｀)
と言いつつもワークアラウンドは必要なので、今回はProxyPACで制御する事にした。

Phase.2記載の通り前段に構えているProxyPACで、
『”.lumpofsugar.co.jp”ドメイン宛の通信は直接(DIRECT)取得』というルールを追加した。
ProxyPACに色々と記載するのは嫌なのだが、こんな事もあろうかとPAC構成にしておいて事なきを得た。

$ vi proxy.pac

-----

function FindProxyForURL(url, host){
  // Direct access for URL
  if ( dnsDomainIs(host, ".lumpofsugar.co.jp")){
    return "DIRECT";
  }

  // Default PROXY
  return "PROXY [[ProxyFQDN:PORT]]";
}

～ Phase.6 追加調査 ～

ここまでやって解決出来ないのは敗北感が凄いので、調べられる範囲内で情報を引っ張ってみた。
下記はInternet上から取得出来る内容なので、興味ある人は迷惑掛けない程度に調査してください。
ちなみに、筆者は中の人では無い事と、下記情報の正確性担保はしない事を宣言しときます。

• ドメイン：www.lumpofsugar.co.jp
• アドレス：124.146.200.148
• 鯖事業者：WebARENA Suite V1/V2

グローバルIPのAS番号、ドメインのネームサーバ情報、whoisの情報、
DNSのSPF登録情報、などを相関的的に分析した結果だが結構良い線行っている筈。

もし本当にWebARENAを使っているのならば、
ホストを共有している他サーバに引きずられるかもしれないし、
今回の様なコネクション断は仕方ないのかもしれない (´・ω・｀)

………

なんとも煮え切らない結果となってしまったが、技術で解決出来る(殴れる)所はなんとかしたい所。
他サイトで発生する事もあるだろうし、何か解決案が無いか長期的に探っていこうと思う。
今回のワークアラウンドを実施する事で、Lump of Sugar新作ページを見れたので一言。

「木那里もみじ」が可愛すぎる！　(*´Д`)ﾊｧﾊｧ

「ケモ耳＋セミロング＋ニーソ」と色々ぶっ込んできているが､
個人的には大歓迎です (｀・ω・´)
主題歌もKiccoさんだし発売が待ち遠しい。

« 続きを隠す

続きを読む »

コアの部分はiBGPにstaticとconnectedを再配布する構成にしてみた。
本当はクライアントPCセグメントでOSPFを喋らせて、BGPとOSPFで再配布したかったのだが、
Cisco 1812JでIPv6のVRFを使っているインターフェースではOSPFv3を喋れない事が判明し、
今回は断念してstaticでルーティングを切った。

あと、本業でBGP取り扱っている人には怒られそうだが、
各BGPスピーカーでピアを張るのが面倒くさかったので、Cisco 1812Jにルートリフレクタも兼用させ、
他のスピーカーからピアを張る形にしてセッション数削減。
こうした事で、別ベンダー装置のBGP検証を行う時も、
ルートリフレクタのみにピアを張ればルーティングテーブルを取得出来るようにした。

今回のキモとなったのは、実はJuniperSRX100の方だった。
今までJuniper製品を殆ど触った事が無いのと、
DefaultRouteをBGP網に流しつつも他NWへ「お漏らし」しないようにフィルタリングしたり、
loopback I/FからBGPのセッションが張れなかったりと四苦八苦した。
最終的にはACL制御をミスってloopback宛の通信をAnyDenyしていたり、
アドバタイズするプレフィックスをミスっているだけだったのだが、
原因調査の過程でコマンドを色々触ったので勉強になった。

FortigateのBGPは難なく設定が完了した。が、NAT64の方でハマった…
NAT64のフューチャーをenableにして、NAT64ルールを作成しても一向に通信出来なかった。
最後の方では、Fortigate上でパケットキャプチャ、デバッグモードでフロー確認もしたのだが、
「”64::FF9B::/96″宛のルーティングテーブルが無い」と言われているだけで謎だった。
海外のサイトも漁った所、「再起動するヨロシ」と書かれていたので再起動を試した所、
NAT64で接続が出来てしまい『自分の苦労は何だったんだろう…』と思ったが、
まぁこんな事もあるだろう _(:3」∠)_

………

着々と進んでいる”ns-lab BB”のIPv6対応だが、
今回の構築を行った事で、BGPの検証環境とNAT64実環境を構築出来たのは収穫。
自分が作成したコンフィグは、レベルが低くて公開出来るレベルでは無いのだが、
時間ある時に公開もしてみようと思う。
折角なので、コンフィグの一部を公開。

………

• Juniper SRX100

interfaces {
    lo0 {
        unit 0 {
            family inet6 {
                address 2001:470:FDB0:FFFF:FFFF:FFFF:FFFF:100/128;
            }
        }
    }
}
routing-options {
    rib inet6.0 {
        static {
            route ::/0 next-hop "DefaultRouteの向け先";
            route 2001:470:FDB0:FFFF:FFFF:FFFF:FFFF:1812/128 next-hop "Cisco1812JのIPv6アドレス";
            route 2001:470:FDB0:FFFF:FFFF:FFFF:FFFF:60/128   next-hop "Fortigate60DのIPv6アドレス";
        }
    }
    router-id 10.0.0.100;
    autonomous-system 65000;
}
protocols {
    bgp {
        export AS65000 {
        group GROUP_AS65000 {
            type internal;
            local-address 2001:470:FDB0:FFFF:FFFF:FFFF:FFFF:100;
            log-updown;
            family inet6 {
                unicast;
            }
            neighbor 2001:470:FDB0:FFFF:FFFF:FFFF:FFFF:1812;
        }
    }
}
policy-options {
    policy-statement AS65000 {
        term redistribute {
            from {
                protocol static;
                route-filter ::/0 exact;
            }
            then {
                next-hop self;
                accept;
            }
        }
        then reject;
    }
}

………

• Cisco 1812J

interface Loopback0
 vrf forwarding vrf_ipv6
 no ip address
 ipv6 address 2001:470:FDB0:FFFF:FFFF:FFFF:FFFF:1812/128
 ipv6 nd router-preference High
!
vrf definition vrf_ipv6
 rd 10.0.18.12:6
 !
 address-family ipv4
 exit-address-family
 !
 address-family ipv6
 exit-address-family
!
router bgp 65000
 bgp router-id 10.0.18.12
 no bgp default ipv4-unicast
 bgp log-neighbor-changes
 !
 address-family ipv4 vrf vrf_ipv6
  no synchronization
 exit-address-family
 !
 address-family ipv6 vrf vrf_ipv6
  neighbor 2001:470:FDB0:FFFF:FFFF:FFFF:FFFF:100 remote-as 65000
  neighbor 2001:470:FDB0:FFFF:FFFF:FFFF:FFFF:100 update-source Loopback0
  neighbor 2001:470:FDB0:FFFF:FFFF:FFFF:FFFF:100 activate
  neighbor 2001:470:FDB0:FFFF:FFFF:FFFF:FFFF:100 route-reflector-client
  neighbor 2001:470:FDB0:FFFF:FFFF:FFFF:FFFF:60  remote-as 65000
  neighbor 2001:470:FDB0:FFFF:FFFF:FFFF:FFFF:60  update-source Loopback0
  neighbor 2001:470:FDB0:FFFF:FFFF:FFFF:FFFF:60  activate
  neighbor 2001:470:FDB0:FFFF:FFFF:FFFF:FFFF:60  route-reflector-client
  redistribute connected
  redistribute static
  default-information originate
  no synchronization
 exit-address-family
!
ipv6 route vrf vrf_ipv6 2001:470:FDB0:FFFF:FFFF:FFFF:FFFF:100/128 "JuniperSRX100のIPv6アドレス"
ipv6 route vrf vrf_ipv6 2001:470:FDB0:FFFF:FFFF:FFFF:FFFF:60/128  "Fortigate60DのIPv6アドレス"

………

• Fortigate 60D

config system interface
    edit "loopback1"
        set vdom "root"
        set type loopback
        set snmp-index 1
        config ipv6
            set ip6-allowaccess ping
            set ip6-address 2001:470:FDB0:FFFF:FFFF:FFFF:FFFF:60/128
        end
    next
end
config router access-list6
    edit "bgp-nat64"
        config rule
            edit 10
                set prefix6 64:ff9b::/96
                set exact-match enable
            next
            edit 20
                set action deny
                set exact-match disable
            next
        end
    next
end
config router route-map
    edit "bgp-route-map"
        config rule
            edit 10
                set match-ip6-address "bgp-nat64"
            next
        end
    next
end
config router static6
    edit 1
        set dst 2001:470:FDB0:FFFF:FFFF:FFFF:FFFF:1812/128
        set gateway "Cisco1812JのIPv6アドレス"
        set device "wan2"
    next
    edit 2
        set dst 2001:470:FDB0:FFFF:FFFF:FFFF:FFFF:100/128
        set gateway "JuniperSRX100のIPv6アドレス"
        set device "wan2"
    next
    edit 3
        set dst 64:ff9b::/96
        set gateway 2001:470:FDB0:FFFF:FFFF:FFFF:FFFF:60
        set device "loopback1"
    next
end
config router bgp
    set as 65000
    set router-id 10.0.0.60
    config neighbor
        edit "2001:470:FDB0:FFFF:FFFF:FFFF:FFFF:1812"
            set remote-as 65000
            set route-map-out6 "bgp-route-map"
            set update-source "loopback1"
        next
    end
    config redistribute6 "static"
        set status enable
    end
end

« 続きを隠す