Назад | Перейти на главную страницу

IPsec VPN site-to-site: как мне настроить файлы ipsec.conf на обоих сайтах, чтобы туннель заработал?

Что я пытаюсь сделать, так это создать межсайтовую IPsec VPN между моей сетью и сетью моего друга. У нас обоих есть маршрутизатор и два компьютера на каждом маршрутизаторе, причем все компьютеры работают под управлением Linux. Итак, я предполагаю, что топология выглядит так

[myPC1 + myPC2] --- myRouter ------ Интернет ----- hisRouter --- [hisPC1 + hisPC2]

Оба маршрутизатора дешевые, поэтому в них нет ничего похожего на OpenWRT.

Итак, конфигурация - я полагаю, это должно быть сделано в Linux с обеих сторон.

До сих пор мы пробовали использовать openSwan как с ключами RSA, так и с PSK, но после команды

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"

мы получили эти IP-адреса с помощью curl ifconfig.me После этой конфигурации мы запускаем:

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.

Я не знаю, помогает ли это, возможно, вы уже заметили, что не так, но вот последнее, статус 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;

Еще один вопрос, как решить проблему NETKEY [Failed], если это необходимо!

Честное слово, у вас действительно есть работа. ХОРОШО; вот что-то вроде основы для начинающих, потому что в настоящий момент у вас настолько неправильные основы, что детали не имеют значения.

Прежде всего, проблема заключается в том, что у вас нет статических публичных адресов для каждого из ваших интернет-соединений. IPSec не поддерживает туннели в таких конфигурациях [1], поэтому вам придется редактировать свой ipsec.conf каждый раз, когда изменяется любой из ваших адресов. ОК?

Теперь, когда я спросил вас, имеет ли каждая конечная точка 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. Если это не так, просто поменяйте соответствие. Я также позвоню бывшей паре осталось и последняя пара право. Не имеет значения, что есть что, но это поможет нам думать прямо, что было бы действительно хорошая идея прямо сейчас.

Вам необходимо настроить общедоступные маршрутизаторы на обоих концах для пересылки UDP / 500 и протоколов 50 и 51 (только для полноты) на конечные точки OpenSWAN внутри каждого общедоступного адреса. Если вы не можете управлять двумя проходами протоколов, изучите документацию по обходу NAT и также отправьте UDP / 4500.

Во-первых, это требование, чтобы каждый конец нашел свой собственный 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. Ты видишь?

Кроме того, вам необходимо настроить всех клиентов на каждом конце так, чтобы у них был маршрут к удаленной сети RFC1918 через локальную конечную точку OpenSWAN. Вам нужно будет проверить это /proc/sys/net/ipv4/ip_forward устанавливается в 1 на каждой конечной точке. И было бы действительно хорошей идеей отключить любой брандмауэр на двух конечных точках, по крайней мере, на данный момент. Вам также может потребоваться активировать некоторые переменные конфигурации, которые сообщают каждой конечной точке не заботиться о том, что удаленная конечная точка думает, что у нее есть IP-адрес, отличный от того, что думает локальная конечная точка; по памяти, это leftid= и rightid=, но вам придется решить это самостоятельно.

Итак, это основы. Если вы правильно поняли фундаментальную топологию и концепции, остальное - это просто отладка деталей. Удачи с этим.

[1] Это не совсем так. Реализации SWAN поддерживают гибкое шифрование IPSec, но для этого требуется, чтобы вы контролировали обратный DNS на обоих концах, а я предполагаю, что вы этого не сделаете. Опять же, прочтите справочные страницы, если хотите узнать об этом больше.