VPN をオンにしたとき、クラウドファイアウォールが見るアドレス

VPN に接続する前は動き、接続後は失敗するデータベースは、認証情報の問題であることはほとんどありません。クラウドファイアウォールは送信元アドレスを照合し、フルトンネルはその照合対象を置き換えます。ノート PC が送っていると思うアドレスとサーバーが受け取るアドレスの差がバグの全体であり、しかも一手で測れます。

送信元アドレスは何になるか

フルトンネルでは、すべてのパケットが VPN ゲートウェイを通って出るため、サーバーは自宅回線ではなくゲートウェイの出口アドレスを見ます。途中にフォワードプロキシがあれば、届くのはそのアドレスです。どちらも正規の送信元であり、元のルールにあるアドレスはどちらでもありません。

Azure SQL のサーバーレベルとデータベースレベルのファイアウォール規則は、論理サーバーに届くクライアントアドレスを照合しますが、フルトンネル後はそれが出口アドレスです。単一アドレスを許可する AWS セキュリティグループも同じように振る舞います。パケットは認証の前に破棄されるため、返ってくるエラーは権限の問題ではなくネットワーク障害のように見えます。だからこそ人がパスワードの再設定を始めるのです。

許可リストはどこで決まるか

失敗している経路に一致するルールを読み、作った覚えのあるルールを読まないでください。その適用範囲、ポート、プロトコル、そして何らかの ID チェックより前に評価されるかどうかを確認します。

次に、どの層がその判断を正当に持つかを決めます。アドレスのルールはトラフィックがどこから来るかに答えます。プライベートエンドポイントは、サービスがプライベート経路で到達できるかどうかに答えます。分割トンネルの例外は、どの宛先がトンネルを迂回するかに答えます。これらは交換できず、トンネルが変わるとそれぞれ違う形で失敗します。

三つの修理、三つの層

以下のどの選択肢も別の理由で流れを直し、間違ったものを選ぶと次のゲートウェイ変更までしか動かない接続になります。

出口アドレスを追加するのは、新しいゲートウェイや別のリージョンが黙って無効にするため、最小の変更であり、最も脆い方法です。アドレスはトンネル定義の隣に記録し、両者が一緒に動くようにします。一時的な広い範囲は診断であって修理ではなく、置いたままにすることが内部サービスを露出させる道です。

管理されたプラットフォームがトンネルに参加できない理由

Heroku、AppHarbor、CloudBees のようなアプリケーションプラットフォームは、tun や tap デバイスがなく、それを作る権限もない環境でコードを実行します。受信のモデルは HTTP であり、任意の待ち受けソケットではありません。VPN バイナリを同梱するビルドパックでも、インターフェースを置く場所がありません。実用的なのは、データベースが許可できる固定の出口アドレス、プラットフォームが提供するプライベート接続製品、HTTPS で到達する DMZ 内のプロキシです。

そのプロキシは独自の認証と記録を持つアクセス経路です。プラットフォームを VPN のメンバーにするわけではなく、そう説明すると誰も監査できないルールが生まれます。

失敗したクライアントから検証する

再接続してクライアントの正確な経路を繰り返します。サービスが記録する送信元アドレス、クライアントがデータベース名に対して選ぶルート、実際のクエリの結果をこの順で確認します。ゲートウェイからのテストはゲートウェイが動くことを示すだけで、それは疑われたことがありません。接続が認証されるようになってもクエリが失敗するなら、残る問題はデータベースの権限です。

トンネルが変わったら必ずこのルールを見直してください。ゲートウェイの交換や新しい出口範囲は、アプリケーション設定を一切変えずに経路を壊します。