Un solo endpoint VPN attraverso Squid: un’eccezione CONNECT ristretta

Squid risponde a una richiesta CONNECT con la prima riga http_access che corrisponde, e quella riga può essere un rifiuto. Questo singolo fatto spiega perché un’eccezione per un endpoint VPN di solito fallisce al primo tentativo, perché la richiesta non arriva mai al permesso che qualcuno ha aggiunto in fondo. Una correzione ristretta mantiene le protezioni di porta esistenti e insegna loro un’origine, una destinazione e una porta riviste. Tutto il resto sul proxy si comporta esattamente come prima.

Come Squid decide una richiesta CONNECT

Una richiesta CONNECT nomina un host e una porta, e Squid percorre le righe http_access in ordine finché una di esse corrisponde. Un rifiuto corrispondente termina subito la valutazione e il client riceve un 403 dal proxy. Per questo la posizione di una regola conta più della sua formulazione. Spostare la stessa riga di un gradino verso l’alto può cambiare completamente il risultato.

Le protezioni convenzionali negano tutto ciò che sta fuori da Safe_ports e negano CONNECT fuori da SSL_ports. Quei nomi sono ACL definite nella tua configurazione, quindi il loro contenuto appartiene a te e non al protocollo. Una distribuzione può consentire un’ampia gamma di porte come Safe_ports limitando CONNECT separatamente. Leggi i valori reali prima di presumere che una porta sia bloccata per progetto.

Verifica che sia il proxy il componente che rifiuta la richiesta. Un 403 generato da Squid non somiglia affatto a un avviso TLS del server VPN, e fondere i due in un unico problema costa la prima ora. Controlla la riga del registro di accesso per la richiesta, perché registra sia l’azione sia la regola che l’ha prodotta.

Costruisci una corrispondenza combinata invece di tre ACL sciolte

Costruisci l’eccezione da tre fatti: un intervallo di origine approvato, un indirizzo di destinazione approvato e l’unica porta su cui ascolta l’endpoint. Due ACL sciolte e una corrispondenza combinata producono politiche molto diverse, perché ciò che viene valutato è la combinazione. Nomina l’ACL combinata per ciò che permette, non per il metodo che porta.

La forma sotto usa intervalli di documentazione che vanno sostituiti con valori rivisti. Squid non si riserva nessuno di questi nomi, quindi sono tuoi da scegliere e tuoi da mantenere coerenti. Questa ricetta è limitata a Squid 6 e 7, la cui configurazione documentata supporta il gruppo all-of. Il riferimento attuale segnala quelle direttive come non disponibili in Squid 8, quindi trattala come una ricetta legata a una versione e non come un percorso di migrazione, e verifica la direttiva nel riferimento della tua versione prima di applicarla.

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

Il gruppo all-of corrisponde solo quando corrisponde ogni membro, il che significa che origine, destinazione e porta sono controllate su una sola riga. Il gruppo non concede nulla da solo, e una richiesta che corrisponde solo a due dei tre fatti non può soddisfarlo. Questa proprietà mantiene l’eccezione ristretta quando qualcuno aggiunge in seguito un secondo gateway. O la nuova destinazione viene aggiunta deliberatamente, oppure la richiesta ricade sulle protezioni originali.

Piega le protezioni di porta senza rimuoverle

Nelle loro posizioni attuali, le due righe di protezione convenzionali appaiono così. Di solito stanno dopo l’autenticazione e prima delle righe di policy che consentono tutto.

http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports

Aggiungi la corrispondenza combinata negata a ciascuna, così un’eccezione corrispondente sopravvive a una protezione che altrimenti la negherebbe. Cambiano solo le righe di protezione, e solo di un termine aggiuntivo ciascuna.

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

I termini su una riga di accesso vengono combinati, quindi la riga ora nega solo le richieste che falliscono sia il controllo originale sia l’eccezione. Una richiesta per l’endpoint approvato passa, e ogni altra richiesta mantiene il vecchio comportamento della porta. Questo è più ristretto che aggiungere la porta a un elenco SSL_ports globale, il che consentirebbe quella porta a ogni destinazione. Se la porta è già presente in quell’elenco, questa ACL non restringe nulla e il permesso più vecchio e più ampio vale ancora per altre destinazioni, quindi leggi l’elenco reale prima di affermare che l’eccezione ha aperto la porta. È anche reversibile, perché due righe tornano alla forma precedente. Il riferimento sul controllo degli accessi documenta l’ordine e le protezioni convenzionali da cui dipende questa modifica.

Dove l’eccezione non va collocata

La tentazione è mettere un permesso sopra le protezioni e considerare finito. Quella collocazione salta anche le protezioni di autenticazione e di destinazione locale che di solito stanno vicino alla cima di una configurazione funzionante. Il risultato non è un’eccezione ristretta, è un buco con un commento sopra. Mantieni ogni nuovo permesso nella stessa fase rivista del resto della policy dei client.

Controlla di cosa ha ancora bisogno la richiesta dopo le protezioni di porta. Un account autenticato, un indirizzo client consentito e una policy di destinazione valgono ancora, e l’eccezione non cambia nessuno di essi. Se il tuo proxy già lascia che l’account approvato raggiunga destinazioni arbitrarie, la protezione di porta non è mai stata il vero controllo.

Chiediti se l’endpoint è TCP. Un’eccezione CONNECT trasporta flussi TCP, e un profilo OpenVPN che usa UDP non diventerà raggiungibile attraverso di essa. Cambia il profilo in TCP solo se il server ascolta così e l’operatore accetta la differenza di comportamento.

Verifica il confine con il parser e una richiesta reale

Analizza la configurazione prima di ricaricare, e tieni aperta una seconda sessione mentre lo fai. Un errore di sintassi al ricaricamento può lasciare il proxy sulla vecchia configurazione o rifiutare quella nuova del tutto. Il parser segnala la riga rifiutata, che è più di quanto ti dirà l’errore del client.

Poi ricarica e invia una vera CONNECT attraverso il proxy da un’origine approvata. L’esecuzione del parser viene prima, perché una ricarica con un errore di battitura non ti insegna nulla sulla policy.

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

Prova tre casi: un’origine e un account approvati, un’origine non approvata e una destinazione diversa sulla stessa porta. Il terzo caso è quello che dimostra che l’eccezione è ristretta, perché esercita la porta senza la corrispondenza di destinazione. Leggi il registro di accesso per tutti e tre invece di fidarti del messaggio del client. Una CONNECT riuscita stabilisce un flusso TCP e nulla di più, quindi la stretta di mano VPN resta un test separato.