Два IPsec шлюза без общ IP: какво всъщност прави превключването при отказ

Спрете шлюз A по време на среща и вижте как тунелът се връща през B минута по-късно; връзката работи, видеоразговорът може и да не работи. Това е честната форма на студено превключване при отказ между два IPsec шлюза с независими адреси. Клиентът избира отново крайна точка и изгражда нова връзка, което възстановява достъпността, без да прехвърля криптографското състояние на старата сесия. Проследяването на последователността прави очевидно кои обещания дизайнът може да спази.

Поставете сцената: два адреса, без плаващ IP

Шлюз A отговаря на един достъпен адрес, а шлюз B — на друг. Клиентът има одобрен начин да избере B, когато A го няма, и няма общ външен адрес, който двата шлюза да претендират. В този дизайн виртуален IP означава точно тази обща входна точка, а не вътрешния адрес, зададен на клиент за отдалечен достъп.

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

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

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

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

Какво B може и какво не може да наследи

B може да споделя с A шаблон за конфигурация, сертификатен орган и политика за удостоверяване. Той не може да наследи живите асоциации за сигурност. Сесийните ключове, индексите на параметрите за сигурност и състоянието на последователността принадлежат на връзката, която A и клиентът са установили, и B няма нито едно от тях.

Преместването на това състояние между шлюзовете е истински инженерен проблем, затова документацията на strongSwan за висока достъпност го третира като клъстерен дизайн, а не като конфигурационен флаг. Конкретна клъстерна рецепта не е общ отговор за облачна мрежа и копирането ѝ без поддържащата инфраструктура купува сложност вместо непрекъснатост.

Установяване на нова връзка

С избран B клиентът извършва нов обмен по IKE: нови nonce стойности, нови стойности на Diffie-Hellman, нови идентификатори за получените асоциации. Удостоверяването се извършва отново при B. Ако дизайнът разчита на машинни идентификационни данни, повторното свързване може да е без надзор; ако изисква човешки фактор, някой трябва да присъства, за да завърши превключването.

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

Запазването на същия вътрешен адрес помага на приложения, които очакват стабилна локална идентичност, но не запазва техните сесии. NAT връзките изтичат, TCP връзките се нулират и всичко със собствен таймаут решава самостоятелно дали да опита отново.

Два тунела паралелно са различен дизайн

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

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

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