Linux 호스트 하나에 OpenVPN 터널 두 개: 경로의 주인은 누구인가?

두 프로필이 연결되어 있고 그중 하나가 다른 하나를 향한 트래픽을 조용히 전달하고 있습니다. Linux 호스트는 두 OpenVPN 클라이언트를 동시에 어려움 없이 실행할 수 있습니다. 할 수 없는 일은 어느 프로세스가 어느 프리픽스를 요구할 수 있는지 대신 결정하는 것입니다. 그 결정은 두 번째 터널이 올라오기 전에 내려야 하며, 리소스가 응답을 멈춘 뒤가 아닙니다.

두 번째 링크가 해야 할 일부터 시작하십시오

한 프로필로 접근하는 사무실과 다른 프로필로 접근하는 실험실은 두 터널이 모두 올라와 있어야 하고 어느 쪽도 전부를 요구하지 않아야 합니다. 두 번째 프로필로 나가야 하는 고집 센 앱 하나에는 두 번째 기본 경로가 아니라 정책 규칙이 필요합니다. 대기 링크는 한 번에 하나의 터널만 돌면 되므로 예비 링크가 머신과 함께 시작해서는 안 됩니다.

이것은 세 가지 다른 구성이고, 셋 다 같은 방식으로 시작하기 때문에 혼동됩니다: 두 번째 프로필과 성공한 연결입니다. 먼저 의도한 배치를 적고 나서 그쪽으로 구성하십시오. 의도에 관한 문장 하나가 한 시간의 패킷 캡처를 아낍니다.

systemctl list-units --type=service 'openvpn-client@*'
ip -4 route show default

첫 번째 명령은 실행 중인 인스턴스를 나열하며, 관리자 밖에서 수동으로 시작한 것도 포함합니다. 두 번째는 현재 기본 요구를 출력하며, 이것이 나중에 설명해야 할 상태입니다.

겹치는 풀은 라우팅보다 먼저 깨집니다

두 서버는 같은 10.8.0.0/24에서 주소를 기꺼이 할당합니다. 그러면 클라이언트는 하나의 프리픽스 안에 두 인터페이스를 갖게 되고 어느 목적지가 어느 쪽에 속하는지 알려 주는 것이 없으며, 그 결과 나타나는 동작은 라우팅 결함처럼 보이지만 실제로는 번호 매기기 결함입니다. 풀의 번호를 다시 매기는 데는 구성 편집 한 번이 들지만, 이후의 모든 라우팅 우회에는 주말 하나가 듭니다. 경로를 추가하기 전에 풀을 확인하십시오.

로컬 LAN도 보십시오. 한 터널이 노출하는 192.168.1.0/24 홈 LAN도 같은 모호함을 만들며, 증상은 호스트 이름은 확인되지만 연결이 끝나지 않는 것입니다. 경로를 출력하기 전까지는 이름 확인 결함처럼 보입니다.

ip -4 addr show
ip route show table all | grep -E '10\.|192\.168\.'

클라이언트를 건드리기 전에 두 출력을 두 서버 구성과 비교하십시오. 프리픽스가 겹치면 아무리 재시작해도 둘을 분리할 수 없으므로 멈추고 번호를 다시 매기십시오.

각 프로필에 고유한 유닛을, 각 프리픽스에 주인을 주십시오

각 프로필은 자체 인스턴스 이름과 자체 구성 파일을 받으므로 office라는 인스턴스는 office.conf를, lab이라는 인스턴스는 lab.conf를 로드합니다. drop-in이 어느 파일이 로드되는지 바꿀 수 있으므로 디렉터리 목록을 믿는 대신 서비스 관리자를 통해 그 매핑을 확인하십시오. 매핑을 잘못하면 돌지 않는 프로필을 조정하게 됩니다.

다음으로 경로를 누가 설치하는지 정하십시오. 서버가 호환되지 않는 집합을 푸시할 때는 푸시를 거부하고 프리픽스를 직접 나열하거나, 한 프로필이 기본을 유지하게 하고 다른 하나는 정책 규칙으로 유도하십시오. 둘 다 기본을 설치하는 두 프로세스는 조용한 승자와 결정에 대한 서면 기록 없이 끝납니다.

systemctl cat [email protected]
grep -E 'route-nopull|pull-filter|redirect-gateway' /etc/openvpn/client/lab.conf

첫 번째는 인수를 바꾸는 모든 재정의와 함께 유닛을 보여 줍니다. 두 번째는 프로필이 푸시된 경로를 아예 받아들이는지 보여 주며, 이것이 이후의 모든 것을 결정하는 스위치입니다.

마크는 응답을 도착한 인터페이스에 붙잡아 둡니다

각 터널이 서로 다른 소스를 처리할 때 응답이 잘못된 링크로 나가 첫 패킷 후 연결이 죽을 수 있습니다. 견디는 패턴은 들어오는 패킷을 입력 인터페이스별로 표시하고, 그 표시를 응답에서 복원하고, 각 표시에 자체 기본 게이트웨이가 있는 테이블을 주는 것입니다.

영향받는 인터페이스에서는 응답이 메인 테이블이 절대 고르지 않을 링크를 통해 정당하게 도착하므로 보통 느슨한 역경로 필터링을 완화해야 합니다. 표시를 좁게 유지해, 잡으면 터널이 자기 자신을 통과하게 되는 터널 자체의 암호화된 트래픽을 절대 잡지 않도록 하십시오.

ip rule show
ip route show table 101
sysctl net.ipv4.conf.all.rp_filter

다른 규칙을 추가하기 전에 기존 규칙을 읽으십시오. 중복 우선순위와 잊힌 테이블이 마크 정책이 전혀 효과가 없어 보이는 흔한 이유입니다.

링크 하나를 멈춰 격리를 증명하십시오

두 터널이 모두 올라온 상태에서 각 인터페이스 주소, 각 터널 뒤의 호스트 하나로 가는 경로, 무관한 목적지가 택하는 경로를 기록하십시오. 테이블 하나는 최종 결정을 절대 보여 주지 않으므로 테이블 하나를 읽는 대신 커널에 조회를 요청하십시오.

그다음 인스턴스 하나를 멈추고 다른 하나가 계속되는 동안 그 인터페이스와 경로가 사라지는 것을 보십시오. 살아남은 쪽의 단절은 둘이 아직 아무도 분리하지 않은 장치 이름, 경로 또는 방화벽 규칙을 공유한다는 뜻입니다.

멈춘 프로필을 되돌리고 같은 점검을 반복하십시오. 재부팅 후 첫 시작에서만 터널이 살아남는다면 라우팅 설계가 아니라 수명 주기 결함을 보고 있는 것입니다.