한 줄만 다른 두 프로필은 같은 호스트에서 두 번째 클라이언트가 시작되는 순간 다르게 동작합니다. 하나는 nobind 가지고 커널이 주는 아무 로컬 포트나 사용하지만, 다른 하나는 1194를 예약하므로 두 번째 인스턴스는 이미 사용 중인 주소 때문에 죽습니다. 그 줄이 원본 포트를 누가 고르는지를 결정하고, 그것이 다시 프로필이 머신의 다른 무엇과 공존할 수 있는지를 결정합니다. 세 가지 질문이 그것을 정리하며, 첫 번째 질문은 나머지 둘에 이르기 전에 대부분의 프로필에 답합니다.

nobind가 실제로 건너뛰는 것

기본적으로 클라이언트는 연결하기 전에 로컬 소켓을 바인딩하며, 프로필이 달리 말하지 않는 한 로컬 포트는 1194입니다. nobind 그 예약을 제거하므로 스택이 연결 시점에 사용되지 않은 포트를 할당합니다. 이것은 기본값이 아니라 예외이며, 그 줄이 없는 클라이언트는 1194를 유지하기 때문에, 고정하지 않은 두 번째 인스턴스가 충돌하는 이유가 바로 그것입니다. 배포되는 대부분의 클라이언트 프로필이 그 이유로 이 지시문을 담고 있으며, 샘플 파일이 어떤 일을 한다는 것이 메커니즘이 기본값으로 그 일을 한다는 것과 같지는 않습니다.

변하지 않는 것은 먼 쪽입니다. 서버는 여전히 프로필이 말하는 곳에서 수신하며, 구성의 목적지 포트는 여전히 목적지 포트입니다. 동적 원본 포트는 자신의 소켓 반환 주소를 바꿀 뿐 서버 소켓에는 아무것도 하지 않습니다.

아무것도 숨기지도 않습니다. 공인 주소는 경로가 그것을 변환한 결과이며, 패킷은 여전히 로컬 네트워크를 지나가고, 그 네트워크를 운영하는 누구든 여전히 흐름을 봅니다. nobind 프라이버시 기능도 아니고 방화벽 우회도 아닙니다.

결정하는 세 가지 조건

하나의 질문이 나머지 둘을 결정하므로 무엇이든 편집하기 전에 그것에 답하세요. 상대가 바깥으로 연결한다면 나머지 질문은 이미 내린 결정을 다듬을 뿐입니다. 상대가 인바운드 연결을 받는다면 로컬 포트를 어떻게 조정해도 도달 가능해지지 않습니다.

이 상대가 연결을 시작합니까? 바깥으로 연결한다면 응답이 같은 흐름으로 돌아오기 때문에 동적 원본 포트는 무해하고 보통 더 낫습니다. 인바운드 연결을 기다린다면 앞단의 무언가가 포트를 공개하지 않는 한 동적 포트는 도달 불가능하게 만듭니다. 그 하나의 답이 모든 클라이언트 프로필을 모든 서버 프로필과 구분합니다.

경로가 원본 포트로 필터링합니까? 하나의 알려진 포트를 위해 작성된 엄격한 규칙은 명시적인 로컬 포트를 강제하며, 프로필은 어떤 규칙을 충족하는지 기록해야 합니다. 대부분의 네트워크는 목적지만 필터링하므로 이 조건은 첫 번째보다 드뭅니다. 적용되는 곳에서는 동적 포트에 대한 선호를 무시합니다.

여러 인스턴스가 호스트를 공유합니까? 고정 포트 하나로는 둘을 동시에 처리할 수 없으며, 다시 시작한 인스턴스는 1194가 아직 닫히는 상태에 있는 것을 볼 수 있습니다. 동적 포트는 다른 무엇도 바꾸지 않고 그 충돌을 없앱니다. 이것에 자신 있게 답할 수 없다면 그렇다고 가정하고 커널이 고르게 하세요.

고정 포트가 정답인 경우

일부 네트워크는 목적지뿐 아니라 원본 포트로도 필터링하므로, 운영자가 알려진 포트 하나에서 오는 트래픽만 통과시키는 규칙을 작성했을 수 있습니다. 그때 로컬 포트를 고정하는 것이 옳으며, 프로필은 충족하는 규칙을 명시하는 주석을 담아야 합니다. 서버 포트와의 대칭을 위한 고정은 두 숫자가 서로 아무 관련이 없기 때문에 이유가 되지 않습니다. 템플릿에 있었기 때문에만 고정이 존재한다면 삭제하세요.

그렇지 않으면 고정 포트는 골칫거리를 삽니다: 한 머신의 두 클라이언트가 둘 다 1194를 유지할 수는 없습니다, 그리고 두 번째는 프로필이 아니라 포트를 가리키는 오류로 실패합니다. 빠르게 다시 시작하는 컨테이너도 같은 벽에 부딪힙니다. 해결책은 배포된 프로필이 이미 담고 있던 지시문입니다.

서버와 클라이언트는 대칭이 아닙니다

OpenVPN 2.6 설명서 는 nobind 를 lport 옆에 두는데, 이는 한 옵션은 커널이 고르고 다른 옵션은 당신이 고른다는 한 줄짜리 논증입니다. 동적 로컬 포트는 응답하는 쪽이 포트를 미리 알 수 없기 때문에 바깥으로 연결하는 상대에게만 작동합니다. 그래서 클라이언트 프로필을 서버에 복사하면 아무도 도달할 수 없는 리스너가 생깁니다.

여러 네트워크 인터페이스가 있는 호스트에서 주소는 포트와 별개의 결정입니다. 특정 로컬 주소를 바인딩하는 것과 특정 포트를 바인딩하는 것은 서로 다른 설정이며, 업링크가 둘인 서버는 보통 둘 다 고정합니다. 둘 다 고정하는 클라이언트는 아무 이득 없이 같은 경직성을 떠안은 것입니다.

요약은 보안이 아니라 역할에 관한 것으로, 바깥으로 연결하는 쪽은 자신의 원본에 대해 유연할 수 있고, 응답하는 쪽은 그럴 수 없습니다. 어느 선택도 상대가 당신의 정체성에 대해 배우는 것을 바꾸지 않습니다. 이 지시문이 클라이언트 예제에는 나오고 서버 예제에는 거의 나오지 않는 이유도 그것입니다.

커널이 고른 포트를 확인하세요

연결 후에는 구성이 의도를 말하고 소켓이 실제로 일어난 일을 말하기 때문에 구성이 아니라 소켓을 읽으세요. 기록할 가치가 있는 사실은 로컬 포트, 원격 엔드포인트, 그리고 무언가가 아직 수신 중인지 여부입니다. Linux 호스트에서는 셋 모두 명령 하나 거리에 있습니다.

ss -unp | grep openvpn
ss -lunp | grep openvpn
sudo lsof -nP -i | grep openvpn

클라이언트가 nobind 를 쓰면 높은 로컬 포트와 구성된 원격 포트를 보여 주며, 이것이 예상되는 형태입니다. 서버는 구성된 포트에서 수신하는 소켓을 보여 주며, 그 소켓이 없으면 프로필이 리스너가 아니거나 바인딩에 실패한 것입니다. 흐름은 있는데 패킷이 돌아오지 않으면 프로필을 편집하기 전에 선택된 원본 포트를 경로의 어떤 포트 필터와도 비교하세요. 한 가지를 바꾸고 다시 연결한 뒤 소켓을 다시 읽으세요.

관련 글