Една VPN крайна точка през Squid: тясно изключение за CONNECT

Позволете на един одобрен източник да достигне един VPN шлюз на порт 1194 през Squid, запазете глобалните защити на портовете и докажете, че нищо друго не се е отворило.

Squid отговаря на заявка CONNECT с първия ред http_access, който съвпада, а този ред може да е отказ. Този единствен факт обяснява защо изключение за VPN крайна точка обикновено се проваля от първия опит, защото заявката така и не достига до разрешението, което някой е добавил в края. Тясната поправка запазва съществуващите защити на портовете и ги учи за един прегледан източник, дестинация и порт. Всичко останало на проксито продължава да се държи точно както преди.

Как Squid решава заявка CONNECT

Заявката CONNECT посочва хост и порт, а 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 ръкостискането остава отделен тест.

Подобни статии