Hatena::ブログ(Diary)

eggshell blue

2017-07-18

iptables と ipset で鎖国ルーターを作る

| iptables と ipset で鎖国ルーターを作るを含むブックマーク iptables と ipset で鎖国ルーターを作るのブックマークコメント

副題: Splatoon 海外勢に慈悲はない(2 に間に合って良かった)

1年ちょっと前に Planex が「鎖国ルーター」を発表しました。あまり話題にならなかったのですが、実態は日本国内および米国割り当てのIPアドレス帯域との通信のみ許可するルーター、というものです。

個人的には Splatoon 海外勢のラグの酷さに辟易していたこともあり*1、コンセプトは面白いよねと思っていたのですが、流石に自腹切って買うほどのものでもないかなぁと思っていました。

が、 Splatoon2 の発売が近づき、流石に次期作でもラグに悩まされるのは不愉快だったので、手元にあった浮いた Linux 端末でさくっと同じようなものを作ってみました。

コードはこちら: tamias / regionalIPFilter / source / — Bitbucket

細かい話は bitbucket に書いているのでここでは簡単に。

ホワイトリスト

Wii UならびにSplatoonは起動時に

の各サーバー群と通信を行います。DNS Lookupすればわかりますが、これらのサーバー群は

のいずれかです。これらの通信先と国内割り当てIPリストを元に、ホワイトリストを作成するという流れになります。


ブラックリスト

Splatoon では「テザリングキッズ」とも呼ばれる、携帯回線経由で対戦を行おうとする一団がいます。常識的に考えて、いくらLTE世代といえども無線回線では遅延が非常に大きく、まともな対戦は望むべくもないことから、最低限3大キャリアからの接続を遮断します。対戦中にパケットキャプチャをしている限り、MVNOで接続するユーザーもいるのですが、Wii U買う前にやることあるだろうにという感じですね。

docomo

ISPとしてmopera/spmodeがあります。一応半公式に使用する帯域情報が公開されていますが、念には念を入れてwhoisからIPアドレスの割り当て情報を引っ張ってきます。docomoの携帯網への割り当てアドレスは「MAPS」というnetnameで管理されているようで、APNICのwhoisサーバーから根こそぎ引っ張ってきます。

KDDI(au)/Softbank

Whois からは携帯網限定で検索を行うことができないため、個人的に調査したモバイル帯域のリストを置いています(当然無保証)。

*1EU南米西アジア諸国なんてRTTが300 ms超えとか余裕ですしね、死体からインク飛び散るのはほんと辛い

2015-12-23

おうちDDNSを実装する

| おうちDDNSを実装するを含むブックマーク おうちDDNSを実装するのブックマークコメント

はじめに

NTTのフレッツ ひかり電話対応ONUは、L2TPによるVPNサーバー機能を内蔵しています。PPTPとは異なり、LSN*1によるアドレス割当が標準になった移動通信網においても、L2TPによるVPNは問題なく通過することができるため、非常に重宝する機能です。これまで、自宅ONUへの接続は Value Domain(以下VD)が提供するDDNS機能を用い、独自ドメインによる名前解決を行ってきました。

しかしながら、

  • VD提供のDDNS機能では、IPアドレスの更新にHTTP Getが必要なこと(IPアドレスの変更を検知し、HTTP Getを行う機器がLAN内部に別途必要)
  • IPアドレスの変更反映に非常に(酷いときには30分ほど)時間がかかること*2
  • なによりVDがGMO傘下ブランドになったため、登録レジストラGMO(お名前.com)に移転するよう露骨に誘導していること

に嫌気が差しており、今後、GMO以外のレジストラに転出した場合も視野に入れ、独自にDDNSシステムを構築することを検討しました。

基本仕様

一般的なDDNSサービスはieServer.netやDynDNSなど、古くから多数展開されています。が、その大半は HTTP Get によるIPアドレス更新しか対応しておらず、現状からの改善はあまり望めません。

