서버가 같은 호스트에서 실행될 때 OpenVPN 클라이언트가 멈춥니다

저는 원격 사이트에서 터널을 받아들이면서 동시에 공급업체 네트워크로 연결하는 실험실 장비를 가지고 있었습니다. 아웃바운드 프로필은 몇 주 동안 잘 작동했습니다. 인바운드 서버를 추가한 뒤 아웃바운드는 연결된 다음 몇 초 만에 트래픽 전달을 멈췄고, 아니면 주소가 이미 사용 중이라는 오류로 시작을 거부했습니다. 설정 파일은 바뀌지 않았고, 호스트가 포트와 경로에 대해 자기 의견을 가진 두 번째 OpenVPN 프로세스를 얻었을 뿐입니다.

이 실패는 무작위가 아니며 인증 문제도 아닙니다. 한 머신의 두 데몬이 같은 로컬 소켓과 같은 라우팅 테이블을 두고 경쟁하고, 마지막에 시작하거나 다시 연결한 쪽이 보통 이깁니다. 이 두 충돌 중 어느 것인지 아는 것이 먼저 어디를 볼지 결정합니다.

증상을 거꾸로 읽으세요

터널이 언제 죽는지부터 시작하세요. 시작할 때의 바인드 오류는 무언가가 이미 그 포트를 소유하고 있어 OpenVPN이 공유하는 대신 시작을 거부한다는 것을 가리킵니다. 올라왔다가 조용해지는 터널은, 다른 인스턴스가 설치한 경로가 바깥 연결의 패킷을 경로에서 끌어낼 수 있기 때문에 라우팅을 가리킵니다.

두 경우 모두 같은 사용자 불만을 낳기 때문에 재시도 루프와 감시 스크립트는 아무것도 고치지 못합니다. 그것들은 클라이언트를 같은 충돌로 다시 연결할 뿐입니다. 유용한 첫 질문은 트래픽이 멈출 때 프로세스가 아직 실행 중인지입니다.

인스턴스마다 소켓 하나와 장치 하나

수신 서버는 자기 포트를 바인드합니다. 아웃바운드 클라이언트도 캡슐화된 트래픽을 위한 로컬 포트가 필요하며, 둘 다 같은 호스트에 있으면 클라이언트의 기본 동작이 서버 포트와 충돌할 수 있습니다. 클라이언트의 로컬 포트는 고정할 수 있습니다, 상대가 고정 소스 포트를 필요로 하지 않는 곳에서는 바인드를 생략할 수 있습니다:

lport 1195
nobind
dev tun1

그 숫자들은 예시일 뿐 요구 사항이 아닙니다. 중요한 것은 클라이언트가 서버 포트를 두고 경쟁하는 것을 멈추고 각 인스턴스가 별도의 터널 장치를 갖는 것입니다. tun0을 공유하는 두 데몬은 포트가 달라도 서로의 장치 상태를 덮어쓰므로 터널마다 장치 하나는 선택 사항이 아닙니다.

nobind는 클라이언트 쪽에 속합니다. 서버는 여전히 바인드하고 수신해야 하므로 이 줄을 서버 설정에 복사하지 말고, 상대가 고정 소스 포트로 필터링하는 클라이언트에서는 바인드를 비활성화하지 마세요.

기본 경로의 소유자를 하나로 정하세요

기본 경로를 설치할 수 있는 연결은 하나뿐입니다. 두 프로필이 모든 트래픽을 리디렉션하면 두 번째 연결이 첫 번째를 조용히 대체하고, 첫 번째는 깨진 것처럼 보입니다. 아웃바운드 터널을 분할된 상태로 두고 공급업체 프리픽스만 보내거나, 아니면 별도의 라우팅 테이블을 주세요.

ip rule add from 10.9.0.2 table 120
ip route add default dev tun1 table 120
ip route get 10.9.0.2

위의 주소와 테이블 번호는 자리 표시자이며, 규칙을 추가한 직후 VPN 서버 자체의 주소가 여전히 일반 테이블을 통해 해석되는지 확인하세요. 바깥 전송을 잡아채는 테이블은 보호하려던 터널을 깨뜨리고, 뒤따르는 재연결 루프는 신뢰할 수 없는 공급자처럼 보입니다.

재연결과 재부팅을 견뎌야 하는 구성에서는 네트워크 네임스페이스가 더 견고한 경계입니다. 두 번째 클라이언트는 자체 인터페이스와 경로를 가진 자체 네임스페이스 안에서 실행되고, 경계를 넘어야 하는 서비스만 노출됩니다. 호스트는 기본 경로를 하나 유지하고, 네임스페이스의 재연결은 그것을 다시 쓸 수 없습니다.

상태 줄이 아니라 테이블로 확인하세요

연결되었다고 보고하는 클라이언트는 제어 채널만 증명합니다. 각 연결 전후의 라우팅 상태를 기록하고, 실제 목적지가 어느 장치를 사용할지 커널에 물어보세요:

ip route show
ip route get 10.40.0.20
ss -lunp | grep 1194

두 번째 터널이 시작될 때 공급업체 주소에 선택된 장치가 바뀌면 경로 충돌입니다. 두 프로세스가 같은 로컬 포트에 나타나면 소켓 충돌입니다. 두 번째 없이 첫 번째만 고치면 실패가 다음 재연결로 옮겨갈 뿐입니다.

포트, 장치, 테이블, 경로 소유자를 호스트의 런북에 적으세요. 그렇지 않으면 세 번째 터널을 추가하는 다음 사람이 같은 충돌을 다시 발견하게 되고, 유일하게 보이는 증거는 다른 사람의 데몬이 다시 시작될 때까지 작동하는 연결뿐입니다.