Перевірка джерела/призначення — це одні ворота, а не весь шлях VPN

VPN завершується на інстансі EC2, ви можете досягти адреси тунелю цього інстанса, а трафік, який мав пройти через нього до іншого приватного хоста, зникає. Це два різні тести, і їх змішування марнує години. Перший питає, чи можете ви досягти інстанса; другий вимагає, щоб він пересилав трафік для призначення, яке не є його власним, що потребує пересилання в Linux, політики брандмауера, маршруту на далекому боці й дозволу на рівні AWS, який не має нічого спільного з гостьовою операційною системою. Ніщо в консолі не звертає уваги на цю різницю. Симптом виглядає як збій маршрутизації, і зазвичай це не так.

Розділіть два тести, перш ніж щось змінювати

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

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

Запишіть шлях, перш ніж торкатися налаштування

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

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

Чотири межі, і перевірка — лише одна з них

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

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

Трансляція змінює те, яке джерело бачить призначення

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

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

Тестуйте з початкового клієнта, потім збережіть зміну

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

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