Мы осуществляем переход на новый узел перехода, переходя с собственной машины. У нас также есть более 100 клиентов, с которыми нам все еще нужно будет общаться через SSH. Их брандмауэры в настоящее время разрешают доступ в наш основной офис через SSH, но не через хост AWS. На миграцию брандмауэров 100+ клиентов требуется время, поэтому, пока это не будет завершено, мы хотим направить весь трафик для этих IP-адресов через уже установленную VPN, чтобы трафик выходил из нашего офиса, а не через Интернет-шлюз (IGW) на Amazon.
В моем образовании мне не хватает некоторых деталей, касающихся маршрутизации, поэтому, если бы кто-нибудь мог мне это объяснить, было бы здорово ...
В VPC есть такая таблица маршрутизации:
0.0.0.0/0 -> igw
172.31.254.0/24 -> local
172.27.0.0/16 -> vgw
8.8.4.4 -> vgw
8.8.4.4 это вторичный DNS-сервер Google, открытый для всех и поддерживающий протокол ICMP, идеально подходящий для тестирования.
traceroutes не показывает переходов. Связь, кажется, умирает после выхода в никуда. Я явно чего-то упускаю, но не знаю чего. Как я могу завершить эту настройку, чтобы весь трафик, отправляемый на виртуальный шлюз (vgw), проходил через VPN?
полная галерея здесь, отдельные изображения ниже
ассоциации подсетей таблицы маршрутизации
распространение таблицы маршрутов
подробности vgw Здесь не так много полезного.
статус vpn Настроен только 1 туннель.
статические маршруты vpn Это то место, где таблица маршрутов вытащила 172.27.224.0/24 адрес от.
Если вы не хотите создавать маршрут для каждого клиента, измените маршрут по умолчанию для отправки всего трафика через VPN и удалите IGW. Тогда ваш корпоративный маршрутизатор сможет управлять трафиком.
Тогда ваша таблица маршрутов будет выглядеть так:
0.0.0.0/0 -> vgw
172.31.254.0/24 -> local
Второй маршрут CIDR выше выглядит странно - он похож на подсеть, а не на сеть VPC. Вы хотите, чтобы это был ваш CIDR VPC.
Убедившись, что это работает правильно для всего трафика, вы можете добавить конечную точку VPC в свой VPC, если вам нужен доступ к ресурсам AWS, таким как обновления, хранилище S3 и т. Д.
Вышеуказанная настройка верна. Было установлено, что проблема заключается в некачественном брандмауэре на корпоративной стороне, который после замены прекрасно функционировал как конечная точка VPN. Для справки, я настоятельно рекомендую ПРОТИВ межсетевых экранов марки WatchGuard. Я уже много лет с ними возился, и они кажутся неполноценными по большинству аспектов и в целом глючными.