また、以前使っていたDynDNSではサービス変更に伴い、あまり更新を行っていなかったために半強制的にアカウント抹消の憂き目に遭ったという苦い経験があり、一方でこれだけCDNが普及し、網側での(広義の)負荷分散が当然になっている中で、ネームサーバーのような重要な機能を貧弱な回線の下に数えるほどしかぶら下げていないというのは、流石にちょっとどうかと思うわけです。

というわけで自前でシステムを組むことになるのですが、ところで、フレッツ ひかり電話対応ONUには、L2TP VPNサーバー機能の一環として、IPアドレスの変更通知機能があります。これはIPアドレスが変更された際、変更後のIPアドレスを含むメールが自動的に送信されるというものであり、DDNSシステムの構築に際し、本機能による通知を主軸に据えることとしました。

個人ユースのDDNSシステムを動かすだけのためにVPSの面倒を見るのはこのご時世にあまりに馬鹿らしいため、SaaSベースのDNSを使い、メール解析は別途PaaSで走らせることとしました。

DNSホスティングは実際のところ、自社サービスのHTTPホスティングとセットで提供、というスタンスの会社が多く、DNSのみ単体で提供しているのはRoute53を筆頭に数える程度しかありません。加えて、個人用途で高々数ゾーン、クエリ数も月間4桁行かないような状況ではできるだけ安上がりなサービスを使いたくなるというのが人情です。候補としては、

あたりでしょうか。実際にコードを書いた際にはサービスインしていなかったサービスや、後日知ったサービスもあるので後付感は否めないのですが…。

他にも海外系サービスはありますが、

  • 国内使用が大半なのでできれば国内サーバーが欲しい
  • メール解析の結果をAPI経由で反映させられる
  • DDNSなので当然TTLは短時間が必須

という条件を満たし、かつ DNSPref で最速値を叩き出しながら無料サービスとして展開している CloudFlare で行くことにしました。

CloudFlareはどちらかといえば分散コンテンツ配信の面で有名ですが、実はDNS単体での提供もしています。本当はセットで使うとより良いのでしょうが…。余談ですが、CloudFlareの本業である分散配信の性格上、エッジサーバーは国内主要ISPとのピアリング、あるいは大手IXへの直接接続によって維持されていることが推測でき、イコール応答性能の良さが期待できます。

メール解析はどこでも良かったのですが、個人的に使い慣れていて、標準でメール受信をトリガースクリプトを走らせてくれる Google App Engine (GAE)にすることにしました。この辺はHerokuでもAWSでも何でも問題ないと思います。

実装

ここまでくれば、あとはコード書くだけです。IPアドレスの変更通知メールから正規表現で変更後のアドレスを抜き出し、それをAPI叩いて反映させる、という簡単な話です。

ご参考: BitBucket

CloudFlareのAPIドキュメントを見ながら書けば良いと思いますが、実際には no title みたいに同じこと考える人もいるので、その辺参考に。

感想

ちょお快適。

IPアドレスの変更がDNSレコードに反映されるまでのタイムラグはほぼゼロとなりました。実際のところIPアドレスはそう頻繁に変わるわけではないものの、変更に即座に追随できないのは致命的といえるので、大幅に性能向上したことになります。

また、webPushによる手持ちのスマフォへの通知機能も併せて実装したため、これまでのように変更通知メールがメールボックスの片隅に埋もれる、ということもなくなり、加えてレジストラへの依存がなくなったことから、これでいつでも脱出できる準備が整いました。

余談:セキュリティ的なやつ

メールベースでのやりとりであるため、悪意のある第三者GAE側受信アドレスにIPアドレスを書いたメールを流し込めば、DNS Hijackingが成立してしまいます。ただ、GAE側の受信アドレスは自身で変更できるので、複雑なアドレスにしつつ、発信元アドレスが正しいかどうかを判定してやれば疑似的にではありますが認証のような形を取ることは可能です。

