web-dev-qa-db-ja.com

IPsec VPNサイト間：トンネルを稼働させるには、両方のサイトでipsec.confファイルをどのように構成すればよいですか？

私がやろうとしていることは、私のネットワークと友達のネットワークの間にサイト間IPsec VPNを作成することです。私たちはどちらもルーターを持ち、各ルーターには2台のコンピューターがあり、すべてのコンピューターでLinuxが実行されています。だからトポロジーはこのように見えると思います

[myPC1 + myPC2] --- myRouter ------ internet ----- hisRouter --- [hisPC1 + hisPC2]

どちらのルーターも安価なので、OpenWRTのようなものはありません。

したがって、構成–これはLinuxの両側で実行する必要があると思います。

これまでのところ、RSAキーとPSKの両方でopenSwanを試しましたが、コマンドの後

ipsec auto --up net-to-net

「net-to-netという名前の接続はありません」というエラー、または「この接続のどちらの側でも自分自身を識別できません」というエラーが発生します。

Ipsec.confファイルを間違って設定していると思います。誰かがこのトポロジを実現するためにそれを正しく構成する方法を説明できますか？

編集...

ここに、私のケースをよりよく理解するのに役立つかもしれないいくつかの事実があります。
これらはすべて、テストしたPSKの例からのものです。

私のifconfig：

eth0 Link encap:Ethernet HWaddr 00:0C:29:1B:F5:1C
inet addr:192.168.1.78 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::20c:29ff:fe1b:f51c/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:829 errors:0 dropped:0 overruns:0 frame:0
TX packets:704 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1213737 (1.1 MiB) TX bytes:57876 (56.5 KiB)

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:53 errors:0 dropped:0 overruns:0 frame:0
TX packets:53 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:3664 (3.5 KiB) TX bytes:3664 (3.5 KiB)

彼のifconfig

Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:4 errors:0 dropped:0 overruns:0 frame:0
TX packets:4 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:240 (240.0 b) TX bytes:240 (240.0 b)

p2p1 Link encap:Ethernet HWaddr 08:00:27:2A:F1:F5
inet addr:10.0.2.15 Bcast:10.0.2.255 Mask:255.255.255.0
inet6 addr: fe80::a00:27ff:fe2a:f1f5/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:21104 errors:0 dropped:0 overruns:0 frame:0
TX packets:12458 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:16079321 (15.3 MiB) TX bytes:1012204 (988.4 KiB)

Ipsec.confファイル、私たちは両方ともまったく同じファイルを使用し、それを/etc/init.dにも配置しました

version 2.0    
config setup    
    protostack=netkey    
    nat_traversal=yes    
    #virtual_private=    
    oe=off    

conn net-to-net  
    authby=secret                # Key exchange method  

    left=212.251.112.115         # Public Internet IP address of the
    leftsubnet=10.0.2.0/24       # Subnet protected by the LEFT VPN device  
    leftnexthop=%defaultroute    # correct in many situations  

    right=79.103.7.114           # Public Internet IP address of
    rightsubnet=192.168.1.0/24   # Subnet protected by the RIGHT VPN device  
    rightnexthop=%defaultroute   # correct in many situations

    auto=start                   # authorizes and starts this connection

また、まったく同じipsec.secretsを使用しました。これらは両方とも/etc/init.dに配置しました。

212.251.112.115 79.103.7.114 : PSK "123"

curl ifconfig.meを使用してこれらのIPを取得しました。その構成の後、次のコマンドを実行します。

service ipsec restart  
ipsec verify

そして、send_redirectsに同じ失敗メッセージが表示され、0への変更が拒否されました

Checking your system to see if IPsec got installed and started correctly:
Version check and ipsec on-path                                 [OK]
Linux Openswan U2.6.37/K3.1.0-7.fc16.x86_64 (netkey)
Checking for IPsec support in kernel                            [OK]
 SAref kernel support                                           [N/A]
 NETKEY:  Testing XFRM related proc values                      [FAILED]

  Please disable /proc/sys/net/ipv4/conf/*/send_redirects
  or NETKEY will cause the sending of bogus ICMP redirects!

    [FAILED]

  Please disable /proc/sys/net/ipv4/conf/*/accept_redirects
  or NETKEY will accept bogus ICMP redirects!

    [OK]
Checking that pluto is running                                  [OK]
 Pluto listening for IKE on udp 500                             [OK]
 Pluto listening for NAT-T on udp 4500                          [OK]
Checking for 'ip' command                                       [OK]
Checking /bin/sh is not /bin/dash                               [OK]
Checking for 'iptables' command                                 [OK]
Opportunistic Encryption Support                                [DISABLED]

その後、私たちは続行しました

ipsec auto --up net-to-net

そして私達は両方を得ました

022 "net-to-net": We cannot identify ourselves with either end of this connection.

