IPSec VPN між Amazon VPC та Linux сервером


9

Я намагаюся встановити IPSec VPN-з'єднання між нашою корпоративною мережею та віртуальною приватною хмарою Amazon, використовуючи їх VPN-систему та сервер Linux. На жаль, єдине знайдене в мене керівництво розповідає про те, як налаштувати тунель за допомогою хост-машини Linux та отримати цю машину Linux для доступу до екземплярів VPC, але в Інтернеті немає обговорення, як отримати інстанцію для доступу до корпоративної мережі (або інший Інтернет через цю мережу).

Інформація про мережу

Local subnet: 10.3.0.0/25
Remote subnet: 10.4.0.0/16

Tunnel 1:
  Outside IP Addresses:
    - Customer Gateway:        : 199.167.xxx.xxx
    - VPN Gateway              : 205.251.233.121

  Inside IP Addresses
    - Customer Gateway         : 169.254.249.2/30
    - VPN Gateway              : 169.254.249.1/30

Tunnel 2:
  Outside IP Addresses:
    - Customer Gateway:        : 199.167.xxx.xxx
    - VPN Gateway              : 205.251.233.122

  Inside IP Addresses
    - Customer Gateway         : 169.254.249.6/30
    - VPN Gateway              : 169.254.249.5/30

Ось мій /etc/ipsec-tools.conf:

flush;
spdflush;

spdadd 169.254.249.2/30 169.254.249.1/30 any -P out ipsec
   esp/tunnel/199.167.xxx.xxx-205.251.233.121/require;

spdadd 169.254.249.1/30 169.254.249.2/30 any -P in ipsec
   esp/tunnel/205.251.233.121-199.167.xxx.xxx/require;

spdadd 169.254.249.6/30 169.254.249.5/30 any -P out ipsec
   esp/tunnel/199.167.xxx.xxx-205.251.233.122/require;

spdadd 169.254.249.5/30 169.254.249.6/30 any -P in ipsec
   esp/tunnel/205.251.233.122-199.167.xxx.xxx/require;



spdadd 169.254.249.2/30 10.4.0.0/16 any -P out ipsec
   esp/tunnel/199.167.xxx.xxx-205.251.233.121/require;

spdadd 10.4.0.0/16 169.254.249.2/30 any -P in ipsec
   esp/tunnel/205.251.233.121-199.167.xxx.xxx/require;

spdadd 169.254.249.6/30 10.4.0.0/16 any -P out ipsec
   esp/tunnel/199.167.xxx.xxx-205.251.233.122/require;

spdadd 10.4.0.0/16 169.254.249.6/30 any -P in ipsec
   esp/tunnel/205.251.233.122-199.167.xxx.xxx/require;

Ось мій /etc/racoon/racoon.conf:

remote 205.251.233.122 {
        exchange_mode main;
        lifetime time 28800 seconds;
        proposal {
                encryption_algorithm aes128;
                hash_algorithm sha1;
                authentication_method pre_shared_key;
                dh_group 2;
        }
        generate_policy off;
}

remote 205.251.233.121 {
        exchange_mode main;
        lifetime time 28800 seconds;
        proposal {
                encryption_algorithm aes128;
                hash_algorithm sha1;
                authentication_method pre_shared_key;
                dh_group 2;
        }
        generate_policy off;
}

sainfo address 169.254.249.2/30 any address 169.254.249.1/30 any {
    pfs_group 2;
    lifetime time 3600 seconds;
    encryption_algorithm aes128;
    authentication_algorithm hmac_sha1;
    compression_algorithm deflate;
}

sainfo address 169.254.249.6/30 any address 169.254.249.5/30 any {
    pfs_group 2;
    lifetime time 3600 seconds;
    encryption_algorithm aes128;
    authentication_algorithm hmac_sha1;
    compression_algorithm deflate;
}

BGP працює нормально, тому я не збираюся публікувати ці конфігурації.

Ось що працює

  • З вікна Linux я можу записати локальні кінцеві точки (169.254.249.2/169.254.249.6) та їх віддалені еквіваленти (169.254.249.1/169.254.249.5).
  • Я також можу пінг-екземпляри в VPC, SSH до них тощо.
  • З віддалених екземплярів VPC я також можу пінг локальних та віддалених кінцевих точок
  • Я не можу пінг локальних серверів у підмережі 10.3.0.0/25

Я припускаю, що мені не вистачає чогось простого, але я спробував додати записи до ipsec-tools.conf, щоб відобразити {local endpoint} <-> {віддалену підмережу}, використовуючи {local subnet} <-> {remote endpoint}, але це, здається, не спрацювало.

Коли я пінг з {віддаленого примірника} на {локальний сервер}, пінг-тайм-аут. Пакети видно на інтерфейсі eth0 (навіть якщо локальна мережа є на eth1).

Google мало допомагає; він показує лише людей, які намагаються використовувати OpenSwan або мають подібні проблеми, але з апаратними маршрутизаторами або з використанням старих інструментів.


Я не експерт, але здається, що звідси wiki.debian.org/IPsec, що вам потрібно вручну додавати маршрути до віддаленої локальної мережі при використанні ipsec, я можу помилитися ..
user993553

Відповіді:


3

Ну, я обдурив :) Я встановив шлюз Astaro, який офіційно підтримується Amazon, а потім використав його для моделювання власного. Ви можете просто SSH в підрозділ Astaro і подивитися, як вони все налаштували. Звичайно, ви можете дотримуватися підрозділу Astaro, якщо вам захочеться платити за це.


1
Чи можете ви детальніше розглянути своє рішення? Що ви маєте на увазі під "моделюю мою власну"? Я застряг у цій же проблемі, і мені було б цікаво, як ви її вирішили, дякую!
Макс

3

