GCP HA VPN: BGP 세션이 Waiting for peer에서 멈출 때, 주소 쌍 뒤바뀜
Cloud VPN BGP 세션이 Waiting for peer에서 멈춰 있다면 보통 터널 주소와 피어 주소가 뒤바뀐 경우입니다. 무언가를 다시 만들기 전에 쌍을 확인하세요.
Cloud VPN 터널에서 Established에 도달하지 못하는 BGP 세션은 보통 라우팅 문제가 아니라 서로를 비춰야 하는 두 주소가 반대 순서로 입력되었거나 첫 터널의 쌍이 두 번째 터널에 재사용된 배선 문제입니다. 터널 자체는 완전히 정상인데 세션만 Waiting for peer에 머무를 수 있습니다. IPsec과 BGP는 같은 두 엔드포인트 사이의 별개 협상이기 때문입니다. 무엇이든 다시 만들기 전에 둘 중 어느 쪽이 고장 났는지 정하세요.
대부분의 사례를 가르는 질문은 하나입니다: 피어 장비가 Cloud Router의 주소를 아예 보는가?
터널 상태와 세션 상태는 서로 다른 점검입니다
먼저 IKE와 ESP입니다. 터널이 수립되지 않았다면 그 안의 무엇도 중요하지 않고 BGP 주소 논의는 이릅니다. 터널의 상태와 상세 상태를 읽고, 그다음 같은 터널에 대한 라우터의 BGP 피어 상태를 읽으세요.
터널은 올라와 있는데 BGP 피어가 내려가 있다면 결함은 세션으로 좁혀집니다: 피어 주소, ASN, 또는 내부 주소로 도착하는 TCP 179 중 하나입니다. 터널이 올라와 있고 세션도 올라와 있으며 여전히 VPC에 경로가 없는 경우가 세 번째입니다. 주소를 바꿔도 세션은 이미 동작하고 있고 프리픽스가 그저 광고되지 않거나 선호되지 않을 뿐이므로 도움이 되지 않습니다. 이 세 가지를 구분하는 것이 작업의 대부분입니다.
각 터널에는 양끝을 채운 전용 /30이 필요합니다
HA VPN의 각 터널은 169.254.0.0/16에서 link-local /30을 하나 받고, 한 주소는 Cloud Router 인터페이스에 다른 하나는 피어에 둡니다. 피어 필드에는 반드시 반대편 끝을 적고, 라우터 자신의 주소는 절대 적지 마세요.
터널이 둘이면 Cloud Router의 인터페이스도 둘이고 각각 다른 /30을 가집니다. 터널 0의 쌍을 터널 1에 재사용하는 것이 요약 표에서는 깔끔해 보이지만 OPEN 패킷에서 죽는 실수입니다.
| Tunnel | Router interface | Peer address | What a swap produces |
|---|---|---|---|
| tunnel 0 | 169.254.1.1/30 | 169.254.1.2 | OPEN sent to itself or to nothing; session waits |
| tunnel 1 | 169.254.1.5/30 | 169.254.1.6 | same failure on the second session |
| both | one pair reused | one address reused | one session up, the other never leaves waiting |
쌍은 콘솔 요약이 아니라 라우터 리소스에서 읽으세요. 요약은 피어 주소를 잘못 읽기 쉬운 열에 나열하고, 인터페이스의 ipRange와 피어의 peerIpAddress가 같은 /30의 반대쪽 끝을 가리켜야 합니다.
뒤바뀜은 보통 재구성 중에 일어납니다
터널을 다시 만들 때 쌍이 엇갈립니다. 예전 터널의 피어 주소를 새 터널의 인터페이스 필드에 복사하거나, 새 세션을 이전 세션의 피어로 돌려 놓습니다. 어느 쪽이든 Cloud Router는 이제 자기 자신인 주소나 뒤에 터널이 없는 주소로 OPEN 패킷을 보냅니다.
콘솔을 열기 전에 쌍을 적어 두세요: 터널 이름, 인터페이스, 라우터 주소, 피어 주소, 피어 ASN입니다. 그다음 두 터널을 한 번에 만들어 두 번째가 첫 번째의 잔여물로 채워지지 않게 하세요.
세션이 기다리는 또 다른 세 가지 이유
첫째는 피어 ASN입니다: 양쪽이 상대의 ASN으로 설정되어야 하고, 어긋나면 피어까지는 도달하지만 절대 수립되지 않습니다. 둘째는 피어 자체의 방화벽으로, 터널 인터페이스에서 TCP 179를 허용해야 하며 IKE나 ESP 규칙으로는 부족합니다. 셋째는 이웃으로 설정한 주소와 다른 출발지 주소에서 응답하는 피어입니다.
판별 기준은 피어 자신의 로그입니다. BGP 요약에 그 주소의 이웃이 없으면 패킷이 도착하지 않는 것이고 쌍이나 경로가 틀렸습니다. 이웃이 Active나 Connect에 머물러 있으면 패킷은 도착하고 세션 매개변수가 어긋난 것입니다.
패킷이 지나가는 순서대로 확인하세요
바깥으로 나아가세요: 터널 상태, 다음 라우터의 BGP 피어 상태, 다음 피어의 BGP 요약, 마지막으로 경로입니다. 처음 둘이 정상이면 Cloud VPN 쪽 편집을 멈추고 피어 장비를 다루세요. 라우터가 피어를 내려감으로 보고하는데 장비에 이웃이 없다면 쌍이 틀렸거나 BGP 포트가 필터링된 것입니다. 피어의 터널 인터페이스에서 패킷을 캡처하면 OPEN 패킷이 거기에 도착하는지 아예 도착하지 않는지가 한눈에 보입니다.
gcloud compute routers get-status ROUTER --region=REGION 은 피어 상태를 그것이 사용하는 주소 옆에 출력하며, 비교해야 할 쌍이 바로 이것입니다.
세션이 수립되면 학습한 프리픽스가 VPC 경로 표에 나타나는지, 양쪽에서 호스트 하나씩 응답하는지 확인하세요. 그다음 최종 쌍을 터널 이름 옆에 기록해 두어 다음 재구성이 콘솔 요약이 아니라 검증된 표에서 시작되게 하세요.