Една VPN крајна точка преку Squid: тесен CONNECT исклучок

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

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 останува одделен тест.

Поврзани статии