DigiLoog

続きを読む »

Squid公式wikiにも記載されている”tcp_outgoing_address”を使う方法が良く出てくるのだが、
コレはSquid 5.xでは動作しない地雷設定となる。
Magic ACLとして宛先FQDNのDNS名前解決をして動かす意図の様だが、
前提となる”tcp_outgoing_address”を動作するす条件に合致しないのでトラフィック分散が機能しない。

• Squid Web Cache wiki > IPv6 in Squid

squid.conf.documentにも書いてある通り、
“tcp_outgoing_address”は送信元アドレスかユーザ認証Proxy時のユーザ名でのみ動作する。
その為、wikiに書いてある様な宛先FQDNのAAAAレコード有無で通信先を切り替える事が出来ない。

DNSキャッシュサーバでDNS応答レコードを細工してAAAAレコードとDNS64に変換する手法もあるが、
サーバ用途でDNS応答を改ざんすると他サーバの挙動にも影響が出そうなのでやらない方が良い。
DNS64はNAT64も必要なのでハードルが高い上、
IPv6からIPv4へ通信する時にアドレス変換を挟むので通信自体への影響が大きい。

それなら、Happy Eyeballsの挙動をLinux Kernelでチューニングする方法も考えたのだが、
該当しそうなパラメータがLinux Kernelに見当たらなかったのであきらめた。
最新のソースコードを読めば追加オプションが出てきそうだが、
筆者環境のサーバでKernelビルドは開発環境以外はやらない様にしたので結果として使えない。

他にもPACファイルを使ってDNS名前解決を応用しつつ振り分ける手法も検証してみたが、
どれも上手くいかず没になった。

WindowsにNICを追加してIPv4とIPv6でそれぞれ通信出来る様にもしてみたが、
何故かIPv4を優先して通信してしまいやりたい事が出来なかった。
NICを1本にしてデュアルスタックにする事も手だったのだが、
匿名IPv6の扱いとかも設計する必要が出てきたので同様に没に。
そもそも、サーバと端末のNW設計を変更する必要が出てくるので簡単に出来るレベルではなかった。

普通の用途ならHappy Eyeballsに従う実装で問題無いが、
筆者環境ではIPv6を優先する動きに固定したかった為、諦めてSquid 4.xへダウングレードする事にした。
いつかはアップグレードをする必要はあるが、ちゃんと設計してからの方が良さそうなので、
バックボーンを大幅アップグレードする時の課題にしようと思う。

« 続きを隠す

続きを読む »

参考サイト

• Kaspersky > SquidサービスでのSSL Bumpの設定
• 技術メモメモ > SquidのSSL Bumpを使ってHTTPS(SSL)通信を可視化する
• Mailing lists > [squid-users] SSL_bump and source IP

SSL複合化を仕込むのはSquidだが、
前段にリバースプロキシ型の負荷分散装置を挟んでいるので一種の多段Proxyと同じになる。
この良くある負荷分散構成がクセ物で、通信次第でアクセスログを正しく記録出来ない場合がある。

Squidが負荷分散装置配下で動いている場合、
HTTPヘッダに追加されたX-Forwarded-Forを参照する事でクライアントPCのIPを識別するのだが、
SSL複合化をした時点でクライアントPCのIPがパケット上は無くなるらしく、
クライアントのIPではなく負荷分散装置のIPになる場合が出てくる。

エンタープライズ環境でアクセスログのIPが正しく記録出来ないのは大問題だが、
今回は自宅サーバなので深追いはせずに使ってみた。

………

前述の通りロードバランサはSSL通信をそのままバイパスさせて、
SquidでSSL Bumpを設定する事でSSL複合化を実装したのだが、
この構成の大きな課題はSSL複合化・再暗号化の処理をSquidで実装する所にある。
ぶっちゃけ、どれだけCPUコアを積んでも処理が確実に追いつかなくなる。

SSL複合化は設定せず、秒間30セッションのSSL通信を普通に処理している状況が上の画像となる。
CPUコアは2コアでメモリは6GB積んだサーバでテストしてみた。
Squidの負荷が高騰するのは新規セッションが張られた時なので、
SSL通信をCONNECTメソッドで素通ししているだけなら以外とCPU負荷は高騰しない。
大容量通信を流すとCPU負荷も上がるが、パケットを捌いている影響なので問題とはちょっと違う。

