VPN між сайтами працює лише в один бік: дві різні несправності

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

Ця відмінність визначає, які команди варто виконувати.

Дві несправності, які виглядають однаково

У першому випадку хост B надсилає SYN на A, і нічого не повертається. У другому хост A успішно відкриває сеанс, і відповідь зникає на зворотному шляху. Обидва користувачі кажуть, що зв'язок односторонній, і обидва описують пакет, який зник, тож сам опис не може їх розрізнити.

Запитайте, яка сторона почала невдалу спробу. Цей єдиний факт прибирає половину можливих причин.

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

Перший випадок: немає зворотного шляху

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

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

Другий випадок: політика цього ніколи не дозволяла

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

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

Порівняйте до і після на тих самих хостах

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

tcpdump -ni any host 10.20.30.40 and port 445
conntrack -L | grep 10.20.30.40
ip route get 10.20.30.40
swanctl --list-sas

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

Після виправлення повторіть той самий тест з того самого хоста й підтвердьте, що сторонній доступ і далі заборонено. Статус тунелю “established” сам по собі не підтверджує жодного з двох висновків.