Мы мигрируем на новый хост jump, мигрируем с машины внутри компании. У нас также есть более 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Здесь не так уж много полезного.
статус впнНастроен только 1 туннель.
статические маршруты vpn Именно отсюда таблица маршрутизации извлекла 172.27.224.0/24адрес.
решение1
Если вы не хотите создавать маршрут для каждого клиента, измените свой маршрут по умолчанию, чтобы отправлять весь трафик через VPN и удалите IGW. Тогда ваш корпоративный маршрутизатор сможет управлять трафиком.
Ваша таблица маршрутизации будет выглядеть следующим образом:
0.0.0.0/0 -> vgw
172.31.254.0/24 -> local
Второй маршрут CIDR выше выглядит странно - он выглядит как подсеть, а не сеть VPC. Вы хотите, чтобы это был ваш VPC CIDR.
Убедившись, что все работает правильно для всего трафика, вы можете добавить конечную точку VPC в свой VPC, если вам нужен доступ к ресурсам AWS, таким как обновления, хранилище S3 и т. д.
решение2
Вышеуказанная настройка верна. Проблема была определена как плохой брандмауэр на корпоративной стороне, который после замены работал просто отлично как конечная точка VPN. Для справки, я настоятельно рекомендую ПРОТИВ брандмауэров бренда WatchGuard. Я возился с ними уже много лет, и они, похоже, уступают по большинству аспектов и в целом глючат.