VPN 핸드셰이크 단계: 트래픽이 흐르기 전에 무슨 일이 일어나는가

연결을 누르면 독립적으로 성공하거나 실패하는 네 가지 작업이 시작된다. 클라이언트는 리스너에 도달하고, 상대가 누구인지 합의하고, 키를 도출한 뒤 작동하는 터널을 시스템의 나머지에 넘겨야 한다. 실패한 연결의 대부분은 잘못된 작업에서 진단된다. 그래서 첫 번째 오류가 세 번째 재시도보다 중요하다.

먼저 리스너에 도달하라

어떤 신원이든 교환되기 전에 클라이언트는 이름을 해석하고, 경로를 선택하고, 포트로 전송을 연다. 모든 것에 응답하는 캡티브 포털, 닫힌 포트, 잘못된 호스트 이름은 모두 여기서 실패하며, 그중 어느 것도 인증 문제가 아니다. 암호를 바꾸어도 세 가지 중 어느 것도 고칠 수 없다. 자격 증명을 건드리기 전에 오류의 첫 줄을 읽으라.

시간 초과, 인증서 거부, 거부된 계정은 서로 다른 세 가지 검사가 필요한 세 가지 결함이다. 이들을 먼저 분류하는 것이 네트워크 문제를 자격 증명 문제로 디버깅하는 것을 막는다.

상대를 증명한 다음 키를 도출하라

모든 프로토콜은 설정된 공개 키든 인증서 체인이든 의도한 서버를 인식할 방법이 필요하다. 사용자 로그인은 그 검사에 더해지는 것이지 대체하는 것이 아니다. 암호를 받아들이는 서버는 자신의 신원에 대해 아무것도 증명하지 않았다. 그래서 클라이언트에 입력한 공유 비밀은 누가 응답했는지 검증하는 것을 대신하지 못한다.

그다음 교환은 프로토콜 자체의 입력에서 트래픽 키를 도출하며, 로그인 암호는 보통 각 패킷에 찍히는 키가 아니다. 장기 신원 자료와 단기 세션 키는 수명과 역할이 다르다. 순방향 비밀이 말하는 것이 바로 이 분리다.

문제를 해결하는 동안에는 검증을 켜 두어야 한다. 검사를 비활성화한 뒤 연결되는 터널은 그 검사가 무언가를 하고 있었다는 것 외에 아무것도 증명하지 못하므로, 무엇을 바꿨는지 적어 두고 다음 테스트 전에 되돌리라.

세 가지 프로토콜, 세 가지 대화

TLS 기반 OpenVPN 배포에서는 제어 채널이 보안 매개변수를 협상하고 데이터 채널이 터널 트래픽을 나르므로, 데이터 채널 옵션과 인증서 문제는 서로 다른 곳에 있다. IKEv2는 두 참여자를 인증한 뒤 자체 수명을 가진 IPsec 보안 연관을 설정한다. WireGuard는 Noise 기반 교환으로 키를 도출하고 상태 기계를 의도적으로 작게 유지한다. 세 가지 중 무엇을 실행하는지 아는 것이 어떤 로그를 읽을 가치가 있는지 결정한다.

비슷하게 생긴 클라이언트가 아래 메시지가 교환 가능하다는 뜻은 아니며, 한 제품에 있는 구성 필드가 다른 제품에 대응물이 없을 수 있다. 둘 사이에 프로필을 복사하는 것은 마이그레이션이 아니라 추측이다.

핸드셰이크가 하지 않는 일

경로, 이름 확인, 목적지 정책은 모두 그 뒤에도 남는다. 상대가 올바르게 인증되고 터널이 올라가 있어도 서브넷 경로가 없어서 내부 사이트에 도달하지 못할 수 있다. 그것을 약한 암호화로 취급하면 잘못된 계층에서 찾게 되고, 보통 아무것도 고치지 못하는 암호 방식 변경으로 끝난다.

키 갱신과 재연결도 대부분의 상태 표시에서 비슷하게 보이며, 둘 다 중단 중에 일반 트래픽이 차단되었는지 알려주지 않는다. 그 질문에 답하는 것은 클라이언트의 실패 정책뿐이므로 아이콘이 아니라 정책을 읽으라.

위 순서대로 단계를 진행하고 처음 오류를 내는 단계에서 멈추라. 이후의 각 단계는 이전 단계의 상태를 상속하므로 세 번째 단계의 실패는 네 번째에 대해 아무것도 말하지 않는다.

ip -brief address show tun0
ip route get 10.60.7.15
resolvectl query intranet.corp.internal