DigiLoog

続きを読む »

ゲーム本編の感想は前回の記事を参照。今回は9-nine-全年齢版と新章に焦点を当てようと思う。
例の如くゲームのネタバレを含むので、未プレイの人は先にゲームをプレイすべし。

………

• シナリオ・システム・攻略順

都BADエンドの回避と各章ハッピーエンド後のエピローグを描いた内容だった。
導入は翔と与一がバトルに突入する所からスタートし、都の一撃で落ち着かせてからエピローグへ繋がる。
全年齢版という事もありエ○シーンは存在しないのだが、エ○必須の天ルートも上手く纏めてあった。
どうしようも無かったのか入浴シーンは白背景に差し替えられているが、ほぼ違和感無く読み進められる。

シナリオ容量が230KByteと事前公表されていた事もあり文量は覚悟していたが、
ロープライスFDである事を考慮してもシナリオが少なかったのは残念だった。
時間を計測していないので厳密には判らないが、音声聞きつつ時々クリックで4～5時間程で終わったと思う。
価格が元の単品ゲームレベルでも良いので、もうちょっとボリュームを増やして欲しかったのが本音。

シナリオ代わりなのかも知れないが、パッケージ版では声優インタビューが入っていたのは嬉しかった。
インタビューを聞くと、如何に「ぱれっと」スタッフの情熱が注がれたゲームなのかが伝わってきた。
声優インタビューはエ○ゲだと出来ない芸当なので、本作を全年齢版にした一番のメリットがコレになる。
9-nine-の作品が好きな人は必聴物だが、如何せんDL版にはコレが含まれていなそうなのが残念。

FDという事もありシナリオ攻略順はほぼ固定となっている。
1か所だけ選択肢があるのだが、確認した限り選択がシナリオ分岐に影響はしていなかった。
シナリオ分岐に影響は無さそうだが、選択次第で都の珍しい表情を見られるのでセーブしてでも見てほしい。
でも、本編をプレイした人ならあのシーンで「しない」を選ぶ筈なので無意識に見ているかもしれない。

………

• 主題歌・ムービー

本編同様に米倉千尋さんが本作の主題歌も担当。
OP曲はBPM140なので他と比較するとスローテンポなのだが、
作りが物語のクライマックスを彷彿とさせる壮大な編曲となっており、疾走感も感じる事が出来る。

歌詞は様々な捉え方が出来るが、素直に捉えるならEpisode.4最後のラスボスシーンを彷彿とした。
9-nine-全年齢版のパッケージを購入しているなら同梱サントラにフルサイズが収録されているので、
歌詞含めてじっくり聞いて欲しい。

グランドED曲も言わずもがな素晴らしいが、曲以上に物語最後の下りからエンディングに入る流れが鳥肌物。
この盛り上げ方が好きな筆者にとっては、シナリオの流れ含め「最高の結末」となった。
エンディング動画は飛ばさずに全て見て、今までの9-nine-プレイに浸りながら曲に聴き入って欲しい。

冒頭に書いた通り半日もあればフルコンプ出来るので、外からの情報を全て絶って集中できる状況を作りつつ、
9-nine-新章のスタートからエンディングまで突っ走れば、より一層染みてくると思う。

………

分割商法は他ゲームでも良くあるので内容が良ければ分割でも気にしないのだが、
9-nine-全年齢版の分割商法は露骨過ぎたのは否めないと思う。
エ○ゲ業界が下火であり資金繰り観点やマーケティング戦略で必要だったのかも知れないが、
ライトユーザ・コアユーザの双方に優しい販売方法にしたらトレンドに出るレベルの炎上はしなかったと思う。
シナリオ・キャラクタ・背景・BGM・主題歌と、全てのゲーム要素が近年まれに見るSクラスなのに、
9-nine-新章の販売戦略でコケてしまったのは何とも残念と言える。

上記の様にマイナス部分はあるが、それを考慮しても9-nine-のゲームは全てが高レベルで仕上がっていた。
9-nine-は周回でゲームの良さが出てくるシナリオなので、
1周で終わらしてしまった人は、内容を忘れない内にゲーム中の「あの日」に戻って2周目に突入して欲しい。
筆者もコレから「あの日」に戻って5周目でもしてこようと思う。

一旦、9-nine-シリーズの展開は一段落となるがメディアミックスしそうな気もするのが本音。
だが何時までも同じゲームに乗っかるのでは無く、
エ○ゲだからこそ出来る和泉つばす先生×ぱれっとの鉄板コンビ新作を期待したい。

« 続きを隠す

続きを読む »

• BGPがEstablishedなのにフルルートを受信出来ない

最初にコレが発生したので非常に困った (´・ω・｀)
ネクストホップが存在せずルーティングに乗らないのは良くあるが、そもそも受信してくれなかった。

