Подовете на GKE загубиха достъп до VPN след 1.14: два начина да оправим източника

След 1.14 подовете стигат до VPN със собствени адреси, затова партньорите изхвърлят отговорите. Изберете договора за източника, после настройте nonMasqueradeCIDRs да съвпада.

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

Има два валидни отговора и те водят до различни места. Изберете договора за източника, преди да редактирате ConfigMap.

Правилото по подразбиране, което спряха да инсталират

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

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

Нищо не е счупено в смисъл на мъртъв компонент. Двете страни просто не са съгласни кой източник е законен.

Изберете източника, който партньорът трябва да вижда

Запазването на адресите на подовете е по-точният договор. Далечната страна вижда натоварването, което е създало трафика, логовете остават честни и политика за всеки под става възможна. Цената е, че партньорът трябва да носи префикса на подовете.

Запазването на адресите на възлите е по-евтиният договор. Включете маскирането отново за тази дестинация и партньорът продължава да вижда адрес, на който вече вярва.

Един въпрос решава между тях: какво прави партньорът с източника? Ако записва в лог, прилага политика за всеки източник или налага тесен обратен маршрут, адресите на подовете оправдават допълнителната конфигурация. Ако трябва само да изпраща отговори, маскирането струва по-малко и не иска нищо от другата страна. Всеки избор е защитим, стига двата екипа да го запишат.

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

Насочете nonMasqueradeCIDRs към реалните диапазони

GKE пуска ip-masq-agent в kube-system и неговият ConfigMap изброява дестинациите, които пропускат маскирането. За да запазите източниците на подовете към тунела, диапазонът на подовете, подмрежата на възлите и локалният префикс всички принадлежат в този списък.

Заменете примерните стойности с диапазони от вашия клъстер. Не правете списъка по-широк от изискването, защото всеки допълнителен запис променя какво вижда някоя друга дестинация. Трите записа по-долу представят мрежата на подовете, подмрежата на възлите и префикса зад тунела:

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 изключва маскирането за всички дестинации, което променя как несвързани натоварвания изглеждат пред външни услуги и рядко е умишлено. Агентът препрочита конфигурацията си на resyncInterval, така че рестарт обикновено не е нужен. Проверете дали подът на агента работи, после отворете монтирания файл вътре в него. Четенето на този файл е това, което доказва, че промяната е стигнала.

Пътят на отговора е другата половина

Маскирането променя източника на заявката и нищо друго. Какъвто и източник да получи партньорът, той все още се нуждае от маршрут обратно до него, а клъстерът все още се нуждае от маршрут към партньора.

Снемане на трафик на VPN шлюза разделя двете повреди бързо. Пакети, които пристигат с адреси на подове и никога не получават отговор, означават, че партньорът няма маршрут за префикса на подовете. Отговор, който се появява на шлюза, но никога не стига до клъстера, означава, че локалният маршрут липсва. Запишете договора в тикета в двата случая: кой източник вижда партньорът и към кой префикс маршрутизира обратно.

Проверявайте отново след всяко обновяване

Поведението на маскирането по подразбиране вече се е променяло веднъж и подмяната на пул от възли може да нулира мрежата на клъстера. Отнасяйте се към договора за източника като към нещо за проверка, а не за приемане.

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

Подобни статии