Linux 호스트 하나에 OpenVPN 클라이언트 둘: 경로의 주인은 누구인가?

두 프로필 모두 연결되었다고 보고하며 그중 하나가 다른 쪽을 향한 트래픽을 조용히 나르고 있습니다. 호스트 하나에 클라이언트 둘은 지원되는 구성이지만, 각 프리픽스에 주인이 없는 클라이언트 둘은 그렇지 않습니다. 작업의 핵심은 두 번째 터널을 올리는 일보다 어느 프로세스가 어느 경로를 주장할 수 있는지 정하는 일에 있습니다. 아래 순서대로 진행하면 구성은 답에서 따라 나옵니다.

두 번째 터널이 무엇을 위한 것인지 묻는 데서 시작하세요

세 상황은 상태 줄에서는 똑같아 보이지만 서로 다른 설계가 필요합니다. 목적지 분할은 한 프리픽스를 사무실 프로필로, 다른 하나를 실험실 프로필로 보내며 둘 다 기본 경로를 주장하지 않습니다. 애플리케이션별 분할은 보통 완전한 터널 하나를 유지하고 특정 트래픽을 정책 규칙으로 돌립니다. 장애 조치는 한 번에 정확히 터널 하나만 켜 두므로 두 번째는 자동으로 시작되어서는 안 됩니다.

그 답이 이후의 모든 것을 정하므로 설정 파일을 열기 전에 사례를 적어 두세요.

가장 흔한 잘못된 구성은 둘 다 기본 경로를 밀어 넣은 완전한 터널 둘로, 마지막에 연결한 쪽이 이기고 첫 번째는 계속 가장합니다. 그 상태는 상태 줄에서는 의도한 것처럼 보이고 라우팅 테이블에서 하루를 낭비합니다. 사례를 먼저 이름 붙이면 그것은 단지 일어나기 어려운 일이 아니라 불가능해집니다.

경로보다 풀을 먼저 보세요

두 서버는 하나의 사설 범위에서 주소를 쉽게 나눠 줄 수 있고, 그렇게 되면 클라이언트는 하나의 프리픽스 안에 인터페이스 둘을 갖게 됩니다. 그러면 둘 다 똑같이 옳아 보이므로 주소로 목적지를 인터페이스에 귀속시킬 수 없습니다. 동점을 깨는 규칙을 발명하는 대신 풀 하나의 번호를 다시 매기세요.

집이나 사무실 LAN이 터널 범위와 겹치면 반대편에서 같은 모호함이 생기므로 로컬 네트워크도 확인하세요. 클라이언트를 탓하기 전에 호스트의 주소를 두 서버 설정과 비교하세요. 실험실 서버의 풀 변경은 오 분짜리 수정이지만, 겹치는 프리픽스에 대한 정책 라우팅 우회는 나중에 설정을 읽는 모든 사람에게 영구적인 세금입니다. 어디에 개입할지 고르기 전에 둘 중 무엇을 원하는지 정하세요.

주소 체계가 둘이면 이 확인도 두 번 합니다. IPv6 풀은 IPv4만큼이나 조용히 충돌합니다.

각 프로필에 주인을 주세요

프로필마다 인스턴스 하나, 인스턴스마다 설정 파일 하나, 그리고 그 쌍을 식별하는 이름 하나입니다. Debian 스타일 패키징에서는 @ 기호 뒤의 이름이 파일을 고르므로, 같은 인스턴스 이름을 공유하는 두 프로필이 둘 다 동작할 수는 없습니다. 매핑은 자습서가 아니라 설치된 유닛에서 확인하세요.

systemctl cat [email protected]
ip -4 addr show

다음으로 누가 경로를 설치하는지 정해야 하는데, 이는 구문이 아니라 정책의 문제입니다.

두 서버가 호환되지 않는 집합을 밀어 넣을 때는,route-nopull를 추가하고 각 프로필에 필요한 프리픽스만 나열하거나, 한쪽이 기본 경로를 유지하게 두고나머지를 정책 규칙으로 돌리세요. 둘 다 기본 경로를 설치하는 두 프로세스는 승자 하나로 끝나고 아무도 이유를 말할 수 없습니다. 두 터널이 서로 다른 출처의 트래픽을 나르기 시작하면 응답이 잘못된 쪽으로 나갈 수 있고, 견디는 패턴은 응답에서 복원되어 자기 테이블로 돌려지는 연결 표시입니다. 터널 자체의 암호화된 패킷이 절대 그 표시와 일치하지 않도록 범위를 좁히세요.

터널별로 검증한 다음 하나를 멈추세요

둘 다 올라오면 각 터널 장치의 주소, 각각 뒤에 사는 호스트로 가는 경로, 둘 밖의 목적지가 택할 길이라는 세 가지를 읽으세요. 규칙이 개입하는 순간 평범한 경로 목록은 최종 조회를 설명하지 못하므로 커널에 실제로 무엇을 고를지 물으세요. 그다음 인스턴스 하나를 멈추고 무엇이 사라지는지 보세요. 첫 번째를 멈출 때 두 번째가 흔들리면 경로, 장치 이름, 또는 아무도 분리하지 않은 방화벽 규칙 같은 것이 아직 둘 사이에 공유되어 있습니다.

ip rule show
ip route get 203.0.113.9

재부팅 뒤 한 번만 동작하고 다시는 동작하지 않는 터널은 라우팅 옷을 입은 수명 주기 버그이므로, 멈춘 프로필을 되돌리고 같은 확인을 반복하세요.

배포 노트에 어느 프로필이 어느 프리픽스를 소유하는지 풀 범위 옆에 기록하세요. 두 터널은 의도된 구성이며, 다음 독자는 어느 프로필이든 건드리기 전에 경계를 볼 수 있어야 합니다. 그 메모가 없으면 공유 프리픽스가 마침내 깨질 때 당직자가 경계를 다시 발견합니다.