それが役立つかどうかはわかりませんが、おそらくすでに問題が発生していることに気づいていますが、最後にもう1つ、ipsecのステータスを示します。

ipsec auto --status
000 using kernel interface: netkey
000 interface lo/lo ::1
000 interface lo/lo 127.0.0.1
000 interface lo/lo 127.0.0.1
000 interface eth0/eth0 192.168.1.78
000 interface eth0/eth0 192.168.1.78
000 %myid = (none)
000 debug none
000 
000 virtual_private (%priv):
000 - allowed 0 subnets: 
000 - disallowed 0 subnets: 
000 WARNING: Either virtual_private= is not specified, or there is a syntax 
000          error in that line. 'left/rightsubnet=vhost:%priv' will not work!
000 WARNING: Disallowed subnets in virtual_private= is empty. If you have 
000          private address space in internal use, it should be excluded!
000 
000 algorithm ESP encrypt: id=2, name=ESP_DES, ivlen=8, keysizemin=64, keysizemax=64
000 algorithm ESP encrypt: id=3, name=ESP_3DES, ivlen=8, keysizemin=192, keysizemax=192
000 algorithm ESP encrypt: id=6, name=ESP_CAST, ivlen=8, keysizemin=40, keysizemax=128
000 algorithm ESP encrypt: id=7, name=ESP_BLOWFISH, ivlen=8, keysizemin=40, keysizemax=448
000 algorithm ESP encrypt: id=11, name=ESP_NULL, ivlen=0, keysizemin=0, keysizemax=0
000 algorithm ESP encrypt: id=12, name=ESP_AES, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=13, name=ESP_AES_CTR, ivlen=8, keysizemin=160, keysizemax=288
000 algorithm ESP encrypt: id=14, name=ESP_AES_CCM_A, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=15, name=ESP_AES_CCM_B, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=16, name=ESP_AES_CCM_C, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=18, name=ESP_AES_GCM_A, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=19, name=ESP_AES_GCM_B, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=20, name=ESP_AES_GCM_C, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=22, name=ESP_CAMELLIA, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=252, name=ESP_SERPENT, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=253, name=ESP_TWOFISH, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP auth attr: id=1, name=AUTH_ALGORITHM_HMAC_MD5, keysizemin=128, keysizemax=128
000 algorithm ESP auth attr: id=2, name=AUTH_ALGORITHM_HMAC_SHA1, keysizemin=160, keysizemax=160
000 algorithm ESP auth attr: id=5, name=AUTH_ALGORITHM_HMAC_SHA2_256, keysizemin=256, keysizemax=256
000 algorithm ESP auth attr: id=6, name=AUTH_ALGORITHM_HMAC_SHA2_384, keysizemin=384, keysizemax=384
000 algorithm ESP auth attr: id=7, name=AUTH_ALGORITHM_HMAC_SHA2_512, keysizemin=512, keysizemax=512
000 algorithm ESP auth attr: id=8, name=AUTH_ALGORITHM_HMAC_RIPEMD, keysizemin=160, keysizemax=160
000 algorithm ESP auth attr: id=9, name=AUTH_ALGORITHM_AES_CBC, keysizemin=128, keysizemax=128
000 algorithm ESP auth attr: id=251, name=(null), keysizemin=0, keysizemax=0
000 
000 algorithm IKE encrypt: id=0, name=(null), blocksize=16, keydeflen=131
000 algorithm IKE encrypt: id=5, name=OAKLEY_3DES_CBC, blocksize=8, keydeflen=192
000 algorithm IKE encrypt: id=7, name=OAKLEY_AES_CBC, blocksize=16, keydeflen=128
000 algorithm IKE hash: id=1, name=OAKLEY_MD5, hashsize=16
000 algorithm IKE hash: id=2, name=OAKLEY_SHA1, hashsize=20
000 algorithm IKE dh group: id=2, name=OAKLEY_GROUP_MODP1024, bits=1024
000 algorithm IKE dh group: id=5, name=OAKLEY_GROUP_MODP1536, bits=1536
000 algorithm IKE dh group: id=14, name=OAKLEY_GROUP_MODP2048, bits=2048
000 algorithm IKE dh group: id=15, name=OAKLEY_GROUP_MODP3072, bits=3072
000 algorithm IKE dh group: id=16, name=OAKLEY_GROUP_MODP4096, bits=4096
000 algorithm IKE dh group: id=17, name=OAKLEY_GROUP_MODP6144, bits=6144
000 algorithm IKE dh group: id=18, name=OAKLEY_GROUP_MODP8192, bits=8192
000 algorithm IKE dh group: id=22, name=OAKLEY_GROUP_DH22, bits=1024
000 algorithm IKE dh group: id=23, name=OAKLEY_GROUP_DH23, bits=2048
000 algorithm IKE dh group: id=24, name=OAKLEY_GROUP_DH24, bits=2048
000 
000 stats db_ops: {curr_cnt, total_cnt, maxsz} :context={0,0,0} trans={0,0,0} attrs={0,0,0} 
000 
000 "net-to-net": 10.0.2.0/24===212.251.112.115<212.251.112.115>[+S=C]---192.168.1.254...192.168.1.254---79.103.7.114<79.103.7.114>[+S=C]===192.168.1.0/24; unrouted; eroute owner: #0
000 "net-to-net":     myip=unset; hisip=unset;
000 "net-to-net":   ike_life: 3600s; ipsec_life: 28800s; rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 0
000 "net-to-net":   policy: PSK+ENCRYPT+TUNNEL+PFS+IKEv2ALLOW+SAREFTRACK+lKOD+rKOD; prio: 24,24; interface: ; 
000 "net-to-net":   newest ISAKMP SA: #0; newest IPsec SA: #0;

