Ограничења Cloud VPN-а која не можете подесити: IKE животни век и NAT пира

Cloud VPN преговара IKE животне векове унутар фиксних граница и на страни пира захтева NAT један-на-један. Планирајте удаљени уређај према томе, а не према страни Google.

Дајте удаљеном уређају животни век фазе 1 од 24 сата и тунел Cloud VPN-а остаје пао, иако је на страни Google све исправно конфигурисано. Пир предлаже вредност коју одговарач неће прихватити, па преговор или потпуно пропада или се бесконачно поново покреће. Cloud VPN ограничава фазу 1 на 36,000 секунди, десет сати, а тај лимит није подешавање које можете подићи. Промена припада удаљеном уређају.

Пир пита, одговарач одлучује

IKE је вежба усклађивања између два скупа предлога. Тунел настаје само тамо где се скупови преклапају унутар граница које одговарач прихвата, и зато животни век изван опсега не ствара никакав делимични тунел. Уобичајена грешка је третирати конфигурацију пира као листу жеља, а не као предлог. Празан пресек оставља тунел палим, колико год су усмеравање и селектори исправни.

Прочитајте сопствено стање тунела пре отварања случаја, јер детаљни статус обично именује фазу која је пропала:

gcloud compute vpn-tunnels describe office-tunnel \
  --region europe-west1 \
  --format="value(status,detailedStatus)"

Упоредите оно што се врати са подржаним скупом за ваш тип приступника и верзију IKE-а, и запишите оба селектора саобраћаја док сте тамо. Несклад селектора даје исти симптом палог тунела као несклад алгоритма, а за разлику од алгоритма то је ваше да поправите.

36,000 секунди је горња граница

Фаза 1 се зауставља на 36,000 секунди. Уређај подешен на 86,400 тражи нешто с чим се одговарач никада неће сложити, а поновни покушај не мења његово мишљење. Вратите удаљени предлог унутар опсега и иста конфигурација се успоставља; асиметрија је цела лекција, јер своју вредност можете снизити, а Google-ову не можете подићи.

Запишите изабрану вредност у пројектне белешке. Иначе следећи инжењер понови експеримент од 24 сата и дође до истог зида.

Подржани скуп се објављује по типу приступника и верзији IKE-а у прегледу Cloud VPN-а, па читајте део за своју топологију, а не општи IKE водич.

Тунел који пада по распореду

Фаза 2 се понаша другачије: када се два краја не слажу, обнављање кључева прати краћи интервал. Пир који несклад сматра фаталним уместо тога обара тунел, па један несклад може изгледати као два неповезана квара. Пазите на ритам обнављања кључева, не само на прво повезивање. Тунел који се подигне и потом пада у редовном такту чешће је несклад животног века него дефект усмеравања.

Повежите те временске ознаке пада са сопственим записима пира пре било какве измене, јер промена селектора или руте може опонашати исти ритам. Ако се такт поклапа са тајмером фазе 2, узрок је нађен без дирања предлога.

Скупови долазе из типа приступника

Скупови шифровања и интегритета нису профил по тунелу који уређујете како вам strongSwan допушта. Бирате их по типу приступника и верзији IKE-а, а тражење профила који не постоји губи једно поподне.

Стари уређај који не нуди ништа унутар подржаног скупа оставља два поштена пута: замените уређај или завршите на софтверском приступнику који контролишете и одатле усмерите у VPC. Све остало је заобилазно решење које пада на следећем прегледу.

Једна спољна адреса по уређају

Спољна адреса пира мора се пресликавати један-на-један на његову унутрашњу адресу. Преоптерећен PAT базен не може да ради, јер неколико домаћина иза једне јавне адресе не даје одговарачу начин да их раздвоји. Где неколико домаћина мора да дели адресу, тунел мора да заврши негде што може да их разликује.

Држите и ту спољну адресу стабилном. Преместите уређај иза другог NAT-а и веза се прекида иако се сваки предлог још увек поклапа. Вреди записати које су вредности Google-ове, а које ваше: животни векови, скупови и NAT један-на-један фиксни су на њиховој страни, док су предлози, селектори, усмеравање и BGP приоритети ваши.

Повезани чланци