OpenVPN и даље гура старе руте? Проверите шта је учитао

Додате руту, рестартујете сервис, поново се повежете, а табела клијента изгледа исто као пре. Могуће су две различите ствари: сервер никада није учитао вашу измену или клијент никада није инсталирао оно што је добио. Заједнички им је само симптом, па је први корак да откријете који од два случаја имате.

Поређење испод иде од процеса ка споља, јер процес је једини ауторитет о томе која датотека важи.

Датотека коју сте уредили и датотека коју процес чита

Почните од unit-а и командне линије коју је произвео. На systemd домаћину systemctl cat openvpn@server исписује линију ExecStart, а instance unit обично изводи путању конфигурације из имена инстанце, па демон покренут као openvpn@office чита другу датотеку од оног покренутог као openvpn@server. Упоредите то са argv процеса који ради. Алат за управљање конфигурацијом додаје још један начин да се измена изгуби: може да упише исправну датотеку на место које unit никада не помиње, и тада успешно распоређивање изгледа као ништа.

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

Шта сервер гура и шта клијент инсталира

Послата рута мора да прође два филтера. На серверу мора да стоји у учитаној конфигурацији, а не у коментарисаном блоку или у датотеци специфичној за клијента чије се име не поклапа. На клијенту pull мора да буде укључен и ниједан pull-filter не сме да одбаци ту опцију. Повежите се са verbosity 4 и прочитајте послате опције које клијент пријављује: ако се рута налази на тој листи, сервер је обавио свој део, а клијент бира да је не инсталира.

Датотеке специфичне за клијента чест су извор забуне. Датотека названа по common name сертификата гура опције само том клијенту, а разлика од једног знака тихо зауставља гурање, без грешке ни на једној страни. Сервер бележи common name који је видео при повезивању, па упоредите ту вредност са именом датотеке, а не са оним како мислите да се клијент зове.

Послати префикс и повратна рута су различити проблеми

Клијент који намерно игнорише redirect-gateway да би задржао своју локалну интернет путању ствара другу, неповезану празнину. Сонде сервера стижу до адресе тунела, а одговори никада не стижу, јер се одговор упућен на IP тунела сервера рутира кроз обичан подразумевани гејтвеј клијента. Овде није крива послата рута подмреже; недостаје рута која саобраћај за тунелску мрежу сервера враћа назад кроз тунелски уређај.

Додавање те руте на клијенту поправља одговоре на сонде које покреће сервер. Она не замењује послату руту подмреже, и обратно такође важи, јер две описују супротне смерове кретања.

Упоредите табеле на оба краја

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

Држите три идентификатора заједно: путању конфигурације, име unit-а или инстанце и идентитет клијента са којим сте тестирали.

Ова три претварају следећи случај у петоминутну проверу уместо нове истраге, и управо су она потребна колеги када тунел постане туђи проблем.

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