Маршрутызацыя VPN па даменах супраць IP-маршрутаў: што падыходзіць?
Імя хоста ў полі split-tunnel — гэта не маршрут. Параўнайце правілы даменаў і яўныя прэфіксы па абнаўленні, ахопу паддаменаў і тым, што адбываецца пры змене DNS.
IP-маршрут супадае з прэфіксам адраса, і ядро ўжывае яго, не задаючы далейшых пытанняў. Правіла VPN на аснове дамена супадае з імем, а значыць, нешта ў стэку павінна вырашыць, якія адрасы гэтае імя цяпер азначае, і падтрымліваць гэтае рашэнне актуальным. Гэта розныя механізмы з рознымі рэжымамі адмоваў, і пастаўшчыкі ўжываюць адно і тое ж слова для абодвух. Параўнанне іх у спісах функцый прапускае сутнасць; параўноўвайце іх па тым, што адбываецца, калі адказ змяняецца.
Карыснае размежаванне — паміж правілам, якое развязае, і правілам, якое не развязае.
З чым насамрэч супадае кожнае правіла
Правіла прэфікса супадае з адрасамі прызначэння ў табліцы маршрутызацыі. Нішто не развязваецца, нішто не сканчаецца, і супадзенне дакладнае для кожнага пакета. Правіла дамена супадае з запытам праграмы на імя, якое RFC 1034 вызначае як дрэва метак, а не адрас. Некаторыя прадукты развязваюць імя аднойчы і ўсталёўваюць атрыманыя адрасы як маршруты, што робіць правіла IP-правілам з далучаным таймерам абнаўлення.
Ведайце, якое з гэтых двух у вас ёсць, перш чым адладжваць, бо адмова выглядае цалкам па-рознаму ў кожным выпадку.
Дзе правіла дамена жыве ў стэку
Калі прадукт рэалізуе правілы даменаў праз лакальны проксі, трафік павінен дасягнуць гэтага проксі, а праграмы, якія ігнаруюць сістэмны проксі, цалкам абыходзяць правіла. Калі ён рэалізуе іх праз развязанне імёнаў і даданне маршрутаў, адрасы свежыя не даўжэй за апошняе абнаўленне. Калі ён перахапляе рэзалвер, паводзіны DNS становяцца часткай палітыкі маршрутызацыі, і рэзервовы рэзалвер можа ціха гэта адмяніць.
Чытайце мадэль пастаўшчыка, а не назву налады. Два кліенты з полем пад назвай Split Tunnel могуць рабіць тры розныя рэчы.
Параўнайце, што ламаецца
Тры рэчы ламаюцца па-рознаму. Зменлівасць адрасоў: імя хоста CDN можа развязацца ў іншы набор адрасоў за хвіліны, таму скапіяваны спіс хутка старэе. Ахоп паддаменаў: правіла для example.com можа ахопліваць api.example.com або не, і дакументацыя звычайна ясна кажа, які выпадак. Збой развязання: калі рэзалвер адмаўляе, кліент, што развязвае, можа перайсці да тунелявання трафіку або да прамой адпраўкі.
Толькі другое — пытанне канфігурацыі. Астатнія два — пытанні дызайну пра тое, колькі прадукт гатовы здагадвацца.
| Behaviour | Prefix rule | Domain rule |
|---|---|---|
| Match basis | destination address | requested name or resolved addresses |
| Staleness | none | depends on refresh policy |
| Subdomain scope | not applicable | product-defined |
| Resolver outage | unaffected | product-defined fallback |
| Where to debug | routing table | client log plus resolver state |
Калі прэфікс — лепшы адказ
Для стабільнай прыватнай падсеткі яўны прэфікс зразумелейшы, хутчэйшы і прасцейшы для аўдыту. Ён таксама перажывае збой рэзалвера, бо нічому не трэба развязвацца. Бярыце правіла дамена, калі сэрвіс размешчаны на хосцінгу, калі адрасы круцяцца або калі вы сапраўды не можаце пералічыць набор прызначэнняў. Не бярыце яго толькі таму, што імя хоста — гэта тое, што вы выпадкова ведаеце.
Здагадачны статычны спіс — горшае з абодвух: ён выглядае дагледжаным і ціха прапускае трафік у той дзень, калі пастаўшчык дадае хост.
Праверце свежым запытам
Праверце халодным запытам пасля звычайнага перападключэння, бо кэшаваная старонка можа ніколі не закрануць правіла. Развяжыце імя, затым праверце, куды насамрэч пайшло злучэнне. dig +short app.example.com дае бягучы набор адрасоў, а спіс злучэнняў кліента паказвае, які інтэрфейс нёс паток.
Паўтарыце пасля інтэрвалу абнаўлення, які дакументуе прадукт. Калі набор адрасоў зрушваецца, а правіла не ідзе за ім, вы знайшлі сапраўдныя паводзіны.
Трымайце палітыку рэзалвера асобна. Правіла дамена патрабуе правільных даных імёнаў, але само па сабе не вырашае, які рэзалвер адказвае на запыт.