route-gateway — гэта не redirect-gateway: што сапраўды мяняецца

Ваш тунэль падымаецца, прыватная падсетка адказвае, а звычайнае блуканне па-ранейшаму знікае ў VPN, хоць хтосьці выдаліў радок шлюза з профілю. Гэта спалучэнне — адбітак таго, што рэдагавалі не тую дырэктыву. Выдаленае давала кліенту наступны хоп для маршрутаў, якія ён усталёўвае; тое, што працягвала захопліваць трафік, прыйшло з іншага месца і было прасунута серверам. Пакрыццё і наступны хоп — розныя задачы, і толькі адна з іх вырашае, ці выкарыстоўваюць публічныя прызначэнні тунэль.

Выдалены радок быў наступным хопам, а не перамыкачом палітыкі

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

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

Чатыры рычагі, чатыры розныя задачы

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

На практыцы ўсе чатыры часта прыходзяць у адным прасунутым блоку, радок за радком, што робіць іх падобнымі на часткі адной налады. Гэта не так, і даведнік OpenVPN менавіта таму апісвае іх як розныя механізмы. Вызначыць, якое рашэнне вы адмяняеце, — гэта задача; выпраўленне — адзін радок.

Фільтруйце прасунуты радок, пакідайце наступны хоп

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

pull-filter ignore "redirect-gateway"

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

Чытайце пошук, а не табліцу

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

ip route get 10.40.7.25
ip route get 203.0.113.77
ip rule show

Варыянт def1 варта ведаць, бо ён пакідае стары запіс па змаўчанні бачным, пакуль пара паўзмовачных запісаў перамагае ў пошуку. Таму радок 0.0.0.0/0 у вывадзе сам па сабе нічога не даказвае. Пошук адказвае на пытанне, на якое пералік толькі выглядае так, быццам адказвае.

DNS, IPv6 і прыватны маршрут павінны ўсё яшчэ працаваць

Адмова ад аднаго перанакіравання IPv4 нічога не кажа пра рэзалвер, таму прасунутая опцыя DNS можа працягваць адпраўляць запыты ў тунэль, пакуль маршруты выглядаюць правільна. Маршрут па змаўчанні IPv6 можа рабіць тое ж для сямейства адрасоў, якога праверка IPv4 не кранала. Абодва патрабуюць відавочнага рашэння, а не здагадкі. Затым пераканайцеся, што прыватная служба ўсё яшчэ адказвае, бо раздзелены тунэль, які страціў свой прыватны маршрут, — гэта не раздзелены тунэль, а зламаны.

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