5
6

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

自宅VPNに接続するときにハマった話

Last updated at Posted at 2019-09-16

概要

趣味開発中にサーバ環境が必要になり、友人宅から自分のLAN環境にVPN接続して、Raspberrypiをサーバとして使えばいいのでは、という話になった。
が、その過程で友人宅からVPN接続する際に色々とハマってしまったので、何が起こったのか、また、原因は何だったのか、などについて書き留めておく。

環境

登場人物 使用PC
T(筆者) Linux(Ubuntu18.04)
Y Mac
K Mac

K宅とT宅の接続は以下の通り。

ネットワーク構成.png

なにがおこったのか

TがVPN接続に成功するが、KとYはVPN接続に失敗する

Tが自身のPCから自宅にVPN接続ができるか確認。VPN接続確認後、T宅ルータのIPアドレスを直打ちして接続を確認。同様の方法でKやYもVPN接続できることを確認するため、方法(アクセス先、ユーザ名、パスワード)を伝える。
KとYが同様の方法でVPN接続を試行したが、接続が確立されない。アクセス先、パスワードの確認などをするも、間違っていないようである。Tが接続済みのVPN経由にてルータの設定を確認するも、特に問題はない。何度か再接続を試みるも、やはり失敗する。
T成功.png

Tが接続していない状態で、実績があったPCでも接続できない

TのPCが接続していることが問題、と考え、TがVPN接続を解除。その後、YとKがノートPCからVPN接続を試みるも失敗する。K宅のデスクトップPCは、別件にて、T宅宛のVPN接続の実績があったので、TがVPN接続を解除している状態で、過去に接続できた環境を用いてデスクトップPCでVPN接続を試行するが、接続が確立されない。
DeskNG.gif

テザリングをしてもうまく行くT、うまく行かないKとY

Tが自身のスマホ(LTE接続)でテザリングをして、自身のPCの接続を試みる。結果、うまくVPN接続できることを確認。また、スマホ自体をVPN接続した場合、LTE接続ではうまく行くが、K宅のWiFi経由だと接続できないことも確認。なお、KとYが自身のスマホでテザリングして、同様の方法で接続を試みるも接続できない。
テザリング.gif

突如接続できるようになるYと接続できなくなったT、依然接続できないK

後述の調査をしつつ、色々と試行錯誤をしている中で、突如としてYのPCがT宅VPNに接続できるようになった。
確認のため、TとKがVPN接続を施行するも、今度はTがVPN接続できなくなっていることが判明。なお、依然としてKは接続できていない。
Y成功.gif

調査したこと

ルータの設定確認

TがVPN経由で自宅ルータの設定を確認。特に問題はなかった。
(TのVPNには以前に別件で複数クライアントの接続経験があったので、問題はないだろうとは思っていた)

ログの調査

Kが接続時のログを確認した結果、VPN接続する際のコネクションを確立する際のネゴシエーションがうまく動作していない、という結論に至る。どうやら、PPTP接続する際に送信したリクエストに対してレスポンスが帰ってきていない模様。

TとYが同時にVPN接続できることを確認

YがVPN接続できるようになった後、YがVPN接続を確立している間にTが自身のテザリング経由で接続できることを確認。どうやら、複数クライアントの接続は問題なくできるようだ。
複数接続.gif

接続ができなかった際のログをもとにPPTPの仕様等を調査

接続できなかった際のログに出てくるマジックナンバー等を理解するために、PPTPの仕様を調査。
セッションを確立要求に対するレスポンスが返ってきていない、以上の情報を取得することはできなかった。

何が起こっていたのか

VPNサーバの気持ちになった時に思いつく

TがVPNサーバ(T宅ルータ)の気持ちになって考えてみる。しばらく考えると、ふと1つの可能性に気がつく。
それは、
新規のVPN接続リクエストに対するレスポンスが、すでにセッションを確立している別PC宛に送信されているのではないか
ということである。
一行はこの仮設を検証してみることに。

仮説検証による原因の特定

KのPCからVPN要求を送りつつ、VPN接続をすることができたYのPCにてtcpdumpを実行。受信パケットのキャプチャすると、Tの予想が正しいことを確認できた。
つまり、
同一IPアドレスかつ、同一ポート番号宛にパケットが飛んできたので、ルータは既にセッションを確立しているPC宛にレスポンスを返していた
ということである。

YのPCからVPN接続を試行したときのログ(成功時の要約)

PPTP接続確立メッセージ
T宅ルータ<-->PC間でのメッセージやりとり
PPTPのポートマッピングメッセージ
IPアドレス/DNS等の割り振り

KのPCからVPN接続を試行したときにのログ(失敗時の要約)

PPTP接続確立メッセージ
PC->ルータ宛メッセージ送信(複数回)
PPTP Config-Requestのタイムアウト
PPTP接続終了

YのPCでパケットをキャプチャしたときのログ(要約)

既存のVPN接続に対するメッセージ
既存のVPN接続とは異なるセッションIDからのConf-Request(複数回)

つまり、TがVPN接続済の状況で、Yが新規VPN接続をした場合の動作は以下のようになっていたのである。
届かない.gif

ルータ再起動による確認

上記内容が正しければ、IPアドレスが変われば接続できるようになるはずである。そこで、K宅PCのルータを再起動して、グローバルIPアドレスを強制的に切り替えることに。すると、今まで接続できていなかったKが接続できるようになり、TとYが接続できなくなった。この段階で上記結論が間違っていないと判断。

なぜ突然Yが接続できるようになったのか

おそらくですが、
TのPCから一定時間応答がなくなったため、VPN側のキャッシュがクリアされたのではないか
と推測しています。

なぜYとKはテザリング経由でPPTP接続できなかったのか

複数クライアントが同一のIPアドレスを用いなければ良いので、テザリング経由であればYとKは接続できるはずである。(現にTは接続できている)不思議に思いググってみると、キャリア(Y:au,K:docomo)ではPPTP接続をサポートしていない、ということが判明。Tはいわゆる格安SIM(iij)だったので接続できていた。という結論になった。
※ ここはあまり詳しく調査していないので間違っているかもしれません

参考1
参考2

さいごに

  • ネットワークって難しい
  • tcpdumpはネ申
5
6
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
5
6

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?