Къде принадлежи маршрутът в OpenVPN: при клиента или при сървъра?
Гол маршрут в конфигурацията на сървъра променя сървъра, не клиента. Изберете клиентския файл, глобален push или push за отделен клиент и проверете какво е пристигнало.
Добавяте route 10.60.0.0 255.255.255.0 към конфигурацията на сървъра, рестартирате, свързвате отново лаптоп и подмрежата все още е недостъпна от този лаптоп. Редът беше приет, услугата стартира чисто и нищо в журнала не изглежда грешно. Случилото се е, че маршрутът беше инсталиран на машината, която редактирахте: шлюзът вече смята, че може да достигне този префикс, а на клиента нищо не беше казано. Позицията е целият въпрос и има четири места, където може да живее същият ред.
Четирите места и кой получава всяко от тях
Маршрут може да бъде добавен от собствената конфигурация на клиента, предложен на всеки клиент чрез глобален push, предложен на един клиент чрез файл за конкретен клиент или записан в собствения контекст за маршрутизиране на сървъра.
Тези четири случая използват почти идентичен синтаксис и дават напълно различни резултати. Първите три влияят на това какво клиентът изпраща в тунела; четвъртият влияе на това как сървърът достига до мрежа, което е полезно, когато самият сървър се нуждае от път, и вредно, когато бъде сбъркано с разпространение.
Решете кой от четирите искате, преди да напишете реда, след което потвърдете получателя.
| Placement | Effect | Receiver |
|---|---|---|
| Client profile route | Installed by the client at connect | That client only |
Global push "route ..." | Sent to every client that accepts pushed options | All pulling clients |
| Client-specific push | Sent to the matching client context | One identity |
| Server config route, no push | Added to the server's own table | The gateway itself |
Защо голият сървърен маршрут изненадва хората
Конфигурацията на сървъра е първото място, където администраторите гледат, и директива за маршрут там се чете като твърдение за VPN мрежата. Не е. OpenVPN я третира като локална инсталация на маршрут на машината, на която работи демонът, което е точно същият вид промяна, която бихте направили с ip route и после забравили.
Разпространението изисква маршрутът да бъде изпратен чрез push, а push изисква клиентът да го издърпа. Клиент, стартиран с изключени издърпани опции, напълно игнорира предложението. Проверете двата края на това ръкостискане, преди да пренапишете сървърния файл, защото журналът на сървъра няма да се оплаче: от негова страна предложението е изпратено. Приетият маршрут също влиза в сила само при следващо свързване, никога в сесията, в която вече се намирате.
Щом видите двете като отделни операции, отказът престава да е загадъчен: сървърът достига префикса, клиентът не може и двете твърдения са верни едновременно.
Файлове за отделни клиенти и идентичността, на която отговарят
Файлът за конкретен клиент е именуван по идентичността, която сървърът е удостоверил, която по подразбиране е общото име на сертификата. Приятелското име на връзката в настолен клиент не е тази стойност и несъответствието създава файл, който никога не се чете.
Проверете директорията, която сървърът действително използва, след което потвърдете, че името на файла съвпада точно с удостоверената идентичност, включително регистъра на буквите.
grep -n 'client-config-dir' /etc/openvpn/server/server.conf
ls -l /etc/openvpn/ccd/Вътре в този файл маршрутът все още трябва да бъде изпратен чрез push, защото контекстът за конкретен клиент е набор от опции, приложени към сесията на този клиент, а не локална таблица за маршрутизиране. Голият маршрут там има същия проблем като голия маршрут в глобалния файл.
Собственият файл на клиента и инструментът, който го притежава
Маршрут, поставен в конфигурацията на клиента, се инсталира, когато този клиент се свърже, и се премахва, когато се разедини, което е правилният жизнен цикъл за статична дестинация.
Ако профилът се притежава от мрежов мениджър, той може да импортира тези опции веднъж и след това да пази собствено копие. Редактирането на изтегления файл по-късно не променя нищо, което е честа причина за фразата "маршрутът е там, но не се прилага".
Проверете активния профил, а не файла, който сте изтеглили, и проверете импортираните настройки, които мениджърът показва. След това се свържете и попитайте системата кой път използва конкретен адрес, вместо да предполагате, че тунелът е спечелил, защото маршрутът е съществувал в текстов файл.
Проверете на клиента, след което проверете обратния път
Попитайте собствената таблица за маршрутизиране на клиента за дестинацията, а не тази на сървъра. Търсене на един хост вътре в префикса е достатъчно, за да покаже интерфейса и следващия хоп, които ще бъдат използвани.
ip route get 10.60.0.10Ако търсенето сочи към тунела, разпространението е работило и останалият проблем е другаде. Ако сочи към шлюза по подразбиране, маршрутът не е инсталиран, бил е филтриран от опция от страна на клиента или принадлежи на профил, който клиентът не използва.
Да приемем, че разпространението е работило и все още нищо не отговаря: тогава проверете препращането на шлюза, обратния маршрут на отсрещната страна и всяка защитна стена между тях. Маршрутът избира път, той не дава достъп.