Cloud VPN да VM у GCP: выкарыстоўвайце ўнутраны IP, а не NAT IP

Канцавы пункт шлюза, унутраны адрас VM і знешні адрас NAT адзін-да-аднага выконваюць тры розныя задачы. Праверце, які з іх выкарыстоўвае ваш маршрут.

Калі лакальная сетка дасягае VPC праз Cloud VPN, прызначэннем для сэрвісу Compute Engine звычайна з'яўляецца ўнутраны адрас VM. Знешні адрас IPv4 — гэта не другі адрас, які можна падставіць у той жа прыватны маршрут. Большасць блытаніны тут узнікае таму, што тры адрасы з трыма задачамі разглядаюць як узаемазаменныя, таму пачніце з таго, каб назваць, які з іх выкарыстоўвае дадзены пакет.

Тры адрасы, тры задачы

Назвіце ўсе тры, перш чым адладжваць любы з іх, бо адказ змяняе аб'ект, які вы будзеце правяраць далей.

AddressJob
Cloud VPN endpointwhere the IPsec peers meet
Internal IPthe address your route and firewall must name
External IPv4the platform's inbound mapping, not a guest address

Першы належыць тунелю. Другі належыць вашай схеме маршруту і міжсеткавага экрана. Трэці належыць уваходнаму доступу з інтэрнэту і адлюстроўваецца, а не далучаецца. Схема, якая працуе для аднаго з іх, нічога не кажа пра два іншыя.

Чаму знешні адрас — не другі інтэрфейс

Кіраўніцтва па адрасацыі з'яўляецца крыніцай пра тое, чым адрозніваецца ўнутраная і знешняя дасяжнасць у Compute Engine. Знешні адрас IPv4 у Compute Engine — гэта адлюстраванне адзін-да-аднага на адзіны ўнутраны NIC інстанса, таму гасцявая сістэма ніколі не бачыць другога інтэрфейса ці другога адраса на гэтым NIC. Тое, што VM паведамляе знутры, па-ранейшаму адзін асноўны ўнутраны адрас.

Менавіта таму прыватны кліент, які накіроўвае трафік праз тунель да 10.24.1.7, і кліент, які нацэлены на знешні адрас VM, знаходзяцца на розных шляхах. Адкрыццё правіла міжсеткавага экрана для публічнага адраса нічога не змяняе ў маршруце VPC, які павінен несці трафік тунелю, а рэдагаванне маршруту ў гасцявой сістэме не зрушвае адлюстраванне платформы. Выберыце адрас, які называе ваш маршрут, і правярайце толькі тыя аб'екты, якія ім кіруюць. Гэтая дысцыпліна прыбірае большую частку здагадак з гэтага шляху пошуку няспраўнасцяў.

Прайдзіце шлях з дапамогай gcloud

Пачніце з інстанса і прачытайце абодва адрасы з аднаго аб'екта, каб ведаць, пра які з іх гаворыць ваша дакументацыя:

gcloud compute instances describe app-1 --zone=europe-west1-b \
  --format="value(networkInterfaces[0].networkIP,networkInterfaces[0].accessConfigs[0].natIP)"

Затым пацвердзіце маршрутызацыю і дазвол, ад якіх насамрэч залежыць шлях:

gcloud compute routes list --filter="destRange:10.24.1.0/24"
gcloud compute firewall-rules list --filter="sourceRanges:10.99.0.0/24"
gcloud compute vpn-tunnels describe TUNNEL_NAME --region=europe-west1

Прачытайце аб'яўленыя і вывучаныя дыяпазоны тунелю, маршрут VPC для падсеткі працоўнай нагрузкі і правіла міжсеткавага экрана, якое дазваляе лакальную крыніцу. Гэтыя тры павінны ўзгадніцца, перш чым слухач у гасцявой сістэме наогул стане актуальным.

Затым праверце гасцявую сістэму: ці слухае сэрвіс на ўнутраным адрасе і ці вяртаецца яго зваротны шлях зноў праз VPC? Слухач, прывязаны толькі да публічнага адраса, праваліць гэты тэст, нават калі кожны аб'ект на баку хмары правільны.

Публічны прэфікс — іншае пытанне

Нішто з вышэйсказанага не азначае, што кожны адрас унутры VPN абавязаны быць RFC1918. Аддаленую сетку цалкам законна нумараваць з публічнай прасторы, калі платформа падтрымлівае маршрутызацыю і аператар валодае паўнамоцтвамі на адрас. Гэта звычайны выбар схемы.

Гэта не тое ж самае, што ставіцца да звычайнага знешняга NAT-адраса як да яшчэ аднаго ўнутранага адраса падсеткі. Адзін — гэта прэфікс, які вы маршрутызуеце; другі — адлюстраванне, якое платформа ўжывае да ўваходнага доступу.

Знешні IPv6 і спецыяльна распрацаваныя схемы адрасацыі маюць сваю семантыку. Калі ваш план залежыць ад аднаго з іх, чытайце дакументацыю платформы для гэтай функцыі, а не абагульняйце выпадак IPv4. Адлюстраванне IPv4 — гэта звычайны выпадак, але не адзіны, і выключэнні маюць свае правілы.

Перакрыцце дыяпазонаў — іншая праблема

Перакрыцце прыватных дыяпазонаў — рэальная прычына, па якой людзі хапаюцца за публічны адрас, і гэта няправільны інструмент. Змена прызначэння на NAT-адрас VM не вырашае перакрыццё; яна змяняе, для якога адраса пакет сцвярджае, што ён прызначаны, не вызначаючы, як працуе зваротны шлях.

Вырашыце перакрыццё свядома: перанумаруйце, выкарыстайце падтрымоўваную схему трансляцыі або маршрутызуйце праз сетку, дзе прэфіксы не сутыкаюцца. Кожнае з гэтага — схема з уласнікам. NAT-адрас — не схема.

Дакументуйце два палі асобна

Запачаткуйце партнёра тунелю і прызначэнне працоўнай нагрузкі як два асобныя палі runbook, кожнае з маршрутам і правілам міжсеткавага экрана, якія яго падтрымліваюць. Тунель IPsec, які падняўся, гаворыць толькі пра тое, што бакі ўзгадніліся; ён нічога не кажа пра тое, на якім адрасе дасяжная працоўная нагрузка, і нічога пра тое, ці поўны яе прыватны маршрут.

Праверце рэальным кліентам на іншым баку: развяжыце імя, пераканайцеся, што яно вяртае ўнутраны адрас, падключыцеся і праверце зваротны трафік. Дакументацыя па адрасах IP у Compute Engine — гэта даведка для адрознення ўнутранага і знешняга, выкарыстанага вышэй.

Падобныя артыкулы