Un punt final VPN a través de Squid: una excepció estreta per a CONNECT

Squid respon una sol·licitud CONNECT amb la primera línia http_access que coincideix, i aquesta línia pot ser una denegació. Aquest sol fet explica per què una excepció per a un punt final VPN normalment falla al primer intent, perquè la sol·licitud no arriba mai al permís que algú va afegir al final. Una correcció estreta manté les proteccions de port existents i els ensenya una font, una destinació i un port revisats. La resta del proxy es comporta exactament com abans.

Com decideix Squid una sol·licitud CONNECT

Una sol·licitud CONNECT anomena un amfitrió i un port, i Squid recorre les línies http_access en ordre fins que una coincideix. Una denegació coincident acaba l’avaluació immediatament i el client rep un 403 del proxy. Per això la posició d’una regla importa més que la seva redacció. Moure la mateixa línia un pas amunt pot canviar completament el resultat.

Les proteccions convencionals deneguen tot el que queda fora de Safe_ports i deneguen CONNECT fora de SSL_ports. Aquests noms són ACL definides a la vostra pròpia configuració, així que el seu contingut és vostre i no del protocol. Una distribució pot permetre un ventall ampli de ports com a Safe_ports mentre restringeix CONNECT per separat. Llegiu els valors vius abans de suposar que un port està bloquejat per disseny.

Confirmeu que el proxy és el component que rebutja la sol·licitud. Un 403 generat per Squid no s’assembla gens a un avís TLS del servidor VPN, i ajuntar tots dos en un sol problema costa la primera hora. Reviseu la línia del registre d’accés de la sol·licitud, perquè hi consten tant l’acció com la regla que la va produir.

Construïu una coincidència combinada en lloc de tres ACL soltes

Construeu l’excepció a partir de tres fets: un interval de font aprovat, una única adreça de destinació aprovada i l’únic port on escolta el punt final. Dues ACL soltes i una coincidència combinada produeixen una política molt diferent, perquè el que s’avalua és la combinació. Anomeneu l’ACL combinada pel que permet, no pel mètode que porta.

La forma de sota fa servir intervals de documentació que cal substituir per valors revisats. Squid no es reserva cap d’aquests noms, així que són vostres per triar-los i vostres per mantenir-los coherents. Aquesta recepta està limitada a Squid 6 i 7, la configuració documentada dels quals admet el grup all-of. La referència actual marca aquestes directives com a no disponibles a Squid 8, així que tracteu-ho com una recepta lligada a una versió i no com un camí de migració, i comproveu la directiva a la referència de la vostra pròpia versió abans d’aplicar-la.

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

El grup all-of només coincideix quan tots els membres coincideixen, cosa que vol dir que font, destinació i port es comproven en una sola línia. El grup no atorga res per si sol, i una sol·licitud que només coincideix amb dos dels tres fets no el pot satisfer. Aquesta propietat manté l’excepció estreta quan algú afegeix més endavant una segona passarel·la. O la nova destinació s’afegeix deliberadament, o la sol·licitud torna a les proteccions originals.

Doblega les proteccions de port sense eliminar-les

A les seves posicions actuals, les dues línies de protecció convencionals es veuen així. Normalment se situen després de l’autenticació i abans de les línies de política que ho permeten tot.

http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports

Afegiu la coincidència combinada negada a cadascuna, de manera que una excepció coincident sobrevisqui a una protecció que d’altra manera la denegaria. Només canvien les línies de protecció, i només amb un terme addicional cadascuna.

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

Els termes d’una línia d’accés es combinen, així que la línia ara només denega les sol·licituds que fallen tant la comprovació original com l’excepció. Una sol·licitud per al punt final aprovat passa, i qualsevol altra sol·licitud conserva el comportament antic del port. Això és més estret que afegir el port a una llista global SSL_ports, cosa que permetria aquest port a qualsevol destinació. Si el port ja és a la llista, aquesta ACL no estreny res i el permís més antic i ampli continua valent per a altres destinacions, així que llegiu la llista viva abans d’afirmar que l’excepció ha obert el port. També és reversible, perquè dues línies tornen a la forma anterior. La referència de control d’accés documenta l’ordre i les proteccions convencionals de què depèn aquest canvi.

On no s’ha de col·locar l’excepció

La temptació és posar un permís per sobre de les proteccions i donar-ho per acabat. Aquesta col·locació també es salta les proteccions d’autenticació i de destinació local que normalment seuen a prop de dalt d’una configuració operativa. El resultat no és una excepció estreta, és un forat amb un comentari a sobre. Mantingueu qualsevol permís nou a la mateixa etapa revisada que la resta de la política de clients.

Comproveu què necessita encara la sol·licitud després de les proteccions de port. Un compte autenticat, una adreça de client permesa i una política de destinació continuen aplicant-se, i l’excepció no canvia cap d’aquests elements. Si el vostre proxy ja deixa que el compte aprovat arribi a destinacions arbitràries, la protecció de port mai no va ser el control real.

Penseu si el punt final és TCP de bon principi. Una excepció CONNECT transporta fluxos TCP, i un perfil d’OpenVPN que faci servir UDP no esdevindrà abastable a través d’ella. Canvieu el perfil a TCP només si el servidor escolta així i l’operador accepta la diferència de comportament.

Comproveu la frontera amb l’analitzador i una sol·licitud real

Analitzeu la configuració abans de recarregar-la i manteniu una segona sessió oberta mentre ho feu. Un error de sintaxi en recarregar pot deixar el proxy amb la configuració antiga o rebutjar la nova de ple. L’analitzador informa de la línia rebutjada, cosa que és més del que us dirà l’error del client.

Després recarregueu i envieu un CONNECT real a través del proxy des d’una font aprovada. L’execució de l’analitzador va primer, perquè una recàrrega amb una errata no us ensenya res sobre la 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

Proveu tres casos: una font i un compte aprovats, una font no aprovada i una destinació diferent al mateix port. El tercer cas és el que demostra que l’excepció és estreta, perquè exerceix el port sense la coincidència de destinació. Llegiu el registre d’accés per als tres en lloc de confiar en el missatge del client. Un CONNECT correcte estableix un flux TCP i res més, així que l’encaixada de mans VPN continua sent una prova separada.