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 даректерди бөлүштүрөт, көздөлгөн маршрут бар жана ички хостко сурам ийгиликтүү болот. Андан кийин клиентти токтотуп, алардын ар бири алынып салынганын же калыбына келтирилгенин ырастаңыз. Эгер туннель жабылгандан кийин хост дагы эле ички аттарды чечсе же дагы эле маршрутту кармап турса, ээликти өткөрүп берүү толук эмес.