今回は迷惑メール対策のうち「なりすましメール対策」について、各認証方式の違いを覚え書きとして記しました。

なりすましメール

受信者が不利益・被害を被るケースの一つに「なりすましメール」があげられます。Amazonや楽天、あるいはクレジットカード会社を装ったメールを受け取った経験がある方は多いのではないでしょうか。

以前は本文が露骨に機械翻訳だったり中国語っぽかったりでそれと気づき易かったのですが、最近はパッと見ただけでは分かり辛い巧妙なものも多いですね。

これ以外では「ドメインを詐称する」という手口があります。受信者もなりすましと気付きにくいうえ、個人や企業のアイデンティティであるドメインのイメージが悪化することで被害が大きくなります。

今回登場するSPF・DKIM・DMARCはいずれもこのなりすましを防ぐための認証手段です。

SPF(Sender Policy Framework)

「DNSに登録されているレコードと送信元サーバーのIPアドレス」で真偽判定するのがSPF認証です。

spfには複数のサーバーを登録することが可能で、この仕組みが威力を発揮するのは例えば外部サービスのお問い合わせフォームなどを利用する場合です。サービス提供者側のサーバーをspfへ併記することで、無事なりすましメール判定を回避することができます。

受信したメールのヘッダを見ると「spf=pass」とか「spf=fail」といった記述がありますので、気になるメールがあれば一度チェックしてみましょう。

DKIM(DomainKeys Identified Mail)

DKIM認証はメールに付与された署名が正しいかどうかを判定するもので、下記はメールサーバーで署名する場合のイメージです。

DKIMは送信経路上のいずれかの地点で署名を付与します。外部サーバーからメールを送信する時、署名を付与する仕組みがなければ認証失敗となります。

こちらもSPF同様「dkim=pass」や「dkim=fail」といった記述をヘッダで確認できます。

DMARC(Domain-based Message Authentication, Reporting, and Conformance)

DMARCはSPFやDKIMのような単体の認証方法ではなく、「SPFもしくはDKIMの判定結果」と「アライメント」と呼ばれる判定結果を組み合わせた仕組みです。従って、SPFもDKIMも設定しない状態でDMARCを有効化すると全てのメールが認証に失敗するので注意が必要です。

DMARCの良いところは「認証失敗時にそのメールをどう取り扱うべきかDNSで公開できること」です。これはSPFの登録と同じでTXTレコードへ記述するのですが、「何もしない（none）」「隔離する（quarantine）」「受信拒否する（reject）」から選択できます。

また、受信者側サーバーから認証失敗の通知を受け取ることができますので、視覚的に状況を把握することが可能であることもポイントです（但し、生データはXMLですので何かしらツールが無いとキツイです）。

以上より、DMARCを有効化する際は一先ず「none」でどのようなレポートが上がってくるかを分析し、状況を見て「quarantine」もしくは「reject」へ変更するのが安全です。

まとめ

ドメイン認証はメール送信者側の立場で考えると、なりすましを防ぐだけではなく自ドメインのメールを確実に相手へ届けるために必要な手段でもあります。伝えたいこと・伝えないといけないことが伝わらなかった結果、言った言わないのトラブルになったり信用を失うことは避けねばなりません。できることは是非先に手を打っておきましょう！

障害は忘れた頃にやってくる

2022年10月23日、青空広がる爽やかな日曜日。それは家族で昼食をとっていたときのことでした。

インターネット繋がらないんだけど何かしてる？

ボス

食事の直前まで機嫌よくツイッターを眺めていたのでボスのスマホが調子悪いのだろうと思い、私は目の前のソバに一味をタップリ振りかけながらボスにスマホの再起動を促しました。

軽くむせながらソバを食べていたところへ鶴の一声がかかります。

直ってないなんとかして

ボス

自分のスマホを取り出してみると確かにネットが使えません。なんで？？

ボスの命令は絶対です。ソバを胃袋に流し込み真っ赤に染まった汁を飲み干し、盛大にむせながら私は調査を開始しました。

全セグメントで障害発生

どうせアクセスポイントの調子が悪いんだろうと思って機器本体を眺めてみると、明らかにアカン感じの色を放っているランプを見つけました。「ほら、きっとこいつのせいだ」とすかさず電源OFF・ONしましたが、再起動後もランプの色は変わりません。

安物だったから壊れちゃったか・・・それにしても短命だったなと、古いアクセスポイントを引っ張り出そうとしたのですが、ちょっと気になったので別セグメントのアクセスポイントへスマホを繋ぎ変えてみました。

「・・・ん？」

ダメです。ボスが使うネットワークと同じ症状。アクセスポイントとはつながるのですがネットが一切使えません。他のセグメントも全部ダメ。重障害です。

ルーターの様子を確認してみた

