GCP Cloud VPN: проверете портата, тунелот и firewall-от по ред

Тунел што пријавува воспоставена врска додека секоја проверка истекува обично нема правило за VPC firewall. Проверете порта, селектори и тип на рутирање во тој ред.

Вашата конзола прикажува зелен тунел, локалното следење сѐ уште не може да стигне ниту една инстанца, а повторното градење на тунелот изгледа како очигледно решение. Тоа е ретко. Воспоставениот тунел докажува само дека две порти ја завршиле IKE размената. Не кажува ништо за тоа дали пакетот некогаш бил пуштен во вашиот VPC.

Четири одлуки стојат помеѓу таа зелена икона и одговор, и тие не успеваат во предвидлив ред. Почнете со најевтината.

Три објекти, и само еден од нив шифрира

VPN портата ја поседува надворешната адреса кон која шифрира вашиот партнер. Во конзолата никогаш не ја создавате рачно: изберете или резервирајте адреса во формуларот за поврзување и портата се појавува со неа. HA портата зафаќа две адреси на две интерфејси, што е важно при проверката на квоти подоцна.

Тунелот е спарувањето помеѓу таа порта и партнерот. Тој ја носи заедничката тајна и селекторите на сообраќај што ветува дека ќе ги заштити. Токму во тие селектори започнуваат повеќето тивки дефекти. Тунел чиј локален селектор покрива 10.0.0.0/24 нема да достави 10.0.1.0/24, колку и да изгледа здрава состојбата.

Далечната страна држи сопствена листа, обично наречена домен за шифрирање, и завршниот хардвер ја споредува со вашата. Ниту една страна не преговара за селектор што никогаш не ѝ бил даден.

Типот на рутирање одлучува што стигнува до табелата со рути

Cloud VPN нуди три форми на рутирање и тие не се мешаат чисто. Рутирањето засновано на политики ги задржува статичните парови селектори, рутирањето засновано на рути очекува самите да додадете статични рути, а динамичкото рутирање објавува префикси преку Cloud Router над BGP. Изберете едно намерно.

Динамичен тунел со рачно напишани статични рути покрај него создава табела со рути што се празни секогаш кога BGP сесијата ќе се заниша.

Динамичкото е единствената форма што дозволува заштитените префикси да се променат без повторно градење на тунелот, и го влече Cloud Router во множеството објекти што мора да ги проверите. Статичните селектори остануваат употребливи кога партнерот е хардверски firewall што не може да зборува BGP. Тогаш двата краја бараат исти опсези, а поспецифичниот запис мора да победи на двете. Пар што се разликува за една подмрежа се воспоставува и потоа носи половина од вашиот сообраќај.

Имплицитното одбивање стои зад тунелот

Влезниот сообраќај се оценува наспроти имплицитно одбивање со најнизок приоритет, и тоа правило не се грижи што пакетот пристигнал шифриран. Додека правило на firewall не го именува опсегот на локацијата и портата што се користи, пакетот се дешифрира, прегледува и отфрла. VPN дневникот останува чист цело време, бидејќи тунелот го направи точно она што го вети.

Наместо тоа читајте го дневникот на одбивања на firewall кога тунелот е активен, а проверката истекува, потоа ограничете правило на изворниот опсег и портите што ви требаат:

gcloud compute firewall-rules create allow-from-dc \
  --network=vpn-vpc \
  --direction=INGRESS \
  --source-ranges=192.168.10.0/24 \
  --allow=tcp:22,tcp:5432,icmp

Работење само во една насока е показател за firewall

Излезниот сообраќај се однесува поинаку, бидејќи имплицитното правило за дозвола им дозволува на инстанците да испраќаат каде било. Центар за податоци што не може да стигне до VM често стои зад совршено функционална излезна патека во другата насока. Таа асиметрија го одделува пропустот во firewall од дефект во рутирањето, бидејќи дефектот во рутирањето ги крши двете насоки одеднаш. Тестирајте ја обратната насока пред да уредите уште едно правило.

Создавањето адреси е исто така квотна операција. Проект близок до својата граница на надворешни адреси во употреба го одбива поврзувањето со грешка што се чита како неуспех на дозволи.

Селектори, квоти, потоа четирите проверки

Тунелите создадени во конзолата понекогаш враќаат празен далечен селектор на сообраќај од gcloud compute vpn-tunnels describe, додека генерираните рути го носат сообраќајот правилно. Споредете што запишува API со опсезите што навистина ги штитите пред да заклучите дека тунелот е погрешен. Создавањето преку API или SDK го држи селекторот експлицитен.

Квотите се другиот лесен пропуст. Побарајте зголемување пред прозорецот за одржување, а не за време на него, и проверете го бројот на адреси во истиот проект како портата.

Работете однадвор кон внатре: состојба на партнерот, двете листи со селектори, рута за секоја страна, влезно правило за изворниот опсег и портата, потоа фаќање пакети. Запишете ја адресата на портата, двете листи со селектори и типот на рутирање во тикетот за промена додека тунелот е нов, бидејќи на следниот инженер што ќе додаде подмрежа ќе му требаат сите три.

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