VPNサーバーとクライアントを兼ねるpfSense：二つの道、一台のルーター

一台の機器が同時に二つの向きを向ける：移動中のユーザーは内側へ接続し、同じ筐体は出口プロバイダーへ外側に接続して、選択したトラフィックを別のネットワークから出します。両方のサービスを有効にするのは数分ですが、共存させるには設計が要り、二つ目の役割が一つ目が依存するルーティングテーブルを書き換えるからです。三つの条件がこの構成の成否を決めます、すなわち、内向きのサービスが自分の戻り経路を保てるか、外向きのトンネルが相手に届くか、転送したいトラフィックが出口に選ばれるかです。一つを誤ると、両方とも接続済みと報告しながら、その間を何も有用なものが通らないトンネルが二本できます。以下の確認は、障害が通常現れる順に各条件を確かめます。

設定に触れる前に二つの役割を名づける

各インスタンスについて、遠隔の相手、認証の材料、配布するアドレスプール、その背後のネットワークという四つの事実を書き留めます。二つのインスタンスは機器上の別個のオブジェクトであり、メモでも別に保つべきです。後に起きる紛らわしい症状のほとんどは両者の値が混ざることから来るもので、二つのインスタンスが一組のメモを共有するのが、誤ったプールが誤った欄に入る道です。

内向きのサービスには、外向きトンネルのアドレスとも、機器がルーティングするどのプライベートネットワークとも重ならないトンネルネットワークが必要です。重複は両方の役割で同時に症状を出す唯一の誤りで、紙の上で捕まえるほうがはるかに安く済みます。どちらのサービスを設定する前にも、両方のプールとルーティングされる各プライベートネットワークを一か所で比べてください。

ハードウェアの共有は資格情報の共有を意味せず、リモートアクセスプールのクライアント証明書は出口プロバイダーに対して使えてはなりません。材料を分けることは、失効を全艦隊の出来事ではなくローカルの判断に変えます。

サーバーの応答をWAN経路に保つ

機器自身が生成する応答は、不注意なデフォルトルートの最初の犠牲です。移動中のユーザーのカプセル化パケットが届くと、応答はローカル発のトラフィックであり、そのユーザーが入ってきたインターフェースから出なければなりません。外向きクライアントがそれを捕まえるデフォルトルートを入れていると、応答は誤ったトンネルに入り、サービスは健全に見えたままセッションが止まります。

判断は外向きクライアントがどのトラフィックを捕まえてよいかという話なので、これを決める単一のチェックボックスはありません。ルートを一切引かずに選んだものだけを向けるか、ルートを引いて機器自身のサービスを動かし続ける例外を足すかです。選択をインスタンスのそばに書いてください、さもないと次の人がもう一方を前提にします。

netstat -rn | head -20
pfctl -sr | grep -i vpn
ifconfig | grep -A3 ovpn

ルーティングテーブルは、何かを設定した順ではなく最長一致で読んでください。問いは、出口の相手のアドレスにどの項目が勝つか、内向きサービスの応答にどの項目が勝つかであり、この二つの答えは異なりえます。

出口トンネルに自分の端点を食べさせない

外向きクライアントは、そもそもトンネルを張るために相手の公開アドレスへ届く必要があります。そのアドレス自体がトンネルにルーティングされていると、クライアントは自分の尾を追い、トランスポートは決して上がらないか、上がってからルートが入る瞬間に落ちます。ログはルーティング障害ではなく認証タイムアウトのように見えるので、ルートを先に確認する価値があります。

項目が起動時には正しく、少し後には誤りうるので、資格情報の前にルートを確認し、トンネルが上がった後にもう一度確認してください。相手のアドレスは通常のWAN経路を指すべきで、トンネルデバイスを決して指してはいけません。トランスポートが安定したら、関心は転送トラフィックに移り、それが次の判断です。

netstat -rn | grep -F '198.51.100.10'
traceroute -n 198.51.100.10

どのユーザーに出口を与えるかを選ぶ

送信元ポリシーはトラフィックが機器に入る入口に属するので、リモートアクセスプール、またはその中のより狭い識別子を選びます。出口に決して送ってはならないプライベートな宛先と管理の例外を保ち、それらの規則を広い規則より前に置きます。次に出口の経路には独自の変換か、ルーティングによる戻り経路の仕組みが要り、多くの設計ではプールを覆う出口インターフェース上の外向きNATを意味します。変換は出口を選ばず、すでに出たものを書き換えるだけなので、無関係なWAN上のNAT規則は選択を何も変えません。

許すプロバイダーと許さないプロバイダーがあるので、遠端がこの設計からの転送トラフィックを許すか確認してください。違いは、接続はするが何も運ばないトンネルとして現れ、ローカルの障害と読み違えやすいものです。三つの流れを別々に試してください、独立に失敗し、三つ中二つでは半分しかできていない設計です。

openvpn --config user07.ovpn
curl -sS https://ifconfig.me
curl --interface 10.10.10.1 -sS https://intranet.corp.example/health

最初のコマンドは移動中のユーザーの外側の接続で、クライアントが初期化手順の完了を報告すれば機能しています。二番目はその接続済みノートPCから実行し、あなたのWANアドレスではなく出口プロバイダーのアドレスを報告すべきです。三番目は機器上でプールのアドレスに束縛して実行し、遠隔ユーザーを一切関与させずに転送トラフィックの送信元ポリシーを試します。代わりにWANから応答するなら、ポリシーが一致しておらず、NATの編集では選択の問題は直りません。

出口が失敗したときに何が起きるかを決める

障害時の挙動を起きる前に書き留めます、つまり、外向きトンネルが落ちたとき、ユーザーは通常のWANへ戻るのか、出口が戻るまで遮断されるのかということです。どちらの答えも擁護でき、機器が代わりに選ぶことはありません。削除されたルートや死んだゲートウェイを指すポリシーは、自動的に完全遮断の結果を生みません。遮断したいなら、ポリシーがそれを明示し、出口を取り去って試すべきで、頭の中で考えるべきではありません。戻したいなら、それをユーザーに周知してください、黙って通常の経路を取るトラフィックこそ、誰かが対象だと思っていたトラフィックです。

クライアントインスタンスを無効にし、接続中のユーザーがまだ何に届くかを見て、それから再び起動します。期限切れになる要求があなたの求めた完全遮断の結果で、WANアドレスで応答する要求が文書化していない戻りです。IPv6とDNSについても確認を繰り返してください、IPv4向けに書かれたポリシーはAAAAトラフィックについて何も言わず、どちらのトンネルが押し込んだリゾルバーも問い合わせが実際に出る場所から応答するからです。

pfSsh.php playback svc stop openvpn client 2
curl --max-time 6 -sS https://ifconfig.me
pfSsh.php playback svc start openvpn client 2

NetgateのルーテッドOpenVPNのレシピ は、送信元ポリシー、インターフェース割り当て、外向き変換がどう噛み合うかを示し、サイト間という範囲が丸ごと写すべきでない部分です。それが教えてくれないのは、上の三つの条件のうち、あなた自身の設計がすでにどれを壊しているかです。