OpenVPN을 Debian 또는 Ubuntu VM에서 실행할 때 .ovpn 파일을 수신하고, 터미널에서 오류가 발생하거나 연결 이전에 멈추는 경우입니다. 파일은 유효할 수 있지만 누락된 인증서, 필터링된 포트 또는 SSH 세션을 차단하는 경로를 가리킬 수 있습니다. 프로파일을 확인하고 첫 번째 오류를 기록한 후 연결 후 경로와 내부 서비스 상태를 확인하세요.
.ovpn 파일을 읽고 OpenVPN을 시작하기 전에
로컬 콘솔, 공급자 콘솔, iDRAC/IPMI 또는 이미 검증된 별도의 관리 네트워크를 유지하세요. 독립적인 이 접근 방식에서 테스트를 시작하세요. redirect-gateway는 파일에 기록되거나 연결 후 서버에 의해 푸시될 수 있습니다. 그렇다면 기본 경로가 터널을 통과할 수 있습니다. 동일한 경로를 사용하는 두 번째 SSH 세션은 백업 접근 방식이 아닙니다.
테스트 전에 SSH로 연결되었다면 클라이언트 주소를 표시하고 기록하세요. 연결 후 사용된 제어 콘솔에서 이 주소를 재설정한 후 경로를 확인하세요. 복구 콘솔을 사용하여 서버에 다시 접속할 수 있지만, SSH 세션이 열려 있을 것이라는 보장은 없습니다.
# 시작 전 SSH 세션에서 :
printf '%sn' "$SSH_CLIENT"
# 연결 후 제어 콘솔에서 :
SSH_CLIENT_IP='198.51.100.42' # 기록한 클라이언트 주소로 대체
ip route get "$SSH_CLIENT_IP"파일을 계정 전용 디렉토리에 배치하고 키가 포함된 경우 권한을 제한하세요. 데모 파일이나 Git 리포지토리에 사용자 이름이나 비밀번호를 포함하지 마세요.
mkdir -p ~/vpn-test
install -m 600 /chemin/recu/client.ovpn ~/vpn-test/client.ovpn
cd ~/vpn-test
grep -nE '^[[:space:]]*(remote|proto|port|ca|cert|key|pkcs12|tls-auth|tls-crypt|tls-verify|auth-user-pass|auth-user-pass-verify|redirect-gateway|redirect-private|route|route-ipv6|route-gateway|route-table|route-noexec|route-nopull|pull-filter|config|plugin|script-security|up|down|route-up|route-pre-down|ipchange|dns-updown|management|daemon|log|log-append|syslog|status|writepid|askpass|cd|chroot|user|group|learn-address|client-connect|client-disconnect)' client.ovpn이 학습은 원격 호스트, 프로토콜, 인증서 파일 및 인증 모드를 보여주지만 내용은 표시하지 않습니다. config가 다른 파일을 로딩하는 경우 프로파일 디렉토리에서 다시 읽고 이 필터를 다시 수행하며 마지막 파일까지 각 config를 따라가세요. 전체 체인이 실행 전 반드시 이해되어야 합니다. up, down, route-up, route-pre-down, ipchange 및 tls-verify는 외부 명령을 실행합니다. plugin은 OpenVPN 프로세스 내에서 라이브러리를 로드합니다. management는 노출해서는 안 되는 제어 인터페이스를 엽니다. learn-address, client-connect, client-disconnect 또는 auth-user-pass-verify가 포함된 클라이언트 프로파일은 이 진단을 위해 거부됩니다. 다른 경로 중 하나라도 알려지지 않은 경우에도 중단하세요. 외부 스크립트는 보안 값을 script-security의 2 또는 3으로 요구하며, 이 값은 프로파일 내에서 설정할 수 있습니다. 또한 auth-user-pass를 확인하세요: 인자 없이 OpenVPN은 프롬프트에서 사용자 이름과 비밀번호를 요청합니다; 경로가 지정되면 해당 파일을 읽고 내용을 프로파일 서버로 전송합니다. 인터페이스와 경로를 생성하기 위해 sudo로 실행하는 것은 일반적이지만 참조된 파일 중 어떤 것도 알 수 없어야 합니다.
# “config” 이후 발견된 각 경로에 대해, ~/vpn-test 부터 :
sed -n '1,220p' chemin-inclus.conf출처나 지시사항이 불확실한 파일은 절대로 운영 서버나 SSH 접근이 특별한 기계에서 실행되어서는 안 됩니다. 첫 번째 시도는 독립 콘솔이 있는 임시 VM에서 진행되어야 합니다. 이 학습은 위험을 줄이지만 임의 프로파일을 안전한 프로파일로 변환하지는 않습니다. 또한 daemon, log, log-append 및 syslog는 이 진단을 위해 거부하세요: 이들은 메시지를 터미널 밖으로 옮기고 프로세스를 백그라운드에서 지속시키는 경향이 있습니다.
프로파일이 상대 경로를 참조하는 경우, client.ovpn만 이동하지 마세요. 수신된 디렉토리를 통제된 위치에 유지하거나 같은 트리 구조로 다시 읽은 각 의존성을 복사하고 제한된 권한을 부여하세요. 예를 들어, ca ca.crt를 명시하는 프로파일은 ~/vpn-test에서 ca.crt를 찾아야 합니다.
install -m 600 /chemin/recu/ca.crt ~/vpn-test/ca.crt부재하거나 읽을 수 없는 의존성은 프로파일 실패이며, 네트워크 시도 이후의 TLS 오류와는 다릅니다. .ovpn 파일은 태그 사이에 인증서를 포함할 수 있으며, 이 확인에서는 외부 경로를 표시하지 않을 것입니다.
find ~/vpn-test -maxdepth 1 -type f -printf '%f %mn'
# proto udp4/tcp4의 경우 :
getent ahostsv4 vpn.exemple.net
# proto udp6/tcp6의 경우 :
getent ahostsv6 vpn.exemple.net
ip -brief link show > ~/vpn-test/links-before.txt호스트와 주소 패밀리를 remote 및 proto의 값으로 바꾸세요. 프로파일에는 여러 줄의 remote가 포함될 수 있습니다. 주소 패밀리가 열려 있으면 두 출력을 모두 확인한 후 OpenVPN 로그에서 실제로 보고된 주소를 보관하세요. OpenVPN 연결 자체는 UDP 또는 TCP 프로토콜과 포트를 테스트하는 유용한 방법입니다.
클라이언트를 포그라운드에서 실행하고 로그 유지하기
클라이언트를 포그라운드에서 실행하세요. 그러면 터미널에 연락된 주소와 첫 번째 유용한 오류가 표시됩니다. openvpn가 없으면 패키지를 설치하세요:
command -v openvpn || { sudo apt update && sudo apt install openvpn; }
sudo openvpn --config ~/vpn-test/client.ovpn --verb 3--verb 3와 함께 첫 번째 명확한 오류, 서버 주소 및 클라이언트가 중단되는 단계를 유지하세요.
- 옵션 오류 또는 파일을 찾을 수 없다는 메시지는 경로, 지시사항 또는 수정이 필요한 인증서를 의미합니다.
- TLS 오류는 연결 시도 후 서버, 포트, UDP/TCP 프로토콜, 네트워크 필터링,
tls-auth또는tls-crypt, 인증서, 시스템 시간 및 프로파일의 암호화 설정을 점검해야 합니다. - 사용자 이름 요청은
auth-user-pass에서 올 수 있습니다. 프롬프트에서 입력하거나 공급자의 제공된 메커니즘을 사용하세요; 비밀을client.ovpn에 추가하지 마세요. Initialization Sequence Completed메시지는 클라이언트가 초기화 완료되었음을 확인하지만, 여전히 내부 리소스가 접근 가능하다는 것을 보장하지는 않습니다.
다음 검사를 수행하는 동안 명령을 열어 두세요. 인터페이스, 경로 및 내부 서비스를 확인한 뒤에만 Ctrl+C로 중지하세요.
연결 후 인터페이스 및 경로 확인
연결 전 인터페이스를 기록하고, 그런 다음 연결 후 비교하세요. tun은 IP 패킷을 운반하고, tap는 이더넷 인터페이스를 에뮬레이트합니다. dev 지시는 이름을 강요할 수 있습니다. 실제로 생성된 이름만 사용하세요. ip route get는 Linux가 선택할 장치를 보여주며, 패킷을 보내지 않습니다.
# “Initialization Sequence Completed” 후 :
ip -brief link show | diff -u ~/vpn-test/links-before.txt -
VPN_IF='생성된-인터페이스-이름'
ip -brief address show dev "$VPN_IF"
ip route get 10.8.0.10
ip route get 1.1.1.1
ip route get "$SSH_CLIENT_IP"10.8.0.10을 VPN 팀에서 문서화된 내부 대상으로 대체하세요. 이 경로는 OpenVPN에서 경로가 지나갈 경우 터널 인터페이스를 명시해야 합니다. 테스트 전에 원격 SSH 세션이 있었다면 SSH_CLIENT_IP로의 경로도 확인하세요.
경로가 서비스가 응답하고 있음을 증명하지는 않습니다. 그런 다음 귀하의 팀에서 문서화한 주소와 포트를 사용하여 예상되는 서비스를 테스트하세요. 예를 들어, HTTPS 서비스가 상태 페이지를 노출하는 경우 :
getent hosts intranet.exemple.lan
curl --fail --silent --show-error --connect-timeout 5 --max-time 10 --output /dev/null --write-out '%{http_code}n' https://intranet.exemple.lan:443/health이 이름, 포트 및 경로를 실제 서비스의 것으로 대체하세요. 첫 번째 명령은 내부 주소를 반환해야 합니다. 두 번째 명령은 이 서비스에 의해 기대되는 코드인 200 또는 204를 출력해야 합니다. curl은 또한 TLS 인증서를 확인합니다: 내부 CA를 설치하거나 필요하면 서비스 문서를 사용하세요; --insecure를 추가하지 마세요. 내부 DNS의 경우, 오히려 귀하의 팀에서 문서화한 이름과 해결사를 쿼리하십시오.
저는 이 진단이 시작되는 것을 위해 openvpn-client@... 서비스가 있는 서버에서 점검 실행을 권장합니다. Ctrl+C 후에 인터페이스가 사라지고, 내부 대상에 대한 경로가 더 이상 터널을 사용하지 않으며, 기록된 SSH 주소에 대한 경로가 예상 장치로 돌아가는지 확인하세요. down 또는 route-pre-down 스크립트가 사용된 프로파일은 이 검사를 요구하며, 클리닝이 성공적으로 이루어졌다고 가정할 수 없습니다.
ip link show "$VPN_IF"
ip route get 10.8.0.10
ip route get "$SSH_CLIENT_IP"첫 번째 명령은 인터페이스가 더 이상 존재하지 않아야 함을 보고해야 합니다. 두 경로의 출력을는 결정과 터널 동안 기록된 이전 값과 비교하세요. 삭제된 인터페이스와 여전히 연결된 경로 또는 오류가 발생한 클리닝 스크립트는 새로운 시도 전에 확인이 필요합니다.
