Cloud VPN до VM на GCP: користете внатрешна IP, а не NAT IP

Кога локална мрежа ќе стигне до VPC преку Cloud VPN, дестинацијата за услуга на Compute Engine обично е внатрешната адреса на VM. Надворешната IPv4 адреса не е втора адреса што можете да ја ставите во истата приватна рута. Поголемиот дел од конфузијата во оваа област доаѓа од тоа што три адреси со три задачи се третираат како заменливи, затоа започнете со именување која од нив ја користи даден пакет.

Три адреси, три задачи

Именувајте ги сите три пред да отстранувате грешки на која било од нив, бидејќи одговорот го менува објектот што ќе го проверите следно.

Првата и припаѓа на тунелот. Втората и припаѓа на вашиот дизајн на рута и огнена бариера. Третата и припаѓа на дојдовниот интернет пристап и се мапира, а не се прикачува. Дизајн што работи за една од нив не кажува ништо за другите две.

Зошто надворешната адреса не е втор интерфејс

Водичот за адресирање е авторитетот за тоа како се разликуваат внатрешната и надворешната достапност на 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 е референцата за разликата меѓу внатрешно и надворешно користена погоре.