「VDSL ＋ PPPoE」が混雑時間帯に著しく速度低下してストレスが半端ない、という方はV６プラスと PPPoE の併設をおすすめします。
V６プラスは使えるポートが 240 個の制限があります。
このポート制限は中から外に出る際というよりも、外から中に入るときの制限です。
ゲームの主催者側とか、Web サービスを公開しているとか、PPTP/IPSec などの VPN を使っているとかの場合です。
ゲームの参加者ならば通常は問題ありません。
Web サービスも 80 / 443 といったポートではなく、V６プラスで割り当てられたポートの一つを使うなら問題ありませんが、そうでなければ困りますよね。
VPN も OpenVPN / WireGuard は大丈夫ですが、PPTP や L2TP/IPSec などは NG です。
VoIP もパケットヘッダーに 5060 ポートを使用するようなサービスは NG です（ ITSP 事業者の、SMARTalk/050plus/Brastel/G-Call050 など多くの場合は大丈夫ですが、nifty フォンなどは NG です）。
こういう場合は PPPoE でサービス継続し、それ以外を V６プラスにすれば速度改善が見込めるとともに、サービス制限もしなくて済みます。
通常は外から中へのサービスがポートの制限から NG になりますが、 PPPoE によってこの制限はなくなり、またダウンロード系（ネット閲覧もそうです）は混雑時間帯の影響を受けやすいのですが、アップロード系（自分でサービスを公開するなどのケース）はさほどではありません。
気をつけなければいけないのは、V６プラスと PPPoE の両方をサービスしていないプロバイダではこの手が使えないのです。
例えば「ドコモ光＋GMO」はこのケースに引っかかります。
ワタシの場合は「NTT 東日本のフレッツ ＋ @nifty」ですのでまったく問題はありません。
その際のやり方は
① V６プラスルーター（PPPoE パススルー設定する）＋ PPPoE ルーター
VDSL の直下が NEC Aterm 以外の場合
② PPPoE ルーター（V６パススルー設定する）＋ V６プラスルーター
VDSL の直下が NEC Aterm の場合
③ VDSL ＋ SW-Hub ＋ V６プラスルーター & PPPoE ルーター
V６プラスルーターと PPPoE ルーターがどこ製なのかの制約を受けないし、
② のケースで気をつけるべき V６セキュリティ問題もない
があリますが、③ がいいのではないか、と思います。
ここではマンションタイプ（VDSL方式）を事例としました。
ワタシはというと、PPPoE の必要性はないのですが ① ② ③ とも検証のための接続は行いました。
2019-06-29
2019-06-05
SessionTalk と GS Wave の両方への同一ブラステルアカウント登録の件
これはプッシュ系と非プッシュ系の混在利用ケースです。
これまで、050Free 改め My050（CloudSoftphone）や Acrobits などのプッシュ系と GS Wave や zoiper などの非プッシュ系の両方に同一ブラステルアカウントを登録すると「片通話」や「無音」の問題がありました。
この問題は Android か iOS かによらずに発生する厄介な問題です。
SessionTalk もまたプッシュ系で、次のケースだけ「無音」問題がありますが、それ以外には問題はなさそうです。
両方に登録したアカウントへの最初の発信で、
① SessionTalk で最初に受け取る → 以降非プッシュ系とも、自身ともに問題はない
② 非プッシュ系で最初に受け取る → 以降 SessionTalk 側は「無音」になる。
この状態になったら、SessionTalk から一度発信を行うと以降は問題はない
（発信先はどこでも構わない）
という事象がありました。
なぜなのかはよくはわかりません。
SessionTalk は SIP ログ取得できるはずですが、この機能をオンにしても実際には記録されていないのでこの事象を詳しく調べることができません。
これは、イエデン（ATAに電話機を接続。ATAは常時接続）と iPhone 上のプッシュ系と共存を行うためです。
iPhone は非プッシュ系はバックグラオウンドで動作させていないと着信しませんが、恐ろしくバッテリー消費します。
2.5%／h くらいの消費ペースです。
プッシュ系ではバックグラウンド動作が不要ですから、このときのバッテリー消費は 0.7〜1.0%／h くらいの消費ペースで済みます。
外でもイエデンを受けるためには iPhone ではプッシュ系が「必須」なのです。
一方プッシュ系と非プッシュ系（ATAも非プッシュ系にあたります）の共存動作は「片通話」や「無音」問題を引き起こしますので困ったことになるわけです。
SessionTalk はこの問題を回避できるのですが、前記のような、最初の扱いで以降問題が「でる／でない」になるのです。
これまで、050Free 改め My050（CloudSoftphone）や Acrobits などのプッシュ系と GS Wave や zoiper などの非プッシュ系の両方に同一ブラステルアカウントを登録すると「片通話」や「無音」の問題がありました。
この問題は Android か iOS かによらずに発生する厄介な問題です。
SessionTalk もまたプッシュ系で、次のケースだけ「無音」問題がありますが、それ以外には問題はなさそうです。
両方に登録したアカウントへの最初の発信で、
① SessionTalk で最初に受け取る → 以降非プッシュ系とも、自身ともに問題はない
② 非プッシュ系で最初に受け取る → 以降 SessionTalk 側は「無音」になる。
この状態になったら、SessionTalk から一度発信を行うと以降は問題はない
（発信先はどこでも構わない）
という事象がありました。
なぜなのかはよくはわかりません。
これは、イエデン（ATAに電話機を接続。ATAは常時接続）と iPhone 上のプッシュ系と共存を行うためです。
iPhone は非プッシュ系はバックグラオウンドで動作させていないと着信しませんが、恐ろしくバッテリー消費します。
2.5%／h くらいの消費ペースです。
プッシュ系ではバックグラウンド動作が不要ですから、このときのバッテリー消費は 0.7〜1.0%／h くらいの消費ペースで済みます。
外でもイエデンを受けるためには iPhone ではプッシュ系が「必須」なのです。
一方プッシュ系と非プッシュ系（ATAも非プッシュ系にあたります）の共存動作は「片通話」や「無音」問題を引き起こしますので困ったことになるわけです。
SessionTalk はこの問題を回避できるのですが、前記のような、最初の扱いで以降問題が「でる／でない」になるのです。
2019-06-02
iPhone へのソフトフォン：SessionTalk Pro Softphone の設定
アプリを初めて起動すると、下図のように最初にアカウントの作成画面になるので
[○に i ] の部分をクリックし、アカウント作成画面に移る
次の画面は、アカウントの作成 画面
アカウント名：任意（アカウント名でも電番その他なんでもいい）
有効ボタン：そのまま
ユーザー詳細
表示名：プロバイダが Caller ID 対応している場合は電番を設定。
そうでなければ空白のまま
ユーザーネーム：ユーザー ID を設定
パスワード：パスワードを設定
ドメイン ：“example.com:5065”の形式で設定
ポートが 5060 のときは“:ポート番号”は省略可
ダイヤルプラン
ダイヤルのルール：ダイヤルプランが不必要なら設定不要
高度設定
上級：クリックして以下の詳細を設定
IPバージョン
IPバージョン：IPV4を優先（デフォルト）のまま
ボイスメール
ボイスメール番号：プロバイダがサポートの場合当該番号を入力
MWIサブスクリプション：メッセージ待ち表示機能をプロバイダがサポート
の場合、オンにするとボイスメール件数表示される
（無サポートならばオフ）
プロキシ＆認証
Proxyアドレス：プロキシ設定が必要ならばそのアドレスを設定
認証ユーザーネーム：プロキシの認証ユーザー名を設定
DTMF
DTMFモード：rfc2833（デフォルト）
SIPネットワークトラバーサル
SIPトラバーサル：クリックして詳細
SIPトラバーサルIP
Private：チェック（デフォルト）
Static：未チェック
Global：未チェック
アウトバウンドプロキシ
設定不要ならばそのまま
SIP登録
着信電話：オン
失効期間：600（デフォルト）
通信セキュリティ
SIP通信：udp（デフォルト）
オーディオの暗号化：Disabled（デフォルト）
オーディオコーデック
WiFiコーデック クリックして詳細
WiFiオーディオコーデック 右の移動をクリック
コーデックを有効にするとコーデックを無効にするの
いずれかに「有効」/「無効」なものを移動する
モバイルコーデック
WiFiコーデックと同様に設定
ビデオコーデック 必要に応じて設定
ビデオ通話 必要に応じて設定
SMSメッセージ 必要に応じて設定
メディアトラバーサル 必要に応じて設定
KEEPALIVE
UDP Keepalive：オン（デフォルト）
Keepalive Interval（秒）：30（デフォルト）→ 60 くらいがいいだろう
転送先の番号 SIP FORWARD メソッドでの転送先を必要に応じて設定
システム設定の同じ内容よりもここでの転送先番号が
このアカウントでは有効になる
URL残高 必要に応じて設定
その他 ブラステルの場合はデフォルトのままで可
※ IP-Phone Smart（SMARTalk）ほかの場合は、次の設定をする
プッシュオプション
プライベート IP：オフ（これをオフにしないとプッシュ着信しない）
単一登録：オン
同期の登録：オフ
通話中の登録をブロック：オフ
アカウントの作成 に戻ると、「アカウントのステータス：登録済み」となる
右上の 保存 をクリックして設定したアカウント情報を保存する
登録がエラーの場合はユーザー ID、パスワード、ドメイン等の設定誤りがある
設定の編集：右下の 設定 をクリックする
アカウント名は SIP 情報設定時の「アカウント名」が表示される
右側の「録音アイコン」は通話録音時の録音有無が表示され、ここをクリックすると内容を確認できる
その右の「アンテナアイコン」は、クリックすると有効な SIP アカウントの一覧が表示され、発信アカウントを変更できる
下図の 設定 画面になる
SIPアカウント → SIPアカウントの編集
下図の SIP アカウント 画面になる
SIP アカウントの下のリストは有効なアカウントのリスト
アカウント名は、SIP 情報設定時の「ユーザーネーム」が表示される
アカウント名の左の枠のチェックマークは発信アカウントを示す
例では、「無効です」の下は空欄なので、無効アカウントはない状態であることがわかる
SIPアカウント
登録が有効なアカウントのユーザーネームのリスト
チェックマークが付いたアカウントが発信アカウント
（有効であればチェックマークがなくても着信する）
無効です
登録が無効なアカウントのユーザーネームのリスト
（なければ空欄なので、「無効です」だけ表示されて 「アレっ？」
と感じるが、単に無効なアカウントがないだけ）
SIPアカウントの編集
アカウントの [ (i) : ○付きi ] をクリックすると編集画面になる
編集する内容は アカウントの作成 を参照
システム設定 画面
システム設定
モバイル通話を許可：オン（デフォルト）
着信電話 → 選択モード → オフ／標準／プッシュの中からいずれかを選択
オフ：着信しないので発信専用で使用
標準：発着信するがプッシュ着信しない
プッシュ：プッシュ着信する
SELECT REGION
Server Location：Japan (tokyo) をチェック
着信音 → 好みで選択
オーディオ → ほとんどデフォルト
通話録音 → 録音ファイル送信先のeメールアドレスを設定する
短縮ダイヤル → 機能を使用するときオン
連絡先画像 → 呼び出されたとき連絡帳に画像が登録されていたら
表示するかどうかの設定
VPN サポート → プロバイダがVPNサポートしているときにオン
SIP 記録 → SIPログを取得のときオン
カスタム画像 → 着信時の背景画像を設定
転送通話 → SIP FORWARD での転送先を設定の場合オン
転送先番号 → 転送通話オンのとき転送先番号を設定
（全ての SIP アカウントに共通）
個別の SIP アカウントでも設定の場合はそちらが有効になる
TLS認証の確認
ビデオを有効にする
SMS を有効にする（一般にいう SMS ではなく SIP メッセージング）
プレミアム機能 → G.729a Codec → 360円 をクリックすると購入手続きに入る
情報
ヘルプ → 設定方法のヘルプ
クイックヘルプ
SIP アカウントの作成
ユーザーのシステム設定
高度SIP設定
ダイヤルのルール
問題のトラブルシューティング
サポート
サポート問い合わせ
詳細情報 → SESSIONTALKロゴ、バージョン等
ロギング
システム設定 で「SIP記録」がオンに設定のとき記録されたログが見れる
※ 着信後転送機能はプロバイダが SIP REFER メソッドに対応している必要があります。
ブラステルの場合、着信後の転送ボタンでの転送には REFER メソッドで対応しては
いるようなのですが、アプリの自動転送（Call Forward）には対応していないよう
です。
海外の場合は多くの事業者がいずれのケースも対応しているようです。
このあたりは「ガラパゴス」をいかんなく発揮している日本仕様、ですねぇ。
SessionTalk は Free 版と Pro 版があり、
Pro 版は有料ですがこちらでないと実質使えません。
2019-05-27
iPhone に最適なソフトフォンは？ ==>> SessionTalk Pro Softphone
Android では GS Wave または zoiper が高評価ですし、ほかにもいくつかあり、色々試して自分環境にあったソフトフォンを使えます。
ですが、iPhone 用は少し厄介です。
というのは、GS Wave や zoiper などの非プッシュ系のアプリの場合、バックグラウンド動作させていないと着信しませんが、これが恐ろしくバッテリー消費するのです。
2.5 %／1h くらいの消費量です。
プッシュ系だとこの３分の１程度で済みます。
ところがプッシュ系はバッテリー消費は抑えられるものの、別の問題があります。
プッシュ系で代表的なものは Acrobits ファミリーです（Acrobits / Groundwire / CloudSoftphone）。
Acrobits は一般用、Groundwire は企業向け、CloudSoftphone は ITSP 向けと、それぞれがなっているようで、050Free 改め My050 はこの CloudSoftphone です。
SMARTalk もまた、CloudSoftphone です（G-Call050 も同じです）。
単独デバイスに単独アカウントを設定して使う場合は気にするような問題はありません。
ブラステルと G-Call050 は一つのアカウントを複数デバイスに設定して、そのいずれも着信する、ということが可能になっています（非推奨な使い方ですから、自己責任です）。
例えば ATA（アナログ・テレフォニー・アダプター）を介してブラステル電番をイエデン化したとします。
スマホのソフトフォンにもこの電番を設定しておくと、イエデンにかかってきた電話を外出先でスマホで受話できるのです。
これは大変に便利です。
ところが、スマホ側がプッシュ系のソフトフォンの場合、イエデンやスマホが音声不通になるという厄介な問題に遭遇します。
この状態になったら、プッシュ系ソフトフォン側を非プッシュに設定して SIP 登録し直し、イエデン側も念のために再起動（再レジスト）してやっと音声不通状態が解消します。
どうしても駄目な場合は、ブラステルの当該アカウントにログインしてパスワード変更し、 SIP 登録状態を初期化する必要があるかも知れません。
これは非常に厄介です。
Android 機ではバックグラウンド常駐ソフトフォンでも、さほど問題にならないバッテリー消費が、iPhone では恐ろしいほどに消費されてしまうのですが、かといってプッシュ系のソフトフォンとイエデンが共存できないという厄介なことになるわけです。
さぁ、困りました。
Asterisk 側でイエデン着信を別電番に転送し、転送された電番をプッシュ着信で受ける、ということをするしかないかと思っていました。
SessionTalk Pro Softphone という UK 製のソフトフォンアプリがあります。
Callkit にも対応しているようです。
有料版（Pro 版）はプッシュとマルチアカウントに対応していて、Apple Store では 600円、Google Play では 430円ですから Acrobits よりは少し安価です。
まだ評価途上なのでハッキリしたことはいえないのですが、プッシュ系でありながら Acrobits の場合のような音声不通問題がないようなのです。
音声不通問題がないならば Asterisk を使わないで、iPhone でイエデンを持ち歩きながらバッテリー消費を抑えることが可能になります。
【追記】結論的に、この SessionTalk Pro Softphone を使うことにしました。
SessionTalk Pro Softphone のプッシュは次のように機能するようです。
「SIP アカウント情報は、安全な https 接続を介して SessionTalk 社のプッシュサーバーに転送され、そのプッシュサーバーがプロバイダへの SIP 登録（レジスト）を代行する。
着信があった場合、アプリを完全に閉じていてもプッシュサーバーを通じて iOS デバイスに通知され、アプリが呼び起こされて着信します。」
つまり、
プッシュの場合：
プッシュサーバーが IP 電話プロバイダへの SIP 登録を代行し、発着信もプッシュ
サーバーを経由して行うようです。
非プッシュの場合：
発着信は IP 電話プロバイダとソフトフォンの間で行われる。
ということです。
また、iOS 版の「プッシュ」には「同期登録（SIP のプッシュサーバーへの登録の仕方？）」というオプションが設定できますが（デフォルトでは設定されている）、どういう意味があるのかは不明です。
Android 版にはこのオプションはありません。
プッシュメカニズム自体は SessionTalk も Acrobits や CloudSoftphone と同様の仕組みですが、「プッシュ」と「非プッシュ」の混在登録時でもうまくどちらも着信・通話が可能で音声不通問題はないようです。
これは Android（プッシュ）と Android（非プッシュ）の組み合わせでも、iOS（プッシュ）と Android（非プッシュ）の組み合わせでも iOS（非プッシュ）と Android（プッシュ）のいずれの組み合わせでも問題はでていません。
残念ながら iPhone は１台しか持ち合わせていませんので iOS 同士での「プッシュ」と「非プッシュ」の組み合わせは検証できていまっせんが、おそらく問題ないと思われます。
【2019/06/02 プッシュ動作の検証の追記】
同じプッシュでも Acrobits 系と SessionTalk では非プッシュ側（GS Wave）との同時着信時動作が異なることがわかりました。
Acrobits 系との組み合わせでは呼び出し側（同じブラステルの別電番）のユーザーID での呼び出しに応じるか、電番での呼び出しに応じるかの選択ができるメニューが、非プッシュ側に出ます。
このいずれで応じるかによって、次回 Acrobits 側での受話が無音になるかならないかが左右されるような動作をします。
SessionTalk と GS Wave の組み合わせではこのような選択メニューは現れません。
どうもプッシュサーバーがプロバイダに代行登録（REGISTER）する際の SIP ID が「ユーザー ID」 か「電番」かで扱いが異なり、それがプロバイダ側での扱いの差異になっているようなのです。
ユーザー ID の場合： 12345678@softphone.spc.brastel.ne.jp
電番の場合 ： 05068680987@softphone.spc.brastel.ne.jp
通常、ソフトフォンからプロバイダへの REGISTER はブラステルの場合、「ユーザー ID」で行われるようです（ソフトフォンによると思われます）。
このときに、プッシュサーバーが「ユーザー ID」で登録代行している場合は「無音問題」
がないように見受けられます。
ところが、プッシュサーバーが 「電番」で登録代行している場合（Acrobits 系はこちらと思われる）は「無音問題」に遭遇するのではないかと思われます。
ブラステルは非推奨ながら「同一アカウントの複数デバイスからの登録（REGISTER）」ができる、とホームページにもあります。
このときのブラステルの SIP サーバーの動作と関連していると思います。
ブラステルでは【「デバイス１」の「電番１」】から【「デバイス２」の「電番１」】を呼び出しが可能で（ある電番から同一電番の呼び出し）、このときに通話可能なケースと通話不可のケースがありますが、どうやらこの事象に類似しているように思います。
このような場合の、「通話可能／不可」は使うソフトフォンやデバイス特性（？）に関連していそうですが、よくはわかりません。
まだまだ大雑把な状況把握ですので、引き続き調べてみたいと思います。
SIP ログを分析すればもう少し、このあたりの動作状況がわかるのではないかと考えます。
-------------------
米中の通商問題、機密保護問題からファーウェイおよびその新端末（P30）が大きな影響を受けています。
これ以前の機種の場合（P20以前）、ファーウェイはセキュリティアップデートは提供する、といっており、 Google も既存機種へのサポートは継続するようですが、いつこれがひっくり返るようなことにならないとも限りません。
そうなると、国産機か非中華製の Android 機、または iPhone にしなくてはならなくなってしまいます。
iPhone は SE 以降では 6s/7/8 くらいがおすすめ機種と「私は」勝手に思っていますが、ソフトフォンも光明が射してきました。
ですが、iPhone 用は少し厄介です。
というのは、GS Wave や zoiper などの非プッシュ系のアプリの場合、バックグラウンド動作させていないと着信しませんが、これが恐ろしくバッテリー消費するのです。
2.5 %／1h くらいの消費量です。
プッシュ系だとこの３分の１程度で済みます。
ところがプッシュ系はバッテリー消費は抑えられるものの、別の問題があります。
プッシュ系で代表的なものは Acrobits ファミリーです（Acrobits / Groundwire / CloudSoftphone）。
Acrobits は一般用、Groundwire は企業向け、CloudSoftphone は ITSP 向けと、それぞれがなっているようで、050Free 改め My050 はこの CloudSoftphone です。
SMARTalk もまた、CloudSoftphone です（G-Call050 も同じです）。
単独デバイスに単独アカウントを設定して使う場合は気にするような問題はありません。
ブラステルと G-Call050 は一つのアカウントを複数デバイスに設定して、そのいずれも着信する、ということが可能になっています（非推奨な使い方ですから、自己責任です）。
例えば ATA（アナログ・テレフォニー・アダプター）を介してブラステル電番をイエデン化したとします。
スマホのソフトフォンにもこの電番を設定しておくと、イエデンにかかってきた電話を外出先でスマホで受話できるのです。
これは大変に便利です。
ところが、スマホ側がプッシュ系のソフトフォンの場合、イエデンやスマホが音声不通になるという厄介な問題に遭遇します。
この状態になったら、プッシュ系ソフトフォン側を非プッシュに設定して SIP 登録し直し、イエデン側も念のために再起動（再レジスト）してやっと音声不通状態が解消します。
どうしても駄目な場合は、ブラステルの当該アカウントにログインしてパスワード変更し、 SIP 登録状態を初期化する必要があるかも知れません。
これは非常に厄介です。
Android 機ではバックグラウンド常駐ソフトフォンでも、さほど問題にならないバッテリー消費が、iPhone では恐ろしいほどに消費されてしまうのですが、かといってプッシュ系のソフトフォンとイエデンが共存できないという厄介なことになるわけです。
さぁ、困りました。
Asterisk 側でイエデン着信を別電番に転送し、転送された電番をプッシュ着信で受ける、ということをするしかないかと思っていました。
SessionTalk Pro Softphone という UK 製のソフトフォンアプリがあります。
Callkit にも対応しているようです。
有料版（Pro 版）はプッシュとマルチアカウントに対応していて、Apple Store では 600円、Google Play では 430円ですから Acrobits よりは少し安価です。
まだ評価途上なのでハッキリしたことはいえないのですが、プッシュ系でありながら Acrobits の場合のような音声不通問題がないようなのです。
音声不通問題がないならば Asterisk を使わないで、iPhone でイエデンを持ち歩きながらバッテリー消費を抑えることが可能になります。
【追記】結論的に、この SessionTalk Pro Softphone を使うことにしました。
SessionTalk Pro Softphone のプッシュは次のように機能するようです。
「SIP アカウント情報は、安全な https 接続を介して SessionTalk 社のプッシュサーバーに転送され、そのプッシュサーバーがプロバイダへの SIP 登録（レジスト）を代行する。
着信があった場合、アプリを完全に閉じていてもプッシュサーバーを通じて iOS デバイスに通知され、アプリが呼び起こされて着信します。」
つまり、
プッシュの場合：
プッシュサーバーが IP 電話プロバイダへの SIP 登録を代行し、発着信もプッシュ
サーバーを経由して行うようです。
非プッシュの場合：
発着信は IP 電話プロバイダとソフトフォンの間で行われる。
ということです。
また、iOS 版の「プッシュ」には「同期登録（SIP のプッシュサーバーへの登録の仕方？）」というオプションが設定できますが（デフォルトでは設定されている）、どういう意味があるのかは不明です。
Android 版にはこのオプションはありません。
プッシュメカニズム自体は SessionTalk も Acrobits や CloudSoftphone と同様の仕組みですが、「プッシュ」と「非プッシュ」の混在登録時でもうまくどちらも着信・通話が可能で音声不通問題はないようです。
これは Android（プッシュ）と Android（非プッシュ）の組み合わせでも、iOS（プッシュ）と Android（非プッシュ）の組み合わせでも iOS（非プッシュ）と Android（プッシュ）のいずれの組み合わせでも問題はでていません。
残念ながら iPhone は１台しか持ち合わせていませんので iOS 同士での「プッシュ」と「非プッシュ」の組み合わせは検証できていまっせんが、おそらく問題ないと思われます。
【2019/06/02 プッシュ動作の検証の追記】
同じプッシュでも Acrobits 系と SessionTalk では非プッシュ側（GS Wave）との同時着信時動作が異なることがわかりました。
Acrobits 系との組み合わせでは呼び出し側（同じブラステルの別電番）のユーザーID での呼び出しに応じるか、電番での呼び出しに応じるかの選択ができるメニューが、非プッシュ側に出ます。
このいずれで応じるかによって、次回 Acrobits 側での受話が無音になるかならないかが左右されるような動作をします。
SessionTalk と GS Wave の組み合わせではこのような選択メニューは現れません。
どうもプッシュサーバーがプロバイダに代行登録（REGISTER）する際の SIP ID が「ユーザー ID」 か「電番」かで扱いが異なり、それがプロバイダ側での扱いの差異になっているようなのです。
ユーザー ID の場合： 12345678@softphone.spc.brastel.ne.jp
電番の場合 ： 05068680987@softphone.spc.brastel.ne.jp
通常、ソフトフォンからプロバイダへの REGISTER はブラステルの場合、「ユーザー ID」で行われるようです（ソフトフォンによると思われます）。
このときに、プッシュサーバーが「ユーザー ID」で登録代行している場合は「無音問題」
がないように見受けられます。
ところが、プッシュサーバーが 「電番」で登録代行している場合（Acrobits 系はこちらと思われる）は「無音問題」に遭遇するのではないかと思われます。
ブラステルは非推奨ながら「同一アカウントの複数デバイスからの登録（REGISTER）」ができる、とホームページにもあります。
このときのブラステルの SIP サーバーの動作と関連していると思います。
ブラステルでは【「デバイス１」の「電番１」】から【「デバイス２」の「電番１」】を呼び出しが可能で（ある電番から同一電番の呼び出し）、このときに通話可能なケースと通話不可のケースがありますが、どうやらこの事象に類似しているように思います。
このような場合の、「通話可能／不可」は使うソフトフォンやデバイス特性（？）に関連していそうですが、よくはわかりません。
まだまだ大雑把な状況把握ですので、引き続き調べてみたいと思います。
SIP ログを分析すればもう少し、このあたりの動作状況がわかるのではないかと考えます。
-------------------
米中の通商問題、機密保護問題からファーウェイおよびその新端末（P30）が大きな影響を受けています。
これ以前の機種の場合（P20以前）、ファーウェイはセキュリティアップデートは提供する、といっており、 Google も既存機種へのサポートは継続するようですが、いつこれがひっくり返るようなことにならないとも限りません。
そうなると、国産機か非中華製の Android 機、または iPhone にしなくてはならなくなってしまいます。
iPhone は SE 以降では 6s/7/8 くらいがおすすめ機種と「私は」勝手に思っていますが、ソフトフォンも光明が射してきました。
2019-04-08
未来型 VPN : WireGuard を導入してみました
ここに特徴や説明が記載されています。
そこで Raspberry Pi 3 にインストールしてみました。
後述の「参考サイト」に導入手順が記載されており、これを参考にインストール・設定してみました。
VPN 導入目的は大きく２点です。
① 自宅ネットワークに外から安全にアクセスできるようにする。
② フリー WiFi 等で安全性を確保するために VPN を張って自宅ネットワークを経由して
インターネットアクセスできるようにする。
これまでは OpenVPN を使っていましたが、速度低下が結構ありいま一つ、という感じでした。
今回 Wireguard の特徴を踏まえてシンプルかつ高速、というのに興味を持ち導入してみたわけです。
実際に導入してみると非常に高速（利用しているネットワークの速度からほとんど速度低下を感じない）かつ軽快な動作です。
参考サイト：https://github.com/adrianmihalko/raspberrypiwireguard
Raspibian には Wireguard はパッケージされていませんので、Debian から引っ張ってきます。
カーネルプロトコルなので、インストール後に OS の再起動をします。
pi@raspberrypi:~ $ sudo apt-get update
pi@raspberrypi:~ $ sudo apt-get upgrade
pi@raspberrypi:~ $ sudo apt-get install raspberrypi-kernel-headers
pi@raspberrypi:~ $ echo "deb http://deb.debian.org/debian/ unstable main" | sudo tee --append /etc/apt/sources.list.d/unstable.list
pi@raspberrypi:~ $ sudo apt-get install dirmngr
pi@raspberrypi:~ $ sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 8B48AD6246925553
pi@raspberrypi:~ $ printf 'Package: *\nPin: release a=unstable\nPin-Priority: 150\n' | sudo tee --append /etc/apt/preferences.d/limit-unstable
pi@raspberrypi:~ $ sudo apt-get update
pi@raspberrypi:~ $ sudo apt-get install wireguard
pi@raspberrypi:~ $ sudo reboot
IP フォワーディング設定をします。
pi@raspberrypi:~ $ sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1
３. 項以降の設定をします。
WireGuard にはサーバーとクライアントという概念はなく、お互いがサーバーでありかつクライアントです。
つまり対等な扱いです。
接続しにいく側をイニシエーターといい、される方をレスポンダーといいます。
接続はどちらからでもよく、いつでもどちらもイニシエーターになり、他方がレスポンダーになります。
以下の設定ファイルは、自分の定義を [Interface] 、相手の定義を [Peer] として定義します。
便宜上、一般通念的にサーバーとクライアントと仮に呼びます。
端末側が「クライアント」、PC などが「サーバー」としておきます。
一般通念的には「クライアント」から「サーバー」に接続要求しますが、WireGuard はここでいうところの「サーバー」から「クライアント」へ接続要求できるのです。
蛇足的な説明でスミマセン。
以下は一般通念的な「サーバー」と「クライアント」として記述しているということです。
pi@raspberrypi:~ $ mkdir wgkeys
pi@raspberrypi:~ $ cd wgkeys
pi@raspberrypi:~/wgkeys $ wg genkey > server_private.key
Warning: writing to world accessible file.
Consider setting the umask to 077 and trying again.
pi@raspberrypi:~/wgkeys $ wg pubkey > server_public.key < server_private.key
pi@raspberrypi:~/wgkeys $ wg genkey > client1_private.key
Warning: writing to world accessible file.
Consider setting the umask to 077 and trying again.
pi@raspberrypi:~/wgkeys $ wg pubkey > client1_public.key < client1_private.key
pi@raspberrypi:~/wgkeys $ ls
client1_private.key client1_public.key server_private.key server_public.key
cat コマンドで各キー等の中身を抽出します。
これらは後でサーバーおよびクライアントの設定で使用します。
pi@raspberrypi:~/wgkeys $ cat server_public.key
Aj2HHAutB2U0O56jJBdkZ/xgb9pnmUPJ0IeiuACLLmI= [文字列は一例]
pi@raspberrypi:~/wgkeys $ sudo leafpad /etc/wireguard/wg0.conf
[Interface]
Address = 10.0.0.1/32 → VPN の仮想アドレスを記述する
ListenPort = 1194 → 例では OpenVPN と同じ 1194 を使う設定にした
PrivateKey = [server_private.key]
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
[Peer]
#Client1
PublicKey = [client1_public.key]
AllowedIPs = 10.0.0.2/32
”Postup" で、起動時の wg0 インターフェースを eth0 にマスカレードします。
"Postdown" では停止時にマスカレードを削除します。
複数台のクライアントを許可する場合はそれぞれのクライアント用の public.key と private.key を client2, 3, … と生成し、[peer] セクションを追加します。
アドレスは例に従うと 10.8.0.3/32, 10.8.0.4/32, … と設定します。
pi@raspberrypi:~/wgkeys $ sudo wg-quick up wg0
[#] ip link add wg0 type wireguard
[#] wg setconf wg0 /dev/fd/63
[#] ip address add 10.0.0.1/32 dev wg0
[#] ip link set mtu 1420 up dev wg0
[#] ip route add 10.0.0.2/32 dev wg0
[#] iptables -A FORWARD -i wg0 -j ACCEPT; iptables -A FORWARD -o wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
停止の場合は "sudo wg-quick down wg0" とします。
wg コマンドで動作状況を確認します。
pi@raspberrypi:~/wgkeys $ sudo wg
interface: wg0
public key: [server_public.key]
private key: (hidden)
listening port: 1194
peer: [client1_public.key]
allowed ips: 10.0.0.2/32
ラズパイ起動時に Wireguard を自動起動する設定をします。
pi@raspberrypi:~/wgkeys $ sudo systemctl enable wg-quick@wg0
Created symlink /etc/systemd/system/multi-user.target.wants/wg-quick@wg0.service → /lib/systemd/system/wg-quick@.service.
Android 端末の場合は、GooglePlay から Wireguard アプリをダウンロードして下記の設定をします。
いまは iOS 版もあるようです。
→ 任意の名前
→ [client1_private.key] を設定すると
[client1_public.key] は自動的に設定される
→ client1 のアドレス
→ Google の DNS "8.8.8.8" でもよい
→ [server_public.key] を設定する
→ 自ネットのアドレス空間を併記する
すべて VPN 経由時は 0.0.0.0/0とする
→ V6プラスの場合は４桁アドレスでもよい
（V6プラスはアドレスが変わらない）
Allowed IPs はすべてのパケットを VPN 経由とする場合には 0.0.0.0/0（ワイルドカード）を設定します。
特定の IP とのみ通信する場合は "10.0.0.1/32, 192.168.xxx.0/24" のように設定します。
この設定は VPN サーバーの仮想アドレスである "10.0.0.1" および自ネットのアドレス空間 "192.168.xxx.0/24" との間の通信を許可する、という意味になります。
例で示したプライベート IP と、VPN 仮想 IP のアドレスは、我が家のものとは異なっていて本記事用の架空のアドレスです。
同様に Endpont の DDNS 名とポート番号も本記事用の架空のものです。
自ネットが PPPoE でインターネット接続の場合は DDNS サービスを使ったほうがいいでしょう。
V6プラスの場合はアドレスはまず変わりませんので４桁の直接指定でもいいでしょう。
通常、ルーターとその配下は「クラス C」を使うことが多いと思います。
また、VPN 仮想アドレスは「クラス A」またはルーターとは ３ 桁目が異なる「クラス C」が多いと思います。
iPhone のテザリング（ネットワーク共有）は「クラス B」のようですが。
ルーター及びその配下は 公共 WiFi での VPN 使用時にアドレス空間の競合を避ける必要があり、例えば、192.168.57.0/24 のように、３桁目は "0" や "1", "10", "11" などを避けた方がいいと思います。
実際にはコンビニ各社の場合はクラス A を割り当てているようです。
ルーター（我が家の場合は HGW : RT500KI で V6プラス）の静的NAPT 設定で、
対象プロトコル：UDP
公開対象ポート：12345（V6プラスで割り当てられたポートの一つ）
宛先アドレス ：192.168.xxx.yyy（Raspberry Pi 3 のアドレス）
宛先ポート ：1194（任意ポート：ここでは OpenVPN のポートを使う設定を想定）
を設定して Wireguard への接続要求（ポート：12345）を Raspberry Pi3（許可されたポート：1194）へ振り向けるようにします。
クライアントから接続し、サーバー側とクライアント側それぞれから相手に ”ping -c 5 10.0.0.2”or “10.0.0.1”として相互に見えていることを確認します。
Firewall を以下のように設定します。
root@raspberrypi:~# ufw default deny
Default incoming policy changed to 'deny'
(be sure to update your rules accordingly)
root@raspberrypi:~# ufw allow in from 192.168.xxx.0/24
Rule added
root@raspberrypi:~# ufw allow in from 10.0.0.0/24
Rule added
root@raspberrypi:~# ufw allow 1194/udp → 通過許可設定
Rule added
Rule added (v6)
root@raspberrypi:~# ufw status numbered
Status: active
To Action From
-- ------ ----
[ 1] Anywhere ALLOW IN 192.168.xxx.0/24
[ 2] Anywhere ALLOW IN 10.0.0.0/24
[ 4] 1194/udp ALLOW IN Anywhere
[ 5] 1194/udp (v6) ALLOW IN Anywhere (v6)
RealVNC サーバーの設定で、次の設定を追加します。
これをしないと VPN 動作時に PC (Mac) からRealVNC で Raspberry Pi 3に接続
できなくなってしまいます。
Raspberry Pi 3 の RealVNC の設定で Connections → Accept “192.168.xxx.0/24” を追加します。
また、ルーターで 10.0.0.0/24 からの外向きパケットを通過設定します。
これを忘れると端末からインターネットにアクセスできない、そもそもWireGuard での接続が不安定になる、Google FCM がエラーになってスリープで接続が切れる、などの事象に見舞われます。
Wireguard の導入と設定は OpenVPN よりも非常に簡単で、すぐに使えます。
また、速度的には VPN トンネル を張らない場合に比べても速度低下はほとんど感じられませんから、LTE 速度（またはフリー WiFi 速度）次第ということになります。
モバイルは LINE モバイルを使用しており、LTE 時でもストレスを感じることもなく VPN でのネットアクセスができます。
下記の画面は m.yahoo.co.jp にアクセスしてみた画面ですが、通知領域に鍵マークが通知されており、VPN 接続状態であることがわかります。
この画面は LTE => VPN ==トンネル==> 自宅ネット => "m.yahoo.co.jp" という経路でのアクセスになり、自宅ネットの保護下でのアクセスになります。
同様に、自宅のルーターにログインしてみました。
LTE 接続中ですが、VPN を自宅に向けて張っていますので、ログインできています。
このようなアクセス経路は、フリー WiFi でも同じです。
プライベート IP アドレスは自ネットワークのアドレスに合わせ、VPN で使用する仮想アドレスを適当に設定します。
フリー WiFi でどうなるかについて。
==>> ４月８〜９日に近所のコンビニで試しました。
結論的にいいますと、こちらもストレスなく VPN でネットアクセスできました。
クライアントの Allowed IPs は 0.0.0.0/0（ワイルドカード）設定しました。
WiFi の接続には NTTBP の「Japan Connected-free WiFi アプリ」によって接続しました。
フリーだからといっても直接接続するとうまくいきません。
「Japan Connected-free WiFi アプリ」による認証 OK で接続しないとダメなようです。
一度接続したことがあると「保存済みネットワーク」にあって、圏内になると自動的に接続されるのですが、これではうまく VPN で使えないようです。
また、VPN クライアントをオンのままでは WiFi 接続が失敗します。
こういう場合は、一旦 WiFi も VPN もオフにし「Japan Connected-free WiFi アプリ」を起動して「Connect」をクリックして接続するようにします。
「端末の WiFi 設定」→「SSID 接続」→「WiFi 認証」を経て接続完了になります。
この後で Wireguard VPN をオンにします。
あとは普通にウェブやその他のネットアクセス、自宅ネット内のアクセス等が可能になります。
下記コンビニのフリー WiFi はいずれも VPN は使えました。
❏ セブンイレブン（SSID=7SPOT）
❏ ファミマ（SSID=Famima_WiFi）
❏ ローソン（SSID=LAWSON_Free_WiFi）
以下の画面は 7SPOT に VPN で接続されているのがおわかりでしょうか。
この状態で m.yahoo.co.jp を閲覧した画面が下の画面です。
通知領域をご覧になると WiFi + VPN での閲覧画面であることが見て取れると思います。
速度等はそのお店のネット環境に左右されますが、概ね 数 Mbps以上が出るようです。
いいときは 50 Mbps くらいのところもあります。
ping値は 20〜30ms 前後、ジッター値は 3ms 程度でパケロスはありません。
いずれの場合も Wireguard を使用して、ヤフー・ジャパンなどの一般サイトのウェブが問題なく行え、自宅のルーターや LAN-HDD などへのログインも問題なく行えます。
もちろん、ターミナルからの自宅サーバー等への ping や ssh も OK です。
その他のフリーWiFi での VPN はフィルタリングされていなくて使えるものと、逆に使えないものがあります。
フリーWiFi でこそ VPN が必要なのにこれが使えない WiFi は安心してインターネットを使えません。
そこで Raspberry Pi 3 にインストールしてみました。
後述の「参考サイト」に導入手順が記載されており、これを参考にインストール・設定してみました。
VPN 導入目的は大きく２点です。
① 自宅ネットワークに外から安全にアクセスできるようにする。
② フリー WiFi 等で安全性を確保するために VPN を張って自宅ネットワークを経由して
インターネットアクセスできるようにする。
これまでは OpenVPN を使っていましたが、速度低下が結構ありいま一つ、という感じでした。
今回 Wireguard の特徴を踏まえてシンプルかつ高速、というのに興味を持ち導入してみたわけです。
実際に導入してみると非常に高速（利用しているネットワークの速度からほとんど速度低下を感じない）かつ軽快な動作です。
参考サイト：https://github.com/adrianmihalko/raspberrypiwireguard
1. Wireguard のインストール (Raspberry Pi 2 v1.2 以降)
Raspibian には Wireguard はパッケージされていませんので、Debian から引っ張ってきます。
カーネルプロトコルなので、インストール後に OS の再起動をします。
pi@raspberrypi:~ $ sudo apt-get update
pi@raspberrypi:~ $ sudo apt-get upgrade
pi@raspberrypi:~ $ sudo apt-get install raspberrypi-kernel-headers
pi@raspberrypi:~ $ echo "deb http://deb.debian.org/debian/ unstable main" | sudo tee --append /etc/apt/sources.list.d/unstable.list
pi@raspberrypi:~ $ sudo apt-get install dirmngr
pi@raspberrypi:~ $ sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 8B48AD6246925553
pi@raspberrypi:~ $ printf 'Package: *\nPin: release a=unstable\nPin-Priority: 150\n' | sudo tee --append /etc/apt/preferences.d/limit-unstable
pi@raspberrypi:~ $ sudo apt-get update
pi@raspberrypi:~ $ sudo apt-get install wireguard
pi@raspberrypi:~ $ sudo reboot
IP フォワーディング設定をします。
pi@raspberrypi:~ $ sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1
2. Wireguard を設定する
３. 項以降の設定をします。
WireGuard にはサーバーとクライアントという概念はなく、お互いがサーバーでありかつクライアントです。
つまり対等な扱いです。
接続しにいく側をイニシエーターといい、される方をレスポンダーといいます。
接続はどちらからでもよく、いつでもどちらもイニシエーターになり、他方がレスポンダーになります。
以下の設定ファイルは、自分の定義を [Interface] 、相手の定義を [Peer] として定義します。
便宜上、一般通念的にサーバーとクライアントと仮に呼びます。
端末側が「クライアント」、PC などが「サーバー」としておきます。
一般通念的には「クライアント」から「サーバー」に接続要求しますが、WireGuard はここでいうところの「サーバー」から「クライアント」へ接続要求できるのです。
蛇足的な説明でスミマセン。
以下は一般通念的な「サーバー」と「クライアント」として記述しているということです。
3. private / public keys を生成する（サーバーおよびクライアント用）
pi@raspberrypi:~ $ mkdir wgkeys
pi@raspberrypi:~ $ cd wgkeys
pi@raspberrypi:~/wgkeys $ wg genkey > server_private.key
Warning: writing to world accessible file.
Consider setting the umask to 077 and trying again.
pi@raspberrypi:~/wgkeys $ wg pubkey > server_public.key < server_private.key
pi@raspberrypi:~/wgkeys $ wg genkey > client1_private.key
Warning: writing to world accessible file.
Consider setting the umask to 077 and trying again.
pi@raspberrypi:~/wgkeys $ wg pubkey > client1_public.key < client1_private.key
pi@raspberrypi:~/wgkeys $ ls
client1_private.key client1_public.key server_private.key server_public.key
cat コマンドで各キー等の中身を抽出します。
これらは後でサーバーおよびクライアントの設定で使用します。
pi@raspberrypi:~/wgkeys $ cat server_public.key
Aj2HHAutB2U0O56jJBdkZ/xgb9pnmUPJ0IeiuACLLmI= [文字列は一例]
4. Wireguard サーバーのインターフェース作成
pi@raspberrypi:~/wgkeys $ sudo leafpad /etc/wireguard/wg0.conf
[Interface]
Address = 10.0.0.1/32 → VPN の仮想アドレスを記述する
ListenPort = 1194 → 例では OpenVPN と同じ 1194 を使う設定にした
PrivateKey = [server_private.key]
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
[Peer]
#Client1
PublicKey = [client1_public.key]
AllowedIPs = 10.0.0.2/32
”Postup" で、起動時の wg0 インターフェースを eth0 にマスカレードします。
"Postdown" では停止時にマスカレードを削除します。
複数台のクライアントを許可する場合はそれぞれのクライアント用の public.key と private.key を client2, 3, … と生成し、[peer] セクションを追加します。
アドレスは例に従うと 10.8.0.3/32, 10.8.0.4/32, … と設定します。
5. Wireguard を起動する
pi@raspberrypi:~/wgkeys $ sudo wg-quick up wg0
[#] ip link add wg0 type wireguard
[#] wg setconf wg0 /dev/fd/63
[#] ip address add 10.0.0.1/32 dev wg0
[#] ip link set mtu 1420 up dev wg0
[#] ip route add 10.0.0.2/32 dev wg0
[#] iptables -A FORWARD -i wg0 -j ACCEPT; iptables -A FORWARD -o wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
停止の場合は "sudo wg-quick down wg0" とします。
wg コマンドで動作状況を確認します。
pi@raspberrypi:~/wgkeys $ sudo wg
interface: wg0
public key: [server_public.key]
private key: (hidden)
listening port: 1194
peer: [client1_public.key]
allowed ips: 10.0.0.2/32
ラズパイ起動時に Wireguard を自動起動する設定をします。
pi@raspberrypi:~/wgkeys $ sudo systemctl enable wg-quick@wg0
Created symlink /etc/systemd/system/multi-user.target.wants/wg-quick@wg0.service → /lib/systemd/system/wg-quick@.service.
6. クライアント側の設定
Android 端末の場合は、GooglePlay から Wireguard アプリをダウンロードして下記の設定をします。
いまは iOS 版もあるようです。
→ 任意の名前
→ [client1_private.key] を設定すると
[client1_public.key] は自動的に設定される
→ client1 のアドレス
→ Google の DNS "8.8.8.8" でもよい
→ [server_public.key] を設定する
→ 自ネットのアドレス空間を併記する
すべて VPN 経由時は 0.0.0.0/0とする
→ V6プラスの場合は４桁アドレスでもよい
（V6プラスはアドレスが変わらない）
Allowed IPs はすべてのパケットを VPN 経由とする場合には 0.0.0.0/0（ワイルドカード）を設定します。
特定の IP とのみ通信する場合は "10.0.0.1/32, 192.168.xxx.0/24" のように設定します。
この設定は VPN サーバーの仮想アドレスである "10.0.0.1" および自ネットのアドレス空間 "192.168.xxx.0/24" との間の通信を許可する、という意味になります。
例で示したプライベート IP と、VPN 仮想 IP のアドレスは、我が家のものとは異なっていて本記事用の架空のアドレスです。
同様に Endpont の DDNS 名とポート番号も本記事用の架空のものです。
自ネットが PPPoE でインターネット接続の場合は DDNS サービスを使ったほうがいいでしょう。
V6プラスの場合はアドレスはまず変わりませんので４桁の直接指定でもいいでしょう。
通常、ルーターとその配下は「クラス C」を使うことが多いと思います。
また、VPN 仮想アドレスは「クラス A」またはルーターとは ３ 桁目が異なる「クラス C」が多いと思います。
iPhone のテザリング（ネットワーク共有）は「クラス B」のようですが。
ルーター及びその配下は 公共 WiFi での VPN 使用時にアドレス空間の競合を避ける必要があり、例えば、192.168.57.0/24 のように、３桁目は "0" や "1", "10", "11" などを避けた方がいいと思います。
実際にはコンビニ各社の場合はクラス A を割り当てているようです。
ルーター（我が家の場合は HGW : RT500KI で V6プラス）の静的NAPT 設定で、
対象プロトコル：UDP
公開対象ポート：12345（V6プラスで割り当てられたポートの一つ）
宛先アドレス ：192.168.xxx.yyy（Raspberry Pi 3 のアドレス）
宛先ポート ：1194（任意ポート：ここでは OpenVPN のポートを使う設定を想定）
を設定して Wireguard への接続要求（ポート：12345）を Raspberry Pi3（許可されたポート：1194）へ振り向けるようにします。
クライアントから接続し、サーバー側とクライアント側それぞれから相手に ”ping -c 5 10.0.0.2”or “10.0.0.1”として相互に見えていることを確認します。
7. Firewall の設定
Firewall を以下のように設定します。
root@raspberrypi:~# ufw default deny
Default incoming policy changed to 'deny'
(be sure to update your rules accordingly)
root@raspberrypi:~# ufw allow in from 192.168.xxx.0/24
Rule added
root@raspberrypi:~# ufw allow in from 10.0.0.0/24
Rule added
root@raspberrypi:~# ufw allow 1194/udp → 通過許可設定
Rule added
Rule added (v6)
root@raspberrypi:~# ufw status numbered
Status: active
To Action From
-- ------ ----
[ 1] Anywhere ALLOW IN 192.168.xxx.0/24
[ 2] Anywhere ALLOW IN 10.0.0.0/24
[ 4] 1194/udp ALLOW IN Anywhere
[ 5] 1194/udp (v6) ALLOW IN Anywhere (v6)
※※※ 留意事項
RealVNC サーバーの設定で、次の設定を追加します。
これをしないと VPN 動作時に PC (Mac) からRealVNC で Raspberry Pi 3に接続
できなくなってしまいます。
Raspberry Pi 3 の RealVNC の設定で Connections → Accept “192.168.xxx.0/24” を追加します。
また、ルーターで 10.0.0.0/24 からの外向きパケットを通過設定します。
これを忘れると端末からインターネットにアクセスできない、そもそもWireGuard での接続が不安定になる、Google FCM がエラーになってスリープで接続が切れる、などの事象に見舞われます。
Wireguard の導入と設定は OpenVPN よりも非常に簡単で、すぐに使えます。
また、速度的には VPN トンネル を張らない場合に比べても速度低下はほとんど感じられませんから、LTE 速度（またはフリー WiFi 速度）次第ということになります。
モバイルは LINE モバイルを使用しており、LTE 時でもストレスを感じることもなく VPN でのネットアクセスができます。
下記の画面は m.yahoo.co.jp にアクセスしてみた画面ですが、通知領域に鍵マークが通知されており、VPN 接続状態であることがわかります。
この画面は LTE => VPN ==トンネル==> 自宅ネット => "m.yahoo.co.jp" という経路でのアクセスになり、自宅ネットの保護下でのアクセスになります。
 |
| LTE で VPN 接続時の m.yahoo.co.jp の画面 |
同様に、自宅のルーターにログインしてみました。
LTE 接続中ですが、VPN を自宅に向けて張っていますので、ログインできています。
 |
| 自宅のルーターにログインしてみた画面 |
このようなアクセス経路は、フリー WiFi でも同じです。
プライベート IP アドレスは自ネットワークのアドレスに合わせ、VPN で使用する仮想アドレスを適当に設定します。
フリー WiFi でどうなるかについて。
==>> ４月８〜９日に近所のコンビニで試しました。
結論的にいいますと、こちらもストレスなく VPN でネットアクセスできました。
クライアントの Allowed IPs は 0.0.0.0/0（ワイルドカード）設定しました。
WiFi の接続には NTTBP の「Japan Connected-free WiFi アプリ」によって接続しました。
フリーだからといっても直接接続するとうまくいきません。
「Japan Connected-free WiFi アプリ」による認証 OK で接続しないとダメなようです。
一度接続したことがあると「保存済みネットワーク」にあって、圏内になると自動的に接続されるのですが、これではうまく VPN で使えないようです。
また、VPN クライアントをオンのままでは WiFi 接続が失敗します。
こういう場合は、一旦 WiFi も VPN もオフにし「Japan Connected-free WiFi アプリ」を起動して「Connect」をクリックして接続するようにします。
「端末の WiFi 設定」→「SSID 接続」→「WiFi 認証」を経て接続完了になります。
この後で Wireguard VPN をオンにします。
あとは普通にウェブやその他のネットアクセス、自宅ネット内のアクセス等が可能になります。
下記コンビニのフリー WiFi はいずれも VPN は使えました。
❏ セブンイレブン（SSID=7SPOT）
❏ ファミマ（SSID=Famima_WiFi）
❏ ローソン（SSID=LAWSON_Free_WiFi）
以下の画面は 7SPOT に VPN で接続されているのがおわかりでしょうか。
この状態で m.yahoo.co.jp を閲覧した画面が下の画面です。
通知領域をご覧になると WiFi + VPN での閲覧画面であることが見て取れると思います。
速度等はそのお店のネット環境に左右されますが、概ね 数 Mbps以上が出るようです。
いいときは 50 Mbps くらいのところもあります。
ping値は 20〜30ms 前後、ジッター値は 3ms 程度でパケロスはありません。
いずれの場合も Wireguard を使用して、ヤフー・ジャパンなどの一般サイトのウェブが問題なく行え、自宅のルーターや LAN-HDD などへのログインも問題なく行えます。
もちろん、ターミナルからの自宅サーバー等への ping や ssh も OK です。
その他のフリーWiFi での VPN はフィルタリングされていなくて使えるものと、逆に使えないものがあります。
フリーWiFi でこそ VPN が必要なのにこれが使えない WiFi は安心してインターネットを使えません。
登録:
投稿 (Atom)