Кеңсе мен VPN үшін бір URL? Рұқсат тізімі туралы аңыз неге сәтсіз болады
VPN қосылымы рұқсат етілген сайт көретін мекенжайды өзгертпейді. URL қоспас бұрын нақты шығуды, сенімді прокси секірісін және IPv6 жолын тексеріңіз.
Туннельді қосыңыз, сол бетбелгіні ашыңыз, және рұқсат етілген сайт кеңседен қалай жауап берсе, дәл солай жауап береді. Бұл — қашықтан қатынау жоспарларының көбі үнсіз сүйенетін болжам, және ол тек үш бөлек нәрсе бір уақытта ақиқат болып тұрғанда ғана күшінде. Олардың ешқайсысы VPN клиентінің функциясы емес, және ешбір DNS жазбасы олардың бірін де бере алмайды. Бетбелгі үйде сәтсіз болғанда, браузер сізге бір жалпы қатені береді, себебі жоғалған маршрут, бекітілмеген шығу мекенжайы немесе өзі хабарлайтын көзді алмастырған прокси болсын. Осы үшеуін бір мәселе ретінде қарау — кішкене саясат түзетуінің рұқсат тізімдерін кеңейтудің бір аптасына айналу жолы.
Нақты кеңсе желісімен жанасуға төтеп беретін дизайн болжамнан тар: үш жолды айқын шешім кестесі, айналып өтуге болмайтын бір орындау нүктесі және бірдеңені дәлелдейтін бас тарту тесті. Болжамды бұзу бірінші келеді, өйткені одан кейінгінің бәрі көзді қай қабаттың дұрыс емес көрсететінін білуге байланысты.
Аңыз: қосылу — маршруттау емес
Туннель орнатылады және клиент префикстердің белгілі бір жиынына маршруттар орнатады. Қосылу осының бәрін ғана жасайды. Байланыссыз HTTPS сұрауы туннельден өте ме, және жеткенде қай жария мекенжайдан келген сияқты көрінеді, бұл кейінірек басқа компоненттер қабылдайтын шешімдер: маршрут кестесі жолды таңдайды, ал шығу көзді таңдайды.
Сондықтан кеңсе мен ас үй үстелі бір ноутбукпен, бір браузер профилімен және бір бетбелгімен ерекшеленеді. Кеңседе сұрау сайт операторы келіскен, қызмет көрсетілетін жария мекенжайдан шығады. Толық туннель арқылы ол VPN шығуынан шығуы мүмкін, бұл басқа мекенжай және біреу оны қоспайынша, бекітілмеген. Бөлінген туннель арқылы ол туннельге мүлдем кірмеуі мүмкін. Сол үш жолдың тек екеуі ғана сайт иесімен келісімнің бөлігі болған, ал үшіншісі қосымша allow жолымен жамауға тиіс ақау емес.
Сұраудың үш күйі, екі бекітілген шығу
Файрволға тиіспес бұрын матрицаны жазып шығыңыз, өйткені кесте — дизайн, ал ереже оның бір ғана іске асырылуы. Төмендегі мекенжайлар — құжаттама диапазондары; оларды өз сүйемелденетін мәндеріңізбен ауыстырыңыз және сайт иесі тексере алатын жерде сақтаңыз.
| Request path | Source the site sees | Intended decision |
|---|---|---|
| Office, no tunnel | Office public exit | Admit to the application login |
| Remote, approved full tunnel | Approved VPN egress | Admit to the same login |
| Remote, ordinary connection | Neither approved address | Deny at the network boundary |
Дәл осы ортаңғы жолда бұл жоспарлардың көбі сынды. Маңыздысы — орындаушы құрылғы көретін мекенжай, ноутбук туннель ішінде ұстайтын жеке мекенжай да, оның LAN мекенжайы да емес. 10.8.0.6 сияқты мән жария сайт үшін ештеңе білдірмейді, 192.168.1.44 де солай. Туннель мекенжайы — туннельді мекенжайдаудың бөлшегі, сайт тексере алатын куәлік емес.
Егер VPN-іңіз тұрақты, құжатталған шығуды қамтамасыз ете алмаса, матрицада жарамды ортаңғы жол жоқ, және рұқсат тізімдерінің қандай да бір саны оны ойдан таппайды. Сол сәтте адал нұсқалар — айқын жеке маршруттар арқылы қолжетімді жеке сайт немесе қосымшаның алдындағы сәйкестікті танитын кіру шлюзі. Екеуінің де жария рұқсат тізімінен басқа шарты бар, және екеуін де аудиторға түсіндіру кездейсоқ іске қосылғанша өскен тізімнен оңай.
Көзді шешім қабылданатын жерде оқыңыз
Шектеуді сұрауды аяқтайтын құрылғыға қойыңыз және ешбір баламалы шығу жолы оны айналып өтпейтініне көз жеткізіңіз. Nginx кіру модулі allow және deny директиваларын ретімен бағалайды, бірінші сәйкестік жеңеді, ал қоршаған блоктан мұраланған ережелер location ішінде әлі де қолданылады. Бір жерде тар allow кең allow-дың жанында болса, әдетте кеңі шешеді. Оның бір жолын өңдеуден бұрын сол location үшін толық қолданыстағы конфигурацияны оқыңыз.
server {
listen 443 ssl;
server_name intranet.example.com;
set_real_ip_from 10.20.0.10;
real_ip_header X-Forwarded-For;
real_ip_recursive on;
location /app/ {
allow 203.0.113.24; # office public exit
allow 198.51.100.77; # approved VPN egress
deny all;
proxy_pass http://app_backend;
}
}
Жүктеме теңгерушісінің немесе кері проксидің артында бұл ереже проксиді көреді, егер сіз оған басқаша айтпасаңыз. Қоңырау шалушының мекенжайын тек қолдау көрсетілетін сенімді прокси механизмі арқылы, прокси мекенжайларының айқын тізімімен қалпына келтіріңіз. Бекітілген мекенжайды мәлімдейтін сұрау тақырыбы қоңырау шалушының оған ие екеніне дәлел емес, ал жария тыңдаушыда тексерілмеген жіберілген тақырып рұқсат тізімін әшекейге айналдырады.
Содан кейін мекенжайлардың басқа отбасын тексеріңіз. Тек IPv4-ті қамтитын ережелер жиыны AAAA-да да жауап беретін хост атауы үшін толық емес шешім, ал жұмыс істейтін IPv6 бар клиент сол қосымшаға сіз ешқашан қарап шықпаған жолмен жетеді.
Бөлінген туннель: ешқашан кірмейтін сұрау
Бөлінген туннель тек өз тізіміндегі префикстерді тасымалдайды. Кеңсенің ішкі ішкі желілері әдетте сол тізімге кіреді; жария веб-сайт кірмейді. Браузер атауды шешеді, таңдалған мекенжайды маршрут кестесімен салыстырады, бірақ бәрібір алдынан жергілікті әдепкі шлюзді табады.
Осылайша сұрау пайдаланушының үй байланысынан келеді, қабылданбайды, ал есеп VPN бұзылған деп жазады, бірақ туннель дәл өзі конфигурацияланған істі істеп тұр. Екі түзету заңды: сол межені туннель арқылы өткізіп, бекітілген шығудың оны тасымалдауына жол беріңіз, немесе сайтқа тікелей жететінін мойындап, қашықтағы пайдаланушыларға кіру шлюзі сияқты басқа бекітілген жол беріңіз. Сайттың жария рұқсат тізімін үй мекенжайы кездейсоқ кіргенше кеңейту — ол екеуі де емес, және дизайн орындауға тиіс шекараны алып тастайды. Алғашқы екеуі матрицаны адал ұстайды; үшіншісі одан бір жолды үнсіз жояды.
Бас тартуды дәлелдеңіз, содан кейін қалпына келуді
Кестенің әр жолында тұрған клиенттен шынайы шешімді іске қосатын сұраумен тексеріңіз. Қандай да бір байланыссыз мекенжайды көрсететін бетке қолжетімділікті тексеру ештеңені дәлелдемейді, өйткені ол меже қосымшадан өзгеше жолмен жүруі мүмкін.
curl -sS -o /dev/null -w 'status=%{http_code}
' https://intranet.example.com/app/login
# repeat with the tunnel up, then with it down
tail -f /var/log/nginx/access.log | grep ' /app/'
Шекарадағы кіру жазбасын кесте болжаған нәрсемен салыстырыңыз. Содан кейін туннельді түсіріп, қабылданбауға тиіс жаңа сұрау жасаңыз; әлдеқашан жүктелген бет немесе әлдеқашан ашық байланыс ештеңені де тексермейді. Егер ешбір бас тарту көрінбесе, орындау нүктесі сіз ойлаған жерде емес.
Желіге жіберілгеннен кейін қосымша аутентификациясын сақтаңыз, өйткені кеңсе шығуы мен VPN шығуының әрқайсысы көп адамды білдіреді және ешқайсысы жеке тұлғаны анықтамайды. Пайдаланушыларға нұсқау қысқа болып қалады: бекітілген туннельді көтеріңіз, содан кейін қайталап көріңіз. Бұл бір URL-ды ыңғайлы ұстайды, ал көз ережесі болжам емес, шешім болып қалады.