세션 도중 피어 주소가 바뀌었을 때: OpenVPN float가 하는 일

노트북이 사무실 Wi-Fi에서 휴대전화 핫스팟으로 옮겨 가면 터널이 몇 초 더 버티다가, 인터페이스는 여전히 연결되어 있다고 주장하는데도 트래픽이 멈춥니다. 서버에서는 상태 목록이 계속 예전 공인 주소를 보여 줍니다. 이것이 float가 존재하는 상황이며, 동시에 사람들이 실제 동작보다 훨씬 많은 것을 기대하는 상황이기도 합니다. 경계를 정확히 파악하면 답답한 정지는 한 줄짜리 설정 변경이나 전혀 다른 조사로 바뀝니다.

float가 느슨하게 하는 것과 절대 느슨하게 하지 않는 것

보통 세션은 시작할 때의 외부 주소와 포트와 계속 대화하며, 다른 곳에서 도착하는 패킷은 무시됩니다. float 옵션은 피어가 이미 자신을 증명한 뒤에 그 엄격한 결속을 풀어 주므로, 바뀐 소스 매핑이 세션을 버리는 대신 같은 세션을 이어 갈 수 있습니다. 암호 검사는 아무것도 달라지지 않습니다. 키와 인증서, 그리고 어떤 HMAC 보호든 설정된 그대로 유지됩니다.

이것은 패킷마다 내리는 판단이며, 누가 접속할 수 있는지에 대한 정책이 아닙니다. 새 주소에서 패킷을 보내는 낯선 기계는 아무것도 증명하지 못했고, 그 패킷은 다른 미인증 트래픽과 똑같이 버려집니다. 세션 자체의 인증을 통과한 트래픽만이 기록된 피어 주소를 옮길 수 있고, 그래서 클라이언트가 이동하는 환경에서 float를 켜 둔 채로 두는 것이 안전합니다.

내부 터널에 대해서도 아무 말도 하지 않습니다. 옮겨진 외부 주소는 터널 주소를 다시 할당하지 않고, 풀을 바꾸지 않으며, 피어에게 새로운 무언가에 대한 접근 권한을 주지도 않습니다. 터널 안에서는 이동 전후에 같은 신원과 같은 푸시 경로가 적용됩니다. 이동은 데이터 채널을 다시 협상하지도 않으므로 협상된 암호와 키가 계속 이어집니다.

세션을 옮기는 패킷은 인증을 통과해야 한다

설정된 원격을 상대로 평소처럼 세션을 시작하면, 매핑이 바뀔 때 무슨 일이 일어나는지는 float가 처리합니다. 흐름 중간에 번호를 다시 매기는 이동통신사, 포트 매핑을 다시 쓰는 NAT 게이트웨이, 업링크를 바꾸는 노트북은 모두 같은 모양을 만듭니다. 새 튜플에서 온 인증된 패킷이, 아직 예전 것을 믿고 있는 세션에 도착하는 것입니다.

float가 동작하는지 물을 때 유용한 증거는 완료된 핸드셰이크와 그 뒤에 수용된 소스 변경이며, 주소만 다루는 로그 한 줄이 아닙니다. 예전 외부 주소와 새 외부 주소를 살아남은 세션과 연결한 다음, 트래픽이 실제로 터널을 지나 계속되었는지 확인하세요.

이동 대신 세션이 죽는다면, 새 주소에서 도착한 패킷이 인증에 실패했거나 아예 도착하지 않았을 것입니다. 클라이언트 쪽에서는 두 경우가 똑같이 보입니다. 서버에서는 공인 인터페이스에서의 캡처가 어떤 경우인지 설정을 건드리기 전에 알려 줍니다.

탐색은 완전히 별개의 메커니즘

float는 타이머로 이름을 해석하지 않고 동적 DNS 레코드를 추적하지도 않습니다. 서버 호스트 이름이 새 주소로 해석되기 시작해도, 대기 중인 클라이언트에는 그것을 알아챌 이유도, 새 엔드포인트에서 인증할 패킷도 없습니다. 그 문제는 재연결 로직과 클라이언트 자체의 재시도 동작, 그리고 DNS의 몫이며 float의 몫이 아닙니다.

옵션을 한 번 더 추가한다고 해서 새 주소로 가는 경로가 없는 것을 메울 수는 없습니다. 피어가 조용할 때도 도움이 되지 않습니다. 조용한 피어는 무언가를 옮길 인증된 패킷을 결코 보내지 않기 때문입니다.

아래쪽 방화벽도 발언권이 있습니다. 예전 외부 엔드포인트만 허용하는 규칙은 OpenVPN이 그 주소를 보기도 전에 바뀐 주소를 막고, 클라이언트 측 설정으로는 고칠 수 없습니다. 허용 주소의 수명 주기를 별개의 작업으로 검토하세요. 규칙을 아무 출발지로나 넓히는 것은 작은 문제를 큰 문제와 맞바꾸는 일입니다.

NetworkManager가 프로필을 소유할 때

명령줄 프로필과 가져온 연결은 별개의 설정이며, 하나를 편집해도 다른 하나는 건드리지 않습니다. 옵션이 지원되지 않는다고 가정하기 전에, 저장된 프로필이 실제로 어떤 플러그인 유형을 쓰는지와 그 값이 어디에 있는지 확인하세요. 무엇이든 검사하거나 수정할 때 중요한 식별자는 프로필의 UUID입니다.

원본 가져오기 파일이 아니라 저장된 연결을 검사하세요. .ovpn 파일에 남아 있는 줄은 활성 관리자가 한 번도 적용하지 않았다면 아무것도 증명하지 못하고, 특정 옵션에 대한 확인란이 없는 편집기도 프로토콜의 능력에 대해 아무것도 증명하지 못합니다.

동작을 추가하려고 패키지된 플러그인을 패치하지 마세요. 특히 무관한 구성 요소의 과거 버전을 위해 작성된 diff로는 더더욱 안 됩니다. 설치된 통합이 정말로 그 설정을 표현할 수 없다면, 올바른 조치는 지원되는 프로필이나 배포 소유자가 승인한 다른 클라이언트 경로입니다.

가정하지 말고 전환을 증명하세요

장애가 일어나는 방식 그대로 테스트하세요. 연결하고, 터널을 지나는 트래픽을 확인하고, 외부 주소를 강제로 바꾼 다음 세 가지를 점검합니다. 세션이 아직 존재하는지, 기록된 피어 주소가 옮겨졌는지, 실제 요청이 여전히 목적지에 도달하는지입니다. 세 가지에 못 미치는 것은 부분적인 답입니다.

테스트하는 동안 복구 접근을 확보해 두세요. 이동 실험은 작업 중인 기계를 꼼짝 못 하게 만드는 버릇이 있기 때문입니다. 시리얼 콘솔이나 대역 밖 경로가 있으면 실패한 테스트가 현장 방문 대신 오 분짜리 복구가 됩니다.

마지막으로, 실제로 시험한 사례만 설명하세요. 세션 중 주소 변경이 성공했다는 것은 DNS 이전, 다른 클라이언트 구현, 다시 만든 프로필이 같은 방식으로 동작한다는 증거가 아닙니다. link-options 문서는 이 옵션의 범위를 정확히 밝힙니다. 테스트 로그에는 그 범위 중 어디까지 실제로 다루었는지 적어야 합니다.