Un único extremo VPN a través de Squid: unha excepción estreita de CONNECT

Squid responde a unha solicitude CONNECT coa primeira liña http_access que coincide, e esa liña pode ser unha denegación. Este único feito explica por que unha excepción para un extremo VPN adoita fallar no primeiro intento, porque a solicitude nunca chega ao permiso que alguén engadiu ao final. Unha corrección estreita conserva as proteccións de porto existentes e ensínalle unha fonte, un destino e un porto revisados. Todo o demais no proxy compórtase exactamente como antes.

Como decide Squid unha solicitude CONNECT

Unha solicitude CONNECT nomea un servidor e un porto, e Squid percorre as liñas http_access en orde ata que unha coincide. Unha denegación coincidente remata a avaliación de inmediato e o cliente recibe un 403 do proxy. Por iso a posición dunha regra importa máis ca a súa redacción. Mover a mesma liña un paso cara arriba pode cambiar por completo o resultado.

As proteccións convencionais denegan todo o que queda fóra de Safe_ports e denegan CONNECT fóra de SSL_ports. Esos nomes son ACL definidas na túa propia configuración, así que o seu contido é teu e non do protocolo. Unha distribución pode permitir unha ampla gama de portos como Safe_ports mentres restrinxe CONNECT por separado. Le os valores vivos antes de supoñer que un porto está bloqueado por deseño.

Confirma que o proxy é o compoñente que rexeita a solicitude. Un 403 xerado por Squid non se parece en nada a unha alerta TLS do servidor VPN, e unir os dous nun só problema custa a primeira hora. Revisa a liña do rexistro de acceso da solicitude, porque rexistra tanto a acción como a regra que a produciu.

Constrúe unha coincidencia combinada en lugar de tres ACL soltas

Constrúe a excepción a partir de tres feitos: un intervalo de fonte aprobado, un enderezo de destino aprobado e o único porto no que escoita o extremo. Dúas ACL soltas e unha coincidencia combinada producen unha política moi distinta, porque o que se avalía é a combinación. Nomea a ACL combinada polo que permite, non polo método que leva.

A forma de abaixo usa intervalos de documentación que cómpre substituír por valores revisados. Squid non reserva ningún destes nomes, así que son teus para escollelos e teus para mantelos coherentes. Esta receita está limitada a Squid 6 e 7, cuxa configuración documentada admite o grupo all-of. A referencia actual marca esas directivas como non dispoñibles en Squid 8, así que trata isto como unha receita ligada a unha versión e non como un camiño de migración, e comproba a directiva na referencia da túa propia versión antes de aplicala.

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

O grupo all-of só coincide cando coincide cada membro, o que significa que fonte, destino e porto se comproban nunha soa liña. O grupo non concede nada por si mesmo, e unha solicitude que só coincide con dous dos tres feitos non pode satisfacelo. Esa propiedade mantén a excepción estreita cando alguén engade despois unha segunda pasarela. Ou o novo destino se engade deliberadamente, ou a solicitude volve ás proteccións orixinais.

Dobra as proteccións de porto sen eliminalas

Nas súas posicións actuais, as dúas liñas de protección convencionais vense así. Adoitan situarse despois da autenticación e antes das liñas de política que o permiten todo.

http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports

Engade a coincidencia combinada negada a cada unha, de xeito que unha excepción coincidente sobreviva a unha protección que doutro modo a denegaría. Só cambian as liñas de protección, e só cun termo adicional cada unha.

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

Os termos dunha liña de acceso combínanse, así que a liña agora só denega as solicitudes que fallan tanto a comprobación orixinal coma a excepción. Unha solicitude para o extremo aprobado pasa, e calquera outra solicitude conserva o comportamento antigo do porto. Isto é máis estreito ca engadir o porto a unha lista SSL_ports global, o que permitiría ese porto a calquera destino. Se o porto xa está nesa lista, esta ACL non estreita nada e o permiso máis antigo e amplo segue aplicándose a outros destinos, así que le a lista viva antes de afirmar que a excepción abriu o porto. Tamén é reversible, porque dúas liñas volven á súa forma anterior. A referencia de control de acceso documenta a orde e as proteccións convencionais das que depende este cambio.

Onde non se debe colocar a excepción

A tentación é poñer un permiso por riba das proteccións e darse por rematado. Esa colocación tamén salta as proteccións de autenticación e de destino local que adoitan estar preto da parte superior dunha configuración operativa. O resultado non é unha excepción estreita, é un burato cun comentario enriba. Mantén calquera permiso novo na mesma etapa revisada que o resto da política de clientes.

Comproba que necesita aínda a solicitude despois das proteccións de porto. Unha conta autenticada, un enderezo de cliente permitido e unha política de destino seguen aplicándose, e a excepción non cambia ningunha delas. Se o teu proxy xa deixa que a conta aprobada chegue a destinos arbitrarios, a protección de porto nunca foi o control real.

Pensa se o extremo é TCP sequera. Unha excepción CONNECT transporta fluxos TCP, e un perfil de OpenVPN que use UDP non se volverá alcanzable a través dela. Cambia o perfil a TCP só se o servidor escoita así e o operador acepta a diferenza de comportamento.

Comproba o límite co analizador e unha solicitude real

Analiza a configuración antes de recargar, e mantén unha segunda sesión aberta mentres o fas. Un erro de sintaxe ao recargar pode deixar o proxy na configuración antiga ou rexeitar a nova de plano. O analizador informa da liña rexeitada, o que é máis do que che dirá o erro do cliente.

Despois recarga e envía unha CONNECT real a través do proxy desde unha fonte aprobada. A execución do analizador vai primeiro, porque unha recarga cun erro tipográfico non che ensina nada sobre a política.

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

Proba tres casos: unha fonte e unha conta aprobadas, unha fonte non aprobada e un destino distinto no mesmo porto. O terceiro caso é o que demostra que a excepción é estreita, porque exercita o porto sen a coincidencia de destino. Le o rexistro de acceso para os tres en lugar de confiar na mensaxe do cliente. Unha CONNECT correcta establece un fluxo TCP e nada máis, así que o aperta de mans VPN segue a ser unha proba aparte.