Калі маршруты расшчэпленага тунелю перакрываюцца: які прэфікс перамагае

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

1. Запішыце прызначэнне і крыніцу

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

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

2. Спытайце ядро, які маршрут яно выбрала

Не чытайце табліцу маршрутаў і не рабіце выснову. Задайце тое ж пытанне, што задае стэк, з тым жа адрасам крыніцы: ip route get 10.20.4.10 from 10.8.0.2 у Linux або Find-NetRoute -RemoteIPAddress 10.20.4.10 у PowerShell. Вывад называе маршрут, які будзе фактычна выкарыстаны, і часта гэта не той, якога вы чакалі, чытаючы табліцу.

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

3. Праверце, ці не перанакіравала пошук правіла палітыкі

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

Тут дзве пасткі. Правіла, якое паказвае на пустую табліцу, стварае пошук, што правальваецца да наступнага правіла, таму правіла выглядае так, быццам нічога не робіць. Другая — сам нумар прыярытэту: правілы чытаюцца па ўзрастанні, а ўбудаваныя значэнні — 0 local, 32766 main і 32767 default. Правіла з нумарам ніжэй за 32767 разглядаецца перад правілам па змаўчанні, якое ловіць усё. Правіла з нумарам вышэй за 32767 стаіць за ім і дасягаецца толькі тады, калі ні адна папярэдняя табліца не адказвае, а звычайны маршрут па змаўчанні ў main гэтаму перашкаджае, таму на практыцы яно ніколі не дасягаецца і маўкліва нічога не робіць, выглядаючы ўсталяваным. Калі кліент запісаў правіла і маршрут, праверце абодва і праверце іх яшчэ раз пасля паўторнага падключэння, бо перапісаны профіль можа дадаць другое правіла з іншым прыярытэтам.

4. Аддзяліце роўнасць маршрутаў ад дубляванага плана адрасоў

Часам прэфікс зусім не пры чым. Дзве пляцоўкі, якія выкарыстоўваюць 192.168.1.0/24, азначаюць, што адзін і той жа адрас вызначае два розныя хасты, і ні адзін маршрут не можа іх адрозніць. Маршрут да хоста да аднаго з двух адказаў працуе толькі да таго часу, пакуль другая пляцоўка не адкажа на тое ж імя, і тады выключэнне маўкліва становіцца памылкай.

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

5. Пераканайцеся, што рэзалвер згодны з маршрутам

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

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

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

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

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