Squid를 통한 VPN 엔드포인트 하나: 좁은 CONNECT 예외

Squid는 CONNECT 요청에 처음 일치하는 http_access 줄로 응답하며, 그 줄이 거부일 수도 있습니다. 이 한 가지 사실은, 요청이 맨 아래에 누군가 추가한 허용에 결코 도달하지 않기 때문에 VPN 엔드포인트 예외가 보통 첫 시도에서 실패하는 이유를 설명합니다. 좁은 수정은 기존 포트 가드를 유지하면서 검토된 출처, 목적지, 포트 하나를 그 가드에 가르칩니다. 프록시의 나머지 동작은 이전과 정확히 같습니다.

Squid가 CONNECT 요청을 판단하는 방식

CONNECT 요청은 호스트와 포트를 지정하고, Squid는 http_access 줄을 순서대로 훑어 일치하는 줄을 찾습니다. 일치한 거부는 평가를 즉시 끝내고 클라이언트는 프록시에서 403을 받습니다. 그래서 규칙의 위치가 문구보다 중요합니다. 같은 줄을 한 단계 위로 옮기는 것만으로 결과가 완전히 달라질 수 있습니다.

관례적인 가드는 Safe_ports 밖의 모든 것을 거부하고 SSL_ports 밖의 CONNECT를 거부합니다. 그 이름들은 자신의 설정에 정의된 ACL이므로 그 내용은 프로토콜이 아니라 여러분의 것입니다. 배포판에 따라 Safe_ports로 넓은 포트 범위를 허용하면서 CONNECT를 따로 제한할 수 있습니다. 포트가 설계상 차단되었다고 가정하기 전에 실제 값을 읽어 보십시오.

요청을 거부하는 구성 요소가 프록시인지 확인하십시오. Squid가 만든 403은 VPN 서버의 TLS 경고와 전혀 닮지 않았고, 둘을 하나의 문제로 합치면 첫 한 시간을 잃습니다. 요청의 액세스 로그 줄은 수행된 동작과 그것을 만든 규칙을 모두 기록하므로 확인하십시오.

느슨한 ACL 셋 대신 결합된 일치 하나를 만드십시오

예외는 승인된 출처 범위, 승인된 목적지 주소 하나, 그리고 엔드포인트가 수신 대기하는 단 하나의 포트라는 세 가지 사실로 구성합니다. 느슨한 ACL 둘과 결합된 일치 하나는 매우 다른 정책을 만드는데, 평가되는 것이 바로 결합이기 때문입니다. 결합 ACL은 그것이 나르는 메서드가 아니라 허용하는 내용으로 이름 붙이십시오.

아래 형태는 검토된 값으로 바꿔야 하는 문서용 범위를 사용합니다. Squid는 이 이름들 중 어느 것도 예약하지 않으므로 고르는 것도 일관되게 유지하는 것도 여러분의 몫입니다. 이 방법은 all-of 그룹을 지원하는 설정이 문서화된 Squid 6과 7로 한정됩니다. 현재 참조는 그 지시문들을 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 스트림을 나르며, UDP를 쓰는 OpenVPN 프로필은 그것을 통해 도달할 수 없게 됩니다. 서버가 그렇게 수신 대기하고 운영자가 동작 차이를 받아들일 때만 프로필을 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 핸드셰이크는 별도의 시험으로 남습니다.