OpenVPN 클라이언트 하나에 서비스 주소 두 개: iroute와 lo

애플리케이션은 자신의 터널 주소에서 응답하지만, 그 앱을 위해 문서화한 주소는 아무 데도 가지 않습니다. OpenVPN 로그에는 아무 불평이 없고, 피어는 연결된 것으로 보이며, 허브는 정확히 클라이언트 하나를 나열합니다. 빠진 것은 클라이언트의 두 번째 주소가 두 가지 별개의 사실이라는 점입니다. 호스트가 그것을 소유해야 하고, 허브는 어느 피어가 소유하는지 알아야 합니다. 하나만 다루면 트래픽은 허브에서 죽거나 집으로 돌아갈 경로 없이 도착합니다.

별칭은 로컬, 소유권은 원격

터널 주소는 협상되므로 핸드셰이크 중에 양쪽이 그것을 알게 됩니다. 추가 서비스 주소는 전혀 협상되지 않으므로, 그것을 추가해도 허브에서는 그 자체로 아무것도 바뀌지 않습니다. 클라이언트는 즉시 주소를 소유할 수 있지만 서버는 여전히 그 트래픽을 기본 경로로 보내거나 버립니다. 레코드 두 개를, 서로 다른 두 곳에 만들어야 합니다.

클라이언트에서 주소는 호스트에 속하며, 루프백은 물리 링크에 절대 나타나서는 안 되는 서비스 ID의 자연스러운 집입니다. 허브에서 피어-프리픽스 매핑은 서버만 읽는 별도 선언입니다. 어느 레코드도 다른 쪽을 함의하지 않습니다.

메모에서도 두 범위를 구분해 두십시오. 예시의 주소는 문서용 값이며, 이를 실제 LAN과 겹치는 것은 동작하는 설정을 고장 난 것처럼 보이게 하는 가장 빠른 방법입니다.

클라이언트에 주소를 영구적으로 추가

서비스 주소를 호스트 프리픽스와 함께 루프백에 두어, 호스트가 도달해야 할 서브넷이 아니라 로컬 입력으로 취급하게 하십시오. ip address add 10.66.0.10/32 dev lo이 한 주소에 대해 그렇게 하며, 두 번째 주소에 대해 명령을 반복하면 두 서비스를 모델링합니다.

먼저 일회성 테스트로 실행한 다음, 호스트의 네트워크 구성을 소유한 곳으로 옮기십시오. 런타임 추가는 재부팅 시 사라지고 재연결 사이에 중복이 쌓입니다. 네트워크 뒤에 정렬된 systemd 유닛이 한 가지 선택지이고, 배포판의 네트워크 관리자가 또 다른 선택지입니다. 무엇을 고르든 애플리케이션이 바인드하기 전에 주소가 있어야 하며, 그렇지 않으면 서비스가 잘못된 소켓에서 뜹니다. 수동 명령 후가 아니라 재부팅 후에 ip address show dev lo로 확인하십시오.

바인딩은 주소 지정과 별개의 결정입니다. 모든 주소에서 수신하는 애플리케이션은 의도하지 않은 인터페이스에서 트래픽을 받아들이므로, 특정 서비스 주소를 가리키게 하십시오. 그러면 로컬 입력 정책이 정확히 일치시킬 대상이 생깁니다.

허브가 실제로 읽는 CCD 파일에서 그것을 요구하십시오

서버에서 소유권 선언은 인증된 공통 이름으로 선택되는 클라이언트별 파일로 들어갑니다, client-config-dir이 이름 붙인 디렉터리 안입니다. 줄은 iroute 10.66.0.10 255.255.255.255이며 주소마다 하나이고, 해당 목적지의 트래픽을 어느 피어가 받아야 하는지 서버에 알려 줍니다.

두 가지 세부 사항이 이것을 조용히 깨뜨립니다. 파일 이름은 서버가 실제로 사용하는 이름과 일치해야 하며, username-as-common-name이 관여하면 달라집니다. 그리고 iroute는 클라이언트 구성 디렉터리가 설정된 TUN 모드에서만 효력이 있으므로, 브리지 배포에서는 같은 줄이 아무 일도 하지 않습니다. 기존 파일을 교체하지 말고 줄을 추가하십시오. 이미 고정 주소나 push 옵션이 들어 있을 수 있습니다. OpenVPN 2.6 참조는 디렉터리와 소유권 지시문을 모두 문서화합니다.

허브 자체의 커널도 그 목적지로 가는 경로가 필요합니다. 로컬에서 생성된 트래픽이 터널 프로세스로 들어가야 하기 때문입니다. 서버 구성의 route 10.66.0.10 255.255.255.255은 서버가 직접 만드는 트래픽을 다루고, 다른 클라이언트는 목적지를 스스로 배우기 위해 push "route 10.66.0.10 255.255.255.255"이 필요합니다.

라우팅과 권한 부여는 별개로 유지됩니다. 푸시된 경로는 클라이언트에 패킷을 어디로 보낼지 알려 줄 뿐 아무것도 허가하지 않습니다. 서비스는 여전히 호출자를 자체 조건으로 받아들여야 합니다.

입력 정책과 응답 경로를 확인하십시오

별칭으로 주소 지정된 패킷은 소유 호스트에 로컬 입력으로 도착하므로, 문제는 로컬 방화벽이 그 출처와 포트를 허용하는지입니다. 주소 전체를 여는 대신 VPN 출처 범위에서 특정 서비스 포트를 허용하십시오.

응답에는 호출자로 돌아갈 경로가 필요합니다. 일반 터널 풀 안의 호출자에게는 그 경로가 이미 있으며, 터널 장치가 그것을 나릅니다. 다른 라우팅된 네트워크 뒤의 호출자에게는 그 네트워크의 반환 경로도 필요하며, 바로 여기서 비대칭 구성이 패킷을 잃습니다.

같은 포트에서 다른 주소에 바인드된 두 번째 리스너를 주의하십시오. 커널은 일치하는 소켓으로 전달하므로 결과가 무작위로 보입니다. ss -lntp로 확인하고 바인드된 주소가 서비스 별칭인지 확정하십시오. 여기서 출처 NAT는 필요하지 않으며, 추가하면 로그가 의존하는 호출자 ID를 숨깁니다.

주소와 소유권을 따로 테스트하십시오

두 단계로 테스트하십시오. 먼저 소유 호스트가 자신의 별칭에 있는 서비스에 자기 자신에서 도달할 수 있는지 확인하십시오. 이것은 바인드와 방화벽 문제를 라우팅에서 분리합니다. 그다음 애플리케이션 자체의 인증을 사용해 실제 VPN 호출자에서 테스트하십시오. 첫 번째가 통과하고 두 번째가 실패하면 빠진 조각은 허브 쪽에 있습니다.

연결 후에도 살아남는 실패 모드도 확인하십시오. 터널이 내려가도 별칭은 할당된 채 남고, 피어가 없어도 허브는 경로를 유지합니다. 어떤 객체도 단독으로 서비스가 도달 가능함을 증명하지 않으므로, 두 단계 테스트가 노트북에서의 한 번 ping보다 낫습니다.