コチラが同条件の秒間30セッションを出しつつSSL複合化を実施している時の負荷状況となる。
2コアなので負荷がかかりやすい環境ではあるが、平常時とは比にならない高付加になっている。
CPUコアを増強してSquidのworkerをCPUコア最大まで増強すればある程度緩和が出来るが、
CPU負荷が上がってしまう点はどうしようも無いので完全解消にはならない。

分かっていた事だが、SquidでSSL複合化を実施するにはサーバと負荷分散が前提となる。
今回は自宅サーバだから適当でも良いが、
それを加味しても負荷が高すぎて使い物にならないので、宛先を限定してSSL複合化する事にした。
コレが意外と大変でログが記録されない問題と戦いながらテストしたら年末年始が溶けた (´・ω・｀)

………

年末年始を使って調査した特定の宛先のみSquidでSSL複合化をする設定は次の通り。
細かい部分はググれば出てくるので割愛するがバックスラッシュの部分を1行で書けば動く。
設定が出来たら意外とあっけなく、SSL Bumpをpeek・bump・spliceに分割するだけで動いた。

acl step1 at_step SslBump1
acl sslbump dstdomain .example.co.jp
acl sslbump dstdomain .example.ne.jp
 
http_port 8080 tcpkeepalive=60,30,3 ssl-bump generate-host-certificates=on \
    dynamic_cert_mem_cache_size=16MB                                       \
    tls-dh=prime256v1:/usr/local/squid/etc/dhparam.pem                     \
    cert=/usr/local/squid/etc/squid.crt                                    \
    key=/usr/local/squid/etc/squid.key                                     \
    cipher=HIGH:MEDIUM:!LOW:!RC4:!SEED:!IDEA:!3DES:!MD5:!EXP:!PSK:!DSS     \
    options=NO_TLSv1,NO_SSLv3,NO_SSLv2,SINGLE_DH_USE,SINGLE_ECDH_USE
  
sslcrtd_children 5
sslcrtd_program  \
    /usr/local/squid/libexec/security_file_certgen -s /var/squid/sslcrt -M 16MB
 
sslproxy_cert_error allow all
ssl_bump peek       step1
ssl_bump bump       localnet sslbump
ssl_bump splice     all

サンプルではACLにlocalnetを設定しているが、SSL複合化をしたいクライアントIPのACLを作り、
localnetの部分を差し替えれば複合化対象を限定する事も出来る。
この辺りのACL基本構文はSquidのACL挙動と同じだった。

………

設定が出来た後に問題になるのは、SSL複合化をする宛先ドメインのリスト化となる。
Webブラウザのアクセス先がwww.example.co.jpだとしても裏では様々な所にアクセスしているので、
SSL複合化対象には全部登録する必要がある。
Squidのアクセスログから調査しても良いが面倒なのでSSL証明書のSANsからぶっこ抜いた。

次の様なコマンドで証明書のSANsをリスト化出来るのでコレを元にスクリプトを組めば良い筈。
しかし、Squidは1個のACLに重複したドメイン・サブドメインがあるとエラーになるので、
上位ドメインが登録されていないかチェックする機構が必要になる。
筆者は手抜きしたかったのでSquidの書式チェックコマンドで都度確認してみた。

openssl s_client -connect example.co.jp:443 -showcerts < /dev/null \
    openssl x509 -text | fgrep DNS | tr ', ' '\r\n' |              \
    sed -e "s/DNS://" -e "s/^\*//" | sort -nf

www.yahoo.co.jpのSSL証明書には大量のSANsが登録されているので参考になる筈。
スクリプトを作り込めば自動化も出来そうだが、
その規模だとエンタープライズ環境だと思うので専用設備の導入を絶対に推奨する。

………

SSL複合化は負荷がかかると言われるので実際にやってみたが、
CPU使用率が予想以上に高騰したのでエンタープライズの環境で常用するのは無理と感じた。
自宅サーバでテストする位ならアリだが、それでも複合化対象のドメインは厳選する必要がある。
とは言っても、一度セッションを張れば通信速度は出るので環境次第では使えるかもしれない。

筆者の環境ではサーバもガッツリとチューニングした上で実環境で試しているが、
1週間使っても特に問題は出ておらず、Twitterも使えたしYoutubeとかも見る事が出来た。
もう少し確認は必要だが、前述のログ問題以外は正常に動作しているので、
お遊びでサクッと使う程度ならアリだと思う。

