Кој треба да ги поседува рутите и 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 доделува адреси, предвидената рута е присутна и барањето до внатрешен домаќин успева. Потоа запрете го клиентот и потврдете дека секое од тие е отстрането или вратено. Ако домаќинот сѐ уште решава внатрешни имиња или сѐ уште држи рута откако тунелот е затворен, предавањето на сопственоста е нецелосно.