Поди GKE втратили доступ до VPN після 1.14: два способи виправити джерело

Після 1.14 поди приходять у VPN зі своїми адресами, тому партнери відкидають відповіді. Виберіть контракт джерела і налаштуйте nonMasqueradeCIDRs відповідно до нього.

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

Є дві слушні відповіді, і вони ведуть у різні місця. Виберіть контракт джерела, перш ніж редагувати ConfigMap.

Правило за замовчуванням, яке перестали встановлювати

Ранні випуски GKE встановлювали правило masquerade, яке замінювало джерела подів адресою вузла щоразу, коли призначення було поза 10.0.0.0/8. VPN-шлюз усередині цього діапазону бачив адресу пода, а все дальше виглядало так, ніби приходить від вузла. Партнери будували списки дозволів і зворотні маршрути навколо адрес вузлів, бо саме це вони спостерігали.

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

Нічого не зламано в сенсі мертвого компонента. Дві сторони просто не згодні, яке джерело законне.

Виберіть джерело, яке партнер має бачити

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

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

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

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

Спрямуйте nonMasqueradeCIDRs на реальні діапазони

GKE запускає ip-masq-agent у kube-system, і його ConfigMap перелічує призначення, які обходять masquerade. Щоб зберегти джерела подів у бік тунелю, діапазон подів, підмережа вузла і локальний префікс усі входять до цього списку.

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

nonMasqueradeCIDRs:
  - 10.12.0.0/14
  - 10.100.0.0/16
  - 172.16.0.0/12
masqLinkLocal: false
resyncInterval: 60s

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

Зворотний шлях — це друга половина

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

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

Перевіряйте знову після кожного оновлення

Поведінка masquerade за замовчуванням уже одного разу змінювалася, а заміна пулу вузлів може скинути мережу кластера. Ставтеся до контракту джерела як до того, що треба перевірити, а не припустити.

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

Схожі статті