tls-auth key-direction: 0과 1은 같지 않고 달라야 합니다
tls-auth에서는 양쪽 끝이 서로 반대 방향인 0과 1을 가져야 하며, 아니면 둘 다 설정을 생략해야 합니다. 같은 숫자는 실패하고, tls-crypt는 절대 사용하지 않습니다.
터널의 한쪽이 다른 쪽이 결코 확인하지 않는 키 슬롯으로 제어 채널에 서명하고, 인증서가 하나도 교환되기 전에 연결이 인증 오류로 죽습니다. 이것이 tls-auth의 방향 불일치이며 결정적입니다. 같은 두 파일은 어느 네트워크에서든 매번 실패합니다. 로그에는 찾고 있는 옵션의 이름이 나오지 않기 때문에 사람들은 망가지지도 않은 키를 다시 만들고 인증서를 재발급합니다. 해결책은 양쪽 끝을 상보적으로 만들거나 둘 다 양방향으로 두는 것이지, 검증을 약화하는 것이 아닙니다.
실패는 인증서보다 먼저 발생합니다
tls-auth에서는 양쪽 피어가 같은 공유 키를 보유하고 각자는 그로부터 파생된 두 슬롯 중 하나를 사용합니다. 한 슬롯은 나가는 제어 패킷에 서명하고 다른 슬롯은 들어오는 패킷을 검증합니다. 방향 0과 방향 1은 이 역할을 반대 순서로 할당하므로 HMAC 검사가 맞으려면 쌍이 상보적이어야 합니다. 한쪽에서 할당이 뒤집히면 수신자는 잘못된 슬롯에서 서명을 찾고 패킷을 거부합니다. 세션은 거기서 끝나며, 그래서 이 오류는 인증서 저장소가 만들어낼 무엇이 아니라 패킷 인증에 관한 것입니다.
결정성은 진단에 중요합니다. 시간이나 경로 문제는 다른 흔적을 남기기 때문입니다. 간헐적 끊김, 한 방향만 실패, 특정 네트워크에서만 죽는 세션 등입니다. 방향 불일치는 매번 첫 핸드셰이크에서 실패하며, 같은 두 파일을 가진 다른 기계에서도 똑같이 실패합니다. --verb 4에서 로그를 읽고 마지막 줄이 아니라 처음 거부된 패킷을 찾으세요. 그 거부가 어떤 인증서 교환보다 먼저 일어난다면, 공유 키와 그 방향이 확인해 볼 가치가 있는 두 가지입니다.
| What you see | What it rules out | Next check |
|---|---|---|
| Authentication error before any certificate is sent | The data channel is irrelevant; the control channel never authenticated | Compare tls-auth and its direction on both ends |
| Certificate or handshake failure after the control channel authenticates | The shared key and its direction already agree | Check the CA, the certificate dates and the hostname |
| Session completes but throughput or cipher warnings appear | Direction was never the problem | Compare the data-channel cipher settings |
| Startup stops on an options error | The number itself is not the issue | Re-read the inline versus external directive syntax |
숫자가 사는 곳
OpenVPN 2.6 설명서 는 방향을 지정하는 두 곳을 문서화합니다. 키가 별도 파일에 있을 때는 tls-auth의 두 번째 인수, 키가 프로필에 인라인으로 있을 때는 독립된 key-direction 줄입니다. 둘 다 같은 값을 설정하므로 프로필은 한 형식이나 다른 형식을 써야 하고 둘 다는 절대 안 됩니다. 생략도 선택이며, 어느 쪽도 방향을 지정하지 않을 때 작동하는 양방향 배치로 양쪽을 넣습니다. 같은 숫자를 가진 두 피어는 그 배치에 있지 않습니다. 각자가 한 슬롯에서 서명하고 다른 슬롯에서 검증하기를 기대하며, 둘 다 같은 방향으로 하기 때문입니다.
# server.conf, external key tls-auth ta.key 0 # client.ovpn, external key tls-auth ta.key 1 # client.ovpn, inline key key-direction 1
인라인 형식은 별도 줄의 지시문이며 키 블록의 여는 태그에 붙는 속성이 아닙니다. 그 태그에 인수를 더하는 것은 방향 변경이 아니라 오류입니다. 위치도 중요합니다. 지시문은 속한 블록 바깥에 있으므로 블록 안에 쓴 값은 키 자료로 읽힙니다. 쌍을 지어내지 말고 프로필 배포자가 의도한 배치를 그대로 복사하세요. 한 서버에서 작동하는 프로필은 반대편에 이미 거울처럼 복제되어 있을 수 있습니다.
이 옵션이 건드리지 않는 것
애플리케이션 트래픽을 암호화하지 않습니다. tls-auth는 제어 채널 패킷 둘레에 HMAC을 두고, 데이터 채널은 핸드셰이크에서 협상한 세션 키로 보호되므로 처리량이나 암호 방식 질문은 방향 숫자와 무관합니다. 이 설정은 두 번째 암호화 계층도 더하지 않으며, 더 긴 키를 찾아 나서게 만드는 것이 바로 이 가정입니다.
이것은 tls-crypt에는 적용되지 않습니다. 자체 옵션과 키 처리를 가진 다른 제어 채널 메커니즘입니다 그리고 어떤 피어의 인증서 신원에 대해서도 말하지 않습니다. 따라서 작동하는 방향 일치는 양쪽 끝이 제어 채널을 어떻게 인증할지 합의했다는 것만 증명하고, 신뢰 체인이 검증되었다는 것은 아닙니다.
쌍을 맞춘 다음 다시 연결하세요
어느 하나를 바꾸기 전에 두 구성을 비교하세요. 이미 올바른 쪽을 편집하면 작업이 두 배가 됩니다. 아래 grep은 각 파일이 어떤 메커니즘을 고르는지 보여 주고, 자세한 실행은 제어 채널이 애초에 인증되었는지 보여 줍니다. 두 출력을 모두 보관해 다음 변경을 알려진 상태와 비교할 수 있게 하세요.
grep -n -E 'tls-auth|tls-crypt|key-direction' server.conf client.ovpn openvpn --config client.ovpn --verb 4 2>&1 | grep -i -E 'hmac|tls error|control channel'
변경 후에는 항상 양쪽 피어를 다시 시작하세요. 이 옵션은 시작할 때 한 번만 읽히고, 한쪽만 다시 로드하면 이전 세션의 수명 동안 쌍이 일관되지 않게 됩니다. 지금 방향을 설정하지 않고 배포가 작동한다면, 한 피어에 설정을 더하는 것은 처음의 실패를 재현합니다. 둘 다 그대로 두거나 둘 다 설정하세요. 한 번에 한 끝만 바꾸고 이전 파일을 보관하면, 회귀는 재구성이 아니라 몇 분이면 되는 되돌리기가 됩니다.
각 끝의 메커니즘, 키 파일, 방향을 배포 노트에 기록하세요. 그러지 않으면 다음 사람이 비슷한 두 파일을 읽고 숫자가 서로 맞아야 한다고 오해합니다. 방향은 조정 세부 사항이지 보안 강화가 아닙니다. 제어 채널의 두 방향을 나눌 뿐 그 밖의 일은 하지 않습니다.