Кой трябва да притежава маршрутите и DNS, когато openfortivpn се свързва?

В работеща сесия на openfortivpn четири етапа се надграждат един върху друг. Клиентът се удостоверява пред шлюза и стартира TLS връзка, след това пуска PPP вътре в тази връзка, после получава адрес и DNS информация и накрая прилага маршрути на хоста и настройки на резолвера. Всеки етап може да е жив, докато следващият не е, и точно затова “свързан” е толкова хлъзгава дума в темите за поддръжка.

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

Четири етапа, които изглеждат като една връзка

Първият етап е допускането. именуван домейн за удостоверяване или еднократен код, и получава параметрите, нужни за продължаване. Когато клиентът отпечата, че е свързан към шлюза, това означава, че TLS транспортът работи. Не означава, че PPP е договорил, и със сигурност не означава, че вътрешно приложение е достъпно.

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

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

Кой редактира таблицата за маршрутизация

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

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

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

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

Кой притежава DNS и файла на резолвера

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

На съвременен Linux хост резолверът може да се управлява от локален stub и презаписването на файла на резолвера зад гърба на този stub създава конфигурация, която изглежда правилна и се държи непоследователно. Ако хостът вече пуска мениджър на резолвера, оставете го да притежава DNS и му подайте сървърите на тунела през поддържания му интерфейс. Опцията no-dns на клиента е правилният избор там, а не заобиколно решение.

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

Привилегии, готовност и предаването

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

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

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