OpenVPN redirect-gateway: што кожны сцяг робіць з маршрутамі

Падключыцеся з redirect-gateway у профілі, і маршрут вашай машыны па змаўчанні можа знікнуть, падзяліцца на два або застацца дакладна там, дзе быў, у залежнасці ад сцягоў, якія ніхто не чытае двойчы. Опцыя змяняе стан маршрутызацыі і нічога болей, таму адзінае надзейнае сведчанне таго, што яна зрабіла, гэта табліца, якую кліент усталяваў пасля. Далей ідзе табліца пасля падключэння, маршрут, які трымае сам тунель жывым, і трафік IPv6, які дырэктыва ніколі не абяцае пакрыць. Кожны крок гэта каманда, якую вы можаце выканаць на кліенце, пакуль тунель узняты.

Што кожны сцяг робіць з маршрутам па змаўчанні

Без аніякага сцяга опцыя выдаляе звычайны маршрут па змаўчанні і ставіць на яго месца тунель, таму стары шлюз знікае з табліцы, пакуль злучэнне ўзнята. Дадайце def1, і гэты маршрут па змаўчанні застаецца ў спісе, а працу выконваюць два больш вузкія маршруты. Дадайце bypass-dhcp, і маршрут DHCP таксама выжывае, што важна ў сетцы, дзе кліент усё яшчэ павінен дасягаць лакальнага сервера DHCP. Спіс сцягоў на старонцы дапаможніка OpenVPN 2.6 дастаткова кароткі, каб прачытаць яго аднойчы, і кожны пункт змяняе, якія маршруты трапяць у табліцу.

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

def1 перамагае дакладнасцю, не кранаючы вашу сетку па змаўчанні

Два паўмаршруты па змаўчанні разам пакрываюць прастору IPv4, 0.0.0.0/1 і 128.0.0.0/1. Кожны з іх больш канкрэтны, чым 0.0.0.0/0, таму пошук аддае ім перавагу, а сапраўдны маршрут па змаўчанні застаецца ў табліцы для ўсяго, што запытвае найменш канкрэтнае супадзенне.

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

ip route show default
ip route show | grep -E '^(0\.0\.0\.0/1|128\.0\.0\.0/1)'

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

Трымайце канцавы пункт тунеля дасягальным

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

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

ip route get 198.51.100.20

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

Трафік IPv6 працягвае карыстацца сваёй табліцай

Перанакіраванне IPv4 пакідае IPv6 у спакоі, і два сямействы змяняюцца рознымі сцягамі. На хосце з двайным стэкам і працоўным маршрутам v6 па змаўчанні трафік v4 можа цалкам сядзець у тунелі, пакуль кожны пункт прызначэння, здольны да v6, выходзіць праз фізічнае звяно. Хост, які выглядае правільна ў адной табліцы, цячэ ў другой.

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

ip -6 route show default
ip -6 route get 2001:db8::10

Дакажыце, які інтэрфейс выкарыстоўвае праграма

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

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

ip route get 203.0.113.10
curl -s --interface tun0 https://ifconfig.me
curl -s --interface eth0 https://ifconfig.me

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