Настройка VPN-подключения к Amazon VPC - маршрутизация
У меня возникли серьезные проблемы с настройкой VPN между нашим офисом и AWS VPC. Кажется, что «туннели» активны, но я не знаю, правильно ли они настроены.
Я использую брандмауэр Netgear VPN Firewall - FVS336GV2.
Если вы видите в прилагаемой конфигурации, загруженной с VPC (конфигурация туннельного интерфейса №3), это дает мне некоторые «внутренние» адреса для туннеля. При настройке туннелей IPsec я использую IP-адреса внутреннего туннеля (например, 169.254.254.2/30) или я использую подсеть внутренней сети (10.1.1.0/24)
Я пробовал оба, когда я пробовал локальную сеть (10.1.1.x), tracert останавливается на маршрутизаторе. Когда я попробовал использовать «внутренние» IP-адреса, tracert к Amazon VPC (10.0.0.x) выходит через Интернет.
Все это подводит меня к следующему вопросу: для этого маршрутизатора, как мне настроить этап 4, статический следующий переход?
Что это за кажущиеся случайными «внутренние» адреса и откуда они были сгенерированы Amazon? 169.254.254.x кажется странным?
С таким устройством VPN находится за брандмауэром?
Я настроил все IP-адреса ниже, чтобы они не были «настоящими». Я полностью осознаю, что это, вероятно, плохо сформулировано. Пожалуйста, дайте мне знать, если есть дополнительная информация / скриншоты, которые помогут.
Amazon Web Services
Virtual Private Cloud
IPSec Tunnel #1
================================================================================
#1: Internet Key Exchange Configuration
Configure the IKE SA as follows
- Authentication Method : Pre-Shared Key
- Pre-Shared Key : ---
- Authentication Algorithm : sha1
- Encryption Algorithm : aes-128-cbc
- Lifetime : 28800 seconds
- Phase 1 Negotiation Mode : main
- Perfect Forward Secrecy : Diffie-Hellman Group 2
#2: IPSec Configuration
Configure the IPSec SA as follows:
- Protocol : esp
- Authentication Algorithm : hmac-sha1-96
- Encryption Algorithm : aes-128-cbc
- Lifetime : 3600 seconds
- Mode : tunnel
- Perfect Forward Secrecy : Diffie-Hellman Group 2
IPSec Dead Peer Detection (DPD) will be enabled on the AWS Endpoint. We
recommend configuring DPD on your endpoint as follows:
- DPD Interval : 10
- DPD Retries : 3
IPSec ESP (Encapsulating Security Payload) inserts additional
headers to transmit packets. These headers require additional space,
which reduces the amount of space available to transmit application data.
To limit the impact of this behavior, we recommend the following
configuration on your Customer Gateway:
- TCP MSS Adjustment : 1387 bytes
- Clear Don't Fragment Bit : enabled
- Fragmentation : Before encryption
#3: Tunnel Interface Configuration
Your Customer Gateway must be configured with a tunnel interface that is
associated with the IPSec tunnel. All traffic transmitted to the tunnel
interface is encrypted and transmitted to the Virtual Private Gateway.
The Customer Gateway and Virtual Private Gateway each have two addresses that relate
to this IPSec tunnel. Each contains an outside address, upon which encrypted
traffic is exchanged. Each also contain an inside address associated with
the tunnel interface.
The Customer Gateway outside IP address was provided when the Customer Gateway
was created. Changing the IP address requires the creation of a new
Customer Gateway.
The Customer Gateway inside IP address should be configured on your tunnel
interface.
Outside IP Addresses:
- Customer Gateway : 217.33.22.33
- Virtual Private Gateway : 87.222.33.42
Inside IP Addresses
- Customer Gateway : 169.254.254.2/30
- Virtual Private Gateway : 169.254.254.1/30
Configure your tunnel to fragment at the optimal size:
- Tunnel interface MTU : 1436 bytes
#4: Static Routing Configuration:
To route traffic between your internal network and your VPC,
you will need a static route added to your router.
Static Route Configuration Options:
- Next hop : 169.254.254.1
You should add static routes towards your internal network on the VGW.
The VGW will then send traffic towards your internal network over
the tunnels.
IPSec Tunnel #2
================================================================================
#1: Internet Key Exchange Configuration
Configure the IKE SA as follows
- Authentication Method : Pre-Shared Key
- Pre-Shared Key : ---
- Authentication Algorithm : sha1
- Encryption Algorithm : aes-128-cbc
- Lifetime : 28800 seconds
- Phase 1 Negotiation Mode : main
- Perfect Forward Secrecy : Diffie-Hellman Group 2
#2: IPSec Configuration
Configure the IPSec SA as follows:
- Protocol : esp
- Authentication Algorithm : hmac-sha1-96
- Encryption Algorithm : aes-128-cbc
- Lifetime : 3600 seconds
- Mode : tunnel
- Perfect Forward Secrecy : Diffie-Hellman Group 2
IPSec Dead Peer Detection (DPD) will be enabled on the AWS Endpoint. We
recommend configuring DPD on your endpoint as follows:
- DPD Interval : 10
- DPD Retries : 3
IPSec ESP (Encapsulating Security Payload) inserts additional
headers to transmit packets. These headers require additional space,
which reduces the amount of space available to transmit application data.
To limit the impact of this behavior, we recommend the following
configuration on your Customer Gateway:
- TCP MSS Adjustment : 1387 bytes
- Clear Don't Fragment Bit : enabled
- Fragmentation : Before encryption
#3: Tunnel Interface Configuration
Outside IP Addresses:
- Customer Gateway : 217.33.22.33
- Virtual Private Gateway : 87.222.33.46
Inside IP Addresses
- Customer Gateway : 169.254.254.6/30
- Virtual Private Gateway : 169.254.254.5/30
Configure your tunnel to fragment at the optimal size:
- Tunnel interface MTU : 1436 bytes
#4: Static Routing Configuration:
Static Route Configuration Options:
- Next hop : 169.254.254.5
You should add static routes towards your internal network on the VGW.
The VGW will then send traffic towards your internal network over
the tunnels.
РЕДАКТИРОВАТЬ # 1
Написав этот пост, я продолжил возиться, и что-то начало работать, только не очень надежно. Локальные IP-адреса для использования при настройке туннелей, в которых действительно находятся мои сетевые подсети. Что еще больше сбивает меня с толку относительно того, для чего предназначены эти «внутренние» IP-адреса.
Проблема в том, что результаты не всегда совпадают. Я могу «иногда» пинговать, я могу «иногда» RDP с помощью VPN. Иногда туннель 1 или туннель 2 может быть вверх или вниз.
Когда я сегодня вернулся к работе, туннель 1 не работал, поэтому я удалил его и заново создал с нуля. Теперь я ничего не могу пинговать, но Amazon И маршрутизатор говорят мне, что туннель 1/2 в порядке.
Я думаю, что оборудование маршрутизатора / VPN, которое у меня есть, просто не подходит для работы ...
РЕДАКТИРОВАТЬ # 2
Теперь туннель 1 активен, туннель 2 не работает (я не менял никаких настроек), и я снова могу пинговать / rdp.
РЕДАКТИРОВАТЬ # 3
Снимок экрана таблицы маршрутов, созданной маршрутизатором. Текущее состояние (туннель 1 все еще работает и идет строка, 2 все еще не работает и повторно не подключается)
Я не думаю, что проблема в том, что одновременно работает только один туннель. Это сделано намеренно; AWS отключает один туннель и подключает его только в случае сбоя другого туннеля. См. Этот текст в документации Windows на AWS.
«Мы предлагаем вам настроить оба туннеля как часть VPN-подключения. Каждый туннель подключается к отдельному концентратору VPN на стороне Amazon VPN-подключения. Хотя работает только один туннель, второй туннель автоматически устанавливается, если первый туннель выходит из строя. Наличие резервных туннелей обеспечивает постоянную доступность в случае сбоя устройства. Потому что одновременно доступен только один туннель, в Консоли управления AWS отображается желтый значок, указывающий, что один туннель не работает. Это ожидаемое поведение, поэтому от вас не требуется никаких действий ".
У меня такая же драма с подключением, как у вас с маршрутизатором Cisco / Linksys IPsec. Этот маршрутизатор отлично работает с несколькими другими системами IPsec, к которым он подключается, например с Cisco ASA, Vyatta и StrongSwan, но у Amazon AWS VPN есть эта проблема с внутренним IP. Для «универсальных» устройств он говорит вам использовать эту внутреннюю нумерацию, но для других платформ, таких как Cisco и Windows, он не упоминает внутреннюю нумерацию. Это работает, только если я проигнорирую внутреннюю нумерацию и настрою свою подсеть и подсеть VPC. Но тогда нет способа сделать этот статический маршрут, и туннель работает только от AWS ко мне, а не в другом направлении.
Обычно я обнаружил, что настроить StrongSwan на t1.micro намного проще, чем использовать AWS VPN.
Я не уверен, но не думаю, что вы сможете сделать это с помощью этого устройства. Руководство по сети AWS VPC требует, чтобы ваш клиентский шлюз был настроен с туннельный интерфейс который связан с туннелем IPSec, и я не вижу эту опцию в Руководство Netgear.
Изменить: вы можете попробовать следующие настройки: (Мастер VPN / IPSec VPN / VPN)
Gateway,
ConnectionName,
<preshared_key>
Remote WAN: 87.222.33.42
Local WAN: 217.33.22.33
Remote LAN: 10.0.0.0
Remote Subnet mask: 255.255.252.0