VPNの専用線？まず要件を翻訳せよ

提案書はオフィスVPN向けの特定の専用線を挙げているが、その数字は説明もなく届く。署名する前に、その一文を実際に隠している四つの要件、すなわち物理的な受け渡し、IPの提供方法、双方向の容量、そして回線の背後にあるサポートの約束に分解しよう。受け渡しで失敗する回線はより大きな帯域幅の数字では救えないので、この順番でゲートとして実行する。その後、納品されたものを自分が書き留めた内容と照合する。

要件を翻訳せよ、製品名ではなく

IPsecはIP層でトラフィックを保護し、伝送は購入した回線に任せる。IPsecアーキテクチャはピア間でトラフィックをどう保護するかを記述するが、受け渡しの種類、保証レート、修復時間については何も語らない。それらはサービス契約の性質である。

この区別こそが、回線の要件が正当でありながらVPNの要件ではない、という事態の理由のすべてだ。シリアルインターフェースしか持たないゲートウェイは本当にシリアル受け渡しを必要とし、それはプロトコルではなくハードウェアの制約である。機器を交換すればその制約は消える。各要件は「ゲートウェイがXを必要とするのはYだからだ」という形で書き、完成できない行はすべて却下する。

速度に名前を付ける前に受け渡しに名前を付けよ

受け渡しとは分界点における物理層とリンク層の接続で、銅線イーサネット、特定のトランシーバーを伴う光ファイバー、シリアルインターフェース、あるいは現在の機器が持っているという理由だけで存在する古い何かのいずれかである。ここを間違えると、ふつう両端に新しいハードウェアが必要になるため、帯域幅では決してない形で高くつく。光モジュールの欠落は容量の問題ではなく、どのアップグレードでも直らない。

コネクタ、速度の折衝、そしてメディアコンバーターやルーターを誰が供給するかを確認する。次に、回線が03:00に落ちたとき誰が何に触れてよいかを分界点が決めるため、自分の責任がどこで終わるかを確認する。その境界を回線識別子の隣に記録として書く。サポートコールを一時間のたらい回しではなく五分の会話に変える、唯一の一行である。

ip -br link show
ethtool eth0 | head -20
sudo lshw -class network -short

アドレスだけでなくIPの提供を確認せよ

サービスが実際にどのアドレスまたはプレフィックスを提供するのか、それが静的かどうかを尋ねる。動的アドレスを配る回線は、ピアの設定が自分が予定していない変更に耐えなければならないため、拠点間ゲートウェイには不向きだ。プレフィックス長も確認する必要があり、単一アドレスとルーティングされた/29は別の製品である。

次に、アドレスが自分に届く前に何かが変換していないかを尋ねる。サービスの手前にあるプロバイダー側NATやキャリアグレードNATは内向きのセッションを壊すので、遠隔拠点からIPsecを受け取るつもりのゲートウェイには到達できない。速度はそれを補えず、自分が制御しない変換器の後ろにある速い回線でも、誰も転送しないポートで内向きの接続を受け取ることはできない。

ルーターとDNSを誰が持つかを記録する。プロバイダーがルーターを供給するなら、そのファームウェア、NATの振る舞い、デフォルトルートについての考え方を受け継ぐことになり、以後の変更はすべてチケットを通る。変換の話を証明する唯一の試験は、自分のネットワークの外にいる誰かに、到達できるはずのポートへの内向き接続を試させることである。

ip -br addr
ip route get 198.51.100.10
traceroute -n 198.51.100.10

両方向の作業負荷から容量を見積もれ

容量は仕事の観点で記述すべきで、ユーザーごとの数値の観点ではない。大量のファイルアクセス、対話的な管理、夜間のバックアップはそれぞれ異なるトラフィックパターンを生み、そのうち一つだけが持続的な上りスループットを気にする。席あたりの帯域幅の数字は販売上の便宜であり、モデルではない。

両方向を見積もり、カプセル化のオーバーヘッドを加え、トラフィックがバースト的か持続的かを記す。次に、数秒で失効するバースト許容量は夜間バックアップの役に立たないため、契約の見出しレートではなく保証レートを確認する。ゲートウェイ自身の限界も同じ予算に入れておく必要があり、暗号処理と同時セッション数は回線よりずっと早く詰まることがある。速い回線は飽和したゲートウェイを直さない。

運用上の約束を確定せよ

可用性、修理対応、エスカレーション経路、保守通知は書面にし、測定方法を明記する。見出しのインターネット速度はそのどれも確立しないし、停電を定義せずに信頼性を約束するマーケティングページも同じだ。プロバイダー自身の確認から測った応答時間と、自分の監視アラートから測った時間は同じ数字ではないため、時計がいつ始まるかを尋ねる。その二つの定義は、誰も嘘をつかずに数時間違うことがある。

サポートの境界も記録する。プロバイダーの責任が、自分のルーターが終端する受け渡しで終わるなら、あらゆる障害の最初の一時間は誰の過失かを決めることに消え、どのSLA時計もそれを覆わない。

書かれた条件と回線を照合せよ

サービスが稼働したら、設置業者が見せた性質ではなく、実際に契約した性質を測定する。実際の経路上のスループット、遅延、損失が証拠であり、名前を言える時刻と場所で取得すべきだ。受け渡し時だけでなく、混雑する時間帯にも測定を繰り返す。静かな日の10:00に実行した受入試験は、15:00の回線についてはほとんど何も語らない。

iperf3 -c speed.example.net -t 30 -P 4
mtr -n --report -c 50 198.51.100.10
curl -sS -o /dev/null -w '%{time_connect} %{time_starttransfer}\n' https://speed.example.net/

基準線のない性能の議論は印象についての議論だから、結果は契約と一緒に保管する。測定が約束を下回ったら、証拠が新しいうちに、そしてサービスが契約の提供する受入期間内にあるうちに提起する。リクエストで指定したホストはTLSハンドシェイクも有効に保つので、証明書の警告が回線の故障と誤解されない。

最後に、その四つのゲートを納品されたものに対して読み直す。受け渡し、IPの提供、容量、サポート条件のそれぞれに記録の行があり、各行の隣には名前がある。