openfortivpn қосылғанда маршруттар мен DNS-ке кім ие болуы керек?

Жұмыс істеп тұрған openfortivpn сессиясында төрт кезең бірінің үстіне бірі қаланады. Клиент шлюзде аутентификациядан өтіп, TLS қосылымын бастайды, содан кейін сол қосылымның ішінде PPP іске қосады, одан кейін мекенжай мен DNS ақпаратын алады, ақырында хост маршруттары мен resolver параметрлерін қолданады. Әр кезең келесісі жоқ кезде де тірі болуы мүмкін, сондықтан қолдау тақырыптарында “қосылған” сөзі соншалықты сырғымалы.

Шатасудың көбін жоятын шешім — соңғы кезеңге кім ие екендігі. Не VPN клиенті хост өзгерістерін өзі қолданады, не оны басқа компонент жасайды, ал екеуін жартылай араластыру — маршруттар мен resolver файлдарының әртүрлі сессияларды сипаттап қалуының себебі.

Бір қосылымға ұқсайтын төрт кезең

Бірінші кезең — рұқсат. аталған аутентификация домені немесе бір реттік код арқылы, және жалғастыру үшін қажет параметрлерді алады. Клиент шлюзге қосылғанын басып шығарғанда, бұл TLS транспортының жұмыс істеп тұрғанын білдіреді. Бұл PPP келіссөз жүргізді дегенді білдірмейді, және ішкі қолданбаға қол жеткізуге болады дегенді әрине білдірмейді.

Екінші кезең — PPP байланысы. Клиент туннель құрылғысына қарсы PPP процесін бастайды, екі тарап байланыс параметрлері мен мекенжайларды келіседі. Тек содан кейін ғана хост сессия қандай жергілікті және қашықтағы мекенжайларды пайдаланатынын біледі, және тек сонда ғана туннельге бағытталған маршрут мәнді бола алады.

Үшінші кезең — бұл ақпаратты хостқа қолдану, және міне осында иелік маңызды. Клиент маршруттарды қосып, resolver конфигурациясын қайта жаза алады, немесе оған шегінуге және екеуін де сол машинадағы желіні басқаратын нәрсеге қалдыруға болады. Жобаның README файлы мұны бір автоматты мінез-құлық емес, бөлек жауапкершіліктер деп сипаттайды.

Маршруттау кестесін кім өңдейді

Әдепкіде иесі — клиент. Ол физикалық интерфейс арқылы шлюзге маршрут, туннель серіктесі үшін маршрут және сессияға пайдалануға рұқсат етілген желілер үшін маршруттар қосады, содан кейін процесс шыққанда оларды жояды. Бұл әдепкі бір желі менеджері бар және басқа VPN бағдарламалық жасақтамасы жоқ ноутбукте ыңғайлы.

Тапсыруды тек басқа нәрсе шынымен маршруттауға ие болғанда таңдаңыз. Желі менеджерінің интеграциясы, контейнердің желілік атау кеңістігі немесе бүкіл сайт бойынша маршруттау агенті сол префикстерді қалай орнату және тазалау керектігін бұрыннан білуі мүмкін. no-routes опциясын беру сонда екі жазушының бір кесте үшін күресуіне жол бермейді, бұл таза ақау емес, бір ішкі желінің мезгіл-мезгіл жоғалуы түрінде көрінетін жарыс.

Қабаттасу — тапсырудың екінші себебі. Егер итерілген маршруттар жергілікті желі бұрыннан пайдаланатын префиксті қамтыса, клиент қақтығысты сіз үшін шеше алмайды. Біреу бұл префикске туннель арқылы, физикалық байланыс арқылы немесе неғұрлым нақты маршрут арқылы қол жеткізуге болатынын шешуі керек, және бұл шешім топологияға ие адамға тиесілі.

Тазалау — үшіншісі. Маршруттарын жоймай тұрып құлаған клиент сессиядан ұзақ өмір сүретін қара шұңқыр қалдырады, ал келесі қосылым оның үстіне көшірме қосуы мүмкін. Маршруттауға ие болған адам ескі жазбалардың жоғалғанын тексеруге де ие. Бұл тексеруді іске қосу жолының бөлігі етіңіз, міндетті емес тазалау қадамы емес.

DNS пен resolver файлына кім ие

DNS — дәл сол шешім, бірақ шеттері өткірірек. Клиент шлюз немесе PPP серіктесі хабарлаған DNS серверлерін қабылдап, оларды хосттың resolver конфигурациясына жаза алады. Қарапайым машинада бұл дәл сіз қалаған нәрсе, өйткені ішкі атаулар сонда туннель жұмыс істеп тұрғанда ғана шешіледі.

Заманауи Linux хостта resolver-ды жергілікті stub басқаруы мүмкін, ал resolver файлын сол stub-тың артында қайта жазу дұрыс көрінетін, бірақ дәйексіз әрекет ететін конфигурация жасайды. Егер хост resolver менеджерін бұрыннан іске қосып жатса, оған DNS-ке ие болуға рұқсат етіңіз және туннель серверлерін оның қолдау көрсетілетін интерфейсі арқылы беріңіз. Клиенттің no-dns опциясы сонда дұрыс таңдау, айналма жол емес.

Бөлінген DNS — файлды кім жазатынынан бөлек сұрақ. Әр сұранысты туннель арқылы жіберу қарапайым әрі баяу; ол арқылы тек ішкі аймақтарды жіберу көптеген қарапайым клиенттер ұсынбайтын домен бойынша конфигурацияны талап етеді. Клиенттің resolver өзгерістерін қоспас бұрын хостқа қандай мінез-құлық қажет екенін шешіңіз. Мұндағы қате таңдау туннельдің өзі дұрыс болса да атауларды шешу үзілісіне ұқсайды.

Артықшылық, дайындық және тапсыру

Туннель құрылғысын жасау және хост маршруттарын немесе resolver күйін өңдеу жоғары желілік өкілеттікті қажет етеді. Жиі кездесетін қате — сондықтан бәрі root ретінде жұмыс істеуі керек деп қорытынды жасау, оның ішінде браузер немесе туннельді пайдаланатын қолданба. Артықшылықты бөлікті шағын ұстаңыз: клиент және оның конфигурация файлы, әкімшіге тиесілі, ал пайдаланушы қолданбалары әдеттегі тіркелгілерін сақтайды.

Дайындық әр тұтынушы үшін анықталуы керек. Қадағалаушы қызметті клиент процесі жұмыс істеп, туннель құрылғысы бар кезде басталды деп санай алады. Сақтық көшірме тапсырмасы VPN-ды тек оның сақтау соңғы нүктесі туннель арқылы жауап бергенде ғана қолданылады деп санауы керек. Бұлар әртүрлі тексерулер, ал әлсізірекді күштірек мақсатқа пайдалану тым ерте басталатын және мезгіл-мезгіл сәтсіз аяқталатын тапсырмалар тудырады. Таңдалған анықтаманы жазып қойыңыз, өйткені дайындық туралы келіспейтін қадағалаушы мен тапсырма — болуын күтіп тұрған қолдау билеті.

Келісімшартты төрт бақылаумен тексеріңіз: шлюз кезеңі аяқталады, PPP мекенжайларды береді, көзделген маршрут бар және ішкі хостқа сұраныс сәтті болады. Содан кейін клиентті тоқтатып, олардың әрқайсысы жойылғанын немесе қалпына келтірілгенін растаңыз. Егер туннель жабылғаннан кейін хост әлі де ішкі атауларды шешсе немесе әлі де маршрут ұстаса, иелікті тапсыру толық емес.