Ota IP-edelleenlähetys käyttöön olemassa olevassa GCE VPN -yhdyskäytävässä

VM luotiin ilman IP-edelleenlähetystä, se ajaa jo VPN-ohjelmistoa, ja vaisto sanoo, että se pitäisi rakentaa uudelleen mallista lipun ollessa asetettuna. Se uudelleenrakennus on tarpeeton. Compute Engine tarjoaa canIpForwardin päivitettävänä ominaisuutena, ja dokumentoitu päivityspolku soveltaa sitä refreshillä uudelleenkäynnistyksen sijaan. Se, mitä lippu tosiasiassa ohjaa, on kapeaa: ilman sitä alusta pudottaa paketit, jotka saapuvat instanssille mutta eivät ole osoitettu instanssin omalle osoitteelle. Yhdyskäytävä, joka välittää muiden koneiden liikennettä, tekee juuri niin, joten lipun on oltava päällä. Kaikki sen jälkeen on vieraan kokoonpanoa ja reititystä, joihin lippu ei koske.

Mitä lippu sallii ja mitä ei

Kun edelleenlähetys on pois päältä, alusta kohtelee instanssia päätepisteenä. Paketit, joiden kohde on instanssin oma osoite, toimitetaan; paketteja, jotka instanssin pitäisi välittää eteenpäin jonkun toisen puolesta, ei toimiteta.

Kun edelleenlähetys on päällä, instanssi voi toimia VPC-reitin seuraavana hyppynä, ja se on rooli, jonka VPN-laite tarvitsee. Lippu ei kerro mitään palomuureista, vieraan reitityksestä, tunnelin kokoonpanosta tai paluureiteistä, ja arvo true rikkinäisessä yhdyskäytävässä on edelleen rikkinäinen yhdyskäytävä.

Lue nykyinen ominaisuus

Tarkista asetus ennen kuin muutat mitään, käyttäen vain lukuun tarkoitettua describe-komentoa aiottua instanssia, projektia ja vyöhykettä vastaan:

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

Arvo false on merkityksellinen vain, jos tämän VM:n on tarkoitus olla seuraava hyppy. Jos on, polun loppuosa on silti tarkistettava erikseen, koska ominaisuus on yksi rivi pidemmässä ketjussa.

Päivitä olemassa oleva instanssi

Googlen instanssin ominaisuuksien päivitysmenettely vie nykyisen resurssin, muuttaa ominaisuutta ja lähettää tuloksen. Se on eri työnkulku kuin luontihetken --can-ip-forward-lippu, ja juuri se toimii käynnissä olevassa VM:ssä.

Vie määritelmä ensin paikalliseen tiedostoon ja säilytä muuttumaton kopio vertailua varten:

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

Aseta kyseisessä vietytyssä tiedostossa ominaisuus äläkä muuta mitään muuta:

canIpForward: true

Säilytä koko resurssi, mukaan lukien sen sormenjälki. Tiedoston korvaaminen yhden rivin YAML-asiakirjalla tai toisiinsa liittymättömien konetyypin, levyn tai liitännän muutosten kokoaminen samaan lähetykseen on tapa, jolla ominaisuuden muutos muuttuu käyttökatkoksi.

Pyydä päivitysmekanismia validoimaan tiedosto ja ilmoittamaan, mitä se vaatisi, ennen kuin mitään tehokasta muutosta sallitaan:

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

Se validointiajo ei ota edelleenlähetystä käyttöön. Lue vastauksesta virheelliset ominaisuudet ja toimenpide, jonka se sanoo tarvittavan. Tälle eristetylle muutokselle dokumentoitu toimenpide on REFRESH. Jos tulos pyytää uudelleenkäynnistystä, tiedosto sisältää enemmän kuin ominaisuuden, jota halusit muuttaa, joten tarkista se sen sijaan, että myöntäisit uudelleenkäynnistyksen.

Käytä tarkistettua tiedostoa refresh-rajoituksella:

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

Tarkista, että toimenpide valmistui, ja aja describe-komento uudelleen. Jos sormenjälki ei enää täsmää, joku muu muutti instanssia muokkauksesi aikana, joten vie tuore kopio ja tarkista muutos uudelleen sen sijaan, että pakottaisit vanhentuneen tiedostosi läpi.

Vieraan on yhä reititettävä paketti

Pilven käyttöoikeus ei tee laitteesta reititintä. Varmista, että VPC-reitti valitsee tämän VM:n kohdeprefiksin seuraavaksi hypyksi, ja että vieras reitittää tunnelin ja oikean liitännän välillä oma edelleenlähetyskäytäntönsä ollessa päällä.

Palomuurikäytännön on sallittava sekä sisäinen virta että ulkoinen kuuntelija. Vain VPN-portin avaaminen kuvaa salatun kuljetuksen eikä kerro mitään sen sisäisestä sovellusvaihdosta.

Lopuksi kohteella on oltava paluupolku asiakaspooliin, tai suunnittelun on käännettävä lähteet tarkoituksella. Jos kohde näkee käännettyä liikennettä, tarkista käännetty lähde; jos suunnittelu säilyttää poolin, tarkista se pooli paluureitillä ja käyttösäännöissä. NAT:n lisääminen ennen kuin päätät, mitä suunnittelua haluat, kätkee puuttuvan reitin ja muuttaa käytäntöä, jonka kohde näkee.

Linux-yhdyskäytävässä ytimen edelleenlähetys on osa vieraan kokoonpanoa. pfSense-laitteella on oma vastineensa, eikä Linuxin sysctl-komennon kopioiminen siihen ole vastaava askel.

Varmista asiakkaasta, joka tarvitsee pääsyn

Testaa VPN-asiakkaasta yhteen kohdepalveluun, älä itse yhdyskäytävästä. Yhdyskäytävässä aloitettu yhteys käyttää eri lähdettä eikä koskaan harjoita juuri käyttöön ottamiasi edelleenlähetyssääntöjä.

Kirjaa ominaisuus siihen, mikä laitetta hallinnoi. Käsin korjattu VM toimii, kunnes sen seuraava korvaaminen hiljaa palauttaa alkuperäisen asetuksen, ja se vika näyttää VPN-ohjelmiston regressionilta.

Työn järjestys: lue ominaisuus, vie ja muokkaa yksi rivi, validoi NO_EFFECTillä, käytä REFRESHillä, varmista että vieras välittää, testaa sitten asiakkaasta.