Доменге негізделген VPN маршруттау және IP маршруттары: қайсысы қолайлы?
Бөлінген туннель өрісіндегі хост атауы маршрут емес. Жаңарту, субдомен ауқымы және 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 ағымдағы мекенжай жиынын береді, ал клиенттің байланыстар тізімі ағынды қай интерфейс тасығанын айтады.
Өнім құжаттайтын жаңарту аралығынан кейін қайталаңыз. Егер мекенжай жиыны жылжып, ереже оны ұстамаса, онда сіз нақты мінез-құлықты таптыңыз.
Шешуші саясатын да бөлек ұстаңыз. Домен ережесіне дұрыс атау деректері керек, бірақ ол сұранысқа қай шешуші жауап беретінін өзі шешпейді.