« 続きを隠す

続きを読む »

購入物紹介は後にしてサークル参加のレビューから。

開会宣言は自サークルで売り子していたので着席しながら開場拍手を迎える事となった。
オリンピック前のコミケだと10:00に拍手していた覚えがあったが、
今回は10:30に変更となっており若干面食らった。

サークルが西地区だったので開会直後は殆ど人は来ず昼過ぎから会場が混みだした。
そんな中でも、立ち寄りが20人を超えた辺りからコミケに帰って来た感じがして懐かしくなった。
今回は久々にサークル参加したので冊子作製もリハビリ感があったのだが、
複数人がサークルチェックをした上で立ち寄って頂けたのも嬉しい限り。

売り子をしている時、とある方が言っていてC101で一番印象に残ったのが、
コミケの為に技術書を書いて頒布している事についての絶賛で、
そのお方から冊子に出来る人は凄いとお褒めの言葉を頂戴した。
直接の声はリアルじゃないと得られないし、コレがあるからコミケにやはり出したくなる。
しかし、筆者は好きな事を自分のポリシーに従い好きな様に書いているだけだったりするので、
もしもご本人がコレを読んでいただけているなら、自身が好きな事を徹底的に書いてみて欲しい。
スタートは調べる事が多くて大変だが経験すれば同人誌を出す醍醐味を実体験できる。

他には、ちょくちょくコピー本に拘っている理由を聞かれたので一応書くが、
筆者が書きたい物を自由に出せるフットワークの軽さと、値段を100円で頒布する為だったりする。
印刷所に頼んでオフセット本にすると装丁も綺麗で映えるが、値段を上げざるを得なくなる。
自身の同人誌ポリシーとして様々な人が手に取って試して貰いたいのが根源にあるので、
価格を抑える為にも100円コピー本に拘っている。
コレは余程の事が無い限り変えないと思う。

………

話は変わり、今回のコミケで購入した物は次の通り。
途中から巡回した事もあり一筆書きの要領で回ってみた。

[NANACAN (ななかまい)] 新刊セット：2,000円

[祭社 (ななろば華)] 新刊セット：2,000円

[きのこのみ (konomi/kino)] スペシャルグッズセット：4,000円、kino新刊：500円

[Marvelous Grace (立羽)] C101新刊7点セット：3,000円

[Chriocity (やたぬき圭)] C101新刊グッズセット：2,000円

[無人少女 (梱枝りこ)] 新刊セット：2,500円

[木漏れ陽ぱれっと (にいち)] 新刊4点セット：1,000円
[ApplePie (柊林檎)] 新刊：500円
[RE:moon (ねむりねむ)] 子2冊：1,000円

[日本openSUSEユーザ会] 新刊：500円
[らぼちっく；げーと] 冊子3冊：1,800円

合計金額：20,800円

2日目しか参加しなかったのと大金になりやすい抱き枕カバーが1個も無かったのもあるが、
色々と買った割には値段が上がらなかった方だと思う。
その分、毎回行っている所に行きつつ普段は長蛇の列で寄らない所にもサクッと行けた。
技術書関連も合同誌を4冊入手したので時間を見つけて少しずつ読み進めなければ。

………

企業ブースは一瞬しか行かなかったが、Navelでそれ散るOPの新verを流していたのが印象的だった。
BasiLの完全版とは違うNavelの考える完全版が出来上がるのを何年待った事か。
今年の5月に発売予定なので待ち遠しいしOPを早くフルで聞きたい。

………

イレギュラー続きのコミケだが、イレギュラーは次回も続く様で8月開催のC102も2日間になる。
入場制限もかかる可能性が非常に高いし、フラっと参加して立ち寄る人には敷居が高すぎるのが困りもの。
始発で参加は疲れるし正直な所何回もやりたくは無いが、
とは言っても始発参加して夜明けを迎えるお祭り感覚が忘れられない。
一種のランナーズハイな状態だと思うが、だからこそコミケと言える状況で参加したい。

前述の通り現地参加するからこそ得られる物やモチベーションは同人の醍醐味なので、
諸々の事が早く落ち着いて以前の様にフリーで参加出来るコミケに戻ってくれる事を強く願う

« 続きを隠す