Межы Cloud VPN, якія нельга наладзіць: тэрмін IKE і NAT суразмоўцы

Дайце аддаленай прыладзе тэрмін фазы 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 — вашы.