全セグメント死亡。休日昼下がりのイベントとしてはかなりのハードモードです。夜は旧知のメンバーと数年ぶりに宴の約束があるので、なんとしても夕方までには復旧させねばなりません。とりあえずPCを持ってルーター(RTX1210）の元へ向かいました。

「これが死んでたらワイも死ぬ」

祈りながらルーターにログイン試行・・・すんなり入れました。見える範囲で異常はありません。なんだろう？ルーターから一度抜けて、再度各セグメントのアクセスポイントに接続しルーターへアクセスしてみるとこれもOK。LAN側に問題は無いようです。

念のためRTX1210を再起動させてみましたが変化ありませんでした。

sandambara家のネットワーク構成

以前記事にまとめましたが、我が家のネットワークは元々ホームゲートウェイ＋ひかり電話という構成だったところへRTX1210を投入し、その後VLANを作成し現在の構成に至ります。

フレッツ光＋IPoE化でハマった記録

先日自宅用に購入したRTX1210、早速活躍しております。何年も前に仕事でRTX1200を少し触っていたのですが、GUIの充実度や操作レスポンスなど、随分進化したんだなあ・・・と感動してしまいました。我が家のネット環境はフレッツ光隼＋OCN...

sandambara.com

2020.09.18

ここでホームゲートウェイを再起動してみましたがこれも変化なし。電話は普通に使えているのでホームゲートウェイから外の土管も問題無さそうです。

となるとプロバイダがあやしいかもと、OCNについて検索するも障害情報は見当たりません。Twitterでも騒いでいる人はいません。おっかしいなあ・・・

もしかして名前解決できない？

この辺りまできて、以前Cloudflareが死んだことをふと思い出しました。

Cloudflare ブログ

Get the latest news on how products at Cloudflare are built, technologies used, and join the teams helping to build a be...

blog.cloudflare.com

当時は「ふーん」くらいにしか思っていなかったのですが、夏頃にCloudflareのパブリックDNSが早いらしいという記事を見つけ、RTX1210で各セグメントに配布するDNSの値を1.1.1.1にしていたのです。

「http://IPアドレス」だとアクセスできるかも？と考え、とあるサイトにアクセスしてみると・・・普通に表示されました。原因は分かりませんが結論としてDNSが機能していないことが分かったので、ルーターの設定を変更（1.1.1.1→OCNのDNS）して無事解決に至りました。

試しにDNSを切り替えながらnslookupを試してみるとこんな感じでした。

反省会

後から気付いたことですが、少ないながらも同じ症状の方がおられることが分かりました。

この記事を書いている今も真実は闇なのですが、今回の反省点として「セカンダリDNSを設定していなかったこと」が挙げられます。不死身のサーバーなどこの世に存在しないのです。

善は急げ。早速RTX1210のコンフィグを修正しました。

dhcp scope option VLANID dns=1.1.1.1,202.234.232.6

8.8.8.8でも良かったのですが、まあ、1個は標準値（プロバイダの指定値）にしておこうかと。

復旧報

約1時間程度で復旧し、思っていたより傷が浅かったことに安堵しました。夜の宴も予定通りです。

ボスに復旧を伝えました。

あ、LINEちゃんと使えるようになったわ

ボス

その直後に放ったツイートがこちらです。

電気ガス水道インターネット、使えて当たり前ではないのです。「何も無いこと」を提供するために裏で働く人たちへの敬意と感謝を忘れないようにしたいですね（褒められたい）。

OpenVPNサーバーを構築する　その１

RTX1210導入をきっかけに自宅通信回線をIPoE化したりLANケーブルを自作したりしておりますが、今日はIPoE化によりL2TP/IPSecが利用できなくなったのでOpenVPNサーバーの構築手順を改めて確認しておきたいと思います。構築...

sandambara.com

2020.09.26

OpenVPNサーバーを構築する　その２

前回に続きOpenVPNのセットアップを行います。ファイアウォールのインストールと設定未導入の場合、ufwをインストールします。sudo apt install ufwインストールが終わったら「全ての通信を拒否する」→「通す通信を登録する」...

sandambara.com

2020.09.29

OpenVPNサーバーを構築する　その３

今日はクライアントの設定を行います！クライアント用秘密鍵を作るでは、早速参りましょう。sandambara@srv001:~$ cd easy-rsa/easyrsa3sandambara@srv001:~/easy-rsa/easyrsa...

sandambara.com

2020.10.05

クライアントはいくつか試しましたが、今はOpenVPN Connectで落ち着いています。

OpenVPN Connect - VPN For Your Operating System | OpenVPN

Download the official OpenVPN Connect client VPN software for your operating system, developed and maintained by our exp...

openvpn.net

OpenVPN Connectの良いところはプラットフォームに依存しないところで、WindowsにMac、iOS、AndroidだけでなくLinuxもクライアントが用意されています。

このアプリはプロファイルを取り込むと後から触れないのが唯一残念なポイントです。削除→再取込でも良いのですが、コンフィグに微調整をしたいときは面倒ですよね。

そこでコンフィグが保存されているパスを調べました。こちらです。

C:\Users\ユーザー名\AppData\Roaming\OpenVPN Connect\profiles

注意というほどのことではありませんが、このディレクトリに直接コンフィグファイル（.ovpn）を保存してもOpenVPN Connectは検知してくれません。アプリケーションのImport Profileから読み込ませる必要があります。

スマホ内線が使えなくなった！

VPNについてはいくつか構築に関する記事を書いてきました。私は現在OpenVPNサーバーを宅内に設置して使っています。

自宅のルーターをVPNサーバーとして利用する part1 ルーターの設定

自宅のルーターをVPNサーバーとして利用します。

sandambara.com

2020.01.31

覚書　VPN利用時のパフォーマンス・トラブル改善

以前こちらの記事で自宅ルーターをVPNサーバーとして利用するための設定について書きました。フレッツ光が足回りという前提でしたが、どのような形態であれVPN利用時のパフォーマンスが悪い、セッションが固まってしまうというトラブルでお悩みの方もお...

sandambara.com

2020.08.24

OpenVPNサーバーを構築する　その１

RTX1210導入をきっかけに自宅通信回線をIPoE化したりLANケーブルを自作したりしておりますが、今日はIPoE化によりL2TP/IPSecが利用できなくなったのでOpenVPNサーバーの構築手順を改めて確認しておきたいと思います。構築...

sandambara.com

2020.09.26

また、NTTのひかり電話回線でスマホを子機にする機能も利用しています。使っているアプリはこちらです。

AGEphone | テレワーク | ageet Corporation

ageet（アギート）は、NTTをはじめ多くの大手企業に採用される、日本のスマホ内線化ソリューションのデファクトスタンダード企業です。AGEphoneはNTT西日本・東日本推奨のひかり電話対応アプリで、スマホやPCから利用可能です。

www.ageet.com

電話の度に受話器を取りに行かなくても手元のスマホで通話出来たり、外出先からVPN経由で自宅の電話回線を利用し通話したりと重宝していました。

ところがある日、外出先からVPNで自宅へ接続していてもAGEphoneが使えなくなっていることに気付きました。ホームゲートウェイ（以下HGW）には接続出来ているのですが、通話が始まると強制切断されてしまうのです。

通話できなくなった原因

利用できなくなったのはどうもOpenVPNを利用するようになってからのようです。「なんでだろう？？」と色々試すも改善されず数か月。OpenVPNにはルーティングモードとブリッジモードの2つがあり、これはルーティングモードで利用する際に起こる事象らしいことが漸く分かりました。

では「OpenVPNをブリッジモードで使えば良いのでは？」と思いましたが、iOSデバイスがブリッジモードでは接続できないことが分かり、いよいよ八方塞がりです。

PPPoEを復活させる

では、そもそもなぜOpenVPNを使うようになったかといえば、IPoE化によりそれまで利用していた手段（L2TP/IPsec）では自宅へVPN接続できなくなったからでした。

折角安定・高速化実現のために導入したIPoEも良いことばかりではないのです。その点についてはこちらの記事にまとめました。

RTX1210＋IPoE環境でVPNを構築する

今日は一工夫必要なIPoE環境のVPN構築について書きます。構築環境プロバイダ　　OCN　IPoE（動的IP契約）HGW　　 　 　RT-500KIひかり電話　　ありVPNサーバー　宅内に構築したOpenVPNサーバーIPoE環境でIPv4...

sandambara.com

2020.10.31

では、どうするか

かなり時間をかけて解決策を考えてみたものの、私の知識ではどうにもなりそうにありませんでした。そのため、L2TP/IPsecでVPNを利用できるPPPoEセッションを復活させたのです。

ではここで、本職のエンジニアさんが見たら発狂しそうな図をご覧いただきましょう。

フレッツは標準で2セッションまで接続できるので、青色のIPoE回線（OpenVPNで利用）に加え緑色表示のPPPoE（L2TP/IPsecで利用）を復活させたのです。L2TP/IPsecはルーティングもDHCPもRTX1210にお任せで良く、スマホ内線も問題無く利用できるのです。

1つだけハマった点

今回PPPoEはなるべく安価に済ませたかったのでインターリンクで契約してみました。

無料体験・即日ID発行のプロバイダ - 株式会社インターリンク【公式】

すぐに使えていつでも解約できる！最大２ヶ月の無料体験あり。フレッツ光対応プロバイダ|各種VPNサービス|固定IPのSIM、MVNO|ドメイン|レンタルサーバー

www.interlink.or.jp

RTX1210はGUIでポチポチするだけでプロバイダ設定が完了します（個人的にはヘタな家庭用ルーターより簡単だと思います）。

設定も終わりリンクアップ確認！ネットも繋がっているしチョロいチョロいとなどと思っていたところでVPNが繋がらないことに気付きました。

ログを見ているとWAN側からVPNを繋ぎに来た形跡はあるのですが・・・

繋がらなかった理由

RTX1210のコンフィグを眺めているとこちらに目が止まりました。

ip route default gateway tunnel 1

tunnel1（IPoEを設定している経路）を使って通信するよーという設定ですね。しかし、L2TP/IPsecのセッションはtunnel 1ではなくpp（PPPoE）から接続しますので、先ほどの図にある緑の経路から入ってきたものを青い経路から送り返そうとしていることになります。

緑の経路から来た通信は緑の経路から戻してあげねばならないので、VPNが繋がらないのも納得です。

ルートの変え方が分からない・・・

そこまでは良かったのですが、その先が分かりません。この辺がGUIポチポチ星人とコンフィグゴリゴリ星人の差。残念ながらポチポチ星人の限界です。

ということで、今回もヤマハルーターお客様ご相談センターのお力をお借りしました。コロナ禍で業務過多になっておられるであろうところ、いつも丁寧にご対応頂き本当に有難うございます！

通信内容によってデフォルトルートを変える

L2TP/IPsecの通信はpp（PPPoE）、それ以外の通信はtunnel 1（IPoE）へ向けたい場合、ppへ送りたい通信をフィルタで定義します。

ip filter 2 pass * * udp 500,4500,1701 *
ip filter 3 pass * * tcp * 2002
ip filter 4 pass * * udp * domain
ip filter 5 pass * * esp

filter 2とfilter 5は見覚えがあるのですが、3と4が何に必要な通信か分からなかったので質問したところ、ヤマハさんが提供されているネットボランチDNSを利用する場合に必要なフィルタとのこと。めっちゃ使わせて頂いています！！

そして、フィルタの定義が終わったらデフォルトルートを修正します。

#修正前
ip route default gateway tunnel 1
#修正後
ip route default gateway pp 1 filter 2 3 4 5 gateway tunnel 1

filter 2-5に合致する通信はpp（PPPoE）を、それ以外の通信はtunnel 1（IPoE）を使うよーという設定になります。

これで無事L2TP/IPsecでVPNを利用できること、当初の目的のスマホ内線を利用できることを確認しました！

通話を利用するVPNはL2TP/IPsecで、それ以外の通信はOpenVPNといった住み分けで使い様子を見ようと思います。

あとがき

私は零細企業の何でも屋なので別に知らなくても良いことかもしれませんが、引き出しが増えたことが嬉しいのと同時にコンフィグを「読めるけど書けない」のがものすごく悔しいのであります（涙）

それが仕事とはいえ、こんな私にでもユーザー目線で技術を教え伝えて下さる方々の存在は本当に有難いです。私も自分が身に着けた知識が、いつかまたどなたかのお役に立つといいなあと思います。

構築環境

• プロバイダ　　OCN　IPoE（動的IP契約）
• HGW　　 　 　RT-500KI
• ひかり電話　　あり
• VPNサーバー　宅内に構築したOpenVPNサーバー

IPoE環境でIPv4通信を行う技術（IPv4 over IPv6）はいくつかあって、今回の記事ではMAP-E（バーチャルコネクト）という技術が前提となります。

また、VPNサーバーはルーターではなく宅内に用意したVPNサーバーが前提です。VPNサーバー構築については過去記事をご参照ください。

OpenVPNサーバーを構築する　その１

RTX1210導入をきっかけに自宅通信回線をIPoE化したりLANケーブルを自作したりしておりますが、今日はIPoE化によりL2TP/IPSecが利用できなくなったのでOpenVPNサーバーの構築手順を改めて確認しておきたいと思います。構築...

sandambara.com

2020.09.26

OpenVPNサーバーを構築する　その２

前回に続きOpenVPNのセットアップを行います。ファイアウォールのインストールと設定未導入の場合、ufwをインストールします。sudo apt install ufwインストールが終わったら「全ての通信を拒否する」→「通す通信を登録する」...

sandambara.com

2020.09.29

OpenVPNサーバーを構築する　その３

今日はクライアントの設定を行います！クライアント用秘密鍵を作るでは、早速参りましょう。sandambara@srv001:~$ cd easy-rsa/easyrsa3sandambara@srv001:~/easy-rsa/easyrsa...

sandambara.com

2020.10.05

なお、以前ご紹介したとおりLAN側の構成はこんな感じです。

フレッツ光＋IPoE化でハマった記録

先日自宅用に購入したRTX1210、早速活躍しております。何年も前に仕事でRTX1200を少し触っていたのですが、GUIの充実度や操作レスポンスなど、随分進化したんだなあ・・・と感動してしまいました。我が家のネット環境はフレッツ光隼＋OCN...

sandambara.com

2020.09.18

IPoEでVPN構築（またはポート開放）が難しい理由

PPPoEではルーターに割り当てられたWAN側IPv4アドレスだけで通信先を特定することが可能でした。しかし、IPoEは複数のユーザーで1つのIPv4アドレスを共有するため、IPアドレスだけで通信先を特定することができません（IPv4アドレスの枯渇問題を思えばこの仕組みは合理的ではあります）。

IPアドレスを共有するということはポートも共有することになるため、自由にポートを開放することができなくなってしまったのでした。

ではどうする？使えるポートもあります

しかし、一切ダメかというとそうではありません（注：DS-Liteは不可です）。利用できるポートはRTX1210で調べることができます。「管理」→「保守」→「コマンドの実行」で下記コマンドを入力します。

show nat descriptor address

「実行」をクリックすると結果が表示されます。

# show nat descriptor address
NAT/IPマスカレード 動作タイプ : 2
参照NATディスクリプタ : 20000, 適用インタフェース : TUNNEL[1](1)
Masqueradeテーブル
    外側アドレス: map-e/aaa.bbb.ccc.ddd
    ポート範囲: ここに利用できるポートが列挙されます
　　　　　　　　例）10000-12000, 13500-14000

ここの「外側アドレス」が現在WAN側に割り当てられているIPv4アドレスで、その下「ポート範囲」が利用できるポートです。つまり、この例ではポート 10000は開放可能ということになりますので、OpenVPNのプロトコルにUDPを指定している場合は

• RTX1210のNAT設定で内側アドレスにOpenVPNサーバーを指定（UDP 10000）
• OpenVPNのserver.confでUDP 10000を指定
• OpenVPNのクライアント設定（.ovpn）でaaa.bbb.ccc.ddd UDP 10000を指定

こうすることでVPN構築が可能です！

フレッツ光＋IPoE化でハマった記録

先日自宅用に購入したRTX1210、早速活躍しております。何年も前に仕事でRTX1200を少し触っていたのですが、GUIの充実度や操作レスポンスなど、随分進化したんだなあ・・・と感動してしまいました。我が家のネット環境はフレッツ光隼＋OCN...

sandambara.com

2020.09.18

いきさつ

この記事はIPoE化の設定で苦労したという内容ですが、実はかなり話を端折っています。元々我が家が利用しているプロバイダはOCNの法人契約なのですが、IPoE化にあたり疑問点を営業担当さんに相談したところ「一度お試しで個人契約を使ってみたらいかがですか？フレッツは標準で2セッション張れますから。」と勧められたときの記録なのでした。

いざ契約・開通日到来

個人契約で一通りIPoEを試し終え、疑問も解消されていよいよ法人契約となりました。法人・個人と言っても契約者が文字通り法人か個人かくらいの差しか無く、法人だから特別な設定が必要とかそういったことはありません。

ユーザー側で行う設定自体は同じですが、OCNの場合法人契約回線の収容設計は個人契約回線の2倍（ワイドプランでは６倍）になっており、ビジネス向けに強化された仕様となっています。

満を持して迎えた開通日。個人契約設定時の手順を思い出し、ルーターの設定を書き換えたのですが繋がりません。

はじめは「開通日だけどまだプロバイダの工事が終わっていないのかな？」と呑気に構えていました（⇒プロバイダの工事は開通の数日前に完了します）。しかし、待てど暮らせど繋がらず、これはいよいよ・・・ということでOCNのサポートへコンタクトしました。

何も解決しなかった

いつもなかなか繋がらない電話もスムーズにつながり、状況を話し終えたところで得た回答は次のようなものでした。

• 自営ルーター（HGWやプロバイダのレンタル品ではないもの）なので疎通確認できない
• 問題無く利用可能な状態になっている
• ルーターの設定については答えられない

文字通り時間の無駄でした。特に自営ルーター利用者には塩対応。

あと、営業担当者がついている場合はそちらへ問い合わせるよう誘導されるのですが、普通営業さんは非技術者ですから細かい話になるとお手上げです。

ヤマハに泣きついた

前回お世話になったヤマハルーターお客様ご相談センターへ電話しました。あらゆる可能性を視野に入れ大変丁寧に対応頂き、共通の認識として「ルーターの設定は限りなくシロ」という結論に至ったのでした。この電話では解決しなかったけれど、とても心強かったです。

再度OCNのサポートへ連絡

電話に出たのは先ほどとは違うオペレーターさんでしたが「本日午前中にもお電話頂きましたね？」と先制ジャブ。なかなかです。ここでルーターのメーカーに問い合わせるよう言われたので確認したが問題は無かったことを伝え、再度状況確認を依頼するも返ってきたのは先ほどと同じ回答・・・

締めのセリフは「営業担当者へ」です。うがーっ。

改めて状況を整理してみる

コーヒーを飲みながら状況を俯瞰してみました。

• 先月は個人契約でIPoE接続できていた
• 先月末日付で個人契約は解約した（開通日は翌月中旬）
• 同じように設定しても繋がらない

解せないのは「同じように設定しても繋がらない」でした。IPoEの場合PPPoEと異なりコンフィグにユーザー名とパスワードを入れる必要が無いので、繋がったときのコンフィグを流し込めば繋がるはずなのです。しかし、2度初期化→コンフィグ流用するも繋がらず・・・

ん？認証？？

ユーザー名とパスワードが要らない理由

PPPoEではユーザー名とパスワードの組み合わせでその通信が正当な利用者によるものかどうかを判断しているのですが、IPoEは回線（フレッツ）に対して認証を行います。

この「回線に対する認証」はプロバイダ契約時に提出するフレッツ契約のCAF番号とアクセスキーで行うため、実際にユーザーが通信するときは既に認証されている状態になっているのです。蛇足ですが回線とプロバイダ契約の紐づけは排他的で、一回線につき2つ以上IPoE契約を持てないのはこのためです。

「個人契約は間違いなく解約したけれど、なんらかの理由で旧契約が回線を握ったままになっているのでは？」と考え営業さんに連絡。直ぐにOCNへ確認してくれることになりました。

プロバイダ解約＝回線がフリーではない

予想通りその後しばらくして「解約済み契約に回線が紐づいたままになっており、原因はほぼこれでしょう」と連絡が入り、至急対応で翌日には紐付けが正常化⇒めでたく正常に通信できるようになったのでした。良かったぁ！

通常だと回線がフリーになるにはもう少し日数がかかるとのこと（なんともおかしな話です）。営業さんもこの可能性には気付かなかったようで平謝りでした。

開通日を含め丸2日弱繋がらなかった訳ですが、こんなこともあろうかとPPPoEの解約日を遅らせておいて本当に助かりました。私としては結果オーライだったので営業さんに対しては何も思いませんが

• 旧契約に紐づけられたままの回線に対し正常に新規契約処理ができてしまうOCNのシステム
• 相手を変え3度確認し3度とも回線・契約に問題は無いと言い切ったOCNのシステム
• サポートも含めて営業担当者に丸投げ対応なOCNのシステム

これらには一言なにがしか申し上げたいところであります。特に1つ目、排他的にしか扱えないものを排他的に扱えていないように見えるんですよね。異常終了させないといけない処理を正常終了させてしまっている感が否めないです。いかんでしょ、それ。特に今回はOCN→OCNの切り替えだったので「他の契約が回線握ってますよ～」とお知らせするのがシステムのあるべき姿なのではと思います。知らんけど。

結論

• プロバイダ契約移行時、旧契約がIPoEの場合は旧契約先にさっさと回線を手放すよう言っておきましょう

我が家のネット環境はフレッツ光隼＋OCNの組み合わせです。一時期耐えられないほど速度低下が酷く、晴れてIPoEがサービスインしたあとも新規ユーザーやコラボ組にだけ開放され既存ユーザーは最後までほったらかし・・・という冷遇に耐え続け、先日ようやく回線がIPoEに切り替わりました！

現在の構成略図とRTXの設定方法

ということで、現在の構成はこんな感じです。

ひかり電話があるためHGWが残っており、IPoEのセッションはRTX1210発となります。

RTXの設定は本当に簡単でGUIの「かんたん設定」→「プロバイダー接続」→「新規」と辿り、ウィザードに表示される選択肢から適切なものを選んでいくだけです。IPoEはPPPoEと異なり利用する回線に対して認証を行うので、ユーザー名やパスワードを入れる必要もありません。

OCNの場合はバーチャルコネクトという方式でIPv4 over IPv6を利用できるのですが、それもこのウィザードでバーチャルコネクトを選択するだけでOKです。業務用機の設定だからと気負う必要も無く、むしろ市販の家庭用ルーターよりも簡単なくらいでした。

ハマりポイントその１

しかし、ここがハマりポイントの一つ目で、私の環境にはひかり電話があるためウィザードでひかり電話を利用するよう設定しました。ところが、ひかり電話を利用するのに必要な機能はHGW側が実権を握っているため、RTXのウィザードでは「ひかり電話を利用しない」として設定するのが正解だったのです。IPoE接続ではひかり電話の利用状況によって割り当てられるIPv6アドレスの体系が異なるため、ここの設定を誤ると待てど暮らせどつながらず・・・ということになるようです。

ハマりポイントその２

無事セッションが張れたのにインターネットが使えない・・・と思ったら、HGWの配下にルーターを設置した場合、DNSサーバーの情報を取得できないことがあるようです。ということで、下記コマンドをRTXに入力しました。

dns server 2001:4860:4860::8888

なんとなく見覚えがおありな方もおられるかと思いますが、これはGoogleのパブリックDNSです（IPv4のときは8.8.8.8）。本来はOCNのDNSを入れるのが良いのかもしれませんが、今はこのまま使っています。

以上2点を修正することでIPoE＋IPv4 over IPv6で無事インターネットを堪能できるようになりました！

ハマりポイントその３

ネットもつながりめでたしめでたし！と思っていたのですが、後になって気づきました。「HGWにログインできない・・・」

RTXがあればネット環境について困る要素は無いのですが、ひかり電話のことを忘れていました。LANからHGWにアクセスできないとスマホ内線を利用できないのです。

このHGWのLAN1の部分です。ここが192.168.0.1などになっているとRTXとはセグメントが異なるので行き来出来ません。HGWにPCを直結して192.168.1.0/24のIPアドレスを割り当てる？いや、それ以前にRTXのLAN2はIPoEのtunnelになっている・・・そもそもLAN2にIPアドレスが無い・・・私の知識では完全にお手上げです。ということで、ハマりポイントその1-2と一緒に「ヤマハルーターお客様ご相談センター」へ問い合わせてみました。

ご担当者さま

その節はお世話になりました。とても親切に分かりやすく対応して下さり感激しました。本当に有難うございました！

まずRTXのLAN2にHGWと同じセグメントのIPアドレスを割り当てます。

ip lan2 address 192.168.0.254/24

次にIPアドレスをHGWのセグメントに合わせたPCとHGWを直結し、HGWにログインしましょう。

ログイン出来たらRTXのLAN1宛の経路情報を登録してあげます。

「宛先IPアドレス/マスク長」にRTXのLAN1のネットワークアドレスを入力し、ゲートウェイにRTXのLAN2に割り当てたIPアドレスを指定したら「設定」をクリックして元の画面に戻り、「有効/無効」の箇所にチェックを付け「設定」をクリックします。

【おぼえがき】

もしHGWのIPアドレスとRTXのLAN1が同じセグメントになっている場合はいずれかのセグメントの変更が必要です。環境に応じて変えやすい方を変えれば良いと思います。

これでRTXのLAN1からHGWにアクセスできるようになりました！

知識なさ過ぎで色々大変でしたが、サポートの方の絶大なご支援あって終わってみれば楽しかったです。何事も経験ですね。

RTX1210 特長

ヤマハのRTX1210のページです。中小規模拠点向けVPNルーター。従来モデル「RTX1200」の機能を継承し、Web GUIを刷新。LANマップ、ダッシュボード等ネットワークの「見える化」を強化。

network.yamaha.com

RTX1200は昔少しだけ触っていたのですが、記憶は完璧にフラッシュされています（きっぱり）。届くのは数日後なので今から勉強開始です！

OpenVPNのよいところ

OpenVPNの場合は自宅LAN内に1台PC・サーバーが必要になりますが（安価に済ませるならラズパイでも可能ですし、予算を気にしなければAWSなどクラウド上に仮想サーバーをたててもOKです）、メーカー・企業が提供するVPNサービスと異なり外部の中継サーバーを必要としません。昨今「VPNサービスを利用し情報漏洩が生じて本末転倒」というニュースもありますが、OpenVPNの場合自宅のサーバーを経由するだけですので「接続先のサーバーが本当に安全なのか信用できない」という悩みは無用です。

OpenVPNのつらいところ

これは前回の記事にもあたりますが、全てにおいて完全に自己責任であることです。自宅のゲートウェイへ外部に対する穴を開けることになりますので、適切な設定を行うことが必要なのは勿論のこと、定期的にログのチェックなども実施した方が良いでしょう。

VPN接続・切断の通知をLINEで受け取る

以上を踏まえ「最低限VPNのセッションが張られた、落ちたくらいは知りたい」と思い色々調べてみました。主に参考にさせて頂いたサイトはこちらです。有益な情報を公開頂き有難うございます！

RaspberryPi VPNのログ監視：VPN接続毎にLINEへ通知して不審なアクセスを検知する

OpenVPN の接続・切断時に Slack に通知する

前者はLINEを使った手法ですが、利用されているのがSoftEther VPNであり、ローカルでの挙動がOpenVPNとは少し異なりました。後者はOpenVPNを利用されていますが、通知先はLINEではなくSlackです。

両者の情報を組み合わせれば上手くいくかも・・・ということで挑戦してみました。全体的な流れはこんな感じです。

VPN接続・切断⇒IFTTTへパラメータを送信⇒IFTTTと連携したLINEが通知を送信

IFTTTに登録

LINEへ通知を飛ばすために「IFTTT（イフト）」というサービスを利用します。恥ずかしながら私はこのIFTTTを知らなくて、今回初めて使ってその便利さに感激しました。「if this then that」を略してIFTTT、読んだ通り「もし〇〇なら☆☆を実行する」という仕組みを提供するものです。アカウントを持っていない方はまずこちらで登録を済ませましょう。

IFTTT - Automate business & home

Get started with IFTTT, the easiest way to automate your favorite apps and devices for free. Make your home more relaxin...

ifttt.com

アカウントを作成したら先ほどのリンク先を参考にIFTTT側の作業を進めましょう。キャプチャを豊富に使いながら大変丁寧に解説されていますので（私も見習わなくては・・・）、特に迷うことは無いと思います。

シェル作成

まずは必要なシェルの置き場を作成しましょう。

sudo mkdir /usr/local/vpn

ここに３つのシェル（LINE.sh、connect.sh、disconnect.sh）を作成します。

connect.sh

#! /bin/bash
sh /usr/local/vpn/LINE.sh connect:$common_name $untrusted_ip $ifconfig_pool_remote_ip

disconnect.sh

#! /bin/bash
sh /usr/local/vpn/LINE.sh disconnect:$common_name $untrusted_ip $ifconfig_pool_remote_ip

LINE.sh

#!/bin/sh
URL="https://maker.ifttt.com/trigger"
EVENTNAME="IFTTTで設定したEventName"
YOUR_KEY="WebhooksのAPIキー（https://maker.ifttt.com/use/***この部分***）"

WEBHOOKSURL="${URL}/${EVENTNAME}/with/key/${YOUR_KEY}"

curl -X POST -H "Content-Type: application/json" -d \
     '{"value1":"'$1'","value2":"'$2'","value3":"'$3'"}' \
         ${WEBHOOKSURL}

echo
exit 0

LINE.shはこちらのサイトのコードをそのまま利用させて頂きました。

それでは、シェルを書き終えたら実行権限を付与しましょう。

sudo chmod +x /usr/local/vpn/*

こんな風になっていればOKです！

sandambara@sandambara:~$ ls -l /usr/local/vpn
合計 12
-rwxr-xr-x 1 root root 340  8月 22 16:24 LINE.sh
-rwxr-xr-x 1 root root  99  8月 22 13:18 connect.sh
-rwxr-xr-x 1 root root 102  8月 22 13:19 disconnect.sh

IFTTT・LINE連携テスト

先ほど作成したLINE.shはconnect.sh、disconnect.shから呼び出して利用しますが、単体でも実行できます。動作テストしてみましょう。

sudo sh /usr/local/vpn/LINE.sh hoge fuga piyo

このように表示されたらシェルの内容はOKです。

sandambara@sandambara:~$ sudo sh /usr/local/vpn/LINE.sh hoge fuga piyo
Congratulations! You've fired the vpn_notification event

無事LINEの通知を受信できたでしょうか？？

server.confに加筆する

VPN接続・切断をどうやって検知するかですが、これは先ほどご紹介した２つ目のリンク先にもあるように、OpenVPNのコンフィグで制御が可能でマニュアルにも記載があります。

Just a moment...

community.openvpn.net

早速コンフィグを編集します。

sudo nano /etc/openvpn/server.conf

コンフィグに下記３行を加筆します。

script-security 2
client-connect /usr/local/vpn/connect.sh
client-disconnect /usr/local/vpn/disconnect.sh

script-security 2はシェル実行を可能にするための設定で、VPN接続・切断時にそれぞれclient-connect、client-disconnectに続くシェルが実行される仕組みになっています。ですのでcronを使ったりディレクトリ監視する必要はありません。

sudo systemctl restart openvpn@server

ここでVPN接続・切断を行いLINEの通知を受け取れれば成功です。ちなみにこれらのシェルを実行できないとき（パスを誤って記述したときなど）は通知が来ないだけではなくOpenVPN自体がコケてしまいますので注意しましょう。

これで「自分がVPNを利用していないのに通知がきた」などというシチュエーションにいち早く気付くことができるようになりました（想像しただけでゾッとしますね/笑）。LINEの通知は他にも色々使い道があると思うので、皆さんも是非挑戦してみてください。

パフォーマンス・トラブルの原因

VPNが繋がっているのに通信に問題がある場合、ネットワーク設定の「MTU」という値を調整することで改善できることがあります。

MTU(Maximum Transmission Unit)とは

データ転送時の最大データサイズのことで（厳密には細かく定義があります）、通常は最大値である1500Bytesが規定値になっている場合が多いです。Windows環境の方はVPN接続した状態でコマンドプロンプトを管理者として実行し、下記コマンドを入力してみてください。

netsh interface ipv4 show interface

この場合最上段（id=54）がVPN接続時の設定で、WindowsではVPNのMTUは1500-100の1400となります。これが1400では大きすぎる場合があり、この時にパフォーマンスの悪化や通信途絶が生じるのです。

MTU値を変えてみる

NTT西日本のサイトではこのように案内があります。

「フレッツ光」を利用する際、「MRU/MTU（最大転送単位）」はいくつに設定すべきですか。 | よくあるご質問｜フレッツ光公式｜NTT西日本

「フレッツ光」をご利用の際は、「MRU/MTU（最大転送単位）」を1,454バイト以下に設定してください。1,455バイト以上に設定した場合、速度が低下したりインターネットが正常に利用できなくなった

qa.flets-w.com

1454Bytes以下で良いのであればWindowsが設定する1400でも良いように思うのですが、実際にはここの調整が必要になります。では、いくつに設定すれば良いか調べてみましょう。VPN接続したままpingを送信します。

ping -f -l 1400 -n 1 LAN内のデバイスどれかのIPアドレス

この例の「1400」を少しずつ下げていき、pingの応答が「パケット数: 送信 = 1、受信 = 0、損失 = 1 (100% の損失)」から「パケット数: 送信 = 1、受信 = 1、損失 = 0 (0% の損失)」に変わる値を見つけます。仮にそれが1000だったとしたら下記コマンドを実行します。

netsh interface ipv4 set interface 54 mtu=1000

interfaceに続く54という値は先ほどnetsh interface ipv4 show interfaceで確認したVPNインターフェースが割り当たっているid、mtu=の右辺にpingで確認した値を入力します。

この状態で様子を見て頂ければと思います。無いと思いますが、万一状況が悪化した場合は先ほどのコマンドでmtu=1400とすると元に戻せますので気軽にお試しください。