auのeSIM再発行フローがわかりにくすぎる
先日久しぶりに au 回線を契約したんですが、eSIMの差し替え・再発行をしようとしたら、長々とよくわからない記載ばっかりのサポートページしか出てこないので、関連リンクを貼っておきます。二言目にはMy auを入れろと言ってくるんですが、いや、普通にQRで導入できる標準化されたフローがあるのになんでわざわざ？としか思えないんですよ。よくわからない人はMy auアプリを入れておけばいいと思います。
- eSIM再発行 ⇒ 「eSIM再発行手続きサイト」
- 回線切り替え ⇒ 「オンライン回線切替のお手続き」
- プロファイルインストール ⇒ 「プロファイルダウンロード用URL」
1. eSIMの再発行
まずは既存のau (e)SIMが入った端末（既存端末）から、「eSIM再発行手続きサイト」にアクセスします。2024年12月から認証周りが厳しくなったので、既存端末には事前にMy au/auPay等のアプリの仕込みが必要で、加えて切り替えるSIMを使ったau回線からの申し込みが必要です。申し込み完了時に「申し込み番号」が表示されるので、メモを忘れずに。
注意点ですが、auでは5G SAがサービスインしてから契約種別が「5G SA」「5G」「4G LTE」の3種に分かれており、手続きに先立ってeSIM導入先の端末がいずれに対応しているか、予め確認しておくことを強くおすすめします。ここ1年くらいでの契約だと5G SA契約になっている可能性が高いと思いますが、例えばこのeSIMを5G端末（iPhoneだと13以前）に差し替える場合は再発行手続きの中で契約変更（\3,850-）が必要です（追記：2025年9月より当面の間無料化対応中。なお、4G→4G、5G→5G等同種間の移行も440円かかるとのことですが、こちらも当面の間無料とのこと）。
というのも、特に5G/5G SAは他社だと契約が共通なのであまり意識しないのですが、auは契約どころか Home PLMN まで別（5G SAは440-54で運用）なので、実質的に別ネットワーク、かつ非下位互換の設計になっているため、5G SA契約のSIMを5G SA非対応端末に刺す（プロファイルをインストールする）とネットワークにアタッチできずに即詰んでしまい、プロファイルの再発行＋契約変更が必要となり、下手したらお店行き＆\3,850-×2が一瞬で飛ぶためです。
2. 回線切り替え
既存端末から「オンライン回線切替のお手続き」にアクセスし、回線を旧SIMから新SIMに切り替えます。この手続きの完了時点で既存端末側の旧SIMはネットワークから切り離されます。もしeSIMの切り替え手続きをキャンセルするなら、このタイミングが最後です。一応、回線切り替え後のキャンセルは不可のように読めますが、回線切り替え後であっても、プロファイルインストール前であれば再発行の通知メールに記載されているキャンセルURLから手続きが可能のようです。キャンセル処理が正常に完了すると、既存端末のSIMが再度通じるようになります（実体験）。
3. 新端末にプロファイルのインストール
「プロファイルダウンロード用URL」からQRを表示させ、新端末にeSIMを導入。インストールに際してはwifiもしくは別回線が必要です。回線切り替え作業後、プロファイルのインストールが可能になるまでは数分が必要です。
以上です。
キッズフォンSIMがiPhoneでもVoLTE対応してた件
掲題通り。
そもそもSoftBankのキッズフォン端末はVoLTE機ですので、通常使用であればちゃんとVoLTEが通る回線として機能します。が、このキッズフォン契約のSIMは何かと便利なので、SIMを別の端末に差し替えて使用する際に通話が3G Fallbackになることが問題になっていたのですね。
Androidでは色々と回避策が編み出され、大半の機種でAPN設定を上手く触ることでVoLTE接続ができるようになっていたのですが、iPhoneだけはどう頑張ってもVoLTE接続にならず通話は3G止まりとなっていました。3G停波が迫る中、その行方が注目されていましたが*1、ここに来てついにiPhoneでもVoLTEが解禁になったようです。
「*5592」の回線種別案内でもVoLTE通話であることは確認できましたが、データの方は従前通りIMEI規制により不通となっており、VoLTE通話中でも4Gピクトは表示されません。
*1:緊急呼のことを考えると流石にVoLTE対応するんじゃないのとは思っていましたが、SBだしなぁという気持ちもあり
Apple Watch を買ってみたら色々と大変だった話
あけましておめでとうございます（関西はまだ松の内なのでセーフ）。4年半ぶりの投稿がこんなネタで良いのかと思いつつ。。。
今北産業向け要約
- Softbankの回線は契約端末種別によって利用可能なオプションが制限されており、Androidスマートフォンでの契約回線にはApple Watchモバイル通信サービスのオプションを付加できない
- SIM交換・端末種別変更（オンラインショップまたは店頭への持ち込み機種変更）することで付加可能になる
- Apple Watchに紐付けた親回線のSIMをiPhoneから抜くと、Apple Watchのセルラー機能も停止する
- 回避策が無いのでGPSモデルとして使用するしかない
今更っちゃ今更なんですが、年始のセールでApple Watch SEを買ったんですよ。GPS+Cellularのやつ。折角セルラーモデルなので携帯回線に紐付けて使おうとしたんですが、いまのところ携帯と回線の布陣はこんな感じなんですよね。
- iPhone 13 mini
- irumo（500 MB）
- povo
Apple Watchにモバイル回線を付与するにはirumoに月500円払うかSoftbankの無料キャンペーンで紐付けるかの二択なんですが、iPhoneはサブ機として使っていてそもそもirumoに月500円しか払ってないので、倍額払うのもなぁ、ということでSoftbankのSIMをXperiaから差し替えて開通申し込みをしたところ、こんな画面が表示されてしまって正常に処理が完了しない。
「処理に時間がかかっています」ってそんなことある？仕方が無いので、157とかショップとかで色々聞いて回ったところ、ショップのお兄さんが「契約端末の種別がスマートフォンだからか、そもそもGENIE上にWatch契約のオプションが上がってこないっぽい」というので、それならということでオンラインショップでSIMをiPhone用に交換することに。店頭だと3850円ですが、自宅配送なら0円なのはありがたいですね、そもそもSIM種別と契約種別を同期させるなというのはともかくとして。
申し込み前の最終確認で、追加オプションに「Softbank Wi-Fi スポット(i)」と表示されたので、これは勝ったという確信がありました（甘い）*1。
で、申し込み翌々日にはSIMが配送されてきました。iPhone用の5G SA対応SIM（nano USIM A (S); ZTWHR1）です。これをアクティベートして、iPhoneに入れてWatchのセルラー契約を進めると無事開通。
これで万々歳と思ったのですが、本番はここからで、SIMを元通りに戻したところ、どうやらWatchのモバイル通信の表示がおかしい。なぜ？とiPhone側のWatchアプリで状態を確認すると、なぜか開通させたはずの回線が「非使用中」に…。
これ知らなかった、ていうか公式サイトにも記載が全くないのふざけんなよと思うんですが、恐らくApple Watchのセルラー機能が稼働するには「ペアリングしているiPhone上でWatchと紐付けた親回線のSIMが常時機能している」ことが前提という仕様っぽいですね。え、そんなの聞いてないんよ…。
ドコモのワンナンバーフォンのように、主回線に紐付いた番号を付与してeSIMにでも焼き込んでしまえば、あとは単独で機能するものと思い込んでいたので、これは完全に盲点でした。まさか親機のSIMも見に行くとは…。ということで当面はこのWatchはGPSモデルとして使っていこうと思います（まじで…）。やっぱりApple＋Softbankって鬼門、というかやっぱりApple製品ってこういうトリッキーな使い方するのには向いてないですね。
余談
SoftbankのiPhone向けSIMですが、Xperiaに戻したときに5G SAも通るのかは不明です（近所にエリアがない）。が、恐らく大丈夫なのでは。。。という感触があります。追記：iPhone 契約SIMでもXperiaで5G SAへの接続を確認しました。
あと、同SIMはIMEI制限撤廃の影響で
- plus.acs.jp(.v6)
- plus.4g
いずれも接続が可能になっています。が、リモートホストが softbank\d{,12}.bbtec.net になるようです。Android端末での契約ならどちらも om***.openmobile.ne.jp だったので、こんなところまで契約種別が影響するんだ…という感じですね。
Whois の Domain Status について
みなさん、ドメイン名*1取ってますか？最近は ICANN が小銭稼ぎに始めたクソみたいな新 gTLD 制度が広まってしまったおかげで、安いドメイン名が跋扈した結果ゴミ以下のまとめサイトやいかがでしたかブログが至る所に生えてしまってネットの治安はもう最悪、本当にどうしようもないですね！逆に、ドメイン名ベースのゴミブログフィルターが捗るので、ある意味では良かったのかもしれません、ポジティブに考えれば。
さて、気になるドメイン名があればすぐ Whois しちゃうことも多いと思いますが、そこに記載される情報を気にしている人って案外少ないんじゃないでしょうか。意外にも Whois サーバーの返す "Domain Status" に関して日本語でまとまった資料がなかったので、まとめておこうと思います。
本稿では特に旧来の gTLD によるドメイン名、すなわち .com/.net/.org であるドメイン名を対象にしています。2000年以降に追加された Affilias/Neulevel 系列の .info や .biz 等、さらにそれ以降の新規 gTLD や sTLD は原則 ICANN の指針に従った形になっているはずなのでほぼ変わらないと思われますが、ccTLD の場合は各国の規制当局（日本だと JPRS）の意向によって必ずしも本稿のケースが当てはまらない場合があるようですので、気になる場合はドメイン名の管理当局（特に ccTLD の場合は各 NIC）に照会するようにしてください。
Whois サーバーの返す情報
言わずもがなですが、改めて。
- レジストリ（registry）
- 各 TLD におけるドメイン名のデータベースを維持管理する機関、例えば .com/.net だと Verisign、 .org は PIR。身近な .jp は JPRS が管理しています。
- レジストラ（registrar）
- 登録者からドメイン名の登録申請を受け付け、その登録データをレジストリのデータベースに登録する機関、例えば「お名前.com（GMO）」や「GoDaddy」、「Gandi.net」など。
例えば以下に示すのは twitter.com の Whois 情報です。どれだけ人気のサイトであろうが、ゴミブログであろうが、 Whois の前では皆平等です。当ドメイン名の場合、.com ドメインなのでレジストリは Verisign 、レジストラは CSC (Corporation Service Company) となります。
$ whois twitter.com
[Querying whois.verisign-grs.com]
[whois.verisign-grs.com]
Domain Name: TWITTER.COM
Registry Domain ID: 18195971_DOMAIN_COM-VRSN
Registrar WHOIS Server: whois.corporatedomains.com
Registrar URL: http://www.cscglobal.com/global/web/csc/digital-brand-services.html
Updated Date: 2018-12-07T19:32:35Z
Creation Date: 2000-01-21T16:28:17Z
Registry Expiry Date: 2020-01-21T16:28:17Z
Registrar: CSC Corporate Domains, Inc.
Registrar IANA ID: 299
Registrar Abuse Contact Email: domainabuse@cscglobal.com
Registrar Abuse Contact Phone: 8887802723
Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited
Domain Status: serverDeleteProhibited https://icann.org/epp#serverDeleteProhibited
Domain Status: serverTransferProhibited https://icann.org/epp#serverTransferProhibited
Domain Status: serverUpdateProhibited https://icann.org/epp#serverUpdateProhibited
Name Server: A.R06.TWTRDNS.NET
Name Server: B.R06.TWTRDNS.NET
Name Server: C.R06.TWTRDNS.NET
Name Server: D.R06.TWTRDNS.NET
Name Server: D01-01.NS.TWTRDNS.NET
Name Server: D01-02.NS.TWTRDNS.NET
Name Server: NS3.P34.DYNECT.NET
Name Server: NS4.P34.DYNECT.NET
DNSSEC: unsigned
URL of the ICANN Whois Inaccuracy Complaint Form: https://www.icann.org/wicf/For more information on Whois status codes, please visit https://icann.org/epp
細かい登録者情報は実際のレジストラである whois.corporatedomains.com に問い合わせればわかりますが、大まかな情報を得るだけであれば上記で十分です。
- ドメイン名が登録された日: 2000-01-21T16:28:17Z
- ドメイン名の期限が切れる日: 2020-01-21T16:28:17Z
- ネームサーバー: 8サーバーからラウンドロビン
- ドメインステータス: 4種類（clientTransferProhibited, serverDeleteProhibited, serverTransferProhibited, serverUpdateProhibited）
さて、このうち、「ドメインステータス」に記載されている情報について詳説しましょうというのが本稿の趣旨です。下記にあるように、英語版の元記事は以下のURLに記載がありますので、気になる方は原典を当たってください。。
For more information on Whois status codes, please visit https://icann.org/epp
ドメイン名の一生
ドメインステータスについて書く前に、ドメイン名の一生について記載しておきます。その方がステータスコードの理解が進むので。
- 1日目
- ドメイン名を登録した日。
- 5日目
- 登録から5日目までは登録猶予期間（Add Grace Period）として設定されます。これはユーザーの勘違いやスペルミス等による登録間違いを防ぐために設けられる猶予期間であり、この期間内であればレジストラを通じてドメイン名の登録を取り消すことができます。
- 60日目
- 登録から60日間は、ドメイン名を登録した際に利用したレジストラから別のレジストラに管理を移管すること（ドメイントランスファー）はできません。これはレジストリによってドメイン名の移管操作がロックされるためであり、登録から60日目にそのロックが解除されます。この日以降は他のレジストラへのドメイントランスファーが可能になります。
- 365日目（失効日）
- 登録から1年経つと、この日までに更新操作を行わない限りドメイン名は失効します。ドメイン名が失効するとDNSによる名前解決ができなくなり、関連するサービスを正常に維持することができなくなります。失効したドメイン名は更新猶予期間（Grace Period）に入ります。
- 405日目（失効から40日目）
- 更新猶予期間（Grace Period）が終了し、30日間の請戻猶予期間（Redemption Period）に入ります。この期間に入ったドメイン名はレジストラの管理を離れてレジストリの管理になります。レジストラからレジストリに特別な申請があれば、レジストラに管理が戻されます。この申請は大半がユーザーによる更新忘れが原因だと思われますが、一般には対応費用がかなり高額になるようです。
- 435日目（失効から70日目）
- 請戻猶予期間が終了し、削除保留期間に入ります。この間、ドメイン名はレジストリのDB上からの削除を待つことになります。
- 440日目（失効から75日目）
- 削除日。人の噂も75日、ではないですが、失効日から大凡75日目に削除処理が行われます。削除されたドメイン名はレジストリの管理台帳から抹消され、一般に開放されます。 Whois 上では「NOT FOUND」となり、登録ができる状態に戻ります。
更新猶予期間（Grace Period）について
失効したドメイン名については、レジストリは自動的に（強制的に）ドメイン名の有効期間を1年分更新し、その費用をレジストラから徴収するという仕組みになっています。この仕組みだとユーザーが更新する意思のないドメイン名についてまで更新料を支払うのはレジストラにとって負担でしかないため、失効後40日間設定されるこの更新猶予期間内にレジストラからレジストリへドメイン名の削除申請を行うことで自動更新にかかる費用がレジストリから返金されるようになっています。
ユーザー側から見た場合、仮に更新忘れによって失効したドメイン名であってもこの期間内であれば比較的安価な手数料で回復することが可能です。レジストラから削除を通告されたドメイン名はこの後請戻猶予期間に移行します。一方、ユーザーから更新を依頼されたドメイン名は再度更新され、通常運用フェーズに戻ります。
EPP コードとは
EPP（Extensible Provisioning Protocol）コード、すなわちドメインステータスコードとはその名の通り登録されたドメイン名の状態を示すコードです。登録されているドメイン名は全て、いずれか一つ以上のステータスコードを持ちます。ドメインステータスコードを通じ、登録されているドメイン名がどのような状態にあるのかを知ることができ、しいては運用が止められてしまった場合の原因や現在の状態、あるいは放棄された後一般に開放されるのはいつになるのか、等の情報を知ることができます。
ドメインステータスコードにはサーバーコード、クライアントコードの二種類があり、前者はレジストリによって設定されるものであり、後者はレジストラによって（場合によってはエンドユーザーからの要求に応じて）設定されます。いくつかのサーバーコードはクライアントコードに優越します。いずれのステータスコードについても、上に示すとおりドメインステータスコードは Whois の結果の一部として返されます。
以下に、EPPコードとして標準化された17のステータスコード一覧を示します。また、併せて RFC3915 で規定される RGP ステータスコード（和訳）も示します。
サーバーステータスコード
レジストリによって設定されるドメインステータスコードの一覧。
| EPP コード | 意味 | 補足 |
|---|---|---|
| addPeriod | 登録猶予期間（Add Grace Period）内にあるドメイン名。 | - |
| autoRenewPeriod | 失効後、自動更新中。 | 失効したドメイン名がレジストリによって強制的に更新された場合に表示される。 |
| inactive | ネームサーバーが設定されていない。 | ドメイン名の登録はされているが、ネームサーバーが正常に設定されておらず、名前解決が行われていない状態。 |
| ok | OK! | ドメイン名が正常に稼働している状態。 |
| pendingCreate | 登録待ち。 | 新規募集が行われる TLD における Sunrise 期間（商標権者による優先登録期間）中に登録されたドメイン名。Sunrise 期間終了後に割り当てられるドメイン名に表示される。 |
| pendingDelete | redemptionPeriod もしくは pendingRestore のいずれか、もしくは削除保留期間として削除待ちの状態。 | - |
| pendingRenew | 更新待ち。 | （失効前に）更新指示を受けたたため更新手続き中。 |
| pendingRestore | 請戻猶予期間内にレジストラがレジストリに管理の返還を要請した。 | レジストラへの再割当作業中に表示される。 |
| pendingTransfer | ドメイン名移管（トランスファー）の作業中。 | 異なるレジストラに移管作業中に表示される。 |
| pendingUpdate | ドメイン名情報の更新中。 | ドメイン名に付随する情報（Whois 情報）の更新作業中に表示される。 |
| redemptionPeriod | 請戻猶予期間中。 | 請戻猶予期間は30日間あり、その後5日間の削除保留期間を挟んでドメイン名は抹消される。 |
| renewPeriod | レジストラによって明示的に更新処理が行われた。 | レジストラによる更新処理が行われた場合に表示される。レジストラによってはユーザーの意思にかかわらず自動的に更新処理を行うケースがあり、その場合に表示される。 |
| serverDeleteProhibited | 削除不可 | 希なコードであり、当該ドメイン名は法的な紛争状態にある等で削除が行えない場合に表示される。また、一部のレジストラでは本ステータスコードをドメイン名を保護するより強力な手段として用いている場合がある。 |
| serverHold | DNS による名前解決不可 | ネームサーバーは設定されているものの、名前解決が正常に行えない場合にレジストリによって設定される。 |
| serverRenewProhibited | 期限更新不可 | 希なコードであり、当該ドメイン名は法的な紛争状態にある等で更新が行えない場合に表示される。また、登録者の住所情報等が不正確な場合にも表示される。 |
| serverTransferProhibited | 移管不可 | ドメイン名の登録から60日間経過しておらず他のレジストラへの移管が許可されていない場合に表示される。また、登録者の住所情報等が不正確な場合にも表示される。それ以外では比較的希なコードであり、当該ドメイン名は法的な紛争状態にある等で他のレジストラへの移管が行えない場合に表示される。一部のレジストラでは本ステータスコードをドメイン名を保護するより強力な手段として用いている場合がある。 |
| serverUpdateProhibited | 情報更新不可 | 希なコードであり、当該ドメイン名は法的な紛争状態にある等で Whois 情報の更新が行えない場合に表示される。また、一部のレジストラでは本ステータスコードをドメイン名を保護するより強力な手段として用いている場合がある。 |
| transferPeriod | 移管作業完了 | 異なるレジストラへの移管作業が正常に完了した。 |
クライアントステータスコード
レジストラによって（場合によってはエンドユーザーからの要求に応じて）設定されるドメインステータスコードの一覧。一般には、レジストラからレジストリへの情報伝達手段としても使われる。
| EPP コード | 意味 | 補足 |
|---|---|---|
| clientDeleteProhibited | 削除不可 | ドメイン名保有者以外からの未承認削除等を防ぐために設定される。 |
| clientHold | DNS による名前解決不可 | 未支払い、法的紛争や削除待ち等の事由により名前解決ができない状態にある。 |
| clientRenewProhibited | 期限更新不可 | 法的紛争や削除待ち等の事由により更新ができない状態にある。 |
| clientTransferProhibited | 移管不可 | ドメイン名保有者以外からの未承認移管等を防ぐために設定される。 |
| clientUpdateProhibited | 情報更新不可 | ドメイン名保有者以外からの未承認情報更新等を防ぐために設定される。特にネームサーバーの情報更新を防ぐことでドメイン名ハイジャッキングを防ぐ目的で設定されることがある。 |
スウェーデンにおけるキャッシュレス事情について
昨年から諸事情でスウェーデン国に住むことになり、当地で住民登録も行い、永住権や国籍こそないものの、ここ最近は普通に市民として暮らしています。
日本では東京五輪に向けてキャッシュレスに関する議論が日に日に高まっているようで、キャッシュレス先進国としてスウェーデンが名指しで挙げられている記事も比較的よく見かけるようになりました。
が、多くの記事が「現金使わなければキャッシュレスなんでしょ？」という感じに終始していることが多く、また当地のキャッシュレス事情についても「カードもしくは非接触決済がだいたいどこでも使える」「現金決済比率が低い」といった観点に留まった紹介が多いので、現地の実情について別の観点から紹介したいと思います。
スウェーデンとは
スウェーデン王国はスカンジナビア半島に位置する、北欧4カ国のうちの1国です。日本では国名こそ有名なものの、ムーミンやマリメッコで有名な隣国フィンランドとは異なり、シュールストレミングやバイキングなどが挙がる感じの国ですが、IKEAやSpotify、Ericsson、Volvo（一部は中国資本になってしまいましたが）など多国籍企業も多い工業国でもあります。
公用語はスウェーデン語ですが、英語はほぼ共通語扱いのレベルで通じます。スウェーデン育ちの人だとほぼ大半が問題なく英語を扱える印象。とはいえ、街中で接客業に従事している移民系の人たちのなかには英語が喋れない人もいるようです。個人的にスウェーデン語の勉強も始めましたが、地味に難しいですね…。
総面積は45万平方キロと日本よりやや広いものの、総人口は1000万人強とかなり人口密度の薄い国です。ほぼ隣国のドイツには4万5千人を超える日本人が在住していますが、スウェーデン国内の在留邦人は4千人少々と、首都のストックホルムを除くと比較的大きめの街であっても日本人はほとんど見かけないレベルです。アジア系だとやはり中華系が多い印象ですね。
通貨は独自のスウェーデン・クローナ（SEK、kr）で、1 krはだいたい12円程度。EUには加盟していますが、Euro圏ではありません。ちなみにスカンジナビアの４カ国（スウェーデン、ノルウェー、デンマーク、フィンランド）はそれぞれ使用する通貨が異なります。フィンランドはEuroですが、それ以外は各国独自通貨です。いずれも呼び名は国名＋クローナですが、互換性はありません。
キャッシュレスの前に
キャッシュレスの話の前に、スウェーデンは住民管理においてもデジタル管理を実現しています。
外国人登録は移民局で実施するのですが、外国人登録証が発行された後に住民登録を行うのは税務署（Skatteverket）になります。通常、日本では住民票は各市区町村の役所が管理するものですが、当地では現地人・外国人問わずすべて税務署が管理することになります。これにより、人の移動とおカネの流れをすべて税務署が把握することができ、取り逃しを防ぐという仕組みになっています。
住民登録を行うと各個人に対し一意の個人番号（Personnummer）が発行されます。この個人番号は半永久的に有効なものになり、スウェーデン国内では何をするにもこの番号が必須となります。というのも、個人番号から住所氏名を引いてくるというシステムが正式に政府によって開放されており、これを多数の民間企業が共有しているので、携帯電話の契約からスーパーのポイントに至るまですべてこの個人番号が顧客管理に利用されているためです。
え、いいの？と思われるかもしれませんが、スウェーデンの情報公開法では税務署（というより政府機関）が保有する情報は原則公開されるべきとされているようで、個人が政府機関に対して提供した各個人の情報についても例外ではなく、原則パブリックなものとして扱われるという仕組みになっているためのようです。
ですので、例えば引越しをして住所が変わっても、税務署に申告さえ行えば個人番号に紐づいているサービスであれば自動的に更新されるので、個々のサービスに対して住所変更を届ける必要はありません*1。
余談ですが、納税額や自動車登録の情報についても例外なく公開対象となります。流石に機微情報のため政府に登録を行った一部の民間サービス（hitta、ratsit、eniro 等）に限られますが、web上でそれらの情報も一般に公開されており、名前が分かれば住所、年齢（誕生日）、納税額、勤務先、保有する車種に至るまで調べることが可能です*2。初めて知ったときは驚愕しましたが、当地の人たちはそれが当たり前という感じなので、そういうものなのかなと。
個人番号は西暦表示の誕生日8桁に加えてランダムな数字4桁を割り当てたもので（YYYYMMDD-XXXX）、覚えやすい形になっています。希望者には電子証明書が格納されたICカード（id-kort (identitetskort)、マイナンバーカードのようなもの）も発行されるのですが、こちらには顔写真も入るので、身分証明書としても不可欠なものになっています。
で、この個人番号カードを持って銀行に行くと、晴れて口座を開くことができます。口座の開設に際して銀行窓口で本人確認が行われ、税務署との間では個人番号をキーにした追跡が可能となります。
余談ですが、当地の大半の銀行の店頭にはATMがありません。ATMはBankomatという銀行各社が出資する子会社が街中や銀行近辺に設置していますが、日本のコンビニATMよりも圧倒的に少ない数です。2015年にクローナの模様替えが行われ、旧札・旧硬貨は2018年ごろまでには流通が終了したこともあって現金の流通が急速に減ったといわれています。
オンラインでの身分証明
口座を開設すると、自動的にBankIDというオンラインでの身分証明が可能なアプリを使うことができるようになります。
BankIDとは、銀行口座開設の際の身元確認を前提に、銀行から配布されるキーパッドとデビットカードによるチャレンジ＆レスポンスによる認証を通じてオンライン上で本人確認・承認を行う仕組みです。
最近のデビットカードにはICカードが搭載されていますが、これをキーパッドに挿入し、web上で表示されたチャレンジとカードのPINコードをそれぞれキーパッドに入力することで、デビットカードに演算処理を行わせて出てきたレスポンスを確認すれば、正しいデビットカードを所有しているのかどうかが判別できる、しいては本人であることが確認できる、というものです。
また、BankIDは上述の簡易的な本人確認に加え、より高レベルな承認処理にも対応しています。キーパッドはICカードの読み取りデバイスとしても使用できるので、PCに接続してデビットカード内の証明書を読み取り、よりセキュアな公開鍵認証方式のログインで本人確認・承認処理を行うこともできます。
最近はAndroidやiPhoneでも利用できるアプリ（mobile BankID）も出されており、一度銀行のウェブサイト上でモバイルアプリの紐づけを行えば、モバイル端末上でこのような本人確認（指紋/PIN認証）や承認処理（追加PIN認証）が可能になります。
BankIDの本人確認機能と承認機能の使い分けですが、例えばwebサイトへのログインのように本人であることの確認ができれば十分、というような用途であれば、上述のチャレンジ＆レスポンスによる確認、あるいはモバイルアプリ上での確認（指紋/PIN）を、例えば口座振替の送金処理など、本人による承認が必要な場合は公開鍵認証、あるいはモバイルアプリ上で追加のPIN認証を行う、というように使い分けられています。
このように、本人の確認（identification）と承認（authorization）の機能がそれぞれ認証レベルの違いとして実装されており、非常にスマートな仕組みという印象を受けます（当たり前なのですが、これがきちんとできているシステムって割とレアなイメージ）。
このBankID、大手銀行が共同で設立した子会社が運営母体になっており、銀行口座開設時に必ず身分証明を行うはずなので、なら銀行が身元保証できるでしょ、という発想で作られています。住民管理にしてもオンラインの身分証明にしても、いずれもお金を扱う機関が積極的に推進しているというのが面白いところです。
Swish
BankIDと並んで広く使われているのがP2P送金システムであるSwishです。このSwishもBankIDとは別会社ながら、同様に大手銀行の連合によって2012年に設立された子会社が運営しています。BankID同様、銀行が設立母体になっているので、おカネのやり取りで一番問題になる身分証明の問題をクリアしているのが最大のアドバンテージです。
このSwishのアカウントも銀行のwebサイトから開設することができます。Swishは個人アカウントと法人アカウントに分けられますが、個人アカウントの場合は銀行に登録した携帯番号に紐づくので（アカウント開設時にSMSによる認証が必要）、この番号をもとに処理が進むことになります。なお、Swishはほぼモバイル運用に特化しており、PCから使用するというようなことはできません。
基本的に、Swishは口座番号のエイリアスとみなすことができます。口座に直結しているため、振替処理が走ると即座に反映されます。利用者の口座が銀行を跨いでいても、即時反映されます（恐らく24時間、ただ夜間に処理したことがないので不明）。スウェーデン国内は銀行間の振込手数料が無料なので、Swishもそれと同じく個人の手数料は無料です。
個人間の支払いでは割り勘はもちろん、ストリートパフォーマーへの投げ銭、教会への寄付等にも使われています。基本的に銀行振り込みと同じ扱いなので、日付時刻のほか、相手の名前と電話番号もばっちり記録に残ります（振り出し元の口座までは分かりません）。
法人アカウントはSwishの運営会社による審査の上発行されます。Swishの運営費は法人アカウントの利用料で賄われているようです。上述の通り銀行振り込みは無料なので、ECサイトでも支払いの選択肢としてクレジットカード以外にオンラインバンキングが選択肢に上がるのですが、運営側が銀行ごとに対応しなければならず、また、利用者もオンラインバンキングにログインして決済処理を進める必要がある、と互いに不便なので、なんだかんだでSwishによる決済も用意される傾向にあります。
多くの民間サイト以外にも、例えば国営の鉄道運営会社であるであるSJのチケットサイトや、民営化した郵便事業体のPostnordの販売サイト（書留等もwebで支払い、店頭でラベル印刷してくれるのでそのまま投函できる）、あるいは空港バスチケットなどでもSwish支払いに対応していますし、珍しいものとしては公衆トイレの使用料支払いに使えることもあります（電子錠と組み合わせて、Swish支払い完了後に一時開錠コードが振り出されるので、電子錠にその開錠コードを打ち込むとトイレが使える）。
BankIDもSwishも、ユーザーサイドのアプリに対してpush型の要求を投げられる設計になっているため、ブラウザ上で決済要求を投げてからアプリを立ち上げると、自動的に支払いや承認のプロセスに入る形になります。
例えばECサイトで決済を行う場合、
- （ブラウザ）携帯番号を入力し、Swish支払いを選択
- （スマホ）Swishアプリを起動し、支払先と金額を確認
- （スマホ）BankIDアプリが立ち上がるので、金額確認の上承認処理
- （ブラウザ）自動的に決済完了画面に遷移
という導線が実現でき、非常にスムーズです。
ECサイトでの支払いでカードを使用する場合、どうしてもカード番号の漏出及び不正利用のリスクが付きまといますが、Swish支払いであればトランザクションの都度本人による認証が必須になることから、セキュリティ上好都合であるとも言えます。加えて、これには独自通貨を維持していることもメリットとして寄与します。スウェーデン国内のECサイトの多くがSwishに対応しているので、オンラインでのSEK建決済は原則Swishとしておき、カードについてはオンライン決済の使用をデフォルトでオフにしておけば不正利用の可能性を極力低く押さえることが可能です。国外のサイトでは他通貨建での決済となりますが、その場合は最近流行のRevolut等多通貨対応なデビットカードを別途用いて決済を行うことで、メインの口座に直結するカード番号は伏せたままにしておけるというメリットがあります。
クレジット・デビットカード
この辺は日本と同じなのでそう触れることはないのですが、大半の店でNFCによる非接触決済（Mastercard Contactless/Visa Paywave）に対応しています。が、主に決済に使われるのはモバイル端末ではなく、デビットカードやクレジットカードに内蔵されたNFCチップによるカードをかざすスタイルでの決済が主流です（体感レベルでは、それも含めた非接触決済よりもICチップ+PINコードによる接触決済の方が多い感じ）。なので、余談ですがEU圏に旅行等の短期滞在で来られる際は、MastercardをApple Payに登録した状態で来ると非常に楽です。なお、最近はEMV必須になっているため、磁気ストライプでの決済はほぼ不可能です（事情を説明すれば受け付けてもらえるかもしれませんが…）。ICカード決済、NFC決済いずれにおいてもカード決済端末は基本的にユーザーが操作することになります。
当地でのデビット/クレジットカードでの決済情報には、使用した店舗の種別IDが含まれるようで、例えば日用品を買った、レストランで食事、等々の区別が利用履歴（最近ではスマホアプリだと思いますが）上で容易に区分できるので、簡易家計簿としても使えたりします。また、当地のデビットはATM引き出しの延長というイメージで、使用後は即時反映（10秒以内）され、Google/Apple Payでの使用であっても早ければ数秒でアプリの通知欄にも表示されます。
国内では決済経路上、デビットカードとクレジットカードの区別はほとんどなくなってしまっていますが（デビットカードと銘打っていても、仕組み上はクレジットカードのそれと同じで、単に与信を行わず口座から即時引き落としを行っているだけ）、本来はdebitとcreditの意味の違いの通り差異はあってしかるべきなのですけどね。国内のクレジットカードでも一括支払いが多いという話なので、本来はdirect debitで事足りる用途が大半なのだろうとは思いますが。
国内の送金系サービスでは、クレジットでのチャージなのかデビットでのチャージなのかの判別がはっきりしないが故に、安易なクレジットの現金化を恐れて厳し目の規制を設定したりサービス内容が複雑化していると見受けられる事例をしばしば見かけるので、この辺はもうちょっとクリアになればなぁと個人的には思っています。
まとめ
SwishにしてもBankIDにしても、銀行口座に直結しているが故のメリットが多分にあるため、旅行者などの口座を開けない、現地の身分証明書を持っていない人にとってはそもそも使えないし知る機会がない、というデメリットがあります。
なので、これだけキャッシュレス先進国として名前が挙がっているにもかかわらず、国内で詳細が全然広まっていないのは残念です。スキームとしては非常によく練られているなと思いますし、慣れるとモバイル全盛の時代に非常にフィットした仕組みだなと思い知らされます。
リーマンショック以降、金融業は難しい局面に立たされ続けていますが、当地ではこのような新しい仕組みを銀行が中心になって引っ張っていっているというのは新鮮な驚きでした。
翻って、国内では最近流行している～Pay系のQRコードによる決済サービスの乱立は目に余るものがありますし、もっと利用者目線のサービスにならないのだろうかという思いもあります。決済系サービスは必然的に利用頻度が高くなる流通系が音頭を取りたがるのは理解できますが、どうしても囲い込む方向に向かってしまうのは残念ですし、そういう面でも比較的中立的な位置づけの銀行系がイニシアチブを取れるともう少し事態は変わるのかなぁと思いますが…。
国内では銀行間決済やカード決済については全銀協やNTTデータ社などを中心にかなりしっかりした仕組みが数十年前から構築・運用されていることもあり、新規に出てくるサービスもそのインフラを利用したものが多く、いずれも似たり寄ったりな形になってしまうのは仕方がないのかもしれません。
ただ、その範疇でも試行錯誤は続くと思いますし、今夏には英国発・Fintechの雄と名高いRevolutが国内参入するという話もありますので（別稿でそのうち書きます）、オリンピックに向けてますます国内Fintech界隈は目が離せない年になりそうです。
ぺいぺい雑感
今回のPayPayの騒動でブコメを見ていて、クレジットカードの仕組み、特にオンライン決済にかかる仕組みの認識がどうも共有されていないんじゃないかな、という気がしたので、自身の認識の整理も兼ねてちょっと補助線になるようなエントリを書いてみます。
おまえ誰よ？
趣味で決済周りを追いかけています。プロではなくただの素人なので、専門家からのツッコミ歓迎。推測ばっかやんけ、というコメントはその通りなので反論できないのですが、是非具体例を交えてコメントいただければ。
そもそも何が問題だったの？
PayPayの「100億円還元キャンペーン」に乗じた不正決済が多発したこと*1。PayPayアカウントへのカード登録はカード番号、有効期限、CVC/CVVが必要だったものの、PayPay非利用者であっても不正利用の対象になった事例が散見されたため大きく問題となりました。
PayPayのカード情報登録って？
PayPayでの決済に際し、予めアカウントと紐付けたクレジットカードから支払うことができます。今回の問題はこのサービスに起因するものです。これは決済代行サービスとみることができますが、カード会社（アクワイアラ、イシュア）から見れば売り上げ処理上は巷のECサイト（加盟店）と何ら変わりありません。
不正利用ならアカウントへのカード登録時に試行回数を制限すればよいのでは？
問題発覚当時、アカウントへのカード登録に際しては試行回数に制限が掛かっていなかったため、ねとらぼ等でも取り上げられました。これをきっかけにtwitter等でもPayPayの設計が悪いと総バッシングになったのは記憶に新しいところです。
編集部でも実際に試してみたところ、カード番号と有効期限を入れてから、セキュリティコードを10回ほど間違えても特にロックはかかりませんでした。
http://nlab.itmedia.co.jp/nl/articles/1812/16/news020.html
が、最近のモダンなECサイトであれば、ユーザーのカード情報は原則「非保持・非通過」となっているはずです。ECサイト側でPCI DSSの監査認証を取得していない限り、自社でカード番号等の機密情報を取得・保管するのはリスク以外の何物でもなく、普通の会社であればそんな選択肢は検討の余地すらないはずです*2。
カード決済全体の流れとしては「非保持・非通過」でありECサイト側では保存はもちろんカード番号そのものに触れなくなっているので、この種のチェックの主体は決済代行事業者やカード会社という線引なのだと思います
https://twitter.com/ockeghem/status/1075355119573581826
逆に、現時点でPayPay自体はPCI DSS認証を取得していないとみられることから、カード情報の取り扱いについては他社へ委託しているはずで、今回のリリースを見る限りではアクワイアラはYahooだったようなので、Yahoo側のシステムでの決済となっていたのではないかと思われます。
となると、PayPayによるカード番号に基いた何らかの制限（試行回数の制限設定等）は絵に描いた餅でしかなく、それを実現するには
- PayPay側でPCI DSS認証を取得する
- 3Dセキュアを組み入れる
- PayPayより上流側の決済サービスで何らかの制限を掛ける
くらいしか手の打ちようがないのは容易に想起されるでしょう。このうち現実的な対応策としては3Dセキュアくらいしかないですが、ユーザーの手間が大きくなることもあり、大型キャンペーンに際して新規ユーザーの獲得率を上げるためにもあえて外した可能性はあります。
不正利用の補償をPayPayがするということは自身が悪かったと認めたということ？
いいえ。と言うのもアレですが、ここ数年でECサイト上での不正利用に関しては原則ECサイトが負担するというルールになりつつあるようです*3。
最終的にはアクワイアラと加盟店との間の契約に依るかと思いますが、大手決済代行会社のペイジェント社による解説資料にもあるように、3Dセキュアを導入していたにも関わらずそれが破られた場合のみカード会社もしくは決済代行会社が不正利用に関する補償を行う、というように、加盟店側で特段の対策を打たない場合は補償しない、という事例もあるようです。
[PDF]チャージバックが発生した場合はカード会社及びペイジェントによる補償はありません
https://www.paygent.co.jp/start/pdf/chargeback.pdf
今回、上述の通りPayPayはサービスイン当初から3Dセキュアには非対応だったこともあってか不正利用についてはPayPay側が負担することで決着がついたものと思われますが、比較的早期にリリースが出たことから当初から不正利用はある程度織り込み済みで、保険等で対応するような想定だったのかもしれません。
3Dセキュア（本人認証サービス）の対応と、クレジットカード不正利用への補償について
https://paypay.ne.jp/notice-static/20181227/01/
ちなみに実店舗等でのオフライン決済においては今年改正割賦販売法が施行されたことでご存じの方も多いと思いますが、いわゆるEMV対応が求められるようになりました。これに伴い、2020年までに磁気カードによる決済は終了という流れになっており、当然不正利用の補償も磁気カードによる決済については加盟店負担となりつつあるようです*4。
じゃあ何が問題だったわけ？
PayPayのリリースによればカード情報登録時の試行回数が20回を超えるようなケースは高々十数回だったとのことなので、カード番号、有効期限、CVC/CVVがセットで既に様々なところから流出していて、それらがこのタイミングで使われたとみるのが妥当でしょう。
総当たりに関しては、今回のインシデントに限っては影響は軽微だったのではないかと思われます*5。
既にtwitter上でも指摘されていますが、敢えて言うなら、
- 実店舗で
- 決済時の本人確認がほぼ不要で
- 流出したカード情報を使いやすく
- 大型キャンペーンに不正利用を紛れ込ませやすく
- 高額の取引ができる
という、PayPayのサービスモデルそのものが脆弱性だった、と帰結せざるを得ないでしょう。
一応、公式には3万円以上の決済には本人確認必須だったそうですが、実施していない店舗が大半だったという話ですし、そもそも仮に決済時に本人確認をしたとしても身分証とPayPayへの登録情報との照合のしようがないので何を以て本人確認という話だったのか、と思わざるを得ません。まさか店舗側の決済記録に誰が決済したという記録を残せという話でもないでしょうし。
ここまでの反響になるとPayPay側も想定していたのかわかりませんが、これだけ大きく報じられるセキュリティインシデントはそうそうあるものでもないので、今後のためにも是非公開できる資料については積極的に公表いただきたいものです。
教訓は？
よくキャッシュレス推進のコメントを見かけるはてブですら曖昧な理解のまま今回の件にコメントしているケースが多かったので、ちょっとびっくりしました。
PayPayなんて使っていないのに不正利用の恐れがあるなんて迷惑だ、というコメントを非常によく見かけましたが、そもそもクレジットカードなんて最低限カード番号と有効期限さえ適正であれば決済が通る代物なわけで、今回のPayPay以外にも国際ブランドであれば世界中どこでも不正利用されうる可能性があるわけです。
それに対してどれだけ不正対策を施すか、というのにイシュア、アクワイアラであれば過去の取引パターンから異常取引検知をしたり、加盟店であればCVC/CVV/3Dセキュアの利用、あるいは自社サービスとのユーザー名の一致不一致を見てみたり、と様々に知恵を絞っているわけですが、今の仕組みだと最終的にはユーザー宛に届く利用明細書をユーザー自らが確認するよりも効果的な手法はないわけですよね。
そういう意味では昨今カード会社（イシュア）が利用明細書の郵送送付を有料化しているのは自分で自分の首を絞めるような話かと思いますが、それはそれとして。
よく言われますが不正利用に際してはいきなり大きな金額を使おうとするのではなく、流出したカードについては過去に小口の不正取引が数件記録されていた可能性があります。その時点でユーザーが気づいていれば大きな被害に繋がることは防げたかもしれなかったわけで、非常に残念と言わざるを得ません。
個人的には相当数の国内利用者のカード情報がCVC/CVVとセットで流出していたようだ、というのがかなり衝撃で、キャッシュレス推進の大きな流れが変わることはないと思うものの、ちょっと踏みとどまるような動きに繋がるかもしれないな、と思うような出来事でした。
WireGuard で Android スマートフォンと自宅の間で VPN 回線を構築する
本稿では、最近流行の兆しを見せている、新規なL3 VPNソフトウェアであるWireGuardを用いた導入モデルケースを検討します。
日本語文献はまだまだ少ないですが、WireGuardの詳細は「作って理解するWireGuard」や「WireGuard:次世代耐乱用性カーネルネットワークトンネル」あたりに良く纏まっている通り、主なメリットとして、
- 最新の暗号化スイート・鍵交換プロトコルを用いている
- 他のVPNソフトウェアに比べ、コードベースが非常にコンパクト（であるためコードの見通しが良く、よりセキュアかつ動作が軽量）
- 一時期出血多量だった OpenSSL 等の他のソフトウェアに依存しない
ということが挙げられます。
また、設定項目が著しく少なくて済むというのも大きなメリットであり、最低限、接続先のIPアドレスと公開鍵情報、および自端末の秘密鍵さえあればセッションが成立します。
デメリットとしては、プロトコルにUDPを用いるため、例えばL2TP/IPsecやSSL-VPNと比べるとファイヤーウォールの貫通力が弱い、という点でしょうか。
ただ、最近の4GキャリアであればUDPパケットも普通に通りますし（例: ｲｶテザリングキッズ）、町中のWifiでもまずフィルタされることはないでしょう。QUICも普通に使われるようになってきましたし、UDP:80や443であれば塞がれる可能性は少ないと思われます。企業内ファイヤーウォールを通すのは難しいでしょうけど（とはいえ、それは倫理的に…）。
最近LKMLでLinusが「ええやんこれ、はよマージできへんの？」と発言するなど、メインライン入りを目指して急ピッチで開発が進められていますが、セキュリティソフトウェアの常として、まだ正式に監査を受けていないこと、実績ベースがほとんどないこと、開発中のため仕様変更の可能性が常にあること、から、本番環境での導入には留意が必要です。
動作環境
公式サイトに記載の通り、メジャーなLinuxディストリビューションであればほぼ動作します。Raspberry Pi（Raspibian）、OpenWrt/LEDEなどの組み込み系でも既にパッケージが配布されており、Androidアプリも開発版ながらGoogle Playで配布されています。ただし、iOS版は未だ手つかずなのと追記：iOS版、Mac版ともにAppStoreで公開されました、Windowsについてはサードパーティ製のものが配布されていますが、脆弱性があるようで、導入を控え公式版を待つように、とのこと。
構築モデル
本稿では、AndroidスマートフォンにWireGuardを導入し、自宅に設置したサーバー（Ubuntu Linux）との間でVPN回線を構築し、スマートフォンの通信はすべて自宅回線を経由してインターネットに繋ぐというモデルを検討します。各箇所に割り振られるIPアドレスは下図の通りとします。
インストールと設定
WireGuardはPeer-to-Peerでの接続を行いますが、上図の通り、本稿ではサーバーが常時待ち受け、スマートフォン側から接続要求を出す、という観点での設定を行います。
サーバー上でのインストール
まず、サーバー側にWireGuardを導入します。Ubuntuであれば
$ sudo add-apt-repository ppa:wireguard/wireguard $ sudo apt-get update $ sudo apt-get install wireguard
で入ります。上述の通り、プロダクション環境への導入は控えるべき、という位置づけのため、PPA経由での導入となります。もしくはgitでコードを落としてきてビルド。
$ git clone https://git.zx2c4.com/WireGuard $ cd WireGuard/src $ make # make install
なお、ビルドの際、
$ make debug
でビルドすれば、dmesgにデバッグメッセージを吐き出してくれます（鍵交換したよとか、keep alive投げたよ、とか）。
サーバー側の設定
WireGuardの本体はカーネルモジュールであり、外部との通信を行うインターフェース周りの設定は原則 ip コマンドを通じて行う必要があります。WireGuradの制御コマンドもありますが、設定の大半となるIP周りの設定には使用しません。
まず、WireGuardで使用するインターフェースを作成し、IPアドレスを割り当てます（サブネットは /24 にしています）。
# ip link add dev wg0 type wireguard # ip address add dev wg0 172.16.15.1/24
インターフェース名は専用の wg0 としており、これがVPNの起点になります。なお、この実体は仮想 TUN インターフェースですので、名前付けは自由です。
次いで、最もキモになる秘密鍵と公開鍵をそれぞれ作成します。以下のコマンドでサーバーとスマートフォン（Android）それぞれの秘密鍵（*.key）と公開鍵（*.pub）が作成されます。
# wg genkey | tee server.key | wg pubkey > server.pub # wg genkey | tee android.key | wg pubkey > android.pub
公開鍵と秘密鍵を間違えないように注意！
ここからWireGuradの接続端末について設定を行います。WireGuard の設定ファイルは
/etc/wireguard/
以下に配置します。先に決めたインターフェース名+「.conf」で設定ファイルを作成すると後々便利（例: wg0.conf）。作成した公開鍵、秘密鍵を用いて以下のように設定ファイルを作成し、/etc/wireguard/wg0.conf として保存します。
設定に必要な情報は以下の通り。
- Peer セクション
[Interface] ListenPort = 1234 PrivateKey = ＜サーバー側秘密鍵＞ [Peer] PublicKey = ＜Andorid 公開鍵＞ AllowedIPs = 172.16.15.200/32
接続用の秘密鍵をテキストファイルに直接記入することになるため、必要に応じてファイルパーミッションを適切に設定する等の対応を検討する必要があります。また、設定ファイルの読み取り時にパスワードを打ち込むことで秘密鍵を読み出すようにするテクニックがArch LinuxのWikiに記載がありますので、そちらも参考に。
なお、複数のスマートフォンやタブレットを接続する場合はPeerセクションを接続台数分作成すれば対応可能です。あるいは、接続ごとに wg1, wg2 ... とインターフェースを区切っても構いません。ただし、複数のPeerを設定する場合は AllowedIPs で指定するネットワークセグメントは他のPeerと重複しないように設定する必要があるようなので、ここでは /32 と最も狭い範囲で固定しています。
設定ファイルができあがれば、WireGuardに読み込ませます。
# wg setconf wg0 /etc/wireguard/wg0.conf # ip link set dev wg0 up
ルーティングテーブルを念のため確認しておきます。以下のように 172.16.15.0/24 のみ wg0 へ向いていればOK。
$ route -n カーネルIP経路テーブル 受信先サイト ゲートウェイ ネットマスク フラグ Metric Ref 使用数 インタフェース 0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 enp5s0 172.16.15.0 0.0.0.0 255.255.255.0 U 100 0 0 wg0 192.168.1.0 0.0.0.0 255.255.255.0 U 100 0 0 enp5s0
ルーター/Firewallの設定
ルーター側の設定で、UDP 1234 へのパケットをサーバー（192.168.1.2:1234）へ振り分け、通信を許可するように設定します。
また、スマートフォンから送られてきたパケットをサーバー側でルーティングするため、サーバー上でIPマスカレードを有効化します。
/etc/sysctl.conf を編集し、net.ipv4.ip_forward = 1 とします。加えて、iptablesにてNATを有効化します（必要に応じて FORWARD チェインも許可してください）。
# iptables -t nat -A POSTROUTING -s 172.16.15.0/24 -o enp5s0 -j MASQUERADE # #Forward chain も設定しないと多分繋がらない気がする # vi /etc/sysctl.conf net.ipv4.ip_forward = 1 # sysctl -p または # reboot
この部分は本筋ではないので割愛します。詳細はググってください。
スマートフォン側の設定
スマートフォンアプリの設定は、外部で作成したファイルをQRコードに変換した形で読み取って設定することが可能ですので、先にサーバー上で作成してしまいます（鍵情報の入力が面倒なので）。なお、qrencodeコマンドを使えない環境で作業している場合は、適宜テキストファイルをQRコードに変換する作業が必要です。
先に作成した wg0.conf ファイルを適宜コピーし、公開鍵、秘密鍵を入れ替えたものを作ります。
[Interface] PrivateKey = ＜Android 秘密鍵＞ Address = 172.16.15.200 [Peer] PublicKey = ＜サーバー側公開鍵＞ AllowedIPs = 0.0.0.0/0 Endpoint = 203.0.113.90:1234
サーバー側の設定ファイルとの違いとして、以下の項目を変更します。
- Address はスマートフォン側のVPNアドレス。サーバー上の wg0.conf で記載した AllowedIPs の範囲と一致しないと通信は成立しません。
- ListenPort は度々変わるので削除
- AllowedIPs は全パケットを転送するなら 0.0.0.0/0 を指定。一方、サーバーとの通信のみ転送するのであれば 172.16.15.1/32 とか 172.16.15.0/24 とか。
- Endpoint はサーバー側の Internet 側 IP を指定。DDNSによるFQDNを指定しても可。
これを android.conf として保存し、
$ qrencode -t ansiutf8 < android.conf
でQRコード化します。公式アプリを立ち上げ、画面右下の「+」ボタンをクリックし、「Create from QR code」からQRコードを読み取ります。プロファイル名を適当に入力すると設定値が反映されます。
なお、このアプリ側設定画面上でDNSを別途指定することも可能です。VPNサーバー上でDNSサーバーも稼働している場合、同じIPアドレスを指定すれば名前解決はVPN網の先で行われますが、指定しない場合、スマートフォン側のネットワークにて名前解決が行われるため、セキュリティ上のリスクとして認識しておいた方が良いでしょう。
接続確認
設定は以上です。Andoridアプリから接続を開始し、正常に接続できていればサーバー上でコマンドを叩くと以下のように表示されるはずです。
# wg interface: wg0 public key: yJN1nv7Cu....... private key: (hidden) listening port: 1234 peer: uFSetu....... endpoint: 198.51.100.5:46128 allowed ips: 172.16.15.200/32 latest handshake: 1 minutes, 24 seconds ago transfer: 32.62 KiB received, 36.75 KiB sent
*1:マニュアル上は「ピア相手から送られてくるパケットの許容宛先もしくはピア相手に送信するパケットの宛先の一覧」となっていますが、実質的にはルーティング相当のことを行っています
*2:オプションではあるが、一方のピア（接続を開始する側）での指定は必須
*3:規定では0（OFF）。WireGuardは非常に寡黙なプロトコルでもあるので、通信が発生しない場合はほぼパケットが飛び交いません。なので、NAT/ファイアーウォール環境下でステートフルパケットインスペクション（SPI）が機能している場合、本設定を有効化して定期的に通信を継続させることで、新規通信と見なされセッションを妨害される可能性を下げることも検討した方がよいでしょう。
iptables と ipset で鎖国ルーターを作る
副題： Splatoon 海外勢に慈悲はない（2 に間に合って良かった）
1年ちょっと前に Planex が「鎖国ルーター」を発表しました。あまり話題にならなかったのですが、実態は日本国内および米国割り当てのIPアドレス帯域との通信のみ許可するルーター、というものです。
個人的には Splatoon 海外勢のラグの酷さに辟易していたこともあり*1、コンセプトは面白いよねと思っていたのですが、流石に自腹切って買うほどのものでもないかなぁと思っていました。
が、 Splatoon2 の発売が近づき、流石に次期作でもラグに悩まされるのは不愉快だったので、手元にあった浮いた Linux 端末でさくっと同じようなものを作ってみました。
コードはこちら： tamias / regionalIPFilter / source / — Bitbucket
細かい話は bitbucket に書いているのでここでは簡単に。
ホワイトリスト
- ecs.wup.shop.nintendo.net
- nppl.app.nintendo.net
- account.nintendo.net
- ias.wup.shop.nintendo.net
- api-us.olv.nintendo.net
- olvjp.cdn.nintendo.net
- mii-secure.account.nintendo.net
- nus.wup.shop.nintendo.net
- api-jp.olv.nintendo.net
- npts.app.nintendo.net
- discovery.olv.nintendo.net
の各サーバー群と通信を行います。DNS Lookupすればわかりますが、これらのサーバー群は
のいずれかです。これらの通信先と国内割り当てIPリストを元に、ホワイトリストを作成するという流れになります。
ブラックリスト
Splatoon では「テザリングキッズ」とも呼ばれる、携帯回線経由で対戦を行おうとする一団がいます。常識的に考えて、いくらLTE世代といえども無線回線では遅延が非常に大きく、まともな対戦は望むべくもないことから、最低限3大キャリアからの接続を遮断します。対戦中にパケットキャプチャをしている限り、MVNOで接続するユーザーもいるのですが、Wii U買う前にやることあるだろうにという感じですね。
おうち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桁行かないような状況ではできるだけ安上がりなサービスを使いたくなるというのが人情です。候補としては、
あたりでしょうか。実際にコードを書いた際にはサービスインしていなかったサービスや、後日知ったサービスもあるので後付感は否めないのですが…。
他にも海外系サービスはありますが、
という条件を満たし、かつ DNSPref で最速値を叩き出しながら無料サービスとして展開している CloudFlare で行くことにしました。
CloudFlareはどちらかといえば分散コンテンツ配信の面で有名ですが、実はDNS単体での提供もしています。本当はセットで使うとより良いのでしょうが…。余談ですが、CloudFlareの本業である分散配信の性格上、エッジサーバーは国内主要ISPとのピアリング、あるいは大手IXへの直接接続によって維持されていることが推測でき、イコール応答性能の良さが期待できます。
メール解析はどこでも良かったのですが、個人的に使い慣れていて、標準でメール受信をトリガーにスクリプトを走らせてくれる Google App Engine (GAE)にすることにしました。この辺はHerokuでもAWSでも何でも問題ないと思います。
実装
ここまでくれば、あとはコード書くだけです。IPアドレスの変更通知メールから正規表現で変更後のアドレスを抜き出し、それをAPI叩いて反映させる、という簡単な話です。
CloudFlareのAPIドキュメントを見ながら書けば良いと思いますが、実際には http://torb.at/cloudflare-dynamic-dns みたいに同じこと考える人もいるので、その辺参考に。
感想
ちょお快適。
IPアドレスの変更がDNSレコードに反映されるまでのタイムラグはほぼゼロとなりました。実際のところIPアドレスはそう頻繁に変わるわけではないものの、変更に即座に追随できないのは致命的といえるので、大幅に性能向上したことになります。
また、webPushによる手持ちのスマフォへの通知機能も併せて実装したため、これまでのように変更通知メールがメールボックスの片隅に埋もれる、ということもなくなり、加えてレジストラへの依存がなくなったことから、これでいつでも脱出できる準備が整いました。
余談：セキュリティ的なやつ
メールベースでのやりとりであるため、悪意のある第三者がGAE側受信アドレスにIPアドレスを書いたメールを流し込めば、DNS Hijackingが成立してしまいます。ただ、GAE側の受信アドレスは自身で変更できるので、複雑なアドレスにしつつ、発信元アドレスが正しいかどうかを判定してやれば疑似的にではありますが認証のような形を取ることは可能です。
なお、より詳細に検討するのであれば、実際にメール本文に記載されているIPアドレスが、メールヘッダ（Received ヘッダ）に記載されているIPアドレスと一致しているかどうかを確認する、あるいはDKIM対応サーバーからメール送信を行うようONUに指定し、受信スクリプト側でDKIMの判定ルーチンを組み込む、などの対応を行えばよりセキュアになるでしょう。ただ、悪用されたところで個人使用のドメインが指すアドレスが変更されるだけであり、ONUの再起動等で修正が可能であることから、実害としてどこまで影響があるかというのは微妙です。
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/