自宅ラボの検証環境も用いてルーティングを確実に受信出来るコンフィグを投入し、
BGP StateももEstablishedに遷移しているのにピアからルーティングが一向に来なくて途方に暮れた。
どうやっても自力で解決出来なかったので、Vultrサポートに下記の問い合わせを投げた所、
「設定ミスっていたわ。ゴメン！」と返答が来て無事にフルルートを受信出来る様になった。

Dear Vultr Support,
After receiving the ticket "XXX-XXXXX",
  I installed CentOS and FRRouting on my server instance and configured BGP peer.
I was able to set up a peer with Vultr BGP router,
  But after 2 days, I still can't receive a full route.
The configuration of FRRouting and the status of the peer are as follows.

- FRRouting Config
> AS20473# show running-config

- BGP neighbor
> AS20473# show ip bgp neighbors

I think the FRRouting settings are correct,
  But is there any reason why I cannot receive BGP full routes?
Also, can you tell me the status of the Vultr facility?

Regards, XXXXXX.

英文を全く書かないので文法が正しいか判らないが、コレで伝えたい事は上手く伝わった模様。
文で説明するのが面倒だったので、コンフィグとステータスを載せたのが良かったのかもしれない。
もしも、BGPピアを張れない状態になったら遠慮無くサポートに助けを求めると良いと思う。

• サーバスペックとプリペイド料金を迷う

Vultrのサーバはスペック毎に通信量が設定されており、通信量を超過すると面倒臭い事になる。
さらに、支払いは事前にお金を払うプリペイド方式がメインとなっており、
サーバで動かしたいサービスの通信量を予測しながらサーバスペックを選択して支払う必要がある。
勿論、利用分のみクレジットカードで引き落とす事も出来るらしいが、
筆者はオーソドックスにクレジットカード支払いプリペイド方式で払った。

ココで問題となったのはサーバスペックの予測が付かず、インスタンス選定に難儀した事。
という事で、実際に14日間起動しっぱなしにしつつ、
思い出した時にBGPステータスを表示するコマンドを打ち込んだ通信量が次の通り。

意外と通信量を抑える事が出来た (｀・ω・´)
コレはVultrのインスタンスFWでBGPセッション用のTCP:179と、
サーバ管理用のTCP:22以外を全部遮断する事で不要なトラフィックが来なくなった結果だと思う。
LookingGlass用途ならフルルートを受信しつつルータのコマンドさえ打てれば良いので、
通信対象を絞る事で気にする必要が無くなる。

メモリの方はフルルートを処理する為に2GB位の容量が必要になってくる。
Linuxを最適化すればワンランク下の1GBメモリでも動くと思うが、
2GBメモリでもモタつく時があったので止めた方が賢明だと思う。

• BGPフルルートを受信出来るコンフィグがわからない

根本的な話だがフルルートを受信するコンフィグを書いた事が無いので手探りだった。
ググればCiscoやJuniperのBGPサンプルは出てくるが、FRRoutingの様にLinuxルータの物は皆無となる。
という事で、筆者が実際に使ったFRRoutingでBGPフルルートを受信するサンプルコンフィグを載せておく。

AS20473# show running-config
Building configuration...

Current configuration:
!
frr version 7.0
frr defaults traditional
hostname AS20473
log file /var/log/frr/frr.log
service integrated-vtysh-config
!
ip route 169.254.169.254/32 207.148.XXX.ZZZ
ipv6 route 2001:19f0:ffff::1/128 fe80::fc00:XXX:ZZZ:1
!
interface eth0
 ip address 207.148.XXX.YYY/23
 ipv6 address 2001:19f0:7001:5aa7:WWW:XXX:YYY:ZZZ/64
!
router bgp 4288000AAA
 bgp router-id 207.148.XXX.YYY
 neighbor 169.254.169.254 remote-as 64AAA
 neighbor 169.254.169.254 password BGPPASSWORDXXXXX
 neighbor 169.254.169.254 ebgp-multihop 2
 neighbor 169.254.169.254 disable-connected-check
 neighbor 169.254.169.254 update-source 207.148.XXX.YYY
 neighbor 2001:19f0:ffff::1 remote-as 64AAA
 neighbor 2001:19f0:ffff::1 password BGPPASSWORDXXXXX
 neighbor 2001:19f0:ffff::1 ebgp-multihop 2
 neighbor 2001:19f0:ffff::1 disable-connected-check
 neighbor 2001:19f0:ffff::1 update-source 2001:19f0:7001:5aa7:WWW:XXX:YYY:ZZZ
 !
 address-family ipv4 unicast
  neighbor 169.254.169.254 soft-reconfiguration inbound
  no neighbor 2001:19f0:ffff::1 activate
 exit-address-family
 !
 address-family ipv6 unicast
  neighbor 2001:19f0:ffff::1 activate
  neighbor 2001:19f0:ffff::1 soft-reconfiguration inbound
 exit-address-family
