Um único endpoint VPN através do Squid: uma exceção CONNECT estreita

O Squid responde a um pedido CONNECT com a primeira linha http_access que corresponde, e essa linha pode ser uma recusa. Este único facto explica porque é que uma exceção para um endpoint VPN costuma falhar à primeira tentativa, porque o pedido nunca chega à autorização que alguém acrescentou no fim. Uma correção estreita mantém as proteções de porta existentes e ensina-lhes uma origem, um destino e uma porta revistos. Tudo o resto no proxy comporta-se exatamente como antes.

Como o Squid decide um pedido CONNECT

Um pedido CONNECT nomeia um anfitrião e uma porta, e o Squid percorre as linhas http_access por ordem até uma delas corresponder. Uma recusa correspondente termina a avaliação de imediato e o cliente recebe um 403 do proxy. É por isso que a posição de uma regra conta mais do que a sua redação. Mover a mesma linha um passo para cima pode mudar o resultado por completo.

As proteções convencionais recusam tudo o que está fora de Safe_ports e recusam CONNECT fora de SSL_ports. Esses nomes são ACL definidas na sua própria configuração, por isso o seu conteúdo é seu e não do protocolo. Uma distribuição pode permitir uma vasta gama de portas como Safe_ports e ao mesmo tempo restringir CONNECT em separado. Leia os valores reais antes de assumir que uma porta está bloqueada por conceção.

Confirme que é o proxy o componente que recusa o pedido. Um 403 gerado pelo Squid não se parece nada com um aviso TLS do servidor VPN, e fundir os dois num só problema custa a primeira hora. Verifique a linha do registo de acesso do pedido, porque regista tanto a ação como a regra que a produziu.

Construa uma correspondência combinada em vez de três ACL soltas

Construa a exceção a partir de três factos: um intervalo de origem aprovado, um endereço de destino aprovado e a única porta em que o endpoint escuta. Duas ACL soltas e uma correspondência combinada produzem uma política muito diferente, porque o que é avaliado é a combinação. Nomeie a ACL combinada pelo que permite, não pelo método que transporta.

A forma abaixo usa intervalos de documentação que têm de ser substituídos por valores revistos. O Squid não reserva nenhum destes nomes, por isso são seus para escolher e seus para manter coerentes. Esta receita está limitada ao Squid 6 e 7, cuja configuração documentada suporta o grupo all-of. A referência atual marca essas diretivas como indisponíveis no Squid 8, por isso trate isto como uma receita ligada a uma versão e não como um caminho de migração, e verifique a diretiva na referência da sua própria versão antes de a aplicar.

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ó corresponde quando todos os membros correspondem, o que significa que origem, destino e porta são verificados numa só linha. O grupo não concede nada por si só, e um pedido que só corresponde a dois dos três factos não o pode satisfazer. Essa propriedade mantém a exceção estreita quando alguém acrescenta mais tarde um segundo gateway. Ou o novo destino é acrescentado deliberadamente, ou o pedido recai sobre as proteções originais.

Dobre as proteções de porta sem as remover

Nas suas posições atuais, as duas linhas de proteção convencionais parecem-se com isto. Costumam ficar depois da autenticação e antes das linhas de política que permitem tudo.

http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports

Acrescente a correspondência combinada negada a cada uma, para que uma exceção correspondente sobreviva a uma proteção que de outro modo a recusaria. Só as linhas de proteção mudam, e apenas com um termo adicional cada uma.

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

Os termos de uma linha de acesso são combinados, por isso a linha agora só recusa os pedidos que falham tanto a verificação original como a exceção. Um pedido para o endpoint aprovado passa, e qualquer outro pedido mantém o comportamento antigo da porta. Isto é mais estreito do que acrescentar a porta a uma lista SSL_ports global, o que permitiria essa porta a qualquer destino. Se a porta já estiver nessa lista, esta ACL não estreita nada e a autorização mais antiga e mais ampla continua a aplicar-se a outros destinos, por isso leia a lista real antes de afirmar que a exceção abriu a porta. Também é reversível, porque duas linhas voltam à forma anterior. A referência de controlo de acesso documenta a ordem e as proteções convencionais de que esta alteração depende.

Onde a exceção não deve ser colocada

A tentação é colocar uma autorização acima das proteções e dar o assunto por encerrado. Essa colocação também salta as proteções de autenticação e de destino local que costumam ficar perto do topo de uma configuração funcional. O resultado não é uma exceção estreita, é um buraco com um comentário por cima. Mantenha qualquer nova autorização na mesma etapa revista que o resto da política de clientes.

Verifique o que o pedido ainda precisa depois das proteções de porta. Uma conta autenticada, um endereço de cliente permitido e uma política de destino continuam a aplicar-se, e a exceção não altera nenhum deles. Se o seu proxy já deixa a conta aprovada alcançar destinos arbitrários, a proteção de porta nunca foi o controlo real.

Considere se o endpoint é sequer TCP. Uma exceção CONNECT transporta fluxos TCP, e um perfil OpenVPN que use UDP não ficará alcançável através dela. Mude o perfil para TCP apenas se o servidor escutar assim e o operador aceitar a diferença de comportamento.

Verifique o limite com o analisador e um pedido real

Analise a configuração antes de recarregar, e mantenha uma segunda sessão aberta enquanto o faz. Um erro de sintaxe ao recarregar pode deixar o proxy na configuração antiga ou recusar a nova por completo. O analisador reporta a linha rejeitada, o que é mais do que o erro do cliente lhe dirá.

Depois recarregue e envie um CONNECT real através do proxy a partir de uma origem aprovada. A execução do analisador vem primeiro, porque um recarregamento com um erro de escrita não lhe 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

Teste três casos: uma origem e uma conta aprovadas, uma origem não aprovada e um destino diferente na mesma porta. O terceiro caso é o que prova que a exceção é estreita, porque exercita a porta sem a correspondência de destino. Leia o registo de acesso para os três em vez de confiar na mensagem do cliente. Uma CONNECT bem-sucedida estabelece um fluxo TCP e nada mais, por isso o aperto de mão VPN continua a ser um teste separado.