なお、より詳細に検討するのであれば、実際にメール本文に記載されているIPアドレスが、メールヘッダ(Received ヘッダ)に記載されているIPアドレスと一致しているかどうかを確認する、あるいはDKIM対応サーバーからメール送信を行うようONUに指定し、受信スクリプト側でDKIMの判定ルーチンを組み込む、などの対応を行えばよりセキュアになるでしょう。ただ、悪用されたところで個人使用のドメインが指すアドレスが変更されるだけであり、ONU再起動等で修正が可能であることから、実害としてどこまで影響があるかというのは微妙です。

*1:Large Scale NAT

*2:浸透、ではなく、VD内部のネームサーバーへの反映に時間がかかっている模様。TTLは標準が120 secで、DNSレベルでは問題ない。

2015-05-27

GData API の初期ライブラリで認証に失敗する件

| GData API の初期ライブラリで認証に失敗する件を含むブックマーク GData API の初期ライブラリで認証に失敗する件のブックマークコメント

Google のサービス系 API (GData API)のうち、 OAuth 2.0 を使わないユーザー認証の API について、27日頃から順次規制が始まったようです。

当初は今月5日頃からの規制予告があったようですが(未確認)、実際の発動が27日頃だったということのようですね。特に .net, Python, PHP系の API はサービスによってはかなり obsolete になって久しく、この数年はほぼノーメンテになっているという事情もあって影響を受けるユーザーも多いようですが*1、国内では以前からユーザーベースが極小なのか、日本語での情報が上がってこないのが通常営業なところもあって辛いものがあります。

個人的な印象で恐縮ですが、GData API ってサービスごとにまちまちな印象があり、後方互換性のためか認証機構もサービスAPIに内蔵されているような記述があるかと思えば OAuth 2.0 を使った統合認証基盤のドキュメントもあったりで、全体的に見通しが良くないように感じます。今回の打ち止めの話もいつもの Google っぽい話といえばそれまでなのですが、ドキュメンテーション中にそれっぽい記載がないのも何だかなぁと思うわけです。

愚痴はともかく、取り急ぎ当該インシデントに対する Google Code と stackoverflow の該当スレを貼っておきます。

Issue 5101 - Execution of authentication request returned unexpected result: 404

https://code.google.com/p/google-apps-script-issues/issues/detail?id=5101

Google.GData.Client.GDataRequestException - Authentication suddenly fails in old code

http://stackoverflow.com/questions/30469058/

*1:その割に .net ライブラリがいつの間にか nuget に登録されていたりでアレ

2015-02-03

LGL24 の GPS 感度を AngryGPS で改善できた話

| LGL24 の GPS 感度を AngryGPS で改善できた話を含むブックマーク LGL24 の GPS 感度を AngryGPS で改善できた話のブックマークコメント

タイトルが全て。

あらすじ

au の2014年夏モデルとして発売された LGL24 こと isai FL ですが、巷で報告されている通り、GPS感度にかなりの難があります。具体的には、

  • カーナビ代わりに使おうにも、高速の高架下道路を走るだけで GPS 信号を見失う
  • ポータル目の前に居るはずなのに範囲外

など、実使用に支障が出るほどのレベルであり、正直2014年モデルでこの出来は流石にどうなの、という感想を抱かざるを得ないものでした。

ただ、元モデルの LG G3 では同様の話を探しても出てこない*1ことと、本機の GPS 機能は Snapdragon の内蔵機能(801 の iZat Gen8B、北斗@China 対応らしいんだけど情報ないよね)を使っているため、恐らくハードウェア不良というよりはソフトウェア側 or 設定上の問題じゃないかな、と当たりを付け、 AngryGPSでP-06D Eluga VのGPSがまともに使えるようになった(追記 2013/10/12): tam network’s blog で書かれている手順に沿って試してみたところ、捕捉衛星数も20以上に、精度も数 m オーダーまで改善しました。条件が良ければ TTFF も 5 秒以内になった。