Зрозумів це. Довелося змінити свій ipsec-tools.conf на це:

flush;
spdflush;

# Generic routing
spdadd 10.4.0.0/16 10.3.0.0/25 any -P in  ipsec esp/tunnel/205.251.233.121-199.167.xxx.xxx/require;
spdadd 10.3.0.0/25 10.4.0.0/16 any -P out ipsec esp/tunnel/199.167.xxx.xxx-205.251.233.121/require;

# Tunnel 1
spdadd 169.254.249.1/30 169.254.249.2/30 any -P in  ipsec esp/tunnel/205.251.233.121-199.167.xxx.xxx/require;
spdadd 169.254.249.2/30 169.254.249.1/30 any -P out ipsec esp/tunnel/199.167.xxx.xxx-205.251.233.121/require;

spdadd 10.4.0.0/16 169.254.249.2/30 any -P in  ipsec esp/tunnel/205.251.233.121-199.167.xxx.xxx/require;
spdadd 169.254.249.2/30 10.4.0.0/16 any -P out ipsec esp/tunnel/199.167.xxx.xxx-205.251.233.121/require;

# Tunnel 2
spdadd 169.254.249.5/30 169.254.249.6/30 any -P in  ipsec esp/tunnel/205.251.233.122-199.167.xxx.xxx/require;
spdadd 169.254.249.6/30 169.254.249.5/30 any -P out ipsec esp/tunnel/199.167.xxx.xxx-205.251.233.122/require;

spdadd 10.4.0.0/16 169.254.249.6/30 any -P in  ipsec esp/tunnel/205.251.233.122-199.167.xxx.xxx/require;
spdadd 169.254.249.6/30 10.4.0.0/16 any -P out ipsec esp/tunnel/199.167.xxx.xxx-205.251.233.122/require;

І змінити мій racoon.conf на це:

path pre_shared_key "/etc/racoon/psk.txt";

remote 205.251.233.122 {
        exchange_mode main;
        lifetime time 28800 seconds;
        proposal {
                encryption_algorithm aes128;
                hash_algorithm sha1;
                authentication_method pre_shared_key;
                dh_group 2;
        }
        generate_policy off;
}

remote 205.251.233.121 {
        exchange_mode main;
        lifetime time 28800 seconds;
        proposal {
                encryption_algorithm aes128;
                hash_algorithm sha1;
                authentication_method pre_shared_key;
                dh_group 2;
        }
        generate_policy off;
}

sainfo address 169.254.249.2/30 any address 169.254.249.1/30 any {
    pfs_group 2;
    lifetime time 3600 seconds;
    encryption_algorithm aes128;
    authentication_algorithm hmac_sha1;
    compression_algorithm deflate;
}

sainfo address 169.254.249.6/30 any address 169.254.249.5/30 any {
    pfs_group 2;
    lifetime time 3600 seconds;
    encryption_algorithm aes128;
    authentication_algorithm hmac_sha1;
    compression_algorithm deflate;
}

sainfo address 10.3.0.0/25 any address 10.4.0.0/16 any {
    pfs_group 2;
    lifetime time 3600 seconds;
    encryption_algorithm aes128;
    authentication_algorithm hmac_sha1;
    compression_algorithm deflate;
}

Однак ця конфігурація, наскільки я розумію, буде здійснювати лише трафік між 10.3.0.0/25 та 10.4.0.0/16 через перший тунель (через xxx121). Я оновлю відповідь, коли зрозумію це.


Я також певний час зациклювався на цьому питанні, і ваша відповідь справді допомогла. Ви придумали рішення для маршрутизації по обох тунелях? Я додав «Загальну маршрутизацію» деталей з іншим IP-адресою тунелю, але не перевіряв його.
Буде

Я не знайшов хорошого рішення для маршрутизації по обох тунелях, але думаю, що це має сенс в одному контексті. Ідея тут полягає у забезпеченні надмірності, і в ідеалі, яка б включала надмірність з обох цілей. Ви можете встановити окремий сервер на другому тунелі і надати два маршрути до своїх VPN (наприклад, надавши стандартним серверам два маршрути, по одному до кожного поля). Або це, або ви спрацьовуєте вручну з відмовою від якоїсь системи моніторингу. Жодне рішення не є дійсно «оптимальним», але перше забезпечує надмірність і з вашого боку.
Ден Удей

0

Чи знаєте ви причину використання "вимагати" замість "використовувати" для конфігурації setkey? Чи знаєте ви також, чи має значення, в якому порядку я розміщую висловлювання у віддалених розділах та на сайті sainfo та помилково дублюю певні твердження? Наприклад:

#original
remote 205.251.233.121 {
        exchange_mode main;
        lifetime time 28800 seconds;
        proposal {
                encryption_algorithm aes128;
                hash_algorithm sha1;
                authentication_method pre_shared_key;
                dh_group 2;
        }
        generate_policy off;
}

проти

#edited
remote 205.251.233.121 {
        generate_policy off;                           #moved/duplicated
        lifetime time 28800 seconds;
        proposal {
                dh_group 2;                           #moved
                encryption_algorithm aes128;
                hash_algorithm sha1;
                authentication_method pre_shared_key;
        }
         exchange_mode main;                      #moved
        generate_policy off;                   #duplicated/moved
}

Ви також розібралися, як домогтися руху потоку по обох тунелях?

Дякую за будь-які вказівки.


Ласкаво просимо до Serverfault. Схоже, ви намагаєтеся задати питання в розділі відповідей іншого запитання плаката. Якщо у вас є нове запитання, будь ласка, опублікуйте його як нове запитання, перейшовши на serverfault.com та натиснувши на велику червону кнопку "Задати питання".
vjones

Буду, дякую за подальші дії.
DPfiler
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.