Жеке қызметті қашықтағы пайдаланушыларға ашқанда екі сұрақ араласып кетеді. Біріншісі — клиенттер қандай атауды қолдануы керек; екіншісі — қызмет қандай дереккөздерді қабылдауы керек. Оларға осы ретпен жауап беріңіз, өйткені қате рұқсат ережесінің артындағы дұрыс атау да сәтсіз болады, ал шешілмейтін атаудың артындағы дұрыс ереже ешқашан тексерілмейді.

Бірінші шарт: клиенттерде қандай resolver жолы бар?

Жеке атау клиенттің resolver-і оған жауап бере алғанда ғана жұмыс істейді. Бұл авторизацияланған қашықтағы клиент аймақты ұстайтын DNS серверіне жетуі керек дегенді білдіреді, не туннель арқылы, не ұйым қашықтағы пайдаланушылар үшін әлдеқашан жүргізіп отырған resolver арқылы. Туннель — тасымал, каталог емес. Ол клиентке resolver-ге жол береді, бірақ қай аймақты сұрау керегін айтпайды.

resolvectl query files.corp.example
dig @10.20.30.10 +short files.corp.example

Жалпыға қолжетімді resolver жеке аймақты ноутбук VPN-ге қосылды деп біліп алмайды.

Жұрнақ та сол көңіл бөлуге лайық. Ұйым бақылайтын доменнің қосымша доменін қолданыңыз, иелік және сертификат жоспары айқын болсын. .local-тен аулақ болыңыз: multicast DNS сипаттамасы бұл жұрнақты link-local шешіміне байланыстырады, ал маршрутталған туннель бұл әрекетті сіз үшін қайталамайды.

Екінші шарт: қызмет қандай дереккөз алады?

Рұқсат ережелері мекенжайларға қарсы жазылады, сондықтан пайдалы сұрақ — маршруттау мен аудармадан кейін қызмет қандай мекенжайды көреді. 10.20.30.40 мекенжайындағы үлгі қызмет үшін кеңсе клиентері 10.20.30.0/24 жақтан келеді, ал қашықтағы клиенттер 10.99.0.0/24 сияқты бөлек пулдан келеді.

Егер шлюз қашықтағы пулды аударса, қызмет аудармашыны көреді, және 10.99.0.0/24 үшін жазылған ереже сәйкес келмейді.

Мұны клиент жағынан емес, қызмет жағынан оқыңыз. Қызмет хостындағы тыңдаушы журналы немесе пакет ұстау нақты келген дереккөзді көрсетеді; клиенттің өз мекенжайы жолдан ненің аман қалғаны туралы болжам ғана.

Үшінші шарт: атау қызметке ме, әлде хостқа ма байланған?

Бір машинаның мекенжайына нұсқайтын атау әр клиентті сол машинаға байланыстырады. Жүктеме теңгерушісіне немесе тұрақты қызмет мекенжайына нұсқайтын атау оның артындағы хосттың ауыстырылуынан аман қалады. Әдейі таңдаңыз, өйткені мұны кейін өзгерту әр клиенттің бетбелгілерін және әр сертификаттың субъектісін өзгертуді білдіреді.

Бір ішкі қызмет үшін тікелей жазба әдетте жақсы және ойлауға жеңіл.

Ауыстырылатын, қайта құрылатын немесе масштабталатын кез келген нәрсе үшін тұрақты алдыңғы жақ қосымша конфигурацияға тұрарлық. Тест қарапайым: егер сіз пайдаланушыларға айтпай-ақ бэкендті ауыстыра алсаңыз, атау қызметке байланған; алмасаңыз, ол хостқа байланған.

Екі шешімді бөлек тексеріңіз

Алдымен шешіңіз, содан кейін қосылыңыз. Күтілетін мекенжайды қайтаратын шешу тесті атау жолын дәлелдейді және рұқсат туралы ештеңе айтпайды. Қосылу тесті жол мен ережені бірге дәлелдейді, сондықтан оны шешу сәтті болғаннан кейін ғана іске қосыңыз.

curl -sv --max-time 5 https://files.corp.example/health

Содан кейін тыйым салынған дереккөзді бір рет тексеріп, нәтижесін жазыңыз.

Құжаттамаңызда екі жазбаны бөлек ұстаңыз: атау және оның аймағы, рұқсат етілген дереккөздер және ереженің иесі. Біреуі өзгерсе, екіншісі өзгеруге міндетті емес.

Шешім әдетте қай жерде қателеседі

Жиі кездесетін ақау — тек кеңсе желісінде шешілетін атаумен жарияланған қызмет және тек кеңсе ауқымын қабылдайтын рұқсат ережесі. Сонда қашықтағы пайдаланушылар бұзылған қызмет туралы хабарлайды, ал шын мәнінде бұл екі бөлек қалтқы. Екінші жиі ақау — керісінше: атау мәселесін кетіру үшін қосылған кең рұқсат ережесі қызметті ешкім ойламаған дереккөздерден қолжетімді етіп қалдырады. Екеуі де конфигурациядағы қалтқы, және пайдаланушы орнынан олар бірдей көрінеді.

Екі қатенің ешқайсысы бір сәтті тесттен көрінбейді. Сондықтан екі шешім бөлек жазбалар мен бөлек тесттерге лайық, тіпті оларды бір адам қабылдаса да.

Қызмет іске қосылмай тұрып екеуін де жазып қойыңыз, өйткені келесі өзгерісті ойлау жеңілірек болады. Жазба қысқа: атау мен оның аймағы үшін бір жол, рұқсат етілген дереккөздер мен ереженің иесі үшін бір жол.

Қатысты мақалалар