VPN між майданчиками: який напрямок справді потребує правила?

Обидві сторони повідомляють про встановлений тунель, віддалена філія відповідає зі шлюзу, а застосунок усе одно виходить у тайм-аут у користувачів з одного боку. Звичайна порада — додати правило міжмережевого екрана в обох напрямках. Іноді це правильно, іноді дублює вже наявне правило, а іноді саме друге правило ламає стан. Який випадок застосовний, залежить від того, де екран бачить пакет.

Зворотний трафік зі станом змінює число

Міжмережевий екран зі станом записує запит і пропускає відповідь без другого правила, тож схема, якій потрібне лише одне правило, нормальна. Список доступу без стану не має такої пам'яті, і відповідь треба дозволити явно. Обидва варіанти правильні на своїй платформі, тому поради суперечать одна одній.

Прочитайте документацію з пересилання для платформи перед собою і перевірте, чи зберігає редагована політика стан там, де бачить пакет. Явна заборона для встановленого трафіку або порядок правил, який оцінює відповідь раніше за таблицю станів, перетворює робочу схему на загадкову. Кількість правил — деталь реалізації, а вимога в тому, щоб обидва напрямки дозволеної розмови могли завершитися.

Де екран бачить розшифровані пакети

У тунелі на основі політик міжмережевий екран може оцінювати зашифрований пакет до розшифрування і розшифрований пакет після, на різних інтерфейсах. Правило, написане для неправильного інтерфейсу, присутнє, коректне і ніколи не спрацьовує. Так набір правил, скопійований з робочого розгортання, може відмовити на ідентичному обладнанні.

IPsec на основі маршрутів і більшість сучасних реалізацій надають тунельний інтерфейс, тому розшифрований пакет приходить туди і діють звичайні правила інтерфейсу. Підтвердьте, яку модель використовує розгортання, перш ніж копіювати набір правил із посібника, написаного для іншої. Тунельний інтерфейс — це також місце, куди дивляться, коли треба знати, чи пакет узагалі було розшифровано.

Асиметрична маршрутизація ламає припущення

Міжмережевий екран зі станом припускає, що бачить обидві половини розмови. Якщо відповідь повертається через інший шлюз, цей пристрій не зберігає стану запиту і відкидає його згідно з власною політикою. Симптом — односторонній збій, який не виправить жодне правило на боці відправника. Прослідкуйте шлях відповіді перш ніж щось змінювати.

Перевірте маршрут відповіді, перш ніж додавати широке дозвільне правило з обох боків. Терпіти все на кожному інтерфейсі приховує помилку маршрутизації і водночас розширює доступ, а це найгірше з можливих поєднань.

Перевірте обидва напрямки з реальними адресами джерела

Перевіряйте з адресою, яку віддалена сторона справді бачить, бо трансляція може зробити так, що правило джерела ні з чим не збіжиться. Запустіть захоплення на обох шлюзах одночасно.

tcpdump -ni any 'host 10.30.8.15 and tcp port 443'
nft list ruleset | grep -A 8 'chain forward'
ip route get 10.30.8.15
conntrack -L | grep 10.30.8.15

Запит, який з'являється на віддаленому шлюзі з неочікуваною адресою джерела, пояснює правило, яке ніколи не спрацьовує, а відповідь, що приходить на неправильний інтерфейс, пояснює невідповідність стану. Потім перевірте одне призначення в межах схваленого діапазону і одне поза ним, щоб межа була показана, а не припущена.

Запишіть адресу джерела після трансляції, інтерфейс, який використав розшифрований пакет, і правило, що збіглося. Ці три факти відповідають на наступну заявку без повторення всього розслідування.