프로필별 점검으로 여러 vpnc 터널을 유지하기

vpnc 프로필 하나는 로밍 후에도 깔끔하게 재연결되지만, 셋이 되면 번갈아 서로의 소켓과 라우트와 리졸버 상태를 깨뜨립니다. 패키지에 포함된 재연결 스크립트는 터널 하나를 전제로 작성되어, 어느 하나만 내려가도 모든 프로필을 재시작합니다. 이를 고치려면 로컬 포트를 분리하고, 프로필마다 실제 서비스를 점검하고, 두 연결을 동시에 실행하지 않는 하나의 정렬된 사슬을 두는 세 가지가 필요합니다.

각 프로필에 전용 로컬 포트를 주십시오

기본 로컬 포트에 그대로 둔 vpnc 프로필은 이미 실행 중인 프로필과 경쟁합니다. 첫 번째가 포트를 쥐고 있는 동안 두 번째 연결이 실패하고, 로그 줄은 로컬 충돌이 아니라 게이트웨이 문제처럼 보입니다. 대신 프로필 파일마다 한 줄을 두십시오:

Local Port 0

영으로 두면 커널이 임시 포트를 고르므로 두 프로필을 동시에 세울 수 있습니다. 각 파일은 그것이 서비스하는 게이트웨이와 그룹의 이름으로 짓고, root만 읽을 수 있게 유지하며, 공유 기본값 대신 항상 해당 프로필로 연결하십시오. 공유 기본 파일은 누군가 프로필 이름을 바꾼 뒤 스크립트가 엉뚱한 터널로 재연결하는 경로입니다.

프로필 파일에는 자격 증명이 들어 있으므로 권한은 설계의 일부이지 뒷정리가 아닙니다. /etc/vpnc 아래에서 누구나 읽을 수 있는 파일은 그룹 비밀을 모든 로컬 사용자에게 넘깁니다. 모드는 0600, 소유자는 root로 두고, 스크립트가 비밀을 인자로 복사하는 대신 root로 파일을 읽게 하십시오. 점검 스크립트가 파일 내용을 로그에 절대 남기지 않아야 하는 이유도 여기에 있습니다.

터널 주소가 아니라 프로필마다 서비스 하나를 점검하십시오

터널 자체 주소로 보내는 에코 요청은 대개 인터페이스가 존재한다는 것만 증명합니다. 그 뒤의 호스트가 터널을 정당화하는 애플리케이션에 여전히 닿는지는 말해 주지 않습니다. 인터페이스는 올라 있어도 그 너머의 라우트는 이미 사라졌을 수 있습니다.

프로필마다 짧은 TCP 타임아웃으로 서비스 하나를 점검하고, 점검이 실패한 프로필만 재연결하십시오. 두 초면 죽은 경로와 느린 경로가 갈리고, TCP 점검은 경로 어딘가에서 ICMP가 허용되는지에 의존하지 않습니다. 프로필 사이에서 목표와 설정 이름만 바꾸십시오:

#!/bin/bash
set -eu
if ! nc -z -w 2 10.63.7.20 8443; then
  /usr/sbin/vpnc-connect ops.conf
fi

그것을 /usr/local/bin/ensure-vpn-ops.sh으로 저장하고 실행 가능하게 만든 뒤, 점검 목표와 설정 이름만 바꾸어 모든 프로필에 반복하십시오. 프로토콜 질문에 답하는 점검은 에코를 버리면서도 사용자가 중요하게 여기는 서비스를 계속 전달하는 게이트웨이를 넘어 살아남습니다.

점검이 절대 경쟁하지 않도록 사슬로 연결하십시오

패키지의 재연결 스크립트는 점검을 차례로 호출할 수 있고, 그 순서가 요점 전부입니다. 함께 도는 두 개의 vpnc-connect 호출은 아무도 통제하지 않는 순서로 라우팅 테이블을 다시 쓰며, 건강한 프로필이 라우트를 잃는 방식이 바로 이것입니다.

호출은 포그라운드에 두고, 하위 인터페이스를 위해 짧은 안정화 지연을 넣고, 터널 라우트를 다시 쓸 수 있는 것은 root뿐이므로 사슬은 root의 cron 테이블에서 예약하십시오:

#!/bin/bash
sleep 20
/usr/local/bin/ensure-vpn-ops.sh
/usr/local/bin/ensure-vpn-lab.sh

부팅 스크립트와 cron 항목 사이에서 순서를 동일하게 유지하십시오. 부팅 시 다른 순서로 도는 사슬은 사실상 다른 프로그램이므로, 한 프로필이 다른 프로필의 라우트에 의존하면 의존성을 먼저 두고, 앞선 터널이 아직 올라오는 동안 뒤의 점검은 무해하게 실패하게 두십시오.

로그를 지켜본 뒤 하나를 일부러 깨뜨리십시오

실행마다 프로필, 점검 대상, 결과, 취한 조치를 한 줄로 기록하십시오. 그것이 없으면 매분 흔들리는 터널은 한 번도 끊긴 적 없는 터널과 똑같이 보이고, 점검 버그는 게이트웨이 장애와 구별되지 않습니다. 로그는 사슬이 실패한 프로필만 건드렸다는 것도 증명합니다. 재부팅 후에도 남는 곳에 쓰십시오 — 그렇지 않으면 증거가 프로세스와 함께 사라집니다.

그다음 터널 하나를 일부러 깨뜨리고 무슨 일이 일어나는지 보십시오. 프로필 하나를 멈추고 어떤 프로세스와 라우트가 아직 남아 있는지 확인하십시오:

pgrep -a vpnc
ip -4 route show | grep -E '10[.]63|10[.]90'
tail -n 5 /var/log/ensure-vpn.log

멈춘 프로필만 재연결되어야 하고, 다른 세션은 프로세스와 라우트를 모두 유지해야 합니다. 두 프로필이 재시작된다면 사슬이 예상하지 못한 어딘가에서 병렬로 돌고 있는 것입니다.

감시자가 하지 말아야 할 일

무엇이든 실패할 때마다 모든 것을 재시작하는 감시자는 시험 중에는 건강해 보이지만 유지보수 창에서 장애를 냅니다. 재시작은 프로필 단위로, 결코 전체로 하지 마십시오.

게이트웨이가 같은 프로토콜용으로 유지 관리되는 클라이언트를 제공하면 그것을 택하고, 프로필 파일이 이미 비밀을 담고 있으므로 스크립트에 비밀번호를 하드코딩하거나 명령줄로 넘기지 마십시오. 터널이 올라온 뒤 작업을 일반 사용자로 돌려야 한다면 전체 사슬을 그 계정으로 돌리는 대신 스크립트 안에서 권한을 낮추십시오. 마지막으로, 프로필이 다른 할당 주소로 돌아와 터널 주소를 향한 어떤 점검도 알아채지 못할 낡은 라우트를 남길 수 있으므로, 재연결 뒤 라우트를 다시 읽으십시오.