WireGuard 클라이언트가 OpenVPN 클라이언트에 도달하지 못합니까?

두 터널이 모두 연결되고 각 클라이언트는 게이트웨이에 도달하며, 한쪽이 다른 쪽 주소를 시도하는 순간 패킷이 사라진다. 어느 핸드셰이크에도 잘못된 것은 없고, 키를 다시 발급해도 달라지지 않는다. 게이트웨이는 자기 인터페이스 두 개 사이에서 평범한 비암호화 IP 패킷을 나르므로 프로토콜들이 서로를 이해할 필요는 전혀 없다. 필요한 것은 어떤 핸드셰이크도 주지 않는 세 가지다. 출발 클라이언트의 목적지 커버리지, 게이트웨이의 소스 소유권, 그리고 반대편의 반환 경로다. 증상은 셋 모두 같아서 함께 진단된다.

증상은 한 번에 한 조각씩 빠진다

이 설계는 wg1 에 10.71.0.0/24 의 WireGuard 풀을, tun1 에 10.72.0.0/24 의 OpenVPN 풀을 두며 둘 다 하나의 게이트웨이에서 끝난다. 시험 대상 요청은 10.71.0.5 에서 10.72.0.30 의 HTTPS 로 간다. 아래 각 단계는 그 하나의 흐름에 관한 것이다. 각 점검의 실패 서명은 다르지만 사용자는 똑같이 겪으며, 보통 한 번에 셋 중 하나만 빠져 있다.

두 풀이 정말 이 게이트웨이에 있고 터널이 사는 네임스페이스에서 포워딩이 켜져 있는지 먼저 확인하십시오. 두 프로토콜을 서로 다른 네임스페이스에서 종료하는 게이트웨이는 둘 사이에서 아무것도 포워딩하지 않으므로, 어떤 피어 설정을 읽기 전에 이것부터 배제할 가치가 있다.

스포크의 목적지 커버리지를 넓히십시오

WireGuard 클라이언트에서 기존 피어 항목이 OpenVPN 목적지에 대해 게이트웨이를 골라야 하며, 즉 목적지 프리픽스가 그 피어의 허용 목록에 있어야 한다. 이를 추가해도 두 번째 터널이 생기지 않는다. 클라이언트가 그 주소를 조회할 때 어느 피어를 고르는지가 바뀔 뿐이고, wg-quick 에서는 보통 경로가 목록을 자동으로 따른다.

AllowedIPs = 10.71.0.0/24, 10.72.0.0/24

실제 키와 엔드포인트 줄은 그대로 두고, Table = off 을 쓰는 관리자는 이 목록에서 경로를 전혀 가져가지 않는다는 점을 기억하십시오. 그 경우 같은 프리픽스를 시스템 라우팅 테이블에 그 소유자가 직접 넣어야 하며, 그곳에서 빠진 경로는 빠진 허용 프리픽스와 똑같이 보인다.

게이트웨이의 소스 소유권은 유지하십시오

이 클라이언트의 게이트웨이 피어 항목은 그 클라이언트의 소스 주소만 계속 소유해야 한다. 허용 주소는 양방향으로 검사된다. 나가는 트래픽의 피어를 고르는 동시에 들어오는 패킷의 소스가 보낸 피어에 속하는지 검증한다. 스포크가 그 풀에 도달하고 싶다는 이유로 OpenVPN 풀을 스포크 항목에 넣는 것이 트래픽을 잘못된 참여자로 보내는 실수다.

AllowedIPs = 10.71.0.5/32

그 항목은 라우팅 편의가 아니라 소유권 선언으로 읽으십시오. 클라이언트가 도달해야 하는 나머지 모든 것은 클라이언트의 목적지 목록에 속하며, 이 피어가 무엇을 보낼 수 있는지에 대한 게이트웨이의 생각에 속하지 않는다.

OpenVPN 쪽에 반환 경로를 주십시오

이제 목적지에는 WireGuard 소스로 돌아가는 경로가 필요하며, 풀 클라이언트에게는 보통 OpenVPN 서버가 밀어주는 경로로 도착한다. 가져야 할 클라이언트에게만 밀어주고, 지시가 적용되었다고 가정하지 말고 클라이언트에서 수락되었는지 확인하십시오.

push "route 10.71.0.0 255.255.255.0"

경로 배포는 인가가 아니다. 목적지가 풀 안이 아니라 다른 OpenVPN 클라이언트 뒤에 있을 때, 그 클라이언트 자신의 LAN 소유권과 포워딩 요건이 설계에 더해진다, 그리고 밀어준 경로는 앞의 절반일 뿐이다. 지시를 더하기 전에 요건을 그래프로 다시 쓰십시오. 어느 노드가 어느 프리픽스를 소유하고 어느 노드가 그쪽으로 포워딩하는가.

허용하려던 바로 그 하나의 서비스만 허용하십시오

포워딩이 켜져 있고 두 풀이 모두 라우팅 가능하면 남는 질문은 정책이다. 규칙은 인터페이스 쌍 전반이 아니라 그 구체적 흐름에 대해 쓰고, 적용 전에 미리 보고, 응답이 새 연결로 차단되지 않도록 상태를 유지하는 반환 경로를 남기십시오. 모의 실행은 비용이 없고 무엇이 추가될지 정확히 보여준다.

sudo ufw --dry-run route allow in on wg1 out on tun1 proto tcp from 10.71.0.5 to 10.72.0.30 port 443

이것은 포워딩되는 트래픽의 규칙이며, 두 VPN 서비스에 대한 게이트웨이의 수신 규칙과는 별개다. 바깥 UDP 포트를 여는 것이 안쪽 요청을 인가하지 않고, 안쪽 요청을 인가하는 데 게이트웨이로의 무제한 SSH나 포워딩의 기본 허용이 필요한 것도 아니다. 목적지 자신의 방화벽과 수신 주소도 일치해야 한다. loopback에 묶인 서비스는 가장 공들여 라우팅된 패킷도 거부하기 때문이다. 대화의 한 방향만 덮는 정책은 보통 요청은 성공하고 응답이 조용한 형태로 실패하며, 이것이 셋 중 가장 혼란스러운 결과다.

상호 경로는 보통 소스 변환이 필요 없다는 뜻이며, 이는 목적지에서 WireGuard 주소를 유지하고 로그를 읽기 쉽게 만든다. 두 프로토콜이 얽혀 있다고 해서 포괄적 masquerading을 더하지 말고, 무엇이 그것에 의존하는지 모른 채 기존 변환 규칙을 지우지 마십시오. 그다음 단일 흐름을 처음부터 끝까지 검증하고, 허용되지 않은 소스나 포트도 하나 시험하십시오. 양쪽에서 핸드셰이크가 된다는 것은 교차 경로도 격리도 증명하지 않는다.