Маршруты OpenVPN, якія праштурхоўваюцца, не ўсталёўваюцца: час, правы ці палітыка

Сервер кажа, што праштурхнуў маршрут, кліент кажа, што падключаны, а прызначэнне ўсё яшчэ недасягальнае. Тры прычыны даюць менавіта гэтую карціну. Даданне маршруту выканалася да з’яўлення прылады, кліенту не хапала правоў змяняць табліцу, або палітыка загадала кліенту ігнараваць праштурханыя параметры.

Звонку яны выглядаюць аднолькава і патрабуюць розных выпраўленняў. Чытайце журнал кліента ў тым месцы, дзе прымаецца рашэнне аб маршруце.

Дакажыце, што маршрут адсутнічае, а не проста зламаны

Пачніце з доказу таго, што маршрут адсутнічае, а не зламаны. У Linux ip route show dev tun0 пералічвае тое, што кліент усталяваў на тунельнай прыладзе. У Windows route print або Get-NetRoute паказвае тое ж самае ў выглядзе табліцы.

Маршрут, які існуе, але не перадае трафік, — іншая праблема. Гэта пераносіць даследаванне да правіл перасылкі і міжсеткавых экранаў, а не да ўсталявання маршруту.

Час: даданне выканалася да з’яўлення прылады

Кліент аналізуе PUSH_REPLY сервера пасля таго, як канал кіравання ўзняты, і пасля таго, як ён наладзіў інтэрфейс. Толькі тады ён дакранаецца табліцы маршрутызацыі, выкарыстоўваючы той механізм, які дае платформа. Linux ідзе праз netlink; Windows выкарыстоўвае API, які патрабуе падвышанага токена. Скрыпт або кліент, які дадае маршруты адразу пасля чытання канфігурацыі, можа выканацца да з’яўлення прылады TUN/TAP, і ядро адхіляе даданне.

Тая ж гонка тлумачыць, чаму маршрут, уведзены ўручную, працуе, а аўтаматычны не: да моманту, калі вы яго ўводзіце, інтэрфейс ужо ўзняты.

route-delay існуе для гэтага выпадку, а route-up паказвае скрыпт, які запускаецца пасля наладкі інтэрфейса і маршрутаў. Змяшчайце маршруты, якія залежаць ад адрасу тунеля, у гэты хук, а не на раннюю стадыю.

Правы: хто можа змяняць табліцу

Змяненне табліцы маршрутызацыі Windows патрабуе падвышанага токена. Графічны інтэрфейс, запушчаны звычайным карыстальнікам, можа задаць адрас адаптара праз службу і ўсё роўна не здолець дадаць маршрут. Тады журнал паказвае памылку ў стылі адмовы ў доступе, а не адсутнае праштурхоўванне.

Запуск графічнага інтэрфейса ад імя адміністратара або выкарыстанне кліента на аснове службы змяняе гэты вынік. Планаваная задача, якая запускае кліента без патрэбнага токена, гэтага не робіць.

Праверце пад якім уліковым запісам насамрэч працуе кліент перад любымі зменамі. Версія і рэжым службы вызначаюць, якія прычыны ўвогуле магчымыя, таму запішыце абодва побач з вывадам маршруту.

Палітыка: праштурханыя маршруты можна адкінуць наўмысна

route-nopull прымушае кліента ігнараваць маршруты, якія праштурхоўвае сервер, уключаючы праштурханы маршрут па змаўчанні, пры гэтым адрас тунеля ўсё яшчэ прымаецца. Праштурханыя параметры DNS і DHCP адкідваюцца той жа дырэктывай. Такі кліент не з’яўляецца няспраўным; ён чакае яўных радкоў маршрутаў у сваёй канфігурацыі.

route-noexec — іншы сродак кіравання: ён цалкам спыняе выкананне кліентам змен маршрутаў. Тапалогія, якую кліент не можа адлюстраваць, можа даць падобны вынік, прычым маршрут запісваецца як адхілены, а не дададзены. Чытайце радок журнала, які паведамляе рашэнне, замест таго каб здагадвацца, якая з трох прычын дзейнічае. Затым праверце эфектыўны профіль, бо імпарцёр або інструмент кіравання можа дадаць параметры, якія карыстальнік ніколі не рэдагаваў.

Профіль, які выглядае чыстым у тэкставым рэдактары, можа ўсё яшчэ несці дададзеную дырэктыву падчас выканання.

Параўнайце спіс праштурхоўвання з табліцай

Пасля падключэння пастаўце спіс праштурхоўвання сервера побач з табліцай кліента. У Linux гэта ip route show dev tun0; у Windows — route print або Get-NetRoute. Калі маршрут адсутнічае, спачатку выпраўце ўсталяванне. Калі ён ёсць, а трафік не ідзе, пераходзьце да палітыкі перасылкі і міжсеткавага экрана.

Запішыце версію кліента, уліковы запіс, ад імя якога ён працуе, і тое, ці заснаваны ён на службе. Гэтыя тры факты падкажуць наступнаму чалавеку, якія прычыны выключаныя.