この2015年にもなって数年前に通用した小手先対応を未だに使わないといけないのは本当にどうかと思うけど、標準状態では位置計算に妙に時間がかかっており、A-GPSのデータを利用し切れていないような印象でした。根本的な解決には次回のバージョンアップで対応してもらえることを期待したいですが、それまでの繋ぎとしてはアリかなと。SUPL サーバーも変更できるので、諸事情で au 網内へのアクセスが困難な場合でも安心ですね。

*1:GPSの話に限らず、全体的に元モデルの先進機能を全部殺して引き替えにガラスマ化の魔改造を受けたとしか思えない出来になってしまっているのが本機で(生き残ったWQHDだけは本当に素晴らしい。あと knock code も慣れると戻れない)、挙げ句の果てに VoLTE 対応後継機が出る前に在庫処分で現金付けて投げ売りとか、どうしてこうも KDDI ってそういうところが下手なんだろうと思わざるを得ない

2014-06-15

既定プロファイルを作成する際に必要な応答ファイル(unattend.xml)を調達する

| 既定プロファイルを作成する際に必要な応答ファイル(unattend.xml)を調達するを含むブックマーク 既定プロファイルを作成する際に必要な応答ファイル(unattend.xml)を調達するのブックマークコメント

既定プロファイル、デフォルトプロファイルは、システムにユーザーが初めてログオンする際に適用される、各種設定のテンプレートとなるものであり、XP時代は Documents and Settings\Defaults フォルダ内に格納されていました。

このため、当時は当該フォルダを触れば自由にカスタマイズを行うことができましたが、ご存じの通り、Vista以降のOSで既定プロファイルを触ろうとすると、

  1. Administratorアカウントで編集作業を行い
  2. Sysprep コマンドに応答ファイルを食べさせて一般化

というより複雑な手順を踏む必要があります。

が、Sysprepコマンドで一般化(generalize)を行う際に必要な応答ファイル(unattend.xml)を作成するには WAIK を使いましょう、というのが公式見解になっており、その際にインストールディスクが必要になりますが、

  • 余程大規模な導入でなければOEM版のWindowsを選択するケースが多い
  • OEM版だと、リカバリディスクと称して配布されるディスクはネイティブなOSが格納されたインストールディスクではない場合が多い(WIMでHDDイメージを固めただけ、とか)
  • あるいは、HDDの隠し領域にリカバリ領域が設定されており、通常ユーザーがアクセスできるものではないケースも多々ある

という矛盾があり、八方ふさがりになっています。

というわけで、Windows7でDefaultプロファイルの作成 - kenmituoの日記から拝借しつつ Win7 向けに書き換えた、最低限 CopyProfile に必要な応答ファイルはこちら。なお、generalize には認証回数を消費するという罠があるので、 SkipRearm もつけています。

厄介なのが応答ファイル側でアーキテクチャ(x86/amd64)を明示する必要があることと、Vistaと7/8で同じ機能でもComponent名が変更になっているケースが多々ある*1ことで、ここは特に注意が必要です。

いずれにしても publicKeyToken は変化ないように思うので(それもそれで変な話ですが)、 processorArchitecture だけに注意すればいいかなと思いますが…。

<?xml version="1.0" encoding="utf-8"?>
<unattend xmlns="urn:schemas-microsoft-com:unattend">
  <settings pass="specialize">
    <component name="Microsoft-Windows-Shell-Setup" processorArchitecture="x86" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS">
      <CopyProfile>true</CopyProfile>
    </component>
  </settings>
  <settings pass="generalize">
    <component name="Microsoft-Windows-Security-SPP" processorArchitecture="x86" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS">
      <SkipRearm>1</SkipRearm>
    </component>
  </settings>
</unattend>

*1:たとえば、 SkipRearm も Vista では Microsoft-Windows-Security-Licensing-SLC だけど、 7/8 では Microsoft-Windows-Security-SPP とか