Raspberry Pi での仕事用 VPN：まずこれらの質問を確認する

雇用主からの四つの答え――どのゲートウェイプロトコルを使うのか、どのオペレーティングシステムとアーキテクチャに対応するのか、認証をどう行うのか、公式クライアント以外が許可されるのか――が、Pi を仕事用 VPN に参加させられるかどうかを決めます。ポータルの URL と Linux という言葉では、そのどれも決まりません。何かをダウンロードする前に質問してください。答えによって、どのパッケージをインストールするか、そもそも画面なしの構成が可能かが変わるからです。

四つの答えを書き留めてください。ここから先は、それぞれが何を変えるかの話です。

ゲートウェイプロトコルがクライアントを決める

ゲートウェイは一つ以上のプロトコルを話し、クライアントは組織が実際に運用しているものを実装しなければなりません。OpenConnect は Cisco AnyConnect との互換性から始まり、今では他のいくつかの企業向けゲートウェイにも対応する独立実装です。ベンダーのブランドクライアントではなく、プロトコルの互換性はゲートウェイのあらゆる機能、ポスチャチェック、デバイスポリシーのサポートを保証するものではありません。ポータルの URL から推測するのではなく、ネットワークチームにプロトコルを確認してください。そのうえで、雇用主がこの配備でこのクライアントを認めていることを確認してください。

互換性の根拠は、雇用主の文書か、同じ機種で実施した同僚から得るものであり、リポジトリにパッケージがあるという事実ではありません。

アーキテクチャは細部ではない

Pi の OS リリースとユーザー空間のアーキテクチャ、使う予定のクライアントのバージョン、そのパッケージの入手元を記録してください。ファイル名が変わったからといって x86 のインストーラーが別のアーキテクチャに適するようになるわけではなく、x86 ビルドしか提供しないベンダークライアントは Pi ではまったく動きません。この一つの事実だけで、認証を論じる前に問題全体が片付くことがあります。フォーラムのスレッドから出所不明のバイナリをインストールするのではなく、パッケージの入手元の保守状況を確認してください。

64 ビットのカーネル上の 64 ビットのユーザー空間は単純なケースです。64 ビットのボード上の 32 ビットのユーザー空間こそ、人が間違ったパッケージを入れる場所です。dpkg --print-architecture と uname -m はどちらの半分にも一行ずつ答えてくれます。

認証がワークフローを決める

パスワード、MFA、ブラウザ経由のサインインは、それぞれ独自のワークフローを強います。ハードウェアトークンに置いた証明書は Pi にないドライバーを必要とすることがあり、SSO の流れは画面なしのセッションでは表示できないブラウザウィンドウを開くことがあります。まさにその場合のためにデバイスコードや手動コピーの経路を用意するゲートウェイもあれば、そうでないものもあります。組織が画面なしの Linux ホストに対してどの方式をサポートしているかを尋ね、依存する前に試してください。

フロントエンドの統合は認証とは別の選択です。NetworkManager のプラグインは接続を整えてその秘密を保存できますが、サポートされていない認証方式を互換にはできません。この二つの問いは切り離しておいてください。

雇用主の境界を保つ

組織が公式クライアント、管理されたデバイス、サポート対象のディストリビューションを要求するなら、その要件に従うか、承認された代替を求めてください。証明書チェックを無効にし、ポスチャの結果を偽装し、別のクライアントが受け入れられたように見せるためにエンドポイント制御を切ることは、互換性の問題をポリシー違反に変えます。パスワード、セッション Cookie、秘密鍵をシェルの履歴やチャットの記録に残さないでください。動作するチャレンジ応答は、セッションの素材を公開する許可ではありません。

承認された登録の後、プライベート DNS、想定したリソース、拒否されるリソース、再接続を、Pi 自体から確認してください。ログイン済みのトンネルでも、誤った経路を通ったり、権限を欠いたりすることがあります。

成果物は、名前のある責任者を伴う支援可能な合意です。どのクライアント、どのバージョン、どの登録経路か。ベンダーに近いクライアントを入れて、残りの要件が任意だったと願うより、それが優れています。