OpenVPN接続の確立中に理解できないエラーが発生し、内部での配置方法についての理解が不足していると感じました。 猫の下には、プロトコルの暗号化部分がどのように配置されているか、実際にどのように見えるか（つまりWiresharkで）、VPNの内部を見る方法、つまり トラフィックを自分の手で解読します（キーがある場合はもちろんです;-)）。 この部分では、静的キーを持つモードのみを考慮します。

動作モード

プラグインなしのOpenVPN自体は、接続を確立するための2つのオプションをサポートしています。

• PSK （PreSharedKeyまたは静的キーモード ）-VPNセットアッププロセス中に生成され、すべてのマシンに書き込まれる対称キーを使用します。 記事の最初の部分では、このモードのみを扱います。
• TLSは公開鍵インフラストラクチャ（PKI）に基づいています 。 最初に、TLS接続が確立されます。TLS接続は、証明書による両当事者の認証を使用して確立され、それを介して鍵素材が交換されます。 対称キーはこのキーマテリアルから生成され、VPN内部のトラフィックはPSKモードと同じ方法でこれらのキーで暗号化されます。 TLSチャネル内にはユーザートラフィックはありません。OpenVPN自体のサービス情報のみです。 このモードでのOpenVPNの準備に関する第2部を書く予定です。

PSKモードの詳細

PSKモードは、 シークレットオプションによって有効になります。その最初のパラメーターは、VPNセットアップフェーズ中に生成される静的キーを持つファイルの名前です。 このファイルには、2組の512ビットランダムキー（各ペアで暗号化用のキーとHMAC用のキー）が含まれ、次々に（ヘッダーなどなしで）書き込まれ、HEXでエンコードされます。 VPNで接続されているすべてのコンピューターに同じキーファイルが存在する必要があります。 2番目のオプションパラメーターであるdirectionがsecretオプションに設定されていない場合、最初のキーペアのみが使用されます。つまり、トラフィックは両側で同じキーで署名および暗号化されます。

静的キーモードでは、 CBCおよび暗号化なしのデータパケット暗号化形式のみを使用できます。 次に、 CBC形式を検討します。 暗号化はそれほど興味深いものではありません 。

デフォルトでは、 BlowFishは 128ビットキーを使用したCBCモードでの暗号化に使用され、 HMACにはSHA1および160ビットキーが使用されます。 キーは、静的キーを持つファイルの512ビットキーの最初の128ビットと160ビットです。

すべてのキー情報と設定は事前に設定されているため、リモートホストのアドレス（ リモートオプション）を指定すると、カプセル化されたトラフィックは、制御パケットの交換前でもOpenVPNを起動した直後に送信できます（詳細は以下を参照）。

試験台

テストでは、次のキーが使用されました（ openvpn --genkey --secret psk.keyコマンドによって生成されます）：

# # 2048 bit OpenVPN static key # -----BEGIN OpenVPN Static key V1----- 5234f60f846bb1d5f059c70e75434be6 <--      89f41113ef56e2bf69253fad6a30ab5f a449204f52f64a0265fd5744a9489f41 cefd95a1d642830e9cf9cdce13c55245 270cf7d367ddc6b56eb1ba749be40e42 <--      HMAC 80cdf7cfbad178348a0e057f1fdc87f0 e5ba84717475b868a7fd617fee8c561c b4575d983534ef71dd8aaa48a53ed469 0ae85faf4522f7defd89ba373a0d22ee <--      f9356e487fdfa0796b0b1fc393fd3ab5 52db7a1ed691ddd50eeb7be2cc32d912 52df93987f4878ec42a12e3a7cda5a40 b1aa850a05821b300359a796313cbcec <--      HMAC 4076483ec7692708c32d323ed080beba 60c58d9281fb5d27c688ac271d3b6d15 1695093291fb788dbbfefb8b7c7f9bef -----END OpenVPN Static key V1-----
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

実際、HEXのある4行ごとに512ビットのキーがあります。 1番目と3番目は暗号化のキーで、それぞれは例の最初の128ビットのみを使用します（残りの384ビットはまったく使用されません）、2番目と4番目はHMACのキーで、最初の160ビットはそれぞれから使用されます。 言い換えれば：

 key_encrypt_0 = unhexlify("5234f60f846bb1d5f059c70e75434be689f41113ef56e2bf69253fad6a30ab5fa449204f52f64a0265fd5744a9489f41cefd95a1d642830e9cf9cdce13c55245")[:16] key_hmac_0 = unhexlify("270cf7d367ddc6b56eb1ba749be40e4280cdf7cfbad178348a0e057f1fdc87f0e5ba84717475b868a7fd617fee8c561cb4575d983534ef71dd8aaa48a53ed469")[:20] key_encrypt_1 = unhexlify("0ae85faf4522f7defd89ba373a0d22eef9356e487fdfa0796b0b1fc393fd3ab552db7a1ed691ddd50eeb7be2cc32d91252df93987f4878ec42a12e3a7cda5a40")[:16] key_hmac_1 = unhexlify("b1aa850a05821b300359a796313cbcec4076483ec7692708c32d323ed080beba60c58d9281fb5d27c688ac271d3b6d151695093291fb788dbbfefb8b7c7f9bef")[:20]
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

