StrongSwan が Mac から到達できない DNS アドレスを配布する

誰かが MacBook を開くまではすべてうまくいきます。トンネルは確立し、内部ホストはアドレスで応答しますが、名前解決が死にます。iPhone でも同じプロファイルが同じように振る舞う一方、Windows と Linux のクライアントは問題ありません。たいてい犯人は配布される DNS 属性です。サーバーが自分の公開インターフェースアドレスを配り、Apple の IKEv2 クライアントはトンネル経由でそこへクエリを送りません。リゾルバーをプール内に移せば、クライアントに触れずに症状は消えます。

症状は配布されたアドレスを指している

一部のプラットフォームだけが失敗する場合、トンネルと資格情報はほぼ確実に正常です。それらは共通だからです。違いは、各クライアントが受け取った構成ペイロードをどう適用するか、内部 DNS サーバーを含めて異なります。アドレスを受け入れてもクエリをトンネルの外へ回すクライアントは、見えるのに使えないリゾルバーを抱えることになります。

公開アドレスが通常の選択肢なのは、管理者がすでに知っている唯一のアドレスだからです。また、トンネル自身のプレフィックスの外にあることが保証された唯一のアドレスでもあり、まさにその性質が Apple のクライアントを壊します。

何かを変える前に値を確認してください。配布されているリゾルバーがサーバーの WAN アドレスなら、問題の形は見つかったので残りの推測は省けます。プールのプレフィックスとも比較してください。プール内だがリース範囲外のアドレスが、修正後の姿そのものだからです。設定をにらむ二分は、クライアントで丸一日パケットを捕るより価値があります。

リース範囲からリゾルバーを切り出す

リゾルバーがプール自身のサブネットの一員になるようにアドレス計画を立て、そのアドレスを予約してどのクライアントにもリースされないようにします。この例ではプールは 10.180.7.0/24、サーバーは 10.180.7.1 を保持し、リースは 10.180.7.2 から始まります。

rightsourceip=10.180.7.2/24
rightdns=10.180.7.1

プールのプレフィックスとリゾルバーが同じサブネットを共有するので、すでにトンネルトラフィックを運ぶルートがクエリも運びます。この一点が修正をクライアント間で持ち運べるものにします。swanctl の構成では、同じ二つの事実が ipsec.conf の構文ではなく、プール定義と接続上の DNS 設定として現れます。

サーバーに新しい物理インターフェースは要りません。ループバックインターフェースに 10.180.7.1 を追加すれば、リゾルバーがバインドして応答できます。クライアントは既存のプールルート経由でそこへ到達するからです。アドレスをリース範囲の外に保ち、どのクライアントも誤って取らないようにします。プールを外部の DHCP や RADIUS サービスが管理している場合は、そこでもアドレスを予約してください。さもないと最初に問い合わせたクライアントが取ってしまいます。

リゾルバーをバインドし、ポート 53 を閉じる

アドレスを割り当てることと、その上で待ち受けることは別です。LAN アドレスだけで待ち受けるリゾルバーは、プールアドレス宛のクエリを拒否するか無視し、クライアントにはルーティング障害に見えるタイムアウトが現れます。

interface: 10.180.7.1
access-control: 10.180.7.0/24 allow
access-control: 0.0.0.0/0 refuse

この unbound の断片はトンネルプールからのクエリを受け入れ、それ以外はすべて拒否します。これは多くの企業リゾルバーが望む方針です。同じインスタンスが LAN クライアントにも応答する場合は、リスナーをすべての送信元に広げるのではなく、LAN プレフィックスを明示的に追加してください。

次に、ファイアウォールのルールがリゾルバー自身のアクセス制御と一致している必要があります。プールからのポート 53 を許可し、それ以外の場所では破棄しますが、まずチェーンの順序を確認してください。

iptables -A INPUT -p udp --dport 53 -s 10.180.7.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 53 -s 10.180.7.0/24 -j ACCEPT
iptables -A INPUT -p udp --dport 53 -j DROP
iptables -A INPUT -p tcp --dport 53 -j DROP

より前にある広い許可ルールがあると、最後の二行は飾りになり、リゾルバーはインターネットから到達可能なままです。意図した順序を信じるのではなく、カウンター付きの実効ルールセットを読んでください。別の方針、つまり公開アドレスを配布して任意の送信元からのクエリを許可する方法は多くのクライアントで機能しますが、リゾルバーをインターネット上に置くことになり、独自のレート制限と監視が必要です。

クライアントが実際に何を受け取ったかを確認する

まずサーバー側の見え方を確認し、次にクライアント側を確認します。両者は示唆に富む形で食い違うからです。プールの一覧はどのアドレスがリースされたかを示し、セキュリティアソシエーションの一覧は接続が期待どおりの ID で確立しているかを示します。

swanctl --list-sas
swanctl --list-pools
dig +short @10.180.7.1 intranet.plant.example

直接クエリを打つと、リゾルバーがプールアドレスで、そこへ到達できるホストから応答することが証明できます。Mac がそのサーバーを選んだことは証明できません。macOS では scutil --dns がスコープ付きサービスごとにリゾルバーを一覧し、概要パネルより情報量が多いです。Windows では Get-DnsClientServerAddress がトンネルアダプターが配布値を受け入れたかを示します。

クライアントがプールアドレスを示しているのにクエリがまだタイムアウトするなら、トンネルのルートかファイアウォールのチェーンが原因です。リゾルバーをまったく報告しないクライアントは、構成ペイロードが届いていないということなので、ネットワークではなくそのプラットフォームが配布設定をどう適用するかを見てください。他を変える前に、どちらのケースを見たのかを書き留めてください。この二つの障害はサポートチケットでは同じに見え、逆の修理に導きます。