元パチ屋店員NWエンジニアの技術ブログ

元パチ屋店員NWエンジニアが技術のアウトプット化を目的に、好き勝手な事を書いてるブログです

インターネットVPN

f:id:hayato-ota-rf:20170909204209j:plain

いまや企業間通信になくてはならないVPN(Virtual Private Nework)ですが、その中でも安価で、個人でも使うことがあるインターネットVPNについてまとめました

VPNの種類

大きくわけて次の二つに分類されます

インターネットVPN

インターネットなどの公衆網を利用したVPNのことで、コストが低い反面、信頼性に乏しい面があります

便利な言葉、必殺ベストエフォート!!

またインターネットVPNにも使用するセキュリティプロトコルで次の二つに分類されます

IPsec-VPN

セキュリティプロトコルIPsecを使用

詳細は後程記載

SSL-VPN

セキュリティプロトコルSSLを使用

詳細は後程記載しない!!

機会があれば、また日記で書こうと思います

IP-VPN

キャリアが提供する閉鎖網を利用したVPNのことで、コストがク○高い分、信頼性が高いといった特徴があります

キャリアの網内で障害が起きた時は、猛烈電凸賠償請求GO!!

またIP-VPNにも、キャリアの閉鎖網L3orL2どちらを使用するかで次の二つに分類されます