両方のキーペアを使用して静的キーモードでUDPを使用する場合の設定ファイル（各方向は独自のペアで暗号化されます）：

 #   dev tun ifconfig 192.168.1.1 192.168.1.2 remote 192.168.0.2 secret psk.key 0
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

 #   dev tun ifconfig 192.168.1.2 192.168.1.1 remote 192.168.0.1 secret psk.key 1
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここで、192.168.0.1と192.168.0.2はマシンの物理インターフェースのアドレスであり、192.168.1.1と192.168.1.2はトンネル内の対応するアドレスです。

構成ファイルの1つでのみ指定するには、 リモートオプションで十分です。 この場合、 リモートが設定されていないホストは、着信接続（この場合はUDPパケット）を待つだけです。

準備中です

送信されるパケットの形式は次のとおりです。

 [Len (2 )] | HMAC (20 ) | IV (8 ) | packet ID (4 ) | timestamp (4 ) | packet payload
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Len-最初の2バイトを除くパケット全体の長さ。 TCP経由で作業する場合にのみ使用されます。 UDPを使用する場合、OpenVPNパケットの長さはUDPパケットの長さから計算されますが、OpenVPNパケットのLenフィールドは計算されません。

HMAC -HMACの後に来るすべてのHMAC-SHA1（IVおよび暗号化されたデータ）

IV -CBCモードの初期化ベクトル。

IVの後に来るすべてが暗号化されて送信されます。

パケットID-パケット番号。 ここには繰り返しを防ぐために含まれており、保証されたデータ配信を整理するためには使用されません。

タイムスタンプ -繰り返しに対する保護にも使用されます。

パケットペイロード -パケットが運ぶデータ。 これは、OpenVPNオーバーヘッドまたはカプセル化されたトラフィック自体です。

サービスパッケージを解読します

約束されたWireshark（ ディセクタページの声明とは反対に、彼は静的キーモードのOpenVPNを理解していません）：

最初のパッケージを取得し、復号化を試みます。 なぜなら VPNはUDPを介して動作するように構成されており、Lenフィールドはありません。パケットはすぐにHMACで始まります。 HMACフィールドなしで、このパケットのHMACが何に等しくなるかを計算してみましょう。

 packet = unhexlify("7c0a45b025b3225c9a60051699fc87bae44dec9026e792a7ff3842aabd7cc77b439564b42002e5e327cba04c620cd80ca92c60139e2345a2c5d99b0f") print("HMAC = %s" % HMAC(key_hmac_0, packet[20:], 'sha1').hexdigest())
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

 HMAC = 7c0a45b025b3225c9a60051699fc87bae44dec90
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

計算されたHMACは、パッケージに挿入されたHMACと正確に一致することがわかります。 そのため、パケット認証はパスされており、私たちは正しい軌道に乗っています！ 今、それを解読する時です。

 iv = packet[20:28] encrypted_part = packet[28:] decrypted = Blowfish.new(key_encrypt_0, mode=Blowfish.MODE_CBC, IV=iv).decrypt(encrypted_part) print(" : %s" % hexlify(decrypted).decode())
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

  : 00000001 58069a45 287f346bd4ef7a812d56b8d3afc5459c00 07070707070707
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

最初の4バイトはパケット番号です。 そうです、最初にパッケージを取りました。 2番目の4バイトは一時的なもので、私はラベルです。 末尾の7バイト0x07はパディング（暗号化中に追加されたため、メッセージの長さがブロックの長さの倍数になる）であり、正しいため、破棄します。

 packet_id = decrypted[:4] timestamp = decrypted[4:8] decrypted_data = decrypted[8:-decrypted[-1]] #  packet_id  timestamp       print("ID : %s" % hexlify(packet_id).decode()) print(" : %s" % hexlify(timestamp).decode()) print(" : %s" % hexlify(decrypted_data).decode())
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

 ID : 00000001  : 58069a45  : 287f346bd4ef7a812d56b8d3afc5459c00
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

