Следуя за предыдущий вопрос относительно того, как перехватывать пакеты на ASA5505, у меня возникают некоторые трудности с различением, какой трафик прошел через VPN, а какой был сгенерирован самим межсетевым экраном.
Чтобы обозначить проблему, у меня есть приложение, которое подключается к серверу telnet через vpn и получает пакеты сброса, когда отправляет данные после того, как соединение какое-то время бездействовало. Я хотел бы выяснить, откуда происходят эти сбросы; либо это маршрутизатор / telnet-сервер на другой стороне VPN, либо на самом деле ASA5505 моя сторона, за которой находится сервер приложений. Я читал об отключении соединений серии ASA из-за низкого тайм-аута по умолчанию, и я надеюсь, что это проблема.
Я перехватил пакеты на сервере приложений, чтобы определить сброс. Я перехватил пакеты на внутреннем интерфейсе брандмауэра, и сбросы тоже там. Что я не могу сделать, так это захватить пакеты, выходящие из туннеля VPN, чтобы увидеть, есть ли они там тоже. Я попытался захватить все пакеты на внешнем интерфейсе, но пакетов нет вообще, поэтому я предполагаю, что данные VPN не могут быть захвачены через внешний интерфейс. Кто-нибудь знает, как я могу захватить пакеты, как только они выходят из туннеля VPN?
Чтобы перехватить пакеты внутри, я сопоставил на сервере telnet в качестве источника:
capture capture1 interface Inside match tcp 171.28.18.50 255.255.255.255 any
В попытке захватить пакеты извне я сопоставил любой источник / адресат, который не является ssh-соединением, которое я установил для отслеживания захвата:
capture capture2 interface Outside match tcp any neq 22 any neq 22
Строка соединения тайм-аута в конфигурации:
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02
Обновление: следуя предложению Шейна Мэддена, я захватил пакеты ESP и теперь установил, что сброс определенно генерируется ASA. Я сейчас попробую увеличить timeout conn
Обновление: я еще не увеличивал timeout conn но наблюдали за VPN-соединением с помощью графика в ASDM, и кажется, что когда оно простаивает в течение 30 минут, туннель закрывается. Я подозреваю, что когда он закрыт, TCP-соединение прерывается, и при отправке дополнительных данных по соединению через час ASA отвечает сбросом. 30 минут по умолчанию для vpn-idle-timeout. Когда я бегу show run | include vpn-idle-timeout Я ничего не получаю обратно, так что надеюсь, просто нужно решить, как установить vpn-idle-timeout переменная.
Пакеты ESP должны захватывать нормально - они просто не будут очень полезны с точки зрения проверки наличия сброса, поскольку они все еще зашифрованы (что такое ACL или инструкция соответствия на вашем capture выглядит как?).
Попытка сопоставить временные метки пакетов ESP для сброса временных меток пакетов - лучший способ, который я могу придумать, чтобы определить, генерирует ли ASA сбросы.
Тупой вопрос: какой у тебя timeout conn команда на ASA установлена на?
Вы смотрели на применение тайм-аута TCP к соединению между сервером приложений и сервером telnet? Я бы попробовал применить его к интерфейсу ASA, ближайшему к серверу приложений, после того, как вы его протестируете.
Вот пример: список доступа no_tcp_timeout расширенное разрешение ip объект appserver объект telnetserver
карта классов no_tcp_timeout соответствует списку доступа no_tcp_timeout
policy-map класс dmz_policy no_tcp_timeout
сервис-политика dmz_policy интерфейс dmz
Это строка из реальной конфигурации ASA?
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02
Если да, то это ваш ответ, это брандмауэр. TCP не реализует какой-либо механизм для определения, живо ли соединение или нет (о чем я знаю), поэтому клиент и сервер теоретически должны быть полностью удовлетворены поддержанием сеанса, даже если данные не передаются. Любой из них может реализовать пакеты поддержки активности TCP, но это будет иметь эффект, противоположный тому, что вы видите. Подтверждение активности TCP с любой стороны заставит брандмауэр видеть соединение как активное.
Обычное завершение TCP-соединения будет заключаться в том, что хост, инициировавший соединение, отправит FIN на другой конец, что приведет к полузакрытому соединению с точки зрения инициирующей стороны, и (исключая любые проблемы) TCP-соединение будет проходить через закрыть процесс. Это изящный процесс, который не вызовет TCP RST. Если одна сторона соединения выйдет из строя, это приведет к полуоткрытому соединению, но, опять же, ни одна из сторон не сможет обнаружить это (что мне известно), поэтому RST не будет выдан, кроме брандмауэра. Ни одна из сторон не должна отправлять RST из-за длительного простоя соединения, если программное обеспечение на любой стороне (клиентское программное обеспечение telnet или программное обеспечение сервера telnet) не запрограммировано на выдачу RST или некоторого типа команды завершения для длительных простоя соединений.
В качестве теста (и для возможности захвата на внешнем интерфейсе брандмауэра) вы можете рассмотреть возможность установления сеанса telnet с другим сервером (если он доступен), который не передает VPN-соединение, и позволяет ему бездействовать. Вы также, вероятно, можете проверить, установив FTP-соединение с внешним сервером, который не передает VPN-соединение, и пусть он простаивает. Если вы видите такое же поведение RST, я думаю, что можно с уверенностью сказать, что причиной является брандмауэр.