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 くらいがおすすめ機種と「私は」勝手に思っていますが、ソフトフォンも光明が射してきました。
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 は安心してインターネットを使えません。
2018-10-09
Root - PNF（Root 版 Push Notification Fixer）で GCM 動作状況を見る
Root - PNF は端末をルート化していなくても GCM の状況を見ることができます。
アプリは下記にあります。
https://play.google.com/store/apps/details?id=com.andqlimax.pushfixer
起動すると最初に次のような画面になります。
Play sevices monitor をクリックすると次の画面になります。
これは Google play開発者サービスのログになっていて、状況を見ることができます。
ハートビート間隔が 550s になっているのが見て取れます。
ほかにもハートビートが成功した回数・失敗した回数、ネットワークタイプ等がわかります。
右上の EVENTS をクリックすると次の画面になります。
画面をスクロールして一番下が最新、上が古いログになっており、ログは一定量になると古いものが消されて新しいものが追加されます。
時刻・net=0（モバイルを表します）/ net=1（WiFi を表します）・Sent Client HB（クライアントからハートビートを送信したことを示します/サーバーから送られてきた場合はそのようにログされこの場合はクライアント側から ACK が返されます）がわかりその間隔が次行の時刻との差でわかります。
10:09 08:26:44.098 Exiting doze → Doze から抜けたことを示します
10:09 08:26:44.099 Sent com.google.android.gsf.gtalkservice → GCM が動作しています
10:09 08:26:51.258 Received jp.co.fusioncom.smartalk.android result=1 time=187 p=10 → この時刻に SMARTalk からの通知を受け取ったことを示しています（着信通知です）
そのあと発信側で呼び出しをとりやめましたので Close err:FIN time=5745 と記録されています。
また、WiFi に接続変更しましたので net=1 に切り替えられたログが記録されています。
つまりログ上は GCM が動作しており、Doze 状態から脱却して SMARTalk がほかからの呼び出しで着信動作に入ったということがわかります。
発着信の動作が不安定などの場合にこのようなシーケンスで動作しているかどうかで不具合の発見に役立てることができます。
常駐型ソフトフォンアプリの場合は少し違うシーケンスになります。
Doze に入っていなければログ上の変化はありません。
アプリは下記にあります。
https://play.google.com/store/apps/details?id=com.andqlimax.pushfixer
起動すると最初に次のような画面になります。
Play sevices monitor をクリックすると次の画面になります。
これは Google play開発者サービスのログになっていて、状況を見ることができます。
ハートビート間隔が 550s になっているのが見て取れます。
ほかにもハートビートが成功した回数・失敗した回数、ネットワークタイプ等がわかります。
右上の EVENTS をクリックすると次の画面になります。
画面をスクロールして一番下が最新、上が古いログになっており、ログは一定量になると古いものが消されて新しいものが追加されます。
時刻・net=0（モバイルを表します）/ net=1（WiFi を表します）・Sent Client HB（クライアントからハートビートを送信したことを示します/サーバーから送られてきた場合はそのようにログされこの場合はクライアント側から ACK が返されます）がわかりその間隔が次行の時刻との差でわかります。
10:09 08:26:44.098 Exiting doze → Doze から抜けたことを示します
10:09 08:26:44.099 Sent com.google.android.gsf.gtalkservice → GCM が動作しています
10:09 08:26:51.258 Received jp.co.fusioncom.smartalk.android result=1 time=187 p=10 → この時刻に SMARTalk からの通知を受け取ったことを示しています（着信通知です）
そのあと発信側で呼び出しをとりやめましたので Close err:FIN time=5745 と記録されています。
また、WiFi に接続変更しましたので net=1 に切り替えられたログが記録されています。
つまりログ上は GCM が動作しており、Doze 状態から脱却して SMARTalk がほかからの呼び出しで着信動作に入ったということがわかります。
発着信の動作が不安定などの場合にこのようなシーケンスで動作しているかどうかで不具合の発見に役立てることができます。
常駐型ソフトフォンアプリの場合は少し違うシーケンスになります。
Doze に入っていなければログ上の変化はありません。
2018-10-07
Bluetooth スピーカー
Sound Blaster 社製の一部機種と SONY のこのシリーズくらいです。
ミニコンポが２セットのほか５ch 対応セットもありますので、AUX 出力対応品を探していました。
Bluetooth アダプターという手もありましたが、本品のようなスピーカーは手軽なのでどうせなら、と AUX 出力可能なものにしました。
ということで、SONY の SRS-BTS50 Black を購入しました。
すでに製造中止機種なので、品薄になっていると思います。
少し高音域の伸びが気になりますが、まぁまぁこの価格帯では妥協も仕方がないでしょう。
カミさんが自分のスマホで楽曲を聴いているのを見ていて、スピーカーを用意してみたらどうだろうか、ということで購入しました。
最初は「自分（カミさん）のためではなくワタシ自身が使うために購入したのでは？」とカミさんにいわれましたが「いやいや、これはアンタのために買ったんだよ」といって使わせたところ、大変気に入ってくれましたから買ってよかったと思います。
1台目のペアリング方法と２台目以降のペアリングの仕方が異なっていて、２台目のペアリングに少し戸惑いましたが、無事にこれもペアリングできました。
マニュアルは丁寧に読むものだと改めて感じた次第でオハズカシイ。
2018-10-06
IP電話サービスの公式アプリってどれも問題があるように思えます
050plus / SMARTalk / 050Free / LaLa call 等のいずれも Google Play store での評価点は軒並み ３.０ 〜 ３.３ です。
少なくとも ４.０ 以上は欲しいと思います。
IP 電話自体はネット環境やサーバー性能、端末性能などが４G になってからは劇的に改善されてきていて固定電話と遜色ないところまできています（固定電話も「黒電話」を除けば IP 電話なのですが）。
２０１６年以前はまだまだ使えるレベルには達していなかったのが、２０１６年秋頃からすごくよくなった、という印象です。
ところが各サービスの「公式アプリ」は安心して使えるレベルにはまだ達していない、というのが実情だと思います。
そのため「IP 電話は使えない」という認識がまだまだ多くあり大変残念です。
すでに NTT の「ひかり電話」も IP 電話です。
インターネット経由の IP 電話か、NTT 直収の IP 網での IP 電話かの違いはあっても同じ IP 電話なのです。
米国には NTT のような存在はありませんからすべてがいまやインターネットによる IP 電話です。
こういう状況を踏まえると日本の電話事業は相変わらず NTT（および総務省）が仕切っている感じで、これが IP 電話事業を限定的にしてしまっているのが実情です。
欧米の IP 電話サービスのように「推奨アプリ」と「プロビジョニング」の対応にした方がいいと思いますが、なぜか「固有のアプリ」にこだわって、しかも作りが決してよくないという悲惨な状況です。
各サービス事業者は一度気持ちをクリアにしてご自分たちのサービスのあり方を見直して欲しいものです。
みなさんは「公式アプリ」の低評価どおりの問題にぶち当たり、ほかの VoIP アプリをあれこれ試行されてお使いになっておられると思うのです。
「ほかのアプリ」で仮に問題が生じても「公式アプリ」ではないので「サポート外の使い方なので相談に乗れません」と冷たくあしらわれていると思います。
そういう方々がお困りになってネット情報を検索しああでもない、こうでもない、と日夜（？）奮闘されていて、そういう方々の一部の方々が当ブログも閲覧くださっていると思うのです。
ワタシはサービス事業者の提供してる「公式アプリ」も評価試用し、ほかの VoIP アプリもいろいろ試用・本運用してきました。
その中でこれはよい、と思うものもいくつかあり、日々進化しているように思いますが、ときにアップデートがグレードダウンしたりして、一層混乱状態を引き起こしているように思います。
端末の OS バージョンとの関係もあったりします。
つまり扱うためのパラメーターが多すぎるのです。
そこでできるだけ単純化して使う、あれこれ試すのは単純な使い方がうまくいってからにする、というのがコツだと思っています。
例えば、コーデック一つをとってみても G.711μ-law（PCMU と表現している場合もありますが同じものです）一本だけにします。
これでうまくいかないから、といってほかのコーデックに手を出してもパラメーターが増えて混乱するだけです。
G.711μ-law でうまくないなら、それはコーデックの問題ではなく別の問題があるからです。
最近思うのは「プッシュ着信」の問題です。
どうも試行した限りでは「プッシュ着信」は問題を大きくするだけでなんらメリットはない、とまで思うに至りました。
常駐型ではバッテリー消費が半端ないから、とお嘆きあなた、実はバッテリー消費が半端ないのはその VoIP アプリのせいばかりではないのです。
ワタシがこれまで経験した範囲では 1 % / 1h 程度なら容認の範囲ということです。
これ以下になることも少なくありませんし、多少コンマ何％か増えたところで問題にするほどではありません。
アプリをインストールして設定して、そのあとキャッシュをクリアし、強制再起動してみればほとんどのケースでバッテリー消費は 1 %以下 / 1h に収まっています。
「プッシュ着信」アプリの設定を「プッシュ着信」のままほかの常駐型アプリを設定した場合、片通話や無音問題を引き起こします。
こういうことはサービス事業者も「公式」には情報開示していません。
（「公式アプリ」が「プッシュ」対応しているのでいい難いのかも知れません）
ですから、「プッシュ着信」アプリは「非プッシュ」に設定し終了させる、実行中アプリリストからも終了させる、ということをしたあとに常駐型アプリの設定をするように注意が必要です。
ほとんどのサービス事業者の「公式アプリ」は「プッシュ着信」対応型になっており、これが引き起こす問題に最近一層の注意が必要だと強く感じるようになりました。
着信の確実性は「プッシュ」である必要はありません。
それよりも「プッシュ」が引き起こす問題を回避するためには「プッシュ型アプリ」の「プッシュ」は強くオススメしません。
Acrobits 系はこの「プッシュ」に対応しているアプリの一つで、異論はもちろん承知の上でいいますが「プッシュ設定での使用」はワタシはあまりオススメしません。
とにかく「常駐型」アプリをできるだけ単純化して問題の根っこを早く見つけることが結果的によい状態になる、ということです。
少なくとも ４.０ 以上は欲しいと思います。
IP 電話自体はネット環境やサーバー性能、端末性能などが４G になってからは劇的に改善されてきていて固定電話と遜色ないところまできています（固定電話も「黒電話」を除けば IP 電話なのですが）。
２０１６年以前はまだまだ使えるレベルには達していなかったのが、２０１６年秋頃からすごくよくなった、という印象です。
ところが各サービスの「公式アプリ」は安心して使えるレベルにはまだ達していない、というのが実情だと思います。
そのため「IP 電話は使えない」という認識がまだまだ多くあり大変残念です。
すでに NTT の「ひかり電話」も IP 電話です。
インターネット経由の IP 電話か、NTT 直収の IP 網での IP 電話かの違いはあっても同じ IP 電話なのです。
米国には NTT のような存在はありませんからすべてがいまやインターネットによる IP 電話です。
こういう状況を踏まえると日本の電話事業は相変わらず NTT（および総務省）が仕切っている感じで、これが IP 電話事業を限定的にしてしまっているのが実情です。
欧米の IP 電話サービスのように「推奨アプリ」と「プロビジョニング」の対応にした方がいいと思いますが、なぜか「固有のアプリ」にこだわって、しかも作りが決してよくないという悲惨な状況です。
各サービス事業者は一度気持ちをクリアにしてご自分たちのサービスのあり方を見直して欲しいものです。
みなさんは「公式アプリ」の低評価どおりの問題にぶち当たり、ほかの VoIP アプリをあれこれ試行されてお使いになっておられると思うのです。
「ほかのアプリ」で仮に問題が生じても「公式アプリ」ではないので「サポート外の使い方なので相談に乗れません」と冷たくあしらわれていると思います。
そういう方々がお困りになってネット情報を検索しああでもない、こうでもない、と日夜（？）奮闘されていて、そういう方々の一部の方々が当ブログも閲覧くださっていると思うのです。
ワタシはサービス事業者の提供してる「公式アプリ」も評価試用し、ほかの VoIP アプリもいろいろ試用・本運用してきました。
その中でこれはよい、と思うものもいくつかあり、日々進化しているように思いますが、ときにアップデートがグレードダウンしたりして、一層混乱状態を引き起こしているように思います。
端末の OS バージョンとの関係もあったりします。
つまり扱うためのパラメーターが多すぎるのです。
そこでできるだけ単純化して使う、あれこれ試すのは単純な使い方がうまくいってからにする、というのがコツだと思っています。
例えば、コーデック一つをとってみても G.711μ-law（PCMU と表現している場合もありますが同じものです）一本だけにします。
これでうまくいかないから、といってほかのコーデックに手を出してもパラメーターが増えて混乱するだけです。
G.711μ-law でうまくないなら、それはコーデックの問題ではなく別の問題があるからです。
最近思うのは「プッシュ着信」の問題です。
どうも試行した限りでは「プッシュ着信」は問題を大きくするだけでなんらメリットはない、とまで思うに至りました。
常駐型ではバッテリー消費が半端ないから、とお嘆きあなた、実はバッテリー消費が半端ないのはその VoIP アプリのせいばかりではないのです。
ワタシがこれまで経験した範囲では 1 % / 1h 程度なら容認の範囲ということです。
これ以下になることも少なくありませんし、多少コンマ何％か増えたところで問題にするほどではありません。
アプリをインストールして設定して、そのあとキャッシュをクリアし、強制再起動してみればほとんどのケースでバッテリー消費は 1 %以下 / 1h に収まっています。
「プッシュ着信」アプリの設定を「プッシュ着信」のままほかの常駐型アプリを設定した場合、片通話や無音問題を引き起こします。
こういうことはサービス事業者も「公式」には情報開示していません。
（「公式アプリ」が「プッシュ」対応しているのでいい難いのかも知れません）
ですから、「プッシュ着信」アプリは「非プッシュ」に設定し終了させる、実行中アプリリストからも終了させる、ということをしたあとに常駐型アプリの設定をするように注意が必要です。
ほとんどのサービス事業者の「公式アプリ」は「プッシュ着信」対応型になっており、これが引き起こす問題に最近一層の注意が必要だと強く感じるようになりました。
着信の確実性は「プッシュ」である必要はありません。
それよりも「プッシュ」が引き起こす問題を回避するためには「プッシュ型アプリ」の「プッシュ」は強くオススメしません。
Acrobits 系はこの「プッシュ」に対応しているアプリの一つで、異論はもちろん承知の上でいいますが「プッシュ設定での使用」はワタシはあまりオススメしません。
とにかく「常駐型」アプリをできるだけ単純化して問題の根っこを早く見つけることが結果的によい状態になる、ということです。
登録:
投稿 (Atom)