한 호스트에서 OpenVPN 서버와 클라이언트 운영: 클라이언트가 끊기는 이유

이미 VPN 서버가 돌고 있는 머신에 클라이언트 프로필을 추가하면 가장 먼저 다치는 것은 기존 서비스입니다. 새 터널이 아예 맺어지지 않을 수도 있고, 올라온 뒤에도 서버의 기존 클라이언트가 조용히 응답을 받지 못하게 될 수 있습니다. 두 가지 충돌이 두 결과를 모두 만듭니다. 이미 사용 중인 터널 풀과, 새 클라이언트 절반이 설치해 테이블 전체를 덮는 기본 경로입니다. 어느 쪽도 OpenVPN 오류 메시지를 내지 않기 때문에 이 고장은 서버 문제로 읽힙니다.

한 머신, 두 역할, 그리고 응답이 어디로 가야 하는지에 대한 양립할 수 없는 두 답.

같은 풀, 두 서버: 누가 이기는가

각 서버 인스턴스에는 고유한 터널 서브넷이 필요합니다. server 10.8.0.0 255.255.255.0 같은 줄을 두 번째 구성에 복사하면 두 인스턴스가 같은 프리픽스를 갖게 되고, 결과는 시작 거부이거나 한 서버의 클라이언트가 다른 서버도 자기 것이라고 믿는 주소를 받는 조용한 다툼입니다. UDP 포트나 장치 이름을 달리해도 둘 다 주소 공간을 건드리지 않으므로 도움이 되지 않습니다. 두 번째 풀을 바꾸고, 경로가 그 풀을 언급하는 모든 곳에서 바꾸십시오.

편집하기 전에 무엇이 살아 있는지 나열하십시오: ip -4 addr show는 터널 장치를 나열하고, ss -lunp는 리스너를 나열하며, systemctl list-units는 유닛 이름을 알려 줍니다. 터널 주소를 한 번만 보면 풀이 충돌하는지 판정됩니다.

클라이언트 프로필이 테이블에 더하는 것

클라이언트 절반은 연결되는 즉시 경로를 기록합니다. redirect-gateway def1는 기본 경로를 0.0.0.0/1과 128.0.0.0/1로 나누고, 둘 다 새 장치를 통해 라우팅하며, 멀리 있는 서버로 가는 호스트 경로는 의도적으로 물리 인터페이스에 고정합니다. 이 고정은 터널이 자기 전송을 위한 길을 유지하기 위해 존재합니다. 그 밖의 모든 것, 로컬 서버가 자기 클라이언트에게 돌려줄 응답까지도 이제 새로운 기본 경로를 따라 원격 링크로 나갑니다.

그러므로 두 번째 충돌은 망가진 터널이 아닙니다. 테이블에서 잘못된 자리에 놓인 정상 동작 터널입니다.

역할을 분리하는 세 가지 방법

가장 침습이 적은 수정은 기본 경로를 클라이언트 프로필에서 빼는 것입니다. 원격 프리픽스에 대해 route-nopull와 명시적 route 줄을 쓰면 로컬 테이블은 요청한 곳에서만 바뀝니다. 다음 단계는 로컬 터널 서브넷을 예외로 두는 정책 규칙으로, 기본 경로가 있어도 로컬 클라이언트로 가는 응답이 도착한 인터페이스로 나가게 합니다. 가장 철저한 방법은 클라이언트 역할을 위한 별도 네트워크 네임스페이스로, 공유 테이블을 완전히 없애지만 두 번째 라우팅 컨텍스트를 유지하는 비용이 듭니다.

어느 길을 택하든 예외는 LAN이 아니라 로컬 터널 서브넷을 지목해야 합니다. 로컬 서버가 보내는 응답의 목적지는 터널 주소이므로 LAN 모양의 예외는 결코 맞지 않습니다.

두 인스턴스 중 어느 쪽이 문제인가

클라이언트 인스턴스를 멈추고 기존 클라이언트를 다시 시험하십시오. 즉시 회복되면 원인은 라우팅이지 서버가 아닙니다. 클라이언트를 다시 올리고 ip route get에 출발지와 목적지 주소를 모두 주어 응답 하나를 추적하면 커널이 고를 경로가 보이고, 그다음 tcpdump -ni any port 1194로 패킷이 실제로 쓰는 인터페이스를 관찰하십시오. 서버의 상태 파일은 몇 초마다 status 지시문으로 기록되며, 연결된 클라이언트 목록과 양방향 바이트 카운터를 담고 있습니다.

그 카운터를 서로 맞대어 읽으십시오. 나갔다가 돌아오지 않는 트래픽은 핸드셰이크 문제가 아니라 라우팅의 답입니다.