Вклучување на препраќање на IP на постоечка GCE VPN порта

VM-от е создаден без препраќање на IP, веќе го извршува VPN софтверот, и инстинктот е да се изгради одново од шаблонот со поставено знаменце. Тоа повторно изградување е непотребно. Compute Engine го изложува canIpForward како ажурирливо својство, а документираната патека за ажурирање го применува со refresh наместо со рестарт. Она што знаменцето всушност го контролира е тесно: без него платформата ги отфрла пакетите што пристигнуваат до инстанцата, но не се адресирани до сопствената адреса на инстанцата. Порта што препраќа сообраќај на други машини го прави токму тоа, затоа знаменцето мора да биде вклучено. Сѐ потоа е конфигурација на гостинот и рутирање, кои знаменцето не ги допира.

Што дозволува знаменцето, а што не

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

Кога препраќањето е овозможено, инстанцата може да дејствува како следен скок за VPC рута, а тоа е улогата што му е потребна на VPN уред. Знаменцето не кажува ништо за огнени ѕидови, рутирање на гостинот, конфигурација на тунелот или повратни патеки, и вредноста true на расипана порта е сѐ уште расипана порта.

Прочитајте го тековното својство

Проверете го поставувањето пред да смените нешто, со describe само за читање кон предвидената инстанца, проект и зона:

gcloud compute instances describe VM_NAME --project PROJECT_ID --zone ZONE --format='value(canIpForward)'

Вредноста false е важна само ако овој VM треба да биде следен скок. Ако е така, остатокот од патеката сѐ уште мора да се провери одделно, бидејќи својството е една линија во подолг ланец.

Ажурирајте ја постоечката инстанца

Постапката на Google за ажурирање на својства на инстанца го извезува тековниот ресурс, го менува својството и го поднесува резултатот. Тоа е различен работен тек од знаменцето --can-ip-forward при создавањето, и тоа е она што работи на VM во работа.

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

gcloud compute instances export VM_NAME --project PROJECT_ID --zone ZONE --destination=instance.yaml

Во таа извезена датотека поставете го својството и не менувајте ништо друго:

canIpForward: true

Задржете го целиот ресурс, вклучително и неговиот отпечаток. Замената на датотеката со едноредов YAML документ, или групирањето на неповрзани измени на типот на машината, дискот или интерфејсот во истото поднесување, е начинот на кој промената на својство станува прекин.

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

gcloud compute instances update-from-file VM_NAME --project PROJECT_ID --zone ZONE --source=instance.yaml --most-disruptive-allowed-action=NO_EFFECT

Тоа извршување за валидација не го овозможува препраќањето. Прочитајте го одговорот за невалидни својства и за дејството што се наведува како потребно. За оваа изолирана промена документираното дејство е REFRESH. Ако резултатот бара рестарт, датотеката содржи повеќе од својството што сте сакале да го смените, затоа проверете ја наместо да го дозволите рестартот.

Применете ја прегледаната датотека со ограничувањето refresh:

gcloud compute instances update-from-file VM_NAME --project PROJECT_ID --zone ZONE --source=instance.yaml --most-disruptive-allowed-action=REFRESH

Проверете дали операцијата завршила и повторно извршете ја командата describe. Ако отпечатокот веќе не се совпаѓа, некој друг ја сменил инстанцата додека сте уредувале, затоа извезете свежа копија и повторно прегледајте ја промената наместо да ја протурите вашата застарена датотека.

Гостинот сѐ уште треба да го рутира пакетот

Дозволата во облакот не го прави уредот рутер. Потврдете дека VPC рута ја избира оваа VM како следен скок за префиксот на дестинацијата, и дека гостинот рутира меѓу тунелот и вистинскиот интерфејс со сопствената политика за препраќање вклучена.

Политиката на огнениот ѕид мора да го дозволи внатрешниот тек, како и надворешниот слушател. Отворањето само на портата VPN го опишува шифрираниот транспорт и не кажува ништо за размената на апликацијата внатре во него.

На крајот, дестинацијата има потреба од повратна патека до базенот на клиенти, или дизајнот мора намерно да ги преведува изворите. Ако дестинацијата гледа преведен сообраќај, проверете го преведениот извор; ако дизајнот го задржува базенот, проверете го тој базен во повратната рута и правилата за пристап. Додавањето NAT пред да одлучите каков дизајн сакате крие рута што недостасува и ја менува политиката што ја гледа дестинацијата.

На Linux порта, препраќањето во јадрото е дел од конфигурацијата на гостинот. Уредот pfSense има свој еквивалент, и копирањето на Linux sysctl команда во него не е соодветниот чекор.

Проверете од клиентот на кој му е потребен пристап

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

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

Редослед на работа: прочитајте го својството, извезете и уредете една линија, валидирајте со NO_EFFECT, применете со REFRESH, потврдете дека гостинот препраќа, потоа тестирајте од клиент.