Един служебен IP на всеки OpenVPN възел: какво не прави

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

Защо един и същ адрес на всеки възел работи

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

Адресът е локален етикет, повтарян, а не репликиран. Всеки възел отговаря само за себе си и никой от тях не препраща трафик от името на адреса на друг възел. Това поддържа една клиентска конфигурация валидна, докато сървърите остават независими. Затова и дизайнът не се нуждае от координация между възлите.

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

Задайте го на loopback, а не на тунела

Поставянето на адреса на loopback интерфейс го отделя от живота на всяко тунелно устройство, така че повторно свързване или презареждане на конфигурацията не го премахва. Адресът съществува, докато съществува хостът.

Адрес на lo не е филтър. Услугата все още трябва да слуша на него и защитната стена на хоста все още оценява реалния входящ път, който пристига по тунелния интерфейс. Всеки, който смята, че loopback означава само локално, в крайна сметка или блокира законни клиенти, или излага нещо, което не е имал намерение.

Направете заданието постоянно чрез мрежовата конфигурация на хоста, вместо да го добавяте отново от hook. Hook за настройка няма да се задейства на възел, където не е вдигнат тунел, а адресът на услугата не бива да зависи от активността на тунела. Сложете адреса в конфигурацията на интерфейса, която дистрибуцията ви притежава, след това рестартирайте веднъж и го проверете. Рестартът е единственият тест, който оцелява при последваща промяна на конфигурацията.

ip address show dev lo | grep 10.250.0.1
ip address add 10.250.0.1/32 dev lo

Пуснете един маршрут и имайте предвид една дестинация

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

Проверете какво е инсталирал клиентът, преди да обвинявате услугата.

ip route get 10.250.0.1

За HTTP услуга дайте на адреса име и сертификат за това име. Споделеният IP не е идентичност и не премахва проверката на TLS, нито оправдава копиране на един частен ключ на всеки възел. Име, което се разрешава до споделения адрес, оставя историята със сертификата обикновена и ви позволява да запазите идентичност за всеки възел, ако ви трябва.

Какво не може споделеният адрес

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

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

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

Пазете идентичността на услугата с името

Запишете какво означава адресът: той стига до услугата на възела, с който клиентът е свързан в момента. Това едно изречение предотвратява голяма част от недоразумението, което този модел привлича.

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

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

Ако изискването е наличност, качете се един слой по-нагоре: балансьор на натоварването, име на услуга с проверки за изправност или оркестрационна система, която вече знае как да замени възел.

Решаването на това рано запазва споделения адрес това, което е — удобен етикет, вместо компонент, от който тихо се очаква да върши работа, за която никога не е бил проектиран.