모든 OpenVPN 피어에 remote 줄이 필요한가? 꼭 그렇지는 않다

두 피어 구성이 나란히 비교되는데, 하나에는 remote 줄이 있고 다른 하나에는 없으며, 결론은 둘 중 하나가 망가졌다는 것이다. 그 추론은 충분히 자주 틀리므로 뜯어볼 가치가 있다. 이 지시자는 첫 패킷을 어디로 보낼지를 설명한다. 프로세스가 연결을 시작하는 클라이언트로 행동하는지 대기하는 게이트웨이로 행동하는지를 고르지 않으며, 어느 쪽이 상대에게 자신의 신원을 증명하는지도 결정하지 않는다.

remote가 실제로 지정하는 것

remote 항목은 호스트를, 선택적으로 포트와 전송 방식을, 그리고 선택적으로 순서대로 시도할 여러 항목을 지정한다.

그것이 없는 것은 정의되지 않은 것이 아니라 정의된 의미를 가진다. 프로세스는 대기하며, 해당 피어가 인증하지 않는 한 어떤 주소에서 온 패킷에도 작용하지 않는다. 따라서 로밍 사용자를 서비스하는 게이트웨이가 그중 누군가를 미리 지정할 이유는 없다.

이 항목은 주소 관계로 읽어야 한다. 원격 쪽을 신뢰하는지는 인증서와 검증 옵션이 답하며, 주소가 적혀 있다는 사실이 아니다.

세 가지 구성이 답을 결정한다

로밍 클라이언트에는 목적지가 필요하다. 시작해야 하고, 목적지가 없으면 게이트웨이가 어디 있는지 알 수 없기 때문이다. 다중 클라이언트 게이트웨이에는 사용자별 목적지가 필요 없다. 클라이언트가 도착해 인증하기 때문이다. 알려진 끝점을 가진 의도적인 두 피어 연결은 어느 쪽이 시작하는지에 따라 한쪽에만, 양쪽에, 또는 어느 쪽에도 목적지를 두지 않을 수 있다.

고정된 클라이언트 주소를 일반 게이트웨이에 붙여 넣는 것은 그 범주를 무시한 데서 오는 실수다. 주소가 기록된 단 하나의 피어에는 통하고 나머지 모두를 오도한다.

이 지시자가 구성을 다중 클라이언트 서버로 바꾸지 않으며, 그 존재가 서버 역할을 막지도 않는다. OpenVPN 2.6 참조는 선택적 인수와 remote가 없을 때의 동작을 따로 문서화하는데, 이는 둘이 얼마나 독립적인지에 대한 힌트다.

전송 역할은 다른 축이다

TCP에서는 한쪽이 대기하고 다른 쪽이 연결을 건다. 이것은 목적지와 별개의 지시자이며, 둘을 섞으면 양쪽이 모두 대기하거나 양쪽이 모두 연결을 거는 쌍이 된다.

TCP 소스 필터 역할도 있으며, 서버가 절대 remote를 포함해서는 안 된다는 단정이 틀린 이유가 여기에 있다.

UDP에는 설정할 연결이 없으므로 양쪽 끝이 해당 UDP 전송을 사용하고 지시자는 어디를 겨냥할지만 말한다. 인증된 피어의 주소 변경은 항목을 더 추가하는 것이 아니라 전용 동작으로 처리된다. 전송을 올바르게 맞추는 것이 목적지가 의미를 가지기 위한 전제이며, 둘을 혼동하면 그럴듯해 보이지만 핸드셰이크를 끝내지 못하는 구성이 만들어진다.

remote가 없다고 열린 문이 아닌 이유

목적지가 없는 프로세스도 인증하지 않는 피어의 트래픽은 거부한다. 사람들이 빠진 줄을 누구에게나 열린 수신자로 읽을 때 놓치는 부분이 바로 이것이다.

인증과 목적지는 독립적이며, 신뢰에 중요한 것은 전자다.

반대 방향의 실수가 더 위험하다. 고정된 소스 주소는 구체적이고 확인하기 쉬워 접근 제어처럼 느껴질 수 있지만, 반대편에 누가 있는지에 대해서는 아무것도 증명하지 않는다. 인증서 검증을 유지하고, 인증서를 그 역할에 묶는 신원 확인도 유지해야 한다. 그것들을 주소 일치로 바꾸는 것은 실제 통제를 그 겉모습과 맞바꾸는 일이다.

구성이 무엇을 전제하는지 적어 두라

각 쪽마다 세 가지를 기록하라. 첫 패킷이 어떻게 피어에 도달하는지, 어느 쪽이 전송을 받아들일 수 있는지, 각 쪽이 상대에 대해 무엇을 검증하는지.

그 전제가 설계다. 지시자는 그 철자일 뿐이다.

두 파일이 다르다면 하나가 틀렸다고 가정하지 말고 서로 다른 전제를 표현하는지 확인하라. 대칭적인 파일 쌍은 동작하는 터널에 필요하지도 충분하지도 않으며, 비대칭이야말로 토폴로지를 동작하게 만드는 부분인 경우가 많다.