IP-VPN(MPLS-VPN

キャリアのL3閉鎖網を使用するタイプ

拠点間ルーティングをキャリアにお任せするので手軽な反面、拠点間ルーティングで使用できるプロトコルに制限があり、カスタマイズ性に乏しい面があります

ちなみにIP-VPNを実現する為に使用されるプロトコルはMPLS( Multi-Protocol Label Switching )です

ネスペの午前試験でラベルって文言出てきたら、MPLSが含まれる選択肢を選らんどけば、大体正解します(笑)

仕組みの詳細は機会があれば、また日記で書こうと思います

広域イーサネット

キャリアのL2閉鎖網を使用するタイプ

拠点間ルーティングも自分たちでする必要があるので面倒な反面、拠点間ルーティングで多様なプロトコルを使用でき、カスタマイズ性が高いといった特徴があります

なんか広域イーサネットって響きがカッコイイと思えるのは俺だけなのだろうか(笑)

ちなみに広域イーサネットを実現する為に使用されるプロトコルIEEE802.1Qトンネリングです

仕組みの詳細は機会があれば、また日記で書こうと思います

インターネットVPNのタイプ

 大きくわけて次の二つに分類されます

サイト間VPN

VPNを実装したルータ同士を接続する構成

企業の拠点間を接続する時に使用します

リモートアクセスVPN

VPNを実装したルータとVPNクライアントソフトをインストールしたPCとを接続する構成

外出先のノートPCからイントラネットにアクセスする時などは、このタイプを使用します

 

f:id:hayato-ota-rf:20170905061443g:plain

VPNにおけるトンネリングと暗号化

VPNはトンネリングと暗号化によって実現されています

トンネリングを行えるプロトコルにはPPTP、L2F、L2TPIPsecGRE などがあります

一方、これらのうち暗号化を行えるプロトコルIPsecだけとなります

じゃあもうIPsecだけでよくね?って思っちゃうんですが、例えば拠点間でOSPFを使用したい時とかに、IPsecではそれが不可能です

何故かというと、OPSFはリンクステート情報の交換にマルチキャストを使用するのは皆さんご存知だと思います

しかし、IPsecマルチキャスト伝送が行えません

なので、IPsecを使いたいけどルーティングプロトコルにOSPFを使いたい場合は、トンネリングはGRE、暗号化はIPsecで行うGRE over IPsec等を使用する必要があります

f:id:hayato-ota-rf:20170905061458j:plain

 

f:id:hayato-ota-rf:20170905061505g:plain

IPsecを構成する2つのプロトコルと鍵交換のプロトコル

IPsecはAH、ESP、IKEなどの複数のプロトコルから構成されています

・AH(Authentication Heade)は改ざん防止

・ESP(Encapsulated Security Payload)はペイロード部に対して暗号化

・IKE(Internet Key Exchage)鍵交換

実はESPは改ざん防止機能も持っていて、ESP+IKEだけでもIPsecは成り立ちます

なのにAHを実装させることがある理由は以下になります

・ESPはIPヘッダの部分までは完全性を保証できない

・AHはESPより負荷がかからない

・AHに輸出規制がない

・AHはIPv6では必須

現在の日本におけるIPsec-VPNといえば、AHを使用しない「ESPとIKE」だけによるIPsec-VPNが一般的な実装方式らしいです

IPsecの通信モード

IPsecにおける通信モードには、トランスポートモードとトンネルモードの2つのモードがあります

f:id:hayato-ota-rf:20170905061513j:plain

 

f:id:hayato-ota-rf:20170905061520g:plain

トランスポートモードとトンネルモードの使い分け

トンネリングと暗号化両方をIPsecで行う場合はトンネルモードを使用

トンネリングはGREやLT2Pで暗号化はIPsecで行う場合はトランスポートモードを使用

何故かというと、既にGREやLT2Pでトンネリング行われているのに、IPsecでトンネリングを行うのは無駄だからです

トランスポートモードとトンネルモードのESPパケット

ちなみにESPの暗号化範囲はネスペ午前と午後両方でよく出題されます

f:id:hayato-ota-rf:20170905061529g:plain

SA ( Security Association )

VPNゲートウェイ間で確立されたコネクションのことを、IPsecではSAと呼びます

IPsecの全ての通信はこのSAを使用します

SAは一方通行のトンネルであるため、パケットを送受信するためには送信用のSA、受信用のSAの合計2つが必要になります

また、SAはIPsecカプセル化プロトコルに対して独自のものになることから、例えば

AHのパケットとESPのパケットの両方を利用して相互にIPsec通信する場合、計4つのSAが必要となります

f:id:hayato-ota-rf:20170905061539g:plain

 

このようにIPsec機器の間には数多くのSAが発生することになりるので、VPNゲートウェイIPsecのパケットがどのSAのものなのかを判断する必要があります

その判断はAHやESPパケットフィールドの SPI の値を元に行っています

f:id:hayato-ota-rf:20170905061545g:plain

 

f:id:hayato-ota-rf:20170905061551g:plain

 

ネスペの午後Ⅱで、SPIのビット長を答える問題があったんですが、おもわず「そんなん分かるか!」ってツッコミいれてしまいました(笑)

ちなみにSPIは32ビット長です

IKE( Internet Key Exchange )

IPsecの通信を始めるにあたり、SAを確立する必要があるのは分かったと思います

そのSAを自動的に生成、管理、更新するのがIKEです

IKEによるSAの生成はフェーズ1とフェーズ2のステップがあります

フェーズ1

各種パラメータを交換しISAKMP SAを生成します

f:id:hayato-ota-rf:20170905061603g:plain

フェーズ1には二つのモードがあります

メインモード

IPsecルータの両端が固定IPの場合使用

アグレッシブモード

IPsecルータの両端が動的IPの場合使用

フェーズ2

ISAKMP SA上で各種パラメータを交換してIPsec SAを生成します

f:id:hayato-ota-rf:20170905061610g:plain

パラメータ補足

ライフタイム

これが0になるとSAが消滅するので、SAの再作成が必要になります

SAの再作成処理のことをリキー(ReKey)と呼びます

このリキーが解答の問がネスペの午後Ⅱで出てきました

「そんなの分かるry」

IPパケットの断片化(フラグメンテーション)

IPパケットのMTUが1500バイトであることは皆さんご存知だと思います

IPsec環境ではIPパケットのサイズが1500を超えてしまい、IPパケットの断片化が発生することがあります

何故かというと、IPsecではカプセル化の際に様々なヘッダーを元のIPパケットに付与する必要があり、それによりIPパケットのサイズが増えてしまうからです

断片化が起きると、通信効率が悪化したり、VPNが正常に行われない可能性があります

IPsecによるIPパケットの断片化を防ぐ為には、PCやサーバのインターフェースのMTUをカプセル化によるオーバヘッドを見越して設定する必要があります(あんま現実的では無い気がするけど)

VPNが正常に行われない可能性がある理由

ルータによっては、IPフラグメントパケットを遮断する設定がONになっていることがあるフラグメント化されたパケットを利用した攻撃を防ぐ為のものらしいですが、IPsec使用環境ではOFFにするのが一般的らしいです

参考サイト

www.infraexpert.com

www.infraexpert.com

www.infraexpert.com

www.ntt.com