GCP Cloud VPN: controleer gateway, tunnel en firewall in de juiste volgorde

Uw console toont een groene tunnel, bewaking op locatie bereikt nog steeds geen enkele instantie, en de tunnel opnieuw opbouwen lijkt de voor de hand liggende oplossing. Dat is het zelden. Een tot stand gebrachte tunnel bewijst alleen dat twee gateways de IKE-uitwisseling hebben afgerond. Hij zegt niets over de vraag of een pakket ooit in uw VPC is toegelaten.

Vier beslissingen staan tussen dat groene pictogram en een antwoord, en ze falen in een voorspelbare volgorde. Werk ze van goedkoopst naar duurst af.

Drie objecten, en slechts één ervan versleutelt

Een VPN-gateway bezit het externe adres waarnaar uw peer versleutelt. In de console maakt u die nooit met de hand aan: kies of reserveer een adres in het verbindingsformulier en de gateway verschijnt ermee. Een HA-gateway neemt twee adressen op twee interfaces, wat later bij de quotacontrole telt.

Een tunnel is de koppeling tussen die gateway en de peer. Hij draagt het gedeelde geheim en de verkeersselectors die hij belooft te beschermen. In die selectors beginnen de meeste stille storingen. Een tunnel waarvan de lokale selector 10.0.0.0/24 dekt, levert geen 10.0.1.0/24, hoe gezond de status er ook uitziet.

De verre kant houdt zijn eigen lijst bij, meestal een versleutelingsdomein genoemd, en de afsluitende hardware vergelijkt die met de uwe. Geen enkele kant onderhandelt over een selector die hij nooit heeft gekregen.

Het routingtype bepaalt wat de routetabel bereikt

Cloud VPN biedt drie routingvormen en ze vermengen zich niet netjes. Beleidsgebaseerde routing houdt de statische selectorparen, routegebaseerde routing verwacht dat u zelf statische routes toevoegt, en dynamische routing adverteert prefixen via een Cloud Router over BGP. Kies er bewust één.

Een dynamische tunnel met handgeschreven statische routes ernaast levert een routetabel op die leegloopt telkens wanneer de BGP-sessie schommelt.

Dynamisch is de enige vorm die de beschermde prefixen laat veranderen zonder de tunnel opnieuw op te bouwen, en het sleurt de Cloud Router mee in de verzameling objecten die u moet verifiëren. Statische selectors blijven werkbaar wanneer de peer een hardwarefirewall is die geen BGP spreekt. Dan hebben beide uiteinden dezelfde bereiken nodig, en de specifiekere vermelding moet aan beide kanten winnen. Een paar dat een subnet verschilt, komt tot stand en draagt daarna de helft van uw verkeer.

De impliciete weigering zit achter de tunnel

Inkomend verkeer wordt beoordeeld tegen een impliciete weigering op de laagste prioriteit, en die regel trekt zich er niets van aan dat het pakket versleuteld aankwam. Totdat een firewallregel het bereik op locatie en de gebruikte poort noemt, wordt het pakket ontsleuteld, geïnspecteerd en weggegooid. Het VPN-logboek blijft de hele tijd schoon, omdat de tunnel precies deed wat hij beloofde.

Lees in plaats daarvan het weigeringslogboek van de firewall wanneer de tunnel actief is en de probe een time-out krijgt, en beperk daarna een regel tot het bronbereik en de poorten die u nodig hebt:

gcloud compute firewall-rules create allow-from-dc \
  --network=vpn-vpc \
  --direction=INGRESS \
  --source-ranges=192.168.10.0/24 \
  --allow=tcp:22,tcp:5432,icmp

Dat één richting werkt is een firewallaanwijzing

Uitgaand verkeer gedraagt zich anders, omdat de impliciete toestemmingsregel instanties overal heen laat sturen. Een datacenter dat een VM niet bereikt, zit vaak achter een perfect werkend uitgaand pad in de andere richting. Die asymmetrie scheidt een firewallvergetelheid van een routingfout, want een routingfout breekt beide richtingen tegelijk. Test de omgekeerde richting voordat u nog een regel bewerkt.

Het aanmaken van adressen is ook een quota-operatie. Een project dat dicht bij zijn limiet voor gebruikte externe adressen zit, weigert de verbinding met een fout die als een rechtenprobleem leest.

Selectors, quota, dan de vier controles

In de console aangemaakte tunnels retourneren soms een lege externe verkeersselector uit gcloud compute vpn-tunnels describe, terwijl de gegenereerde routes het verkeer correct dragen. Vergelijk wat de API vastlegt met de bereiken die u werkelijk beschermt voordat u besluit dat de tunnel fout is. Aanmaken via de API of SDK houdt de selector expliciet.

Quota zijn de andere makkelijke misser. Vraag de verhoging aan vóór het onderhoudsvenster en niet tijdens, en controleer het aantal adressen in hetzelfde project als de gateway.

Werk van buiten naar binnen: peerstatus, beide selectorlijsten, een route per kant, een inkomende regel voor het bronbereik en de poort, en dan een pakketopname. Schrijf het gatewayadres, beide selectorlijsten en het routingtype in de wijzigingsticket terwijl de tunnel nieuw is, want de volgende engineer die een subnet toevoegt, heeft alle drie nodig.