IPsec VPN сайт-сайт: как мне настроить файлы 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], если это необходимо!
1 ответ
Мое слово, у тебя есть работа. ХОРОШО; Вот своего рода набросок учебника, потому что в данный момент вы настолько неправильно поняли основы, что детали не имеют значения.
Прежде всего, проблема в том, что у вас нет статических публичных адресов для каждого из ваших интернет-соединений. 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 на обоих концах, и я предполагаю, что вы этого не делаете. Опять же, прочитайте справочные страницы, если вы хотите узнать больше об этом.