もう1つの質問は、必要に応じて、NETKEY [失敗]の問題をどのように解決できるかです。

linuxvpnipsecsite-to-site-vpnopenswan
5
Deneb

私の言葉、あなたはあなたの仕事を切り取ってもらいました。 OK;これは一種のアウトラインプライマーです。現時点では、ファンダメンタルズが非常に間違っているため、詳細は重要ではありません。

何よりもまず、インターネット接続ごとに静的なパブリックアドレスを取得していないことが問題です。 IPSecはそのような構成[1]でトンネルを簡単にサポートしないため、どちらかのアドレスが変更されるたびにipsec.confを編集することになります。 OK？

さて、各OpenSWANエンドポイントにパブリックIPアドレスがあるかどうかを尋ね、自信を持って「はい」と言ったとき、私が疑っていたように、それは間違いでした。あなたのifconfig出力は、一方の端のアドレスが192.168.1.78で、もう一方の端のアドレスが10.0.2.15であることを示しています。また、一方の端が（現在）背後パブリックIPアドレス212.251.112.115であり、もう一方の端が79.103.7.114の後ろにあることも教えてください。あなたはどちらがそうであるかは言わないので、192.168.1.78は212.251.112.115より遅れており、10.0.2.15は79.103.7.114より遅れていると想定します。それが間違っている場合は、対応を逆にしてください。前者のペアをleftと呼び、後者のペアをrightと呼びます。どちらでも違いはありませんが、考えを正直に保つのに役立ちます。これは、本当に良いアイデアになると思います。

各パブリックアドレス内のOpenSWANエンドポイントにUDP/500とプロトコル50および51（完全を期すため）を転送するように、両端にパブリックルーターを設定する必要があります。 2つのプロトコルのパンチスルーを管理できない場合は、NATトラバーサルと転送UDP/4500についても同様にdocoを調査してください。

まず、両端が構成で独自のIPアドレスを見つけることが要件であり、両端が開始時に左右どちらであるかを知ることができます。したがって、左にはipsec.conf含む

conn net-to-net  
    authby=secret
    left=192.168.1.78
    leftsubnet=192.168.1.0/24
    leftnexthop=%defaultroute
    right=79.103.7.114
    rightsubnet=10.0.2.0/24

と ipsec.secrets言う

192.168.1.78 79.103.7.114: PSK "123"

一方、権利にはipsec.conf含む

conn net-to-net  
    authby=secret
    left=212.251.112.115
    leftsubnet=192.168.1.0/24
    right=10.0.2.15
    rightsubnet=10.0.2.0/24 
    rightnexthop=%defaultroute

と ipsec.secrets言う

10.0.2.15 212.251.112.115: PSK "123"

各エンドは、それが本当は誰であるかを本当に知る必要がありますが、リモートエンドがNATの背後にあることを気にしないふりをすることができます。見える？

さらに、ローカルのOpenSWANエンドポイントを介してリモートRFC1918ネットワークへのルートを持つように、両端ですべてのクライアントを構成する必要があります。確認する必要があります/proc/sys/net/ipv4/ip_forwardは、各エンドポイントで1に設定されます。そして、少なくとも今のところは、2つのエンドポイントでファイアウォールを無効にすることをお勧めします。また、リモートエンドポイントがローカルエンドポイントが持っているものとは異なるIPアドレスを持っていると思っても気にしないように各エンドポイントに指示するいくつかの設定変数をアクティブにする必要があるかもしれません。メモリから、これらはleftid=およびrightid=、しかしあなたはそれを自分で解決しなければならないでしょう。

これが基本です。基本的なトポロジーと概念が正しい場合、残りは詳細をデバッグするだけです。これで頑張ってください。

[1]これは真実ではありません。 SWANの実装は日和見的なIPSec暗号化をサポートしていますが、これには両端でリバースDNSを制御する必要がありますが、そうではないと思います。繰り返しますが、これについて詳しく知りたい場合は、manページをお読みください。

25
MadHatter