一見、16バイトのランダムな文字列とゼロバイトが送信されているように見えます。 なぜなら OpenVPNはオープンソースプロジェクトです。コードを調べて、 occ.cファイルで仮説を部分的に確認する答えを見つけます。

287f346bd4ef7a812d56b8d3afc5459cはocc_magic定数です-パッケージがOpenVPNコントロールパッケージであることを示します。 制御パケットタイプのタイプの後、この場合はバイト0x00 == OCC_REQUESTです。 OCC_REQUESTを含むパケットでは、他に何も送信すべきではありません。

次に、2番目のパッケージを復号化します。

 packet = unhexlify("91861a4479c376d3013cdcd7f3e657ac093048cdb3a40775fc5804f68842ef06288a9343acb298562aaa4c92c10aae2213441619c3df0d8b89a0f13f5dd69d1eaa0e22667938b68e38a1238e39b76b889b7b6e5dbadd8f3a264f6fc9bb9c225de387d5d17914b2e2853d7fbb706da429f596721ab394febe7e52875183f0e9e10ec16042398c4116c2069ef18f06da45b55581a9997d1f54def143b053226727934404be44379a0172d1b618bbf1b676b60f57889e734af6b54291d07d9c7e13573cc81e") #        'secret'    'direction',         . key_hmac = key_hmac_1 key_encrypt = key_encrypt_1 print("HMAC = %s" % HMAC(key_hmac, packet[20:], 'sha1').hexdigest()) iv = packet[20:28] encrypted_part = packet[28:] decrypted = Blowfish.new(key_encrypt, mode=Blowfish.MODE_CBC, IV=iv).decrypt(encrypted_part) print(" : %s" % hexlify(decrypted).decode()) packet_id = decrypted[:4] timestamp = decrypted[4:8] decrypted_data = decrypted[8:-decrypted[-1]] #  packet_id  timestamp       print("ID : %s" % hexlify(packet_id).decode()) print(" : %s" % hexlify(timestamp).decode()) print("  HEX: %s" % hexlify(decrypted_data).decode()) print(" : %s" % decrypted_data)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

 HMAC = 91861a4479c376d3013cdcd7f3e657ac093048cd  : 0000000158069a45287f346bd4ef7a812d56b8d3afc5459c0156342c6465762d747970652074756e2c6c696e6b2d6d747520313534342c74756e2d6d747520313530302c70726f746f2055445076342c6966636f6e666967203139322e3136382e312e31203139322e3136382e312e322c6b657964697220312c6369706865722042462d4342432c6175746820534841312c6b657973697a65203132382c73656372657400030303 ID : 00000001  : 58069a45   HEX: 287f346bd4ef7a812d56b8d3afc5459c0156342c6465762d747970652074756e2c6c696e6b2d6d747520313534342c74756e2d6d747520313530302c70726f746f2055445076342c6966636f6e666967203139322e3136382e312e31203139322e3136382e312e322c6b657964697220312c6369706865722042462d4342432c6175746820534841312c6b657973697a65203132382c73656372657400    ASCII: b'(\x7f4k\xd4\xefz\x81-V\xb8\xd3\xaf\xc5E\x9c\x01V4,dev-type tun,link-mtu 1544,tun-mtu 1500,proto UDPv4,ifconfig 192.168.1.1 192.168.1.2,keydir 1,cipher BF-CBC,auth SHA1,keysize 128,secret\x00'
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このパケットの最初の16バイトはocc_magicであり、次のバイト（制御パケットのタイプ）は0x01 == OCC_REPLYであることがわかります。 OCC_REPLYパケットでは、パラメータ付きのC文字列がパケットタイプの後に渡されます。 この場合、次のテキストが送信されます： V4、dev-type tun、link-mtu 1544、tun-mtu 1500、proto UDPv4、ifconfig 192.168.1.1 192.168.1.2、keydir 1、cipher BF-CBC、auth SHA1、keysize 128、secret 。 同じ行がOpenVPNログにあります。

次の2つのパケットは、2番目のホストから最初のホストへのOCC_REQUESTと 、そのホストへのOCC_REPLYです。 同様の方法でそれらを解読します。

 HMAC = fc52f6981ccb4d7c2a3c951bd1ce8e882f9155da ID : 00000002  : 58069a45   HEX: 287f346bd4ef7a812d56b8d3afc5459c00  : b'(\x7f4k\xd4\xefz\x81-V\xb8\xd3\xaf\xc5E\x9c\x00'
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

 HMAC = e4987efec6d4625e89ba26b69b0d8f54ed391c3c ID : 00000002  : 58069a45   HEX: 287f346bd4ef7a812d56b8d3afc5459c0156342c6465762d747970652074756e2c6c696e6b2d6d747520313534342c74756e2d6d747520313530302c70726f746f2055445076342c6966636f6e666967203139322e3136382e312e32203139322e3136382e312e312c6b657964697220302c6369706865722042462d4342432c6175746820534841312c6b657973697a65203132382c73656372657400  : b'(\x7f4k\xd4\xefz\x81-V\xb8\xd3\xaf\xc5E\x9c\x01V4,dev-type tun,link-mtu 1544,tun-mtu 1500,proto UDPv4,ifconfig 192.168.1.2 192.168.1.1,keydir 0,cipher BF-CBC,auth SHA1,keysize 128,secret\x00'
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

