OpenVPN op GCE: foeg in alias-IP ta foardat jo rûtes push

In klant skillet de OpenVPN-server op in Compute Engine-VM, it statusfinster seit ferbûn, en in ping nei in host yn 'e VPC giet noch altyd nearne hinne. De ympuls is om noch in push-regel ta te foegjen, en dat reparearret it nea. Compute Engine beslút wêr't pakketten hinne geane op grûn fan syn eigen rûtetabel en fan 'e adressen dy't in VM-ynterface eins hat, dus in tunnelpool dy't de VM net besit is in pool dêr't nimmen nei leveret.

Folgje it mislearjende pakket ynstee fan it konfiguraasjebestân, en de ûntbrekkende stikken ferskine yn folchoarder.

Begjin by it pakket dat stjert

De SYN ferlit de klant, komt yn 'e tunnel telâne en berikt de VM as in ynkapselle pakket foar in bestimming yn 'e VPC. OpenVPN ûntkapsellet it en besiket it troch eth0 troch te stjoeren, wêr't de fabric foar alle oare dingen ien fraach stelt: besit dizze ynstânsje it bestimmingsadres. In tunnelpool dy't út it subnet fan in oar snien is, falt foar dy fraach, en it pakket wurdt fuortgoaid foardat hokker rûte of firewallregel dan ek rieplachte wurdt.

De rjochting fan klant nei VPC hat dus twa aparte easken, en gjin ien fan beide is in push-ynstruksje. De VM hat in aliasberik nedich dat de tunnelpool dekt, en dat is wat it in rjochtmatige eigener fan dy adressen makket. De VPC hat in rûte nedich dy't de VM foar elk beskermde foarheaksel as folgjende hop neamt. Mis ien fan beide en it pakket stjert op in oare plak, wylst de klant deselde stilte sjocht.

Lês de flater yn dy folchoarder, want fan 'e klantkant ôf lykje de twa betingsten identyk. In tunnel dy't ferbûn rapportearret wylst neat antwurdet, is it skaaimerk fan in topologyske probleem en net fan in minne cipher.

Besit de ynstânsje de tunnelpool

Jou de VM in sekundêr berik binnen syn eigen subnet en lit OpenVPN adressen krekt út dat berik útjaan. Op in ynstânsje mei primêr adres 10.156.0.10/20 hâldt in /28-alias de pool apart fan 'e adressen dy't oare ynstânsjes al hawwe:

gcloud compute instances network-interfaces update openvpn-vm \
  --zone=europe-west1-b \
  --aliases=eth0:10.156.1.0/28

De server-ynstruksje moat dan itselde blok beskriuwe. It earste adres wurdt de tunnelgateway en de oare adressen wurde oan klanten útjûn. Twa getallen beskriuwe hjir ien blok, in netwurk en in netmasker, en dat is de poolsyntaksis dy't OpenVPN noch ferwachtet.

server 10.156.1.0 255.255.255.240

Befêstigje dat it adres wier op 'e ynterface telâne kaam is en net allinnich yn 'e OpenVPN-konfiguraasje stiet. De fabric stjoert troch wat de NIC rapportearret, net wat de daemon leaut. Ien opdracht beslút it:

ip -4 addr show dev eth0

In sekundêr adres dat nea eth0 berikt, of in pool dy't in oar subnet oerlaapet, ferskynt letter as sporaadsk ferlies ynstee fan as in startflater. De daemon start, klanten ferbine, en allinnich guon bestimmingen dogge it ferkeard. Hâld it aliasberik lyts sadat de pool yn in rûtetabel maklik te werkenjen is. Snij it nea út in subnet dat in oare ynstânsje al brûkt.

Jou it weromferkear in folgjende hop

In antwurd fan in host yn 'e VPC is adressearre oan in klantadres yn 'e tunnelpool, dat by gjin subnet heart dat de VPC ken. Sûnder in rûte foar dy pool stoppet it antwurd by de earste hop sûnder treffer, en it fersyk kin oan 'e oare kant best slagge wêze.

gcloud compute routes create openvpn-return \
  --network=prod-vpc \
  --destination-range=192.168.127.0/24 \
  --next-hop-instance=openvpn-vm \
  --next-hop-instance-zone=europe-west1-b \
  --priority=800

Deselde rûte is nedich foar elk foarheaksel dat efter in klant leit ynstee fan yn 'e VPC. Dy foarheaksels hawwe ek in iroute-ynskriuwing nedich yn 'e ccd-bestân fan dy klant. Dy ynskriuwing is boekhâlding oan 'e serverkant: it fertelt de server hokker klant it foarheaksel besit, en it ynstallearret neat op 'e klant sels.

Hâld de push-list foar de klantkant fan it petear, want dy foeget allinnich rûtes ta oan 'e masine dy't ferbynt. In push-regel foar in VPC-subnet en in VPC-rûte werom nei de pool binne twa helten fan itselde paad, en eltse helte allinnich leveret in tunnel dy't fersiken draacht mar gjin antwurden.

Firewalls, trochstjoeren en de hops dêrtusken

De VPC-firewall beoardielet it ûntkapselle pakket, dus in yngeande regel moat de tunnelpool talitte en elk sitefoarheaksel dat de VM op dy wize berikt. In standert-weger-hâlding falt hjir stil: it pakket wurdt nei ûntkapseling fuortgoaid, en it OpenVPN-log lit in sûne sesje sjen.

Kontrolearje op elke Linux-host dy't trochstjoert ynstee fan te terminearen oft net.ipv4.ip_forward oan is. De eigendomsregel jildt dêr ek: in bak dy't trochstjoert foar in subnet dat er net hat, smyt it pakket krekt sa fuort as de VM. Lês de wearde foardat jo de tunnel de skuld jouwe.

Wannear't krekt ien foarheaksel mist

Dielmistich falen is it maklikst te lêzen gefal, want al it oare yn it paad is al bewiisd. Begjin by de rûtelist en lês it bestimmingsberik en de folgjende hop fan 'e yngong dy't it foarheaksel dekke moat, lês dan de ynstânsjebeskriuwing en fergelykje syn aliasberik mei de pool dy't de server útjout.

gcloud compute routes list --filter=destination-range~10.164.0.0
 gcloud compute instances describe openvpn-vm --format=get(networkInterfaces[0].aliasIpRanges)

In ûntbrekkende rûte lit himsels sjen as gjin folgjende hop foar it foarheaksel, wylst in ûntbrekkende alias himsels lit sjen as in pakket dat by de ynterface fuortgoaid wurdt; fan 'e klant ôf lykje de twa opinoar en yn dy twa útfieringen folslein oars. As beide der binne, is de oerbliuwende fertochte de ccd-iroute foar de klant dy't it foarheaksel opeasket.

Skriuw de fjouwer wearden njonken de tunnel: aliasberik, serverpool, pushte foarheaksels, VPC-rûtes. In ferâldere alias brekt elk pooladres, in ferâldere rûte brekt ien rjochting, in ûntbrekkende push ferberget it foarheaksel foar de klant, en in ferkearde iroute stjoert it foarheaksel nei de ferkearde peer. De folgjende persoan dy't in subnet taheakket hat alle fjouwer op ien plak nedich, en de notysje is goedkeaper as de jûn.