2019-06-02

iPhone へのソフトフォン:SessionTalk Pro Softphone の設定


アプリを初めて起動すると、下図のように最初にアカウントの作成画面になるので



img



 





























 


[○に i ] の部分をクリックし、アカウント作成画面に移る






次の画面は、アカウントの作成 画面


img 


















 






 




 アカウント名:任意(アカウント名でも電番その他なんでもいい)

 有効ボタン:そのまま

ユーザー詳細
 表示名:プロバイダが 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、パスワード、ドメイン等の設定誤りがある



設定の編集:右下の 設定 をクリックする


img































アカウント名は SIP 情報設定時の「アカウント名」が表示される

右側の「録音アイコン」は通話録音時の録音有無が表示され、ここをクリックすると内容を確認できる


その右の「アンテナアイコン」は、クリックすると有効な SIP アカウントの一覧が表示され、発信アカウントを変更できる



下図の 設定 画面になる


img































SIPアカウント → SIPアカウントの編集

下図の SIP アカウント 画面になる



img
































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 くらいの消費量です。
プッシュ系だとこの3分の1程度で済みます。



ところがプッシュ系はバッテリー消費は抑えられるものの、別の問題があります。


プッシュ系で代表的なものは 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 は1台しか持ち合わせていませんので 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 サーバーの動作と関連していると思います。


ブラステルでは【「デバイス1」の「電番1」】から【「デバイス2」の「電番1」】を呼び出しが可能で(ある電番から同一電番の呼び出し)、このときに通話可能なケースと通話不可のケースがありますが、どうやらこの事象に類似しているように思います。


このような場合の、「通話可能/不可」は使うソフトフォンやデバイス特性(?)に関連していそうですが、よくはわかりません。 



まだまだ大雑把な状況把握ですので、引き続き調べてみたいと思います。

SIP ログを分析すればもう少し、このあたりの動作状況がわかるのではないかと考えます。






-------------------

米中の通商問題、機密保護問題からファーウェイおよびその新端末(P30)が大きな影響を受けています。


これ以前の機種の場合(P20以前)、ファーウェイはセキュリティアップデートは提供する、といっており、 Google も既存機種へのサポートは継続するようですが、いつこれがひっくり返るようなことにならないとも限りません。


そうなると、国産機か非中華製の Android 機、または iPhone にしなくてはならなくなってしまいます。


iPhone は SE 以降では 6s/7/8 くらいがおすすめ機種と「私は」勝手に思っていますが、ソフトフォンも光明が射してきました。









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台目のペアリングに少し戸惑いましたが、無事にこれもペアリングできました。



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