Еден URL за канцеларија и VPN? Зошто митот за дозволената листа пропаѓа

Поврзете го тунелот, отворете ја истата обележувачка, и дозволената страница одговара точно како што одговараше од канцеларијата. Ова е претпоставката на која повеќето планови за далечински пристап тивко се потпираат, и таа важи само додека три одделни работи остануваат вистинити истовремено. Ниту една од нив не е функција на VPN клиентот, и ниту еден DNS запис не може да обезбеди која било од нив. Кога обележувачката не успева дома, прелистувачот ви дава една општа грешка, без разлика дали причината е маршрута што недостига, неодобрена излезна адреса или прокси што го замени изворот за кој известува. Третирањето на тие три како еден проблем е патот по кој мала исправка на политиката се претвора во една недела проширување на дозволените листи.

Дизајнот што преживува контакт со вистинска канцелариска мрежа е потесен од претпоставката: јасна табела на одлуки со три реда, една точка на спроведување што не може да се заобиколи, и тест за одбивање што докажува нешто. Разградувањето на претпоставката доаѓа прво, бидејќи сѐ по него зависи од знаењето кој слој го претставува изворот погрешно.

Митот: поврзувањето не е рутирање

Се воспоставува тунел, и клиентот инсталира маршрути за некое множество префикси. Тоа е сѐ што прави поврзувањето. Дали некое неповрзано HTTPS барање патува низ тунелот, и од која јавна адреса изгледа дека доаѓа кога ќе пристигне, се одлуки што подоцна ги носат други компоненти: табелата за рутирање го избира патот, а излезот го избира изворот.

Затоа канцеларијата и кујнската маса се разликуваат со истиот преносен сметач, истиот профил на прелистувач и истата обележувачка. Во канцеларијата барањето излегува низ одржувана јавна адреса со која операторот на страницата се согласил. Низ целосен тунел може да излезе низ VPN излезот, што е друга адреса и, додека некој не ја додаде, неодобрена. Низ поделен тунел може воопшто да не влезе во тунелот. Само два од тие три патишта некогаш биле дел од договорот со сопственикот на страницата, а третиот не е дефект што треба да се закрпи со дополнителен ред allow.

Три состојби на барањето, два одобрени излези

Запишете ја матрицата пред да допрете огнен ѕид, бидејќи табелата е дизајнот, а правилото е само една негова реализација. Адресите подолу се документациски опсези; заменете ги со свои одржувани вредности и чувајте ги таму каде што сопственикот на страницата може да ги провери.

Токму средниот ред е местото каде повеќето од овие планови се кршат. Важна е адресата што ја гледа уредот за спроведување, не приватната адреса што преносниот сметач ја држи внатре во тунелот и не неговата 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 удобен, додека правилото за изворот останува одлука, а не претпоставка.