Cloud VPN의 BGP 주소는 NIC가 아니라 터널 안에 있습니다

VPN의 Cloud Router 페이지를 열면 169.254.0.0/16 안의 주소를 가진 BGP 세션이 여러분을 바라보고 있습니다. 자연스러운 반응은 그 주소를 VM 어딘가에 두고 세션이 올라오기를 기다리는 것입니다. 그 반응은 특정한 방식으로 틀렸습니다. 이 쌍은 IPsec 터널이 만드는 논리적 링크에 속하며, 머신의 평범한 네트워크 인터페이스에 속하지 않습니다. NIC에 무엇을 더해도 터널이 BGP를 운반하게 되지는 않습니다.

쌍을 호스트에 더하지 말고 스택을 따라 내려가십시오.

콘솔이 쌍을 보여 주는 곳에서 시작하십시오

세션 페이지에는 Cloud Router의 BGP 주소와 피어 주소가 나열되며, IPv4 HA VPN에서는 둘 다 link-local입니다. 그 옆에는 터널을 종료하는 외부 게이트웨이 주소가 있습니다. 이들은 다른 객체입니다. link-local 쌍은 안쪽에 있고, 게이트웨이 주소는 바깥쪽에 있으며 다른 무엇이 동작하기 전에 라우팅 가능해야 합니다.

설정 파일을 열기 전에 셋 다 적어 두십시오. 그것들을 뒤섞는 것이 바로 전체 실패 유형이기 때문입니다.

그것을 운반하는 터널까지 내려가십시오

link-local 쌍은 두 게이트웨이 사이에 IPsec 보안 연결이 존재한 뒤에야 의미가 있습니다. Google 쪽에서는 HA VPN 터널이 두 인터페이스에서 그것을 만듭니다. 여러분 쪽에서는 피어가 협상한 것이 그것입니다. 먼저 swanctl --list-sas으로 데이터 연결을 확인하고 어느 터널이 어느 인터페이스에서 올라와 있는지 적어 두십시오. 죽은 터널 위의 건강한 BGP 세션은 불가능하고, 희망에 찬 설정을 가진 죽은 터널은 일상이기 때문입니다.

BGP 패킷은 내부 IP 트래픽입니다. 외부 네트워크는 그것을 결코 보지 못하므로 어떤 스위치도 두 주소를 하나의 VLAN에 둘 필요가 없습니다.

이제 Linux 피어를 맞게 설정하십시오

지원되는 터널 설계를 고르고 내부 주소는 그것이 정하게 하십시오. 라우팅 기반 인터페이스에서는 라우팅 항목과 협상된 트래픽 선택자가 일치해야 합니다. 인터페이스 이름만으로는 아무것도 허용하지 않기 때문입니다. BIRD를 내부 로컬 주소와 Cloud Router의 내부 주소로 향하게 하고, 세션 페이지의 AS 번호를 설정하고, 보호 경로 안에서 TCP 179를 허용하십시오. 먼 외부 주소로 가는 경로는 물리 업링크에 두어 터널이 자기 자신의 전송을 가로채지 않게 하십시오.

스스로를 라우팅하는 터널은 핸드셰이크가 붙은 루프이며, 한 시간 동안 방화벽 문제처럼 보일 것입니다.

전체를 한 번에 보지 말고 각 단계를 순서대로 확인하십시오

단계를 밟아 가십시오. 보안 연결이 올라왔는지, 터널 주소에서 내부 피어에 닿는지, BGP 세션이 성립했는지, 프리픽스가 수락되었는지, 그다음 워크로드 프리픽스가 실제로 사용되는지. birdc show protocols은 세 번째 질문에만 답합니다. 그래서 사람들이 일찍 승리를 선언합니다.

성립한 이웃은 양쪽이 필요한 프리픽스를 광고했다거나 그 경로가 선호로 설치되었다는 것을 보장하지 않습니다.

세션이 성립했는데 트래픽이 여전히 잘못된 경로를 탄다면, 광고된 프리픽스와 라우팅 테이블이 그것을 어떻게 다루는지 비교하십시오. 다른 곳의 더 구체적인 경로나 다른 경로에 대한 선호는 동작하는 BGP 세션과 쓸모없는 포워딩을 줍니다.

이것을 Router Appliance에 적용하기 전에 멈추십시오

Network Connectivity Center Router Appliance는 다른 연결 모델입니다. 그 Cloud Router 피어는 HA VPN의 link-local 쌍이 아니라 VPC와 서브넷 배치에서 나온 내부 주소를 사용합니다. 실제 목표가 라우팅 VM과의 BGP라면 link-local 세션을 복사하지 말고 그 제품의 인터페이스 요구 사항을 따르십시오.

link-local 범위는 여전히 말 그대로입니다. 논리적 터널이 이 인접성을 제공하며, VPC 전역에서 임의의 link-local 목적지를 라우팅하도록 허가하지는 않습니다.