Један URL за канцеларију и VPN? Зашто мит о листи дозвољених пропада
VPN веза не мења адресу коју види дозвољени сајт. Проверите стварни излаз, скок поузданог проксија и путању IPv6 пре него што додате URL.
Повежите тунел, отворите исти обележивач и дозвољени сајт одговара тачно као што је одговарао из канцеларије. То је претпоставка на којој већина планова удаљеног приступа тихо почива, и важи само док три одвојене ствари остају истовремено тачне. Ниједна од њих није функција 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 удобним док правило о извору остаје одлука, а не нагађање.