BGP сесија која никогаш не стигнува до Established на тунел на Cloud VPN обично не е проблем со рутирање. Тоа е проблем со поврзување: две адреси што треба меѓусебно да се огледуваат се внесени во погрешен редослед, или парот од првиот тунел е повторно искористен на вториот. Самиот тунел може да биде сосема здрав, додека сесијата стои на Waiting for peer, бидејќи IPsec и BGP се одделни преговори меѓу истите две крајни точки. Одлучете која од двете е расипана пред да изградите сѐ уште нешто.

Едно прашање решава повеќето случаи: дали уредот на партнерот воопшто ја гледа адресата на Cloud Router?

Состојбата на тунелот и состојбата на сесијата се различни проверки

Прво доаѓаат IKE и ESP. Ако тунелот не е воспоставен, ништо внатре во него нема значење и разговорот за BGP адресата е предвремен. Прочитајте ја состојбата и деталната состојба на тунелот, потоа состојбата на BGP партнерот на рутерот за истиот тој тунел.

Тунел што е подигнат додека неговиот BGP партнер е спуштен ја стеснува грешката на сесијата: адреса на партнерот, ASN или TCP 179 што пристигнува на внатрешната адреса. Тунел подигнат, сесија подигната и сѐ уште нема рути во VPC е трет случај. Менувањето адреси таму нема да помогне, бидејќи сесијата веќе работи, а префиксот едноставно не се објавува или не се претпочита. Раздвојувањето на овие три случаи е најголемиот дел од работата.

Секој тунел бара свој /30, со исполнети двата краја

Секој тунел на HA VPN добива link-local /30 од 169.254.0.0/16, една адреса на интерфејсот на Cloud Router и другата кај вашиот партнер. Полето за партнер мора да го именува далечниот крај, никогаш сопствената адреса на рутерот.

Два тунели значат два интерфејси на Cloud Router, секој со различен /30. Повторното користење на парот од тунелот 0 на тунелот 1 е грешката што изгледа уредно во збирна табела и умира во пакетот OPEN.

TunnelRouter interfacePeer addressWhat a swap produces
tunnel 0169.254.1.1/30169.254.1.2OPEN sent to itself or to nothing; session waits
tunnel 1169.254.1.5/30169.254.1.6same failure on the second session
bothone pair reusedone address reusedone 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 и дека по еден домаќин на секоја страна одговара. Потоа запишете ги конечните парови до имињата на тунелите, за да започне следното повторно градење од проверена табела, а не од резимето во конзолата.

Поврзани статии