!
line vty
!
end

ひとまず動けばOKのコンセプトで書いたのでセキュリティ設定などは追加で入れる必要がある。

ハマりポイントとしては、BGPピアと接続出来る様にスタティックルートを書いておかないと、
BGPセッションを張れてもフルルートがルーティングテーブルに載らなくなる。
OSに細工をするとスタティックルートを書かなくてもフルルートがルーティングに載るのだが、
今回の構成で手っ取り早く確実にルーティングを載せる方法はスタティックルートの設定だった。

………

Vultrは日本であまり聞かない事や管理画面が英語なので敬遠しがちだが、
AWSや国産VPSで無い面白い機能も実装されているのでエンジニアなら1回は触ると良いと思う。
筆者も初めてVultrを触ってみたが遊び程度なら意外と使い物になる事がわかったので、
作って壊す用途でまた契約するかも知れない。

という事でフルルートを受信する事が出来たので、これからインスタンスを削除してこねば。

« 続きを隠す

続きを読む »

攻撃内容は、海外のグローバルIPと国内キャリア偽装グローバルIPから同時にSYNフラッド攻撃が来た。
“ns-lab”では要所に攻撃緩和や自動遮断の仕組みがあるのでロードバランサ・メールサーバは耐えたのだが、
入り口となるFirewall兼NATルータでセッションテーブルが飽和してしまい、対外接続が不安定になった。

ちなみに、”ns-lab”のシステムは全てzabbixで監視しつつ各種ログはsyslogで集約化もしているので、
攻撃内容をリアルタイムで確認しつつ、この記事の様に後から分析する事が楽に出来た。

構成図の”#01″に当たるFirewallの監視ステータスがこちら。左がICMP死活、右がCPU負荷で表示してる。
CPU負荷が突出しているタイミングがあるがバッチ処理の負荷なので対象外。
見るべきなのは、ICMP死活監視が落ちて0の所とCPU負荷監視が取得出来ていない所の2箇所。
コレはセッションテーブルが飽和してしまい、監視用の通信も通らなくなった為に起きた物となる。

Firewallのエラーログはこちら。FirewallにはIIJ SEILを使っているので、ログの見方はドキュメントを見るべし。
“nat session is full”と出ている通り、SYNフラッド攻撃によってNATテーブルを食い潰していた。
セッション維持時間やFirewallポリシーは結構テコ入れしているので、今までに落ちた事は1回位しか無いのだが、
その設定を上回る通信が来たのでセッションを捌ききれなくなった。

攻撃が来ていた時にサーバでセッションを確認した所、見事にSYN_RECVが大量に並んでいた。
画像は10行のみ表示しているが、目視で5,000は軽く超えていたと思う。
攻撃元セグメントは普通のSYNフラッド攻撃がアフリカ辺りの”/24″ブロックから、
グローバルIP詐称型攻撃は国内のISP・キャリア偽る形で合計10箇所位からが同時に来ていた。

………

流石に放置するのは不味いので、Firewallポリシー調整とサーバで通信を遮断。
さらに、全サーバにiptables遮断ルール追加と攻撃緩和用ブラックリストの反映も行った。
コレを行う事で、Ansibleで別途仕込んでいる攻撃自動遮断と連携しながら、
FirewallのNATセッション時間調整とルーティング操作でパケットも捨てられる様になっている。

サーバでサイレントドロップすると、途中のFirewallでは通信を片方向SYNとして捉えさせる事が出来る。
所謂、エンタープライズのFirewallならNATセッションの廃棄時間を、
通信プロトコルや3ウェイハンドシェイク毎に決められるので、
SYNのみの通信のセッション破棄時間を短くすると簡単な防御に仕立てる事が出来る。

BGPを使っているならRTBH(Remotely Triggered Black Hole Filtering)をする事でnullに落とす事も出来る。
FirewallでBGPを喋るのが難しいなら、PBRでも似たような子とが出来るのでお試しあれ。
流石に企業やデータセンターで利用する様な本気の攻撃防御には全然届かないが、
この様な事をやれば自宅サーバを守る程度なら対応する事が出来たりする。

………

自宅サーバと言えどもインターネットにサーバを晒すなら攻撃が来るのは当たり前だが、
今回は久々に手の込んだ物が来たので実際に筆者が実施している防御の一部を記事にしてみた。
世の中にはもっと上を行く自宅ラボやDDoS専用装置を所有している誤家庭もあるが、
やり方次第では対策出来る場合もあるので、参考に出来そうなら防御のヒントにでもして欲しい。

« 続きを隠す