2019-04-08

未来型 VPN : WireGuard を導入してみました

ここに特徴や説明が記載されています。

そこで Raspberry Pi 3 にインストールしてみました。

後述の「参考サイト」に導入手順が記載されており、これを参考にインストール・設定してみました。


VPN 導入目的は大きく2点です。

① 自宅ネットワークに外から安全にアクセスできるようにする。
② フリー 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 を設定する


3. 項以降の設定をします。

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] → cat コマンドで抽出した中身をペーストする

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] → cat コマンドで抽出した中身をペーストする
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プラスの場合は4桁アドレスでもよい
(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プラスの場合はアドレスはまず変わりませんので4桁の直接指定でもいいでしょう。



通常、ルーターとその配下は「クラス C」を使うことが多いと思います。
また、VPN 仮想アドレスは「クラス A」またはルーターとは 3 桁目が異なる「クラス C」が多いと思います。

iPhone のテザリング(ネットワーク共有)は「クラス B」のようですが。




ルーター及びその配下は 公共 WiFi での VPN 使用時にアドレス空間の競合を避ける必要があり、例えば、192.168.57.0/24 のように、3桁目は "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 でどうなるかについて。

==>> 4月8〜9日に近所のコンビニで試しました。

結論的にいいますと、こちらもストレスなく 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 に入っていなければログ上の変化はありません。








2018-10-07

Bluetooth スピーカー

AUX 入力が可能な Bluetooth スピーカーは多いのですが、AUX 出力可能な機種は限られています。

Sound Blaster 社製の一部機種と SONY のこのシリーズくらいです。

ミニコンポが2セットのほか5ch 対応セットもありますので、AUX 出力対応品を探していました。


Bluetooth アダプターという手もありましたが、本品のようなスピーカーは手軽なのでどうせなら、と AUX 出力可能なものにしました。


ということで、SONY の SRS-BTS50 Black を購入しました。

すでに製造中止機種なので、品薄になっていると思います。


























少し高音域の伸びが気になりますが、まぁまぁこの価格帯では妥協も仕方がないでしょう。

カミさんが自分のスマホで楽曲を聴いているのを見ていて、スピーカーを用意してみたらどうだろうか、ということで購入しました。



最初は「自分(カミさん)のためではなくワタシ自身が使うために購入したのでは?」とカミさんにいわれましたが「いやいや、これはアンタのために買ったんだよ」といって使わせたところ、大変気に入ってくれましたから買ってよかったと思います。


1台目のペアリング方法と2台目以降のペアリングの仕方が異なっていて、2台目のペアリングに少し戸惑いましたが、無事にこれもペアリングできました。



マニュアルは丁寧に読むものだと改めて感じた次第でオハズカシイ。








2018-10-06

IP電話サービスの公式アプリってどれも問題があるように思えます

050plus / SMARTalk / 050Free / LaLa call 等のいずれも Google Play store での評価点は軒並み 3.0 〜 3.3 です。

少なくとも 4.0 以上は欲しいと思います。

IP 電話自体はネット環境やサーバー性能、端末性能などが4G になってからは劇的に改善されてきていて固定電話と遜色ないところまできています(固定電話も「黒電話」を除けば IP 電話なのですが)。


2016年以前はまだまだ使えるレベルには達していなかったのが、2016年秋頃からすごくよくなった、という印象です。



ところが各サービスの「公式アプリ」は安心して使えるレベルにはまだ達していない、というのが実情だと思います。

そのため「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 系はこの「プッシュ」に対応しているアプリの一つで、異論はもちろん承知の上でいいますが「プッシュ設定での使用」はワタシはあまりオススメしません。




とにかく「常駐型」アプリをできるだけ単純化して問題の根っこを早く見つけることが結果的によい状態になる、ということです。 









2018-10-04

ブラステルとプッシュ系ソフトフォンアプリの留意事項

ブラステルは複数デバイスに同一アカウントを登録できますのでこのような使い方がしたいときがあると思います。

ブラステルは複数デバイスへの登録は強く非推奨な使用法としていますのでサポート対象外になりますから、自己責任ということになります。


それでも例えば、イエデンにブラステルを登録して外出中でも着信を受けたい、というような場合があります。


転送設定して別の電話(携帯電話や他社 050 アカウントの電話)で受ける、というのが普通の使い方なのですが、 一定時間呼び出し後に転送または即時転送の場合、外出のたびに転送設定し直すなど多少の面倒臭さがあります。

またブラステルの転送は転送先に発信元電番は表示されず着信電番(転送設定した電番)が表示されますので、転送先で受ける際誰からの電話なのかがわかりません(SMARTalk は転送しても発信元電番が通知されます)。


そこで複数デバイスに同一アカウントを登録して使いたいわけです。

これは外出中に限らず、スマホをウチの中でも子機扱いできる使い方でもあるのです。




イエデン用のアナログアダプターは通常はプッシ着信には対応していません(常時起動待受状態ですからそもそもプッシュは必要としません)。


同一アカウントを 050Free にも登録してこれをプッシュ着信に設定すると、イエデンも 050Free も無音になったり、片通話になったりします


ブラステルは非推奨ですが、こういう使い方をしたい場合は非プッシュ着信のアプリを使う必要があります。


プッシュ着信対応しているソフトフォンは Acrobits 系(Acrobits、Croud Softphone、Groundwire、050Freeなど)や他 ITSP(SMARTalk [Acrobits 系か?]、050plus など) があります。


ブラステルの場合、Acrobits 系を使ってプッシュ着信設定し、イエデンにも登録すると無音・片通話問題を引き起こします


そこで、複数デバイスに同一アカウントを登録の場合は、非プッシュのソフトフォンアプリを使用します。

また、それらのコーデックはすべて同じコーデックを使う設定にする必要があります。
具体的には G.711μ-law(PCMU と表現している場合もあります)のみに設定します。


非プッシュのソフトフォンは GS Wave、Zoiper、CSipSimple、MizuDroid などがあります。


プッシュ系にも設定してしまったときは、プッシュ系のソフトフォンアプリの「プッシュ着信」を「発信のみに使用」または「オフ」にし、そのアプリを終了させます。
この段階でアンインストールしても構いません。

非プッシュ系のソフトフォンアプリもすべて非 Active にします。


その後ブラステルのマイページに入り、「パスワード」を再発行します。

 「パスワード」の再発行で、サーバーのレジスト状態がクリアされるようです。


その後にイエデンのアダプターのパスワード再設定を行い Reboot します。

これが Register 状態になったら、ほかのデバイスの非プッシュのソフトフォンアプリを起動し、これもパスワード再設定し Active にします。



以上の手順で複数デバイスへの設定が終わります。


あとは普通に発着信できるようになります。

イエデンへの着信もスマホで受けることも可能です。


このような使い方で、実際にイエデンにかかってきた電話を、外出中に何度か受けたことがありますが、相手はイエデンと話していると思ってくれていたようです。



複数デバイスに同一アカウントをプッシュ着信のアプリに設定してはいけません



実は 050FRee はプッシュ着信設定していても常時起動状態です。
おそらく Doze が関係していると思われますが、常時起動ならばプッシュである必要もないのですが、なぜかこういう動作をしています。


ですから、このことでバッテリー消費が抑えられるわけではありません。



なお、ブラステルの SIP サーバーは kamailio (4.1.0-pre0 (x86_64/linux)) です。
Kamailio は Asterisk のようなオープンソースの SIP サーバーです。

そのため複数デバイスへの同一アカウントの登録が可能になっていると思われます。


SIP サーバーでは内線扱いでゲートウェイしているようです。

ブラステル以外からの着信の場合、相手アカウントは 172.16.0.0/16 〜 172.31.0.0/16 のプライベートアドレスと内線アカウントを割り当てられて発着信や音声ストリームのやり取りをしているようにログからは見えます。

ブラステルからブラステル以外への発信の場合は、ブラステル側は 172.16.0.0/16 〜 172.31.0.0/16 を割り当てられ、相手側は 192.168.0.0/16 が割り当てられるようですから、どちらも内線扱いでゲートウェイしているように見えます。

ブラステルからブラステルの場合は発信側は 172.16.0.0/16 〜 172.31.0.0/16 のプライベートアドレス、着信側はブラステルの SIP プロキシアドレスが割り当てられているように見えます。



実際のところはよくはわかりませんが、ログを見る限りこのような振る舞いをしているように思えます。