Ці поўнае тунеляванне прасцейшае за доўгі спіс раздзеленага тунелю?
Спіс выключэнняў, які ахоплівае большасць праграм, — гэта замаскіраванае значэнне па змаўчанні. Палічыце правілы, праверце шлюз, потым перанясіце адзін профіль і праверце абодва краі.
Спіс раздзеленага тунелю пачынаецца з трох праграм і сканчаецца тым, што ахоплівае большую частку машыны, а кожны новы радок — нечы вынятак. У гэты момант спіс ціха стаў значэннем па змаўчанні з дадатковымі крокамі. Поўнае тунеляванне перавяртае парадак: усё ўваходзіць у тунель, калі дакументаванае выключэнне не кажа інакш. Ці гэта прасцей, залежыць ад шлюза і ад лакальных службаў, якія вы зламаеце.
Пачніце з падліку правілаў, якія вы падтрымліваеце
Палічыце запісы, а потым палічыце, колькі з іх маюць названага ўласніка і дату апошняй праверкі. Важны другі лік, бо вынятак, якім ніхто не валодае, немагчыма ацаніць, калі праграма, на якую ён спасылаецца, пераназываецца або замяняецца. Правілы, прывязаныя да шляху выканальнага файла, ціха перастаюць дзейнічаць пасля абнаўлення, і збой выглядае як няўстойлівы VPN, а не як састарэлае правіла. Запішыце спіс, перш чым мець пра яго думку.
Кожны запіс павінен адказаць на тры пытанні: што ламаецца без яго, хто гэта вырашыў і як вы заўважыце, што прычына страціла сілу. Запісы, якія не могуць адказаць на ўсе тры, — кандыдаты на выдаленне, а не на перанос, і выдаленне іх першымі робіць наступнае параўнанне сумленным.
Калі большасць запісаў накіроўвае вялікую долю трафіку, вы ўжо трымаеце поўны тунель з дадатковым цяжарам абслугоўвання. Тады рашэнне пра тое, дзе жыве значэнне па змаўчанні, а не пра тое, ці яно павінна быць.
Праверце, ці вытрымае шлюз значэнне па змаўчанні
Поўнае тунеляванне пераносіць кожны пакет на адну прыладу, што адначасова змяняе загрузку яе працэсара, табліцу conntrack, трансляцыю адрасоў і патрабаванні да выходнай паласы. Шлюз, які спакойна абслугоўваў некалькі ўнутраных падсетак, можа быць не разлічаны на ўсё блуканне карыстальніка. Глядзіце на найбольшую колькасць адначасовых сесій, якую чакаеце, а не на сярэднюю, бо першым ламаецца пік.
ip -s link show dev tun0
conntrack -C
ss -s
Мерце тую ж нагрузку да і пасля змены, а не разважайце ад спецыфікацый. Адна пасляабедзенная гадзіна звычайнага выкарыстання на адной машыне пакажа, ці шлюз блізкі да мяжы, і гэта нічога не каштуе ў параўнанні з выяўленнем гэтага ў панядзелак раніцай.
Праверце таксама MTU шляху ад канца да канца, бо поўнае значэнне па змаўчанні падвяргае кожную праграму максімальнаму памеру пакета тунелю. Праграмы, якія працавалі па-за тунелем, могуць цяпер залежаць ад паводзін фрагментацыі, пра якія вам не даводзілася думаць.
Пераканайцеся, што лакальныя службы і прыватны DNS яшчэ працуюць
Пералічыце тое, што мусіць застацца лакальным, па пратаколе, а не па назве праграмы: пратаколы выяўлення для прынтараў і экранаў, мост разумнага дома, старонка кіравання маршрутызатарам, лакальны сервер распрацоўкі, да якога звяртаюцца па імені, што развязваецца толькі ў лакальнай сетцы. Гэта ламаецца, калі маршрут па змаўчанні пачынае паказваць у тунель, і ламаецца ціха, бо нішто не запісвае памылку на кліенце.
Прыватны DNS — іншая залежнасць. Калі ўнутраныя імёны раней развязваў рэзалютар тунелю, нічога не змяняецца; калі яны развязваліся лакальна, поўнае значэнне па змаўчанні павінна данесці іх да рэзалютара, які ведае зоны. Пасля змены праверце адно ўнутранае імя і адно публічнае, а не мяркуйце, што спіс рэзалютараў перажыў змену.
Запішыце лакальныя выключэнні ў профіль, якому яны належаць. Выключэнне, якое захоўваецца толькі ў нечай памяці, — першае, што губляе наступны перанос.
Перанясіце адзін профіль і праверце межы
Змяніце профіль праз яго ўласную канфігурацыю, а не накладайце новае значэнне па змаўчанні на ручныя маршруты, пакінутыя ранейшымі эксперыментамі. Гэтыя рэшткавыя маршруты — звычайная прычына пераносу, які выглядае працоўным і паводзіць сябе непаслядоўна праз дзень. Трымайце стары профіль даступным, каб адкат быў выбарам, а не перабудовай.
Затым праверце дзве мяжы асобна: што публічныя і прыватныя прызначэнні працуюць абедзве, і што непажаданы трафік не выходзіць па-за тунель. Паспяховая загрузка старонкі даказвае першае і нічога не кажа пра другое.
ip route get 203.0.113.10
ip route get 10.40.8.15
resolvectl query intranet.example
curl -sS -o /dev/null -w "%{remote_ip}\n" https://example.com
Паўтарыце праверку пасля перападлучэння і пасля збою, бо перамыкач, які блакуе трафік падчас разрыву, — гэта іншая ўласцівасць, чым маршрут, які пасля аднаўляецца правільна. Прасьцейшая канструкцыя — тая, чыё рэальнае пакрыццё вы яшчэ можаце патлумачыць пасля змены праграмы або сеткі.