В нашей сети есть выделенное устройство VPN, которое находится внутри офисной сети. У нас есть Cisco ASA со статическим маршрутом, который направляет подсети VPN к устройству VPN. Итак, типичный запрос от клиента к удаленному сайту (192.168.161.28 -> 192.168.101.28) идет:
Client ASA Local VPN Remote VPN Remote Server 192.168.161.28 -> 192.168.161.17 -> 192.168.161.10 -> 192.168.101.1 -> 192.168.101.28
При использовании этого маршрута брандмауэр на удаленной конечной точке VPN 192.168.101.1 отклоняет трехстороннее подтверждение TCP:
Status: A TCP packet was rejected because it has an invalid sequence number or an invalid acknowledgement number
Однако, если я обойду ASA (со статическим маршрутом на клиентских машинах напрямую):
Client Local VPN Remote VPN Remote Server 192.168.161.28 -> 192.168.161.10 -> 192.168.101.1 -> 192.168.101.28
Потоки TCP правильно согласованы, и все идет гладко.
Что бы это могло быть? Есть ли какие-то правила проверки на ASA, которые могли бы это нарушить? Я подозреваю, что это связано с тем, что обратный маршрут трафика отличается от маршрута отправки (т.е. пакеты будут идти напрямую от конечной точки VPN к клиенту, а не через ASA, поскольку они находятся в одной локальной сети).
Отключение рандомизации ACK на ASA решает эту проблему (этот сценарий соответствует Пример B - Множественные пути в Интернет):
access-list tcp_bypass extended permit tcp 192.168.161.0 255.255.255.0 any
class-map tcp_bypass
match access-list tcp_bypass
policy-map tcp_bypass_policy
class tcp_bypass
set connection advanced-options tcp-state-bypass
set connection timeout idle 0:10:00
service-policy tcp_bypass_policy interface inside
Это отстойное решение - убедитесь, что вы прочитали последствия, прежде чем делать это.
Скорее всего, брандмауэр (192.168.101.1) пропускает SYN-ACK, потому что он маршрутизируется по другому маршруту обратно и, поскольку это брандмауэр с отслеживанием состояния, он его отклоняет.
Это обычно называется асимметричной маршрутизацией.