IP-oerdracht ynskeakelje op in besteande GCE VPN-gateway
canIpForward is in by te wurkjen eigenskip, gjin reden om de VM opnij te bouwen. Eksportearje de boarne, feroarje ien rigel, falidearje, en pas dan ta mei in refresh.
De VM is oanmakke sûnder IP-oerdracht, hy draait al de VPN-software, en de yndruk is om him opnij te bouwen út it sjabloan mei de flag oan. Dy werbou is net nedich. Compute Engine biedt canIpForward oan as in by te wurkjen eigenskip, en it dokumintearre fernijingspaad past it ta mei in refresh ynstee fan in werstart. Wat de flag eins regelet is smel: sûnder him smyt it platfoarm pakketten fuort dy't by de ynstânsje oankomme mar net oan it eigen adres fan de ynstânsje adressearre binne. In gateway dy't it ferkear fan oare masines trochjout docht krekt dat, dus de flag moat oan wêze. Alles dêrnei is gastkonfiguraasje en rûtelearring, dêr't de flag neat oan docht.
Wat de flag tastiet, en wat net
Mei oerdracht útskeakele behannelet it platfoarm de ynstânsje as in einpunt. Pakketten wêrfan't de bestimming it eigen adres fan de ynstânsje is, wurde besoarge; pakketten dy't de ynstânsje foar in oar trochjaan moat, net.
Mei oerdracht ynskeakele mei de ynstânsje as folgjende hop foar in VPC-route tsjinje, en dat is de rol dy't in VPN-apparaat nedich hat. De flag seit neat oer firewalls, gastrûtelearring, tunnelkonfiguraasje of weromwegen, en in wize wearde op in stikken gateway is noch altyd in stikken gateway.
Lês de hjoeddeiske eigenskip
Undersykje de ynstelling foardat jo wat feroarje, mei in allinnich-lêzen describe tsjin de bedoelde ynstânsje, projekt en sône:
gcloud compute instances describe VM_NAME --project PROJECT_ID --zone ZONE --format='value(canIpForward)'
In falske wearde is allinnich fan belang as dizze VM de folgjende hop wêze moat. Is dat sa, dan moat de rest fan it paad noch apart kontrolearre wurde, want de eigenskip is ien rigel yn in langer keatling.
Wurkje de besteande ynstânsje by
De proseduere fan Google foar it bywurkjen fan ynstânsje-eigenskippen eksportearret de hjoeddeiske boarne, feroaret de eigenskip en tsjinnet it resultaat yn. Dat is in oare wurkstream as de flag --can-ip-forward by it oanmeitsjen, en it is dy't op in draaiende VM wurket.
Eksportearje earst de definysje nei in lokaal bestân, en hâld in net-feroare kopy foar ferliking:
gcloud compute instances export VM_NAME --project PROJECT_ID --zone ZONE --destination=instance.yaml
Yn dat eksportearre bestân sette jo de eigenskip en feroarje jo neat oars:
canIpForward: true
Hâld de hiele boarne, ynklusyf syn fingerôfdruk. It bestân ferfange troch in YAML-dokumint fan ien rigel, of ûnferbûne bewurkings fan masinetype, skiif of ynterface yn deselde yntsjinning bondelje, is de manier dêr't in eigenskipsferoaring in ûnderbrekking fan wurdt.
Freegje it fernijingsmeganisme it bestân te falidearjen en te rapportearjen wat it nedich hawwe soe, foardat in effektive feroaring tastien wurdt:
gcloud compute instances update-from-file VM_NAME --project PROJECT_ID --zone ZONE --source=instance.yaml --most-disruptive-allowed-action=NO_EFFECT
Dy falidaasje-run skeakelet oerdracht net yn. Lês it antwurd foar ûnjildige eigenskippen en foar de aksje dy't it nedich seit te wêzen. Foar dizze isolearre feroaring is de dokumintearre aksje REFRESH. As it resultaat in werstart freget, befettet it bestân mear as de eigenskip dy't jo feroarje woene, dus besjoch it ynstee fan de werstart te jaan.
Pas it neisjoen bestân ta mei de refresh-limyt:
gcloud compute instances update-from-file VM_NAME --project PROJECT_ID --zone ZONE --source=instance.yaml --most-disruptive-allowed-action=REFRESH
Kontrolearje dat de operaasje klear is en rûn it describe-kommando opnij. As de fingerôfdruk net mear oerienkomt, hat immen oars de ynstânsje feroare wylst jo bewurken, dus eksportearje in farske kopy en besjoch de feroaring opnij ynstee fan jo ferâldere bestân troch te drukken.
De gast moat it pakket noch altyd rûte
Cloud-tastimming makket it apparaat gjin router. Befêstigje dat in VPC-route dizze VM as folgjende hop foar it bestimmingsprefiks kiest, en dat de gast tusken de tunnel en de juste ynterface rûtet mei syn eigen oerdrachtsbelied ynskeakele.
It firewallbelied moat sawol de ynderlike stream as de uterlike listener tastean. Allinnich de VPN-poarte iepenje beskriuwt it fersifere transport en seit neat oer de applikaasje-útwikseling deryn.
Uteinlik hat de bestimming in weromwei nei de kliïntpool nedich, of it ûntwerp moat boarnen bewust fertale. As de bestimming fertaalde ferkear sjocht, kontrolearje de fertaalde boarne; as it ûntwerp de pool behâldt, kontrolearje dy pool yn 'e weromroute en de tagongsregels. NAT tafoegje foardat jo beslute hokker ûntwerp jo wolle ferberget in ûntbrekkende rûte en feroaret it belied dat de bestimming sjocht.
Op in Linux-gateway is kernel-oerdracht diel fan 'e gastkonfiguraasje. In pfSense-apparaat hat syn eigen ekwivalent, en in Linux-sysctl-kommando deryn kopiearje is net de oerienkommende stap.
Ferifiearje fan 'e kliïnt dy't tagong nedich hat
Test fan in VPN-kliïnt nei ien doeltsjinst, net fan 'e gateway sels. In ferbining dy't op 'e gateway begjint brûkt in oare boarne en oefenet nea de oerdrachtsregels dy't jo krekt ynskeakele hawwe.
Registrearje de eigenskip yn wat it apparaat ek beheart. In mei de hân korrizjearre VM wurket oant syn folgjende ferfanging de oarspronklike ynstelling stil werombringt, en dy flater sil as in regresje yn 'e VPN-software lykje.
Wurkfolchoarder: lês de eigenskip, eksportearje en bewurkje ien rigel, falidearje mei NO_EFFECT, pas ta mei REFRESH, befêstigje dat de gast trochjout, en test dan fan in kliïnt.