Маршрутизация через шлюз в другую подсеть - конструктор межсетевого экрана
вопрос очень похож на тот, который размещен здесь: Маршрутизация через шлюз в другую подсеть
Мой вопрос касается правильных настроек маршрутизации / iptable для следующей топологии сети, которая включает в себя VPN типа «сеть-сеть» между сайтом A и сайтом B.
В клиент-А хочет получить доступ клиент-B, например, веб-сервер размещен на клиент-B. Для простоты я хочу сосредоточиться только на сайте-A. Предположим, что клиент-B имеет vpn-server-B в качестве шлюза.
клиент-А может получить доступ к веб-серверу на клиент-B, если клиент-А использует vpn-server-A в качестве шлюза. Но клиент-А также хочет получить доступ к Интернету через шлюз. Следовательно, клиент-А наборы шлюз-А в качестве шлюза по умолчанию. Так шлюз-А должен перенаправить трафик для 192.168.1.0/24 на vpn-server-A. Я использую конструктор брандмауэра для настройки правил брандмауэра и маршрутизации. Я установил следующее в построителе брандмауэра.
клиент-А может успешно пинговать клиент-B но соединение http (s) не может быть установлено. Заглянув в файл журнала шлюз-А:
Apr 3 21:22:35 gateway-A kernel: [ 5456.799769] RULE 1 -- ACCEPT IN=eth0 OUT=eth0 MAC=00:11:22:33:44:55:00:55:44:33:22:11:08:00 SRC=192.168.0.100 DST=192.168.1.100 LEN=52 TOS=0x02 PREC=0x00 TTL=127 ID=28583 DF PROTO=TCP SPT=53133 DPT=443 WINDOW=8192 RES=0x00 CWR ECE SYN URGP=0
Apr 3 21:22:35 gateway-A kernel: [ 5456.814869] RULE 3 -- DENY IN=eth0 OUT=eth0 MAC=00:11:22:33:44:55:00:55:44:33:22:11:08:00 SRC=192.168.0.100 DST=192.168.1.100 LEN=40 TOS=0x00 PREC=0x00 TTL=127 ID=28584 DF PROTO=TCP SPT=53133 DPT=443 WINDOW=260 RES=0x00 ACK URGP=0
Проблема в том, что шлюз-А не перенаправляет правильно трафик на vpn-server-A. Как последний комментарий в сообщении, указанном выше, следует проверить брандмауэр. Возможно, потребуется дополнительный NAT, но я не понимаю почему. Входящий запрос на доступ к 192.168.1.0/24 по адресу шлюз-А должен быть просто перенаправлен на vpn-server-A.
Вы видите следующие записи брандмауэра:
- Начальный TCP SYN (шаг подтверждения 1): Разрешено.
- Серверный TCP SYN-ACK (шаг квитирования 2): Отсутствует?
- Последующий TCP ACK (шаг квитирования 3): заблокирован.
Это говорит мне о том, что отслеживание соединений на брандмауэре работает не так, как вы могли ожидать. Это говорит о том, что существует проблема с маршрутизацией (подробнее см. Ниже) или проблема с конфигурацией брандмауэра. У меня нет информации / опыта работы с брандмауэром или VPN, которые вы используете, поэтому сложно предложить более подробную информацию.
Проблема с маршрутизацией:
На представленной диаграмме видно, что трафик от клиента A к клиенту B направляется напрямую через соединяющуюся сеть (в незашифрованном виде) (поскольку шлюз клиента A является шлюзом A), а трафик от клиента B к клиенту A маршрутизируется через VPN (поскольку шлюз клиента B - vpn-server-B).
Поскольку VPN-сервер A находится в той же сети, что и клиент A, любой пакет, маршрутизируемый через VPN, будет доставлен непосредственно клиенту A, а НЕ через шлюз-A.
Это означает, что шлюз-A никогда не увидит TCP SYN-ACK от клиента B. Таким образом, что касается шлюза A, соединение между A и B никогда не устанавливается, и дальнейший трафик от клиента A к клиенту B по этому соединению блокируется.
Пинг-трафик в порядке, потому что он выходит незашифрованным и возвращается зашифрованным, но последующие отправленные пакеты идентичны первым, поэтому они обрабатываются так же, как и TCP-соединение, которое требует значительного двунаправленного обмена данными даже для настройки.
Я предлагаю разместить VPN-серверы в отдельных сетях от клиентов (например, 192.168.100.0/24 и 192.168.101.0/24) и создать явные маршруты на серверах шлюза (шлюз-A и шлюз-B), которые направляют трафик для удаленного сеть через VPN. Таким образом, вам не нужно специально настраивать клиентов.