Ко би требало да поседује руте и DNS када се openfortivpn повезује?

У радној openfortivpn сесији четири фазе се натрупавају једна на другу. Клијент се аутентификује на порти и започиње TLS везу, затим у тој вези покреће PPP, затим прима адресу и DNS информације, и на крају примењује руте домаћина и подешавања resolver-а. Свака фаза може бити жива док следећа није, и зато је „повезано“ тако клизава реч у темама подршке.

Одлука која уклања највише забуне је ко поседује последњу фазу. Или VPN клијент сам примењује промене на домаћину, или то чини друга компонента, а мешање оба на пола пута је разлог зашто руте и resolver датотеке на крају описују различите сесије.

Четири фазе које изгледају као једна веза

Прва фаза је пријем. именовани домен аутентикације или једнократни код, и добија параметре потребне за наставак. Када клијент испише да је повезан са портом, то значи да је TLS транспорт активан. То не значи да је PPP преговарао, и свакако не значи да је унутрашња апликација доступна.

Друга фаза је PPP веза. Клијент покреће PPP процес према тунелском уређају, и обе стране преговарају о опцијама везе и адресама. Тек након тога домаћин зна које локалне и удаљене адресе сесија користи, и тек тада рута ка тунелу има смисла.

Трећа фаза је примена тих информација на домаћина, и ту је важна својина. Клијент може да дода руте и препише конфигурацију resolver-а, или му се може рећи да се повуче и остави обоје ономе што иначе управља мрежом на том рачунару. Пројектни README описује ово као одвојене одговорности, а не као једно аутоматско понашање.

Ко уређује табелу рутирања

Подразумевано власник је клијент. Додаје руту ка порти кроз физички интерфејс, руту за партнера тунела и руте за мреже које сесија сме да користи, а затим их уклања када процес изађе. То подразумевано је згодно на преносном рачунару са једним мрежним менаџером и без другог VPN софтвера.

Изаберите предају само када нешто друго заиста поседује рутирање. Интеграција са мрежним менаџером, мрежни именски простор контејнера или агент за рутирање целог сајта можда већ знају како да инсталирају и очисте исте префиксе. Предаја опције no-routes тада спречава два писца да се боре за исту табелу, што је трка која се показује као повремени губитак једне подмреже, а не као чист дефект.

Преклапање је други разлог за предају. Ако гурнуте руте укључују префикс који локална мрежа већ користи, клијент не може да реши конфликт уместо вас. Неко мора да одлучи да ли је тај префикс доступан кроз тунел, кроз физичку везу или кроз конкретнију руту, и та одлука припада ономе ко поседује топологију.

Чишћење је треће. Клијент који падне пре него што уклони своје руте оставља црну рупу која надживљава сесију, а следећа веза може да дода дупликат преко ње. Ко поседује рутирање, поседује и проверу да су стари уноси нестали. Учините ту проверу делом путање покретања, а не опционим кораком чишћења.

Ко поседује DNS и resolver датотеку

DNS је иста одлука са оштријим ивицама. Клијент може да прихвати DNS сервере које пријављује порта или PPP партнер и да их упише у конфигурацију resolver-а домаћина. На једноставном рачунару то је тачно оно што желите, јер се унутрашња имена тада решавају само док је тунел активан.

На савременом Linux домаћинству resolver-ом може да управља локални stub, а преписивање resolver датотеке иза леђа тог stub-а ствара конфигурацију која изгледа исправно и понаша се неконзистентно. Ако домаћин већ покреће менаџер resolver-а, дозволите му да поседује DNS и нахраните га серверима тунела кроз његов подржани интерфејс. Опција no-dns клијента је тамо прави избор, а не заобилазни пут.

Подељени DNS је одвојено питање од тога ко пише датотеку. Слање сваког упита кроз тунел је једноставно и споро; слање само унутрашњих зона кроз њега захтева конфигурацију по домену коју већина једноставних клијената не нуди. Одлучите какво понашање домаћин захтева пре него што омогућите промене resolver-а у клијенту. Погрешан избор овде изгледа као прекид решавања имена чак и када је сам тунел у реду.

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

Стварање тунелског уређаја и уређивање рута домаћина или стања resolver-а захтевају повишени мрежни ауторитет. Уобичајена грешка је закључак да зато све мора да ради као root, укључујући прегледач или апликацију која користи тунел. Држите привилеговани део малим: клијент и његова конфигурациона датотека, у власништву администратора, док корисничке апликације задржавају свој нормални налог.

Спремност треба дефинисати по потрошачу. Надгледник може да сматра услугу покренутом када клијентски процес ради и тунелски уређај постоји. Задатак резервне копије треба да сматра VPN употребљивим само када његова крајња тачка складиштења одговара кроз тунел. То су различите провере, а коришћење слабије за јачу сврху ствара послове који почињу прерано и повремено не успевају. Запишите изабрану дефиницију, јер надгледник и задатак који се не слажу око спремности су тикет за подршку који чека да се догоди.

Тестирајте уговор са четири запажања: фаза порте се завршава, PPP додељује адресе, предвиђена рута је присутна и захтев ка унутрашњем домаћинству успева. Затим зауставите клијента и потврдите да је свако од тога уклоњено или враћено. Ако домаћин и даље решава унутрашња имена или и даље држи руту након затварања тунела, предаја власништва је непотпуна.