リモートホストの設定を受け取ったローカルホストは、自身と外部の設定の適合性をチェックし、矛盾がある場合は警告を発行します。 この場合、両側のVPN設定が方向に一致することがわかります。

V4、dev-type tun、link-mtu 1544、tun-mtu 1500、proto UDPv4、ifconfig 192.168.1.1 192.168.1.2、keydir 1、暗号BF-CBC、auth SHA1、キーサイズ128、シークレット

V4、dev-type tun、link-mtu 1544、tun-mtu 1500、proto UDPv4、ifconfig 192.168.1.2 192.168.1.1、keydir 0、暗号BF-CBC、auth SHA1、キーサイズ128、シークレット

カプセル化されたトラフィックの復号化

このトラフィックダンプの次のパケットは、ユーザーデータを伝送します。 前と同じ方法でデコードします。

 HMAC = efe4850d41f0e4a7535f13310685d74c2722a0da ID : 00000003  : 58069a45   HEX: 4500005420874000400196cec0a80102c0a80101080066ed1a1300014d9a0658000000005a390a0000000000101112131415161718191a1b1c1d1e1f202122232425262728292a2b2c2d2e2f3031323334353637
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

occ_magicもping_magic（ 2a187bf3641eb4cb07ed2d0a981fc748に等しい別のマジック定数）も存在しない場合、これはデータパケットです。 実際、0x45はオプションのヘッダーフィールドのないIPv4パケットの最初のバイトです。 これは、tunインターフェイスから出たping-requestを含むIPv4パケットとまったく同じであることがわかります（図の16進数では、IPv4は2行目から始まります）。

応答パッケージ：

 HMAC = a0a0108cd173e8829b91e8b34bd5cac2ab8a9c0b ID : 00000003  : 58069a45   HEX: 450000547f00000040017855c0a80101c0a8010200006eed1a1300014d9a0658000000005a390a0000000000101112131415161718191a1b1c1d1e1f202122232425262728292a2b2c2d2e2f3031323334353637
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これは、トンネルに送信されたping-replyを使用したIPv4とまったく同じであることがわかります。

備考

OpenVPN Ping

pingパケットもあります-最後のパケットが別のホストに送信されてから時間が経過した場合に接続を確認するためにOpenVPNが送信するサービスパケット（キープアライブ、非アクティブ、ping *オプションで設定）。 通常のicmp pingとは異なり、OpenVPNは受信したパケットに応答しませんが、接続が生きていることを単に覚えています。

nmapとOpenVPN

OpenVPNがPSKモード（およびTLS-AUTHオプションを有効にしたTLSモード）でリッスンするUDPポート。秘密鍵を知らないすべての人にとって、その上のすべてのパケットがドロップしているように見えます。 nmapは、このポートのステータスを「open | filters」と表示します。 OpenVPNログ（verbオプションの値が十分に高い）で、ポートをスキャンすると、「パケットの認証/復号化エラー：パケットHMAC認証に失敗しました」というエントリがあります。

OpenVPNトラフィック検出

PSKモードでは、UDPを使用して作業する場合、サードパーティのオブザーバー（秘密鍵を持たない）のOpenVPNパケットのコンテンツ全体がランダムに見えます。 これらのパッケージをOpenVPNに起因させる署名はありません。 ただし、パケット長はランダムデータイメージから外れます-使用されるハッシュ関数と、使用される暗号のブロックサイズに等しい増分の変化、および固定長サービスパケット（OCC_REQUESTおよびOpenVPN PINGパケット）の存在に依存します。

さらに、TCPを使用して作業する場合、各OpenVPNパケットの先頭には、暗号化されていないパケット長の2バイトフィールドがあります。

おわりに

PSKモードでは、すべてが非常に単純に配置されていることがわかります。 実際にはクライアント/サーバーの分離さえありません。

TLSモードでは、接続の確立ははるかに困難ですが、公開キーインフラストラクチャを使用できるようにし、セッションキーの定期的な変更を提供し、 Perfect Forward Secrecyを実装します。 ただし、次のパートのTLSモードについては。