Ко поседује адресу, руту, DNS и заштитни зид на Linux VPN-у?

Два скрипта која се боре за исту руту уобичајен су облик проблема са Linux VPN-ом који се евидентира као грешка у рутирању. Једна компонента ствара уређај тунела, друга додаје подразумевану руту, трећа преписује конфигурацију resolver-а, а четврта поново учитава правила заштитног зида. Било која од њих може да поништи рад друге, а победник је једноставно она која се извршила последња. Питање на које вреди одговорити није који пакет инсталирати, већ која је компонента надлежна за сваки део стања.

Запишите ову мапу једном, и већина неуспеха при поновном повезивању престаје да буде мистериозна. Важна су четири објекта: уређај и његове адресе, руте и правила политике, DNS конфигурација и заштитни зид.

Уређај и његове адресе

Уређај тунела ствара или менаџер који познаје профил, или демон који је неко покренуо ручно. Оба распореда раде сама за себе; њихово мешање не. Ако профил поседује NetworkManager, нека поседује и уређај, и не покрећите неуправљани OpenVPN процес против истог имена тунела.

Забележите ко уклони уређај када се сесија заврши. Уређај који надживи своју сесију најчешћи је извор застарелих адреса и забуне која следи.

Руте и правила политике

Управо на рутама конфликти власништва чине видљиву штету. Менаџер везе инсталира подразумевану руту за тунел плус специфичнију руту за удаљену мрежу; затим ручно написана скрипта додаје своју подразумевану руту са другом метриком и тихо побеђује или губи зависно од времена. Одлучите који су уноси везани за везу, који су трајна политика и која компонента их освежава после поновног повезивања. Затим држите остале компоненте изван те табеле.

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

DNS је увек засебан власник

Демон resolver-а ради као сопствени процес под сопственим идентитетом, па не наслеђује случајно одлуке рутирања тунела. Када VPN гура DNS сервере, нешто то мора да преведе у конфигурацију за сваку везу коју resolver поштује, и нешто то мора после да уклони.

Мит је овде да писање сервера имена у профил мења куда иду упити. Мења шта се каже resolver-у, не који сокет resolver користи према горе. Тестирајте упитом и претрагом руте уместо да верујете датотеци.

Стање заштитног зида и ко га обнавља

Правила заштитног зида су најчешће преписивани објекат на VPN домаћину. Менаџер може да додаје NAT или правила прослеђивања по вези, док услуга заштитног зида при подизању поново учитава сачувани скуп правила и брише их. Изаберите један орган за политику и учините други његовим потрошачем, или прихватите да рестартовање тихо мења понашање. Изузеци везани за везу припадају датотеци коју учитава исти власник, а не iptables команди откуцаној током решавања проблема.

Ако правила морају да преживе поновно повезивање, реците то експлицитно. Ако не морају, реците и то, јер ће следећи инжењер претпоставити погоднији одговор.

Животни циклус: подизање, поновно повезивање, расклапање

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

За посматрање, ip monitor link address route приказује промене језгра док се дешавају, али извештава о догађајима, а не о намери: избрисана рута ништа не говори о томе који је процес избрисао. Спојите га са мапом власништва, и збуњујуће искључивање постаје кратак списак кандидата.

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