IPsec 게이트웨이용 WireGuard 프로필: 대신 무엇을 물어야 할까

침묵하는 게이트웨이와의 핸드셰이크 시간 초과는 보통 절대 만나지 않는 두 프로토콜을 뜻합니다. WireGuard 피어는 Noise를 말하고 IPsec 게이트웨이는 IKE를 기다립니다. 올바른 주소와 포트로도 바뀌지 않습니다.

프로필에서 엔드포인트를 재사용해도 둘은 연결되지 않습니다. 다음 단계는 게이트웨이를 운영하는 사람에게 요청하는 것입니다.

첫 번째 요청: 프로토콜 버전

IPsec은 하나의 워크플로가 아니라 한 계열을 가리킵니다. IKEv2와 IKEv1은 교환 방식, 인증 옵션, 네트워크 변경 시의 동작이 다릅니다. IKEv1만 종료하는 게이트웨이는 IKEv2를 제공하는 게이트웨이와 상당히 다르게 동작합니다. 클라이언트 구성도 그에 따라 달라집니다.

서비스가 어떤 버전을 종료하는지, 표준 기반 구현인지 자체 클라이언트를 가진 벤더 변형인지 물어보십시오. 운영체제 메뉴는 그 답을 하나의 레이블 뒤에 숨기는 경우가 많습니다. 레이블은 프로토콜이 아닙니다.

두 번째 요청: 클라이언트 인증 방법

인증은 실제 작업의 대부분이 있는 곳입니다. 서비스는 특정 확장 키 사용이 있는 머신 인증서, 사용자 인증서, IKEv2 상의 EAP 방법, 또는 ID에 묶인 사전 공유 키를 기대할 수 있습니다. 어느 것이 적용되는지가 클라이언트에 무엇이 필요한지를 결정합니다.

WireGuard 개인 키는 그중 어느 것도 아닙니다. 특정한 하나의 핸드셰이크에 쓰이는 Curve25519 키입니다. 어떤 변환도 그것을 인증서나 EAP 자격 증명으로 만들지 않습니다. 그렇다고 주장하는 도구는 파일 이름을 바꾸거나 무관한 것을 생성하는 것입니다.

RFC 7296의 IKEv2 명세는 그 버전의 구현이 무엇을 지원해야 하는지 설명합니다. 운영자의 모호한 답변을 위한 참고 자료이지 클라이언트 구성 안내서가 아닙니다.

세 번째 요청: 신뢰된 ID와 목적지

클라이언트가 보아야 하는 게이트웨이 ID와 그것을 검증하는 신뢰 앵커를 요청하십시오. 그다음 서비스가 밀어 넣는 사설 범위와 리졸버를 물어보십시오. 이 두 답이 터널이 실제로 무엇을 나르는지를 결정합니다.

그것들이 없으면 연결이 되어 있어도 작업은 실패할 수 있습니다. 리졸버가 푸시되지 않은 터널은 내부 이름을 응답 없이 남깁니다. 트래픽 선택자가 없으면 핸드셰이크가 성공했더라도 목적지가 터널 밖에 남습니다.

엔드포인트 점검은 클라이언트 오류와 다른 질문에 답합니다. 연결 없이 도달 가능한 포트는 인증을 가리키고, 도달할 수 없는 포트는 경로를 가리킵니다.

# what does the endpoint offer on its IPsec ports?
sudo nmap -sU -p 500,4500 198.51.100.44

# strongSwan: what did the IKE exchange negotiate?
sudo swanctl --list-sas
sudo swanctl --list-conns

클라이언트에서 무엇이든 바꾸기 전에 그 점검을 실행하십시오. 포트가 응답하는데도 연결이 계속 실패하면 문제는 자격 증명이나 정책입니다. 전혀 응답하지 않으면 프로필 편집으로는 해결되지 않습니다.

두 프로토콜이 공존해야 할 때

두 네트워크를 모두 관리하는 것은 두 프로토콜을 유지할 정당한 이유입니다. 일반적인 설계는 WireGuard와 IPsec을 별도 인터페이스나 별도 게이트웨이에서 종료합니다. 승인된 트래픽은 그 사이에서 라우팅됩니다.

그 설계는 신뢰와 권한 부여의 경계를 도입하므로 그렇게 문서화해야 합니다. 어떤 피어가 통과할 수 있고, 어느 방향이며, 누구의 정책 아래인지는 라우팅과 방화벽의 결정입니다. 어느 프로토콜도 그것을 제공하지 않습니다.

그것이 아닌 것은 투명한 변환입니다. WireGuard로 도착한 트래픽은 IPsec 터널로 다시 생성되며, 그 사이의 모든 정책이 적용됩니다.

먼저 서버의 프로토콜과 인증 요구 사항을 확정하십시오. 그다음 운영자가 지원하는 클라이언트와 등록 경로를 사용하고, 그동안 개인 키를 웹 변환기에서 멀리 두십시오.