Ubuntu 업그레이드 후 OpenVPN 연결이 끊긴 이유

지난주까지 작동하던 VPN 프로필이 Ubuntu 릴리스 업그레이드 후 깨지고, 로그는 업그레이드를 거의 언급하지 않습니다. 로그가 지목하는 것은 실패한 계층입니다. TLS 핸드셰이크, 데이터 채널용으로 협상된 암호, 설치된 패키지, 또는 바이너리가 시작할 때 불러오는 OpenSSL 사본입니다. 계층마다 오류의 모양과 수리가 다르므로 분류가 첫 번째 일이고 편집이 두 번째 일입니다. 로그가 지목할 때까지 프로필은 무죄로 보십시오.

어느 계층이 실패했나: 핸드셰이크, 암호, 패키지, 라이브러리

프로필을 건드리기 전에 클라이언트 로그를 읽으십시오. 출력의 가장 이른 오류 가 계층을 식별합니다. 그 뒤에 찍히는 것은 대개 그 첫 실패의 결과입니다. 클라이언트가 아예 시작하지 않는다면 VPN 로그는 열어 볼 파일이 아닙니다.

인증서와 서명에 대한 불만, 또는 키 길이에 대한 메시지는 제어 채널과 그것을 규율하는 라이브러리 정책에서 옵니다. 반면 DEPRECATED OPTION 로 시작하는 경고는 데이터 채널 협상에 속합니다.

이런 줄은 Unrecognized option 세 번째 범주입니다. 새 바이너리는 예전 바이너리가 용인하던 지시문을 더 이상 받지 않으므로 라이브러리를 풀어 주는 대신 프로필을 다시 써야 합니다. 패키지 실패는 또 달라 보입니다. 터널 코드가 돌기 전에 일어나기 때문입니다. 빠진 바이너리, 로드되지 않는 플러그인, 잘못된 코드명을 가리키는 저장소가 모두 그 모양을 만듭니다. 네 가지 증상, 살펴볼 네 곳, 그리고 수리들 사이의 겹침은 거의 없습니다.

핸드셰이크가 실패하면 TLS 정책이 인증서를 거부한다

Ubuntu 22.04는 시스템을 OpenSSL 3로 옮겼고, 그 갈래의 기본 보안 수준은 인증서 서명과 키 크기에 대해 20.04보다 엄격합니다. 오래된 다이제스트로 서명된 CA 인증서나 현재 임계값 아래의 키는 이제 핸드셰이크 중에 실패합니다. 아직 아무것도 인증되지 않았으므로 오류는 잘못된 비밀번호나 죽은 서버처럼 읽힙니다.

좁은 수리는 암호 문자열을 이 연결에만 붙입니다. 데스크톱 편집기에서 프로필을 열고 고급 설정으로 가서 DEFAULT:@SECLEVEL=0 를 TLS 암호 필드에 넣으십시오. NetworkManager 키 파일은 [vpn] 아래에서 같은 값을 받습니다:

[vpn]
tls-cipher=DEFAULT:@SECLEVEL=0

NetworkManager를 다시 시작하고 다시 연결하십시오. 데몬이 파싱한 프로필을 캐시하므로 그렇게 하지 않으면 이미 가진 사본을 계속 사용합니다. 이 줄을 남기기 전에 무엇을 하는지 아십시오. 그 설정은 암호 이름이 아니라 여러 인증서와 키 매개변수에 걸친 임계값이므로, 낮추면 단일 프로필이 받아들이는 범위가 넓어집니다. 어느 서버가 그것을 요구했는지 적고, 운영자가 최신 자료를 다시 발급하면 설정을 버리십시오. 반면 /etc/ssl/openssl.cnf 를 바꾸면 그 파일을 읽는 모든 프로그램에 같은 임계값이 적용되어 VPN보다 훨씬 멀리 미칩니다.

OpenVPN 2.6은 협상용 암호 목록을 요구한다

Ubuntu 22.10은 OpenVPN 2.6을 실었고, 그 릴리스에서 --cipher 는 데이터 채널을 스스로 고르지 않습니다. 암호는 협상된 data-ciphers 목록에도 있어야 하며, 그렇지 않으면 클라이언트가 사용 중단 경고를 찍고 터널을 올리지 못합니다.

같은 시기의 NetworkManager 플러그인은 여전히 옛 지시문만 썼습니다. 이 세부가 진단을 가릅니다. 손으로 고친 프로필이 셸에서는 연결되고 데스크톱 애플릿에서는 여전히 실패할 수 있기 때문입니다. 목록을 연결 파일의 [vpn] 아래에 추가하십시오:

data-ciphers=AES-256-CBC

기억하는 값이 아니라 서버가 알리는 값을 쓰십시오. AES-256-GCM을 내세우는 서버는 CBC만 이름 붙인 클라이언트 목록과 협상하지 않습니다. 관리자를 다시 시작하고 다시 연결한 뒤, 셸에서 암호를 협상과 대체 모두에 명시해 시도를 반복하십시오:

sudo openvpn --config client.ovpn --data-ciphers AES-256-CBC --data-ciphers-fallback AES-256-CBC

그 명령이 터널을 올린다면 서버, 인증서, 자격 증명이 모두 온전하고 남은 결함은 관리자가 저장한 옵션뿐입니다. keysize 지시문에 대한 경고도 같은 정리에 속합니다. 주석 처리하고 원본 파일을 프로필 옆에 두십시오.

패키지와 플러그인 결함은 VPN 결함처럼 보인다

업그레이드 후의 모든 실패가 암호학적이지는 않습니다. 릴리스가 쓰지 않는 코드명 아래 추가된 OpenVPN 저장소는 결코 설치되지 않는 패키지를 만듭니다. lsb_release -a 가 무엇을 보고하는지 추가한 목록 파일과 비교하십시오. 빠진 universe 구성 요소나 보안 주머니는 아예 찾을 수 없는 패키지를 만듭니다. 두 경우 모두 프로필은 그대로이고 터널은 불가능합니다.

VPN 로그보다 패키지 관리자의 오류를 먼저 읽으십시오. 클라이언트가 설치된 적이 없다면 아무리 프로필을 편집해도 핸드셰이크는 나오지 않습니다.

묻기를 멈춘 이중 인증 프로필은 같은 이야기의 플러그인판입니다. 과제는 인증 플러그인에서 오고, 그것을 빼거나 바꾼 업그레이드는 프로필을 온전히 둔 채 프롬프트를 사라지게 합니다. 연결이 작동하도록 두 번째 요소를 지우는 대신 지원되는 플러그인을 다시 설치하십시오.

공급업체 라이브러리가 정책 오류 뒤에 숨을 수 있다

한 가지 패턴은 알아 둘 만합니다. 모든 정책 수리를 무력화하기 때문입니다. 하드웨어 공급업체의 구성 도구는 자체 OpenSSL 라이브러리를 설치해 로더의 검색 경로에서 시스템 사본보다 앞에 둘 수 있습니다. 그러면 클라이언트는 아무도 업그레이드하지 않은 라이브러리에 대고 시작하고, 시작 실패는 거부된 인증서와 똑같이 보입니다.

VPN 패키지를 다시 설치해도 어느 라이브러리가 먼저 발견되는지는 바뀌지 않고, TLS 수준을 낮춰도 시스템에서 온 적 없는 라이브러리에는 닿지 않습니다. 바이너리가 실제로 어떤 암호 객체를 해석하는지 로더에게 물으십시오:

ldd /usr/sbin/openvpn | grep -i -E 'ssl|crypto'

공급업체 사본을 제거하거나 다시 지정한 뒤 같은 점검을 다시 실행하십시오. 프로필로 돌아가기 전에 예상 버전이 사용 중이어야 합니다.

오래된 클라이언트를 고정하는 것은 시간을 벌 뿐 해결이 아니다

이전 클라이언트 버전을 유지하면 유지가 지속되는 동안 터널이 복구됩니다. 또한 그 패키지의 보안 업데이트를 얼리고 다음 업그레이드에 같은 고장을 예약하므로, 해결이 아니라 날짜가 붙은 임시 조치로 다루십시오.

그래도 고정한다면 무인 업그레이드가 고정을 되돌리지 못하도록 패키지를 명시적으로 유지하고, 이유와 재검토 날짜를 적고, 공급업체의 다음 프로필 릴리스에 맞춰 알림을 설정하십시오. 지켜볼 조건은 현재 암호를 협상하는 서버 프로필이며, 그것이 생기면 고정에는 더 이상 근거가 없습니다. 반대로 기록되지 않은 고정은 반년 뒤 아무도 설명할 수 없는 장애가 됩니다. 적용한 사람은 떠났고 파일은 아무것도 남기지 않기 때문입니다.

다음에 릴리스 업그레이드 후 VPN이 죽으면 다섯 질문을 차례로 하십시오. 어느 계층이 첫 오류를 냈는가, TLS 정책이 인증서를 거부했는가, 암호가 양방향으로 협상 가능한가, 패키지와 플러그인이 실제로 설치되었는가, 프로세스가 어느 라이브러리를 불러오는가. 다섯이 모두 깨끗하게 돌아온 뒤에야 다운그레이드가 의미를 갖습니다.