Једна VPN крајња тачка кроз Squid: уско CONNECT изузеће

Squid одговара на CONNECT захтев првим редом http_access који се подудара, а тај ред може бити одбијање. Та једна чињеница објашњава зашто изузеће за VPN крајњу тачку обично не успева из првог покушаја, јер захтев никада не стиже до дозволе коју је неко додао на дну. Уско решење задржава постојеће чуваре портова и учи их једном прегледаном извору, одредишту и порту. Све остало на проксију понаша се тачно као пре.

Како Squid одлучује о CONNECT захтеву

CONNECT захтев именује host и порт, а Squid пролази кроз редове http_access редом док се један од њих не подудари. Подударање одбијања одмах прекида процену и клијент добија 403 од проксија. Зато је положај правила важнији од његове формулације. Померање истог реда један корак горе може потпуно променити исход.

Уобичајени чувари одбијају све изван Safe_ports и одбијају CONNECT изван SSL_ports. Та имена су ACL дефинисани у вашој сопственој конфигурацији, па њихов садржај припада вама, а не протоколу. Дистрибуција може да дозволи широк распон портова као Safe_ports док засебно ограничава CONNECT. Прочитајте живе вредности пре него што претпоставите да је порт блокиран по дизајну.

Потврдите да је прокси компонента која одбија захтев. 403 који генерише Squid нимало не личи на TLS упозорење са VPN сервера, а спајање двају у један проблем кошта први сат. Проверите ред приступног дневника за захтев, јер бележи и радњу и правило које ју је произвело.

Направите једно комбиновано подударање уместо три одвојена ACL-а

Изузеће изградите од три чињенице: одобреног распона извора, једне одобрене адресе одредишта и јединог порта на којем крајња тачка слуша. Два одвојена ACL-а и једно комбиновано подударање дају врло различиту политику, јер се процењује управо комбинација. Комбиновани ACL назовите по ономе што дозвољава, а не по методи коју носи.

Облик испод користи документационе распоне које треба заменити прегледаним вредностима. Squid не задржава ниједно од тих имена за себе, па их ви бирате и ви их одржавате усклађеним. Овај рецепт је ограничен на Squid 6 и 7, чија документована конфигурација подржава all-of групу. Тренутна референца означава те директиве недоступнима у Squid 8, па ово третирајте као рецепт везан за верзију, а не као пут миграције, и проверите директиву у референци своје верзије пре примене.

acl pvpn_src src 192.0.2.128/25
acl pvpn_dst dst 198.51.100.77/32
acl pvpn_port port 1194
acl pvpn_ok all-of CONNECT pvpn_port pvpn_dst pvpn_src

all-of група се подудара само када се подудара сваки члан, што значи да се извор, одредиште и порт проверавају у једном реду. Група сама по себи ништа не даје, а захтев који се подудара са само две од три чињенице не може да је задовољи. То својство држи изузеће уским када неко касније дода други пролаз. Или се ново одредиште додаје намерно, или се захтев враћа на изворне чуваре.

Савијте чуваре портова без уклањања

На својим постојећим позицијама два уобичајена реда чувара изгледају овако. Обично стоје после аутентификације и пре редова политике који дозвољавају било шта.

http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports

Додајте негирано комбиновано подударање сваком од њих, тако да подударајуће изузеће преживи чувара који би га иначе одбио. Мењају се само редови чувара, и то само за по један додатни члан сваки.

http_access deny CONNECT !SSL_ports !pvpn_ok
http_access deny !Safe_ports !pvpn_ok

Чланови у једном приступном реду се комбинују, па ред сада одбија само захтеве који падну и на изворној провери и на изузећу. Захтев за одобрену крајњу тачку пролази, а сваки други захтев задржава старо понашање порта. Ово је уже од додавања порта на глобалну SSL_ports листу, што би тај порт дозволило сваком одредишту. Ако порт већ постоји на тој листи, овај ACL ништа не сужава и старије, шире дозволе и даље важе за друга одредишта, па прочитајте живу листу пре него што тврдите да је изузеће отворило порт. Оно је и реверзибилно, јер се два реда враћају у претходни облик. Референца за контролу приступа документује редослед и уобичајене чуваре од којих ова промена зависи.

Где се изузеће не сме поставити

Искушење је ставити дозволу изнад чувара и завршити. Такав смештај прескаче и заштите аутентификације и локалног одредишта које обично стоје при врху радне конфигурације. Резултат није уско изузеће, него рупа с коментаром изнад себе. Сваку нову дозволу држите на истом прегледаном ступњу као и остатак клијентске политике.

Проверите шта је захтеву још потребно након чувара портова. Аутентификовани налог, дозвољена адреса клијента и политика одредишта сви важе и даље, а изузеће не мења ниједно од тога. Ако ваш прокси већ дозвољава одобреном налогу да достигне произвољна одредишта, чувар порта никада није био права контрола.

Размотрите да ли је крајња тачка уопште TCP. CONNECT изузеће преноси TCP токове, а OpenVPN профил који користи UDP неће постати доступан кроз њега. Промените профил на TCP само ако сервер тако слуша и оператер прихвата разлику у понашању.

Проверите границу парсером и стварним захтевом

Парсирајте конфигурацију пре поновног учитавања и држите другу сесију отвореном док то радите. Синтаксна грешка при учитавању може оставити прокси на старој конфигурацији или одбити нову у целини. Парсер пријављује одбијени ред, што је више него што ће вам рећи грешка клијента.

Затим поново учитајте и пошаљите један стварни CONNECT кроз прокси са одобреног извора. Покретање парсера долази прво, јер поновно учитавање са словном грешком не учи вас ничему о политици.

squid -k parse
squid -k reconfigure
curl -v -p -x http://proxy.lab.internal:3128 https://vpn.lab.internal:1194/ --max-time 5

Тестирајте три случаја: одобрени извор и налог, неодобрени извор и друго одредиште на истом порту. Трећи случај доказује да је изузеће уско, јер користи порт без подударања одредишта. Прочитајте приступни дневник за сва три уместо да верујете поруци клијента. Успешан CONNECT успоставља TCP ток и ништа више, па VPN руковање остаје засебан тест.