WireGuard 5G 지사: 지사가 허브로 연결하게 하라

지사가 허브로 연결하면 허브는 변하는 셀룰러 주소를 찾을 필요가 없습니다. 구성하고 검증한 다음, 이것이 해결하지 못하는 것을 확인하십시오.

지사를 허브로 향하게 하는 것은 지사가 변하는 셀룰러 주소 뒤에 있고 허브에 안정적인 이름이 있을 때 이 설계의 쉬운 절반입니다. 그러면 허브는 계속 최신으로 유지해야 하는 기록이 아니라 인증된 트래픽에서 지사를 배웁니다. 계약은 단순합니다: 지사가 항상 시작합니다.

의도적으로 구성한 다음, 사람들이 당연히 작동한다고 여기는 부분을 검증하십시오. 두 단계 모두 몇 분이 걸리며, 이런 설계는 보통 두 번째에서 실패합니다.

어느 쪽이 안정적인 엔드포인트를 보유하는가

지사 구성은 허브의 엔드포인트와 공개 키를 지정합니다. 허브 구성은 지사의 공개 키와 허용된 내부 프리픽스를 지정하며, 신원이 마지막 패킷의 출발지 주소가 아니라 키에서 오기 때문에 엔드포인트를 전혀 담지 않을 수도 있습니다. 이 비대칭이 전체 메커니즘이며, 허브 쪽에서 탐색 문제의 한 부류를 통째로 없앱니다.

지사가 인증된 패킷을 보내면 허브는 그것이 도착한 출발지를 기록하고 그 매핑을 응답에 사용합니다. 그러면 셀룰러 링크의 재번호 부여는 다음 핸드셰이크 외에는 비용이 들지 않고, 더 이상 필요 없는 구성 요소는 전환 중에 실패할 수 없는 구성 요소가 됩니다. 이 속성은 장애 때가 아니라 계획된 변경 중에 시험할 가치가 있습니다. 누군가 양쪽 끝을 동시에 볼 수 있을 때 하십시오.

재번호 부여를 견디는 구성을 지사에 주십시오

엔드포인트와 keepalive는 지사에 두고, 허브의 피어 항목은 하드코딩된 주소가 없도록 유지하십시오. keepalive는 유휴 기간 후 허브가 요청되지 않은 트래픽을 보낼 수 있도록 변환된 매핑을 충분히 오래 열어 둡니다.

[Peer]
PublicKey = HUB_PUBLIC_KEY_BASE64
Endpoint = hub.example.net:51820
AllowedIPs = 10.60.0.0/24, 10.60.10.0/24
PersistentKeepalive = 25

이십오 초는 NAT 매핑을 살아 있게 유지하는 데 자주 인용되는 예이며 모든 피어에 대한 요구 사항은 아닙니다. 실제로 관찰하는 매핑 타임아웃에 맞춰 설정하고, 인터페이스가 켜져 있는 동안에는 데이터 한도가 있는 링크에서 트래픽을 발생시킨다는 점을 기억하십시오.

허브에서 지사 피어의 허용 프리픽스는 지사가 보낼 모든 것을 포함해야 합니다. 빠진 프리픽스는 먼 쪽에서 라우팅 실패처럼 동작하며 어느 쪽에서도 경고를 내지 않으므로 첫 실제 패킷 전에 검토할 가치가 있습니다. 첫 연결 전에 허브의 허용 프리픽스와 지사 인터페이스 주소를 대조하십시오.

매핑과 페일오버를 검증하십시오

핸드셰이크가 완료되고, 허브가 지사의 현재 엔드포인트를 나열하며, 터널을 통해 지사의 내부 주소에 도달할 수 있는지 확인하십시오. 이것이 기준선이며 누군가 셀룰러 링크를 만지기 전에 기록해야 합니다. 출력 두 줄이면 충분합니다. 타임스탬프와 함께 티켓에 보관하십시오.

wg show wg0
wg show wg0 latest-handshakes
ip route show default
ping -c 3 10.60.10.1

그다음 이 설계가 존재하는 이유인 장애를 시험하십시오. 기본 WAN을 뽑고 지사의 허브로 가는 기반 경로가 이제 셀룰러 인터페이스로 나가는지 확인하십시오. 터널은 끊어진 물리 경로를 고칠 수 없으므로 죽은 업링크를 여전히 가리키는 외부 경로는 핸드셰이크 타임아웃을 만들고, 그것은 정확히 허브 문제처럼 보입니다.

외부 경로가 명시적으로 바인딩되었거나 정책으로 라우팅된다면 페일오버에 그것이 포함되어야 합니다. 올바르게 읽히는 설계와 장애를 견디는 설계 사이의 그 간극이 보통 유일하게 빠진 것입니다.

이 설계가 해결하지 못하는 것

여기서는 지사로 들어오는 연결을 허용하지 않습니다. 본사의 무언가가 셀룰러 사이트로 전화를 걸어야 한다면 그 요구에는 터널 방향이 잘못되었고, 동적 DNS는 이름만 갱신합니다. 사업자의 변환, 인바운드 정책, 클라이언트의 엔드포인트 갱신이 모두 가로막고 있으며, 변경된 레코드는 통신사급 NAT를 열 수 없습니다.

지사의 프리픽스를 다른 모든 사이트와 구분하고, 그 게이트웨이가 전달할 범위를 제한하십시오. 안정적인 허브 엔드포인트는 탐색을 단순하게 하지만 라우팅 설계, 주소 계획, 어떤 애플리케이션 경로가 페일오버를 견디는가라는 질문에는 아무것도 하지 않습니다.

런북에 네 가지를 적으십시오: 누가 시작하는지, 어떤 프리픽스가 허용되는지, keepalive가 얼마나 긴지, 기본 링크가 끊기면 무슨 일이 일어나는지. 미래의 운영자가 새벽 세 시에 정말로 필요로 하는 것은 바로 그 줄입니다.

관련 글