OpenVPN에서 경로는 어디에 속하는가: 클라이언트인가 서버인가?
서버 설정에 그냥 경로를 넣으면 바뀌는 것은 서버이지 클라이언트가 아니다. 클라이언트 파일, 전역 push, 개별 클라이언트 push 중에서 고르고 무엇이 도착했는지 확인한다.
서버 구성에 route 10.60.0.0 255.255.255.0 를 추가하고 다시 시작하고 노트북을 다시 연결해도, 그 노트북에서는 서브넷에 여전히 접근할 수 없습니다. 줄은 받아들여졌고 서비스는 깨끗하게 시작했으며 로그에도 이상한 점이 없습니다. 일어난 일은 편집한 머신에 경로가 설치된 것이며, 게이트웨이는 이제 그 접두사에 도달할 수 있다고 믿지만 클라이언트에는 아무것도 알려지지 않았습니다. 위치가 문제의 전부이며, 같은 줄이 살 수 있는 곳은 네 군데입니다.
네 장소와 각각을 받는 대상
경로는 클라이언트 자체 구성으로 추가하거나, 전역 push로 모든 클라이언트에 제공하거나, 클라이언트별 파일로 한 클라이언트에 제공하거나, 서버 자체의 라우팅 컨텍스트에 기록할 수 있습니다.
이 네 경우는 거의 같은 구문을 쓰지만 결과는 완전히 다릅니다. 처음 세 가지는 클라이언트가 터널로 무엇을 보내는지에 영향을 주고, 네 번째는 서버가 네트워크에 어떻게 도달하는지에 영향을 주는데, 이는 서버 자체에 경로가 필요할 때 유용하고 배포로 착각하면 해롭습니다.
줄을 쓰기 전에 네 가지 중 무엇을 원하는지 정하고, 그다음 수신자를 확인하십시오.
| Placement | Effect | Receiver |
|---|---|---|
| Client profile route | Installed by the client at connect | That client only |
Global push "route ..." | Sent to every client that accepts pushed options | All pulling clients |
| Client-specific push | Sent to the matching client context | One identity |
| Server config route, no push | Added to the server's own table | The gateway itself |
서버에 그냥 둔 경로가 사람들을 놀라게 하는 이유
서버 구성은 관리자가 가장 먼저 보는 곳이고, 그곳의 경로 지시문은 VPN 네트워크에 대한 선언처럼 읽힙니다. 그렇지 않습니다. OpenVPN은 그것을 데몬이 도는 머신에 대한 로컬 경로 설치로 취급하며, 이는 ip route 로 하고 나서 잊어버리는 것과 정확히 같은 종류의 변경입니다.
배포에는 경로를 push해야 하고, push에는 클라이언트가 가져와야 합니다. 가져온 옵션을 비활성화하고 시작한 클라이언트는 제안을 완전히 무시합니다. 서버 파일을 다시 쓰기 전에 이 악수의 양쪽 끝을 확인하되, 서버 쪽에서는 제안이 이미 전송되었으므로 서버 로그는 불평하지 않습니다. 승인된 경로는 다음 연결에서만 적용되고 이미 참여 중인 세션에서는 결코 적용되지 않습니다.
두 가지를 별개의 작업으로 보면 실패는 더 이상 신비롭지 않고, 서버는 접두사에 도달하고 클라이언트는 도달하지 못하며, 두 진술은 동시에 참입니다.
클라이언트별 파일과 그것이 맞춰지는 식별자
클라이언트별 파일은 서버가 인증한 식별자의 이름을 따르며, 기본값은 인증서의 공통 이름입니다. 데스크톱 클라이언트의 친숙한 연결 이름은 그 값이 아니며, 불일치가 있으면 절대 읽히지 않는 파일이 생깁니다.
서버가 실제로 사용하는 디렉터리를 확인하고, 파일 이름이 인증된 식별자와 대소문자까지 정확히 일치하는지 확인하십시오.
grep -n 'client-config-dir' /etc/openvpn/server/server.conf
ls -l /etc/openvpn/ccd/그 파일 안에서도 경로는 push되어야 하는데, 클라이언트별 컨텍스트는 그 클라이언트의 세션에 적용되는 옵션 집합이지 로컬 라우팅 테이블이 아니기 때문입니다. 거기에 그냥 둔 경로는 전역 파일의 경로와 같은 문제를 가집니다.
클라이언트 자신의 파일과 그것을 소유한 도구
클라이언트 구성에 놓인 경로는 그 클라이언트가 연결할 때 설치되고 끊을 때 제거되며, 정적 대상에 맞는 올바른 수명 주기입니다.
네트워크 관리자가 프로필을 소유한다면 그 옵션을 한 번 가져온 뒤 자체 사본을 유지할 수 있습니다. 나중에 내려받은 파일을 편집해도 아무것도 바뀌지 않으며, 이것이 "경로는 있는데 적용되지 않는다"의 흔한 원인입니다.
내려받은 파일이 아니라 활성 프로필을 확인하고, 관리자가 표시하는 가져온 설정도 확인하십시오. 그런 다음 연결해서, 텍스트 파일에 경로가 있었으니 터널이 이겼다고 가정하지 말고 특정 주소가 어떤 경로를 쓰는지 시스템에 물어보십시오.
클라이언트에서 확인한 뒤 반환 경로를 확인한다
대상에 대해서는 서버가 아니라 클라이언트 자체의 라우팅 테이블에 물어보십시오. 접두사 안의 호스트 하나를 조회하는 것만으로 사용될 인터페이스와 다음 홉을 보여주기에 충분합니다.
ip route get 10.60.0.10조회가 터널을 가리키면 배포가 작동한 것이고 남은 문제는 다른 곳에 있습니다. 기본 게이트웨이를 가리키면 경로가 설치되지 않았거나, 클라이언트 측 옵션으로 필터링되었거나, 클라이언트가 사용하지 않는 프로필에 속한 것입니다.
배포가 작동했는데도 아무 응답이 없다면, 게이트웨이의 전달, 반대편의 반환 경로, 그 사이의 방화벽을 확인하십시오. 경로는 길을 고를 뿐 접근을 허용하지 않습니다.