셀룰러 두 사이트, 인바운드 포트 없음: 작동하는 허브 만들기

셀룰러 업링크에 연결된 두 사이트는 어느 쪽도 요청되지 않은 IPv4 연결을 받을 수 없어 양방향 모두 같은 문제를 안고 있습니다. 작동하는 구조는 가운데에 접근 가능한 제삼자를 두고, 각 사이트는 바깥으로 연결하며 가운데는 승인한 트래픽만 전달합니다. 그 가운데는 직접 운영하는 라우터일 수도, 피어를 소개하는 제품일 수도 있으며 둘은 같은 것이 아닙니다. 아래 단계는 다음 단계가 그것에 의존하기 전에 각 단계가 증거를 남기도록 배열되어 있습니다.

어느 사이트도 전화를 받을 수 없으므로 둘 다 바깥으로 전화해야 합니다

설계하기 전에 제약을 확인하십시오. 통신사가 WAN 인터페이스에 사설 주소를 준다면 변환이 상류에서 일어나므로, 사이트 자체 라우터의 포트 포워딩으로는 접근 가능하게 만들 수 없습니다. 같은 링크에 공인 IPv6 주소가 있을 수 있고 설계가 완전히 달라지므로, 확인은 두 체계를 모두 다룹니다. 같은 통신사를 공유하더라도 두 사이트의 제약이 같기는 드물기 때문에 사이트별로 답을 적어 두십시오.

일반적인 셀룰러 상황은 통신사의 변환된 대역 주소와 그를 지나는 기본 경로처럼 보입니다. 이것은 고칠 결함이 아니라 허브가 존재하는 이유입니다. 찾고 있는 것은 사이트가 먼저 말하지 않고도 제삼자가 도달할 수 있는 주소입니다.

눈앞의 사이트 주소 질문에는 두 명령이 답합니다. 사이트 라우터에서 실행하고, 그 뒤의 노트북에서는 실행하지 마십시오:

ip -4 addr show scope global
ip -6 addr show scope global

누가 피어를 소개하고 누가 패킷을 나르는가

소개와 전송은 별개의 작업이지만 제품은 경계를 드러내지 않은 채 둘을 묶는 경우가 많습니다. 만남 메커니즘은 두 피어가 후보 경로를 찾도록 돕고, 직접 경로가 없을 때 릴레이가 그들의 패킷을 나릅니다. 피어를 소개하는 서비스를 사도 라우터가 생기는 것은 아니며, 그 차이가 설계에 허브가 필요한지를 결정합니다.

트래버설에는 자체 어휘가 있고, 그 단어들은 보증이 아니라 역할을 설명합니다. ICE 명세 는 후보와 연결성 검사를 설명하고, STUN은 주소 변환을 알아내는 한 가지 방법을, TURN은 그것을 구현한 애플리케이션을 위한 릴레이 전송을 설명합니다. 이런 메커니즘은 발견 주소로 향하게 했을 뿐이므로 어느 것도 일반 게이트웨이에 나타나지 않습니다. 트래버설은 제품 능력으로 검증하고, 시험이 반대를 보일 때까지 릴레이를 가정하십시오.

사이트마다 하나의 경로, 피어가 소유

허브에는 사이트마다 하나의 터널, 각각 뒤에 별도의 LAN 프리픽스, 그리고 각 프리픽스의 소유자를 지명하는 경로가 필요합니다. 예에서 허브는 10.61.0.1, 사이트 A는 LAN 10.60.10.0/24를 가진 10.61.0.11, 사이트 B는 LAN 10.60.20.0/24를 가진 10.61.0.12입니다. 아래 각 경로는 터널 인터페이스가 아니라 프리픽스를 소유한 피어를 가리킵니다:

ip route add 10.60.10.0/24 via 10.61.0.11 dev wg0
ip route add 10.60.20.0/24 via 10.61.0.12 dev wg0
sysctl net.ipv4.ip_forward
ip route get 10.60.20.55 from 10.60.10.77

포워딩이 켜져 있지 않으면 패킷이 허브에서 멈추고 원인을 가리키는 오류도 남지 않으므로, 포워딩은 켜져 있어야 합니다. 마지막 명령은 출발지를 조회에 포함해 사이트 A의 LAN에서 사이트 B의 LAN으로 패킷이 어느 경로를 탈지 묻기 때문에 실제 질문에 답합니다. 터널 인터페이스를 지명하는 조회는 증거로, 기본 경로로 떨어지는 조회는 수수께끼가 아니라 빠진 경로로 다루십시오. 모든 피어 사이를 포워딩하는 허브는 두 사이트를 평면 네트워크로 만들고 있다고 생각한 접근 정책이 더는 적용되지 않으므로, 통과는 의도적으로 제한하십시오.

암호화가 어디서 끝나는지도 정하십시오. 허브가 두 터널 끝을 모두 가지면 그 장비의 운영자와 워크로드가 신뢰와 가용성 모델에 들어오고, 그 대역폭이 경로의 일부가 됩니다.

통신사를 거쳐 각 매핑을 살려 두십시오

각 사이트는 자기 터널을 시작하고, 각자가 변환 매핑을 살려 두지 않으면 통신사가 그것을 잊습니다. 시작하는 쪽의 키프얼라이브가 핸드셰이크 사이에 그 매핑을 유지합니다. 허용 프리픽스를 허브 주소와 원격 LAN으로 한정해 침해된 피어가 자기 것이 아닌 프리픽스를 주장하지 못하게 하십시오:

[Peer]
PublicKey = <hub public key>
Endpoint = 192.0.2.10:51820
AllowedIPs = 10.61.0.1/32, 10.60.20.0/24
PersistentKeepalive = 25

다른 사이트에서 그 사이트의 원격 프리픽스로 블록을 그대로 복제하고, 터널 범위 전체를 허용하려는 충동을 억누르십시오. 멈췄다가 새 출발 포트에서 다시 시작하는 핸드셰이크는 만료된 매핑의 서명이고, 핸드셰이크 시각은 그것이 일어났다는 증거입니다. 통신사의 타임아웃보다 짧은 간격은 나중에 고치는 대신 만료를 막습니다. 통신사가 변환 동작을 바꾸면 그 시각들도 함께 바뀔 것으로 예상하십시오.

양방향을 증명한 뒤 복구를 증명하십시오

검증은 방향성을 가지므로 A에서 B로 가는 ping은 설계의 절반을 증명하고 돌아오는 경로에 대해서는 아무것도 말하지 않습니다. 허브에서 같은 출발지 인식 조회로 응답 경로를 확인하고 반대편에서 시험을 반복하십시오. 한 시간 유휴였던 터널은 오래된 매핑을 시험하고 있을 수 있으므로 새 핸드셰이크도 증거에 포함시키십시오:

wg show wg0 latest-handshakes
ping -c 3 10.60.20.55
traceroute -n 10.60.20.55

그다음 원하는 성공이 아니라 예상하는 실패를 시험하십시오. 한 사이트의 업링크를 다시 시작하고, 통신사 쪽 변경이 있을 때마다 운영자가 필요한 설계는 미완성이므로, 어느 쪽 끝도 사람이 건드리지 않아도 터널이 돌아오는지 확인하십시오. 기본 경로, 있으면 IPv6 대안, 허브를 쓸 수 없을 때의 동작을 기록하십시오. 허브는 이제 가용성 모델의 일부이므로, 장애 중에 발견하는 대신 적어 두십시오.