Захоплення пакету VPN на ASA5505

Виходячи з попереднього питання щодо захоплення пакетів на 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

Намагаючись захопити пакети зовні, я зіставив будь-яке джерело / dest, яке не є 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?

Чи відповідає цей рядок від фактичної конфігурації 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-з'єднання буде продовжуватися через закритий процес. Це витончений процес і не спричинить RST TCP. Якщо одна сторона з'єднання збоїв, це призведе до напіввідкритого з'єднання, але знову ж таки жодна сторона не може виявити це (про що мені відомо), тому жодне RST не буде видано, крім брандмауера. Жодна сторона не повинна надсилати RST через тривале з'єднання в режимі очікування, якщо програмне забезпечення з обох боків (клієнтське програмне забезпечення telnet або програмне забезпечення сервера telnet) не запрограмоване для видачі RST або деякого типу команди припинення для тривалих простоїв.

Як тест (і щоб мати можливість захоплювати зовнішній інтерфейс брандмауера), ви можете розглянути можливість встановлення сеансу telnet на інший сервер (за наявності), який не передає VPN-з'єднання, і дасть йому можливість сидіти в режимі очікування. Ви також можете, можливо, протестувати, встановивши FTP-з'єднання із зовнішнім сервером, який не передає VPN-з'єднання, і нехай він працює в режимі очікування. Якщо ви бачите ту саму поведінку RST, то я думаю, що це безпечна ставка, що саме брандмауер є причиною.

Ви розглянули застосування тайм-ауту TCP для з'єднання між сервером додатків та сервером telnet? Я спробую застосувати його до інтерфейсу вашого ASA, найближчого до вашого додатка, після того, як ви його протестуєте.

Ось приклад: список доступу no_tcp_timeout розширений дозвіл ip об’єкт appserver об’єкт telnetserver

карта класів no_tcp_timeout список відповідності списку доступу no_tcp_timeout

поліс-карта dmz_policy клас no_tcp_timeout

сервісна політика dmz_policy інтерфейс dmz