GCP Cloud VPN: pārbaudiet vārteju, tuneli un ugunsmūri secībā

Tunelis, kas ziņo par izveidotu savienojumu, kamēr katra pārbaude beidzas ar taimautu, parasti nav nodrošināts ar VPC ugunsmūra noteikumu. Pārbaudiet vārteju, selektorus un maršrutēšanas veidu šajā secībā.

Jūsu konsolē ir zaļš tunelis, lokālā uzraudzība joprojām nevar sasniegt nevienu instanci, un tuneļa pārbūve šķiet acīmredzamais risinājums. Tā tas ir reti. Izveidots tunelis pierāda tikai to, ka divas vārtejas pabeidza IKE apmaiņu. Tas neko nepasaka par to, vai paketei kādreiz tika ļauts iekļūt jūsu VPC.

Starp šo zaļo ikonu un atbildi ir četri lēmumi, un tie neizdodas paredzamā secībā. Sāciet ar lētāko.

Trīs objekti, un tikai viens no tiem šifrē

VPN vārteja pārvalda ārējo adresi, uz kuru šifrē jūsu partneris. Konsolē jūs to nekad neveidojat ar rokām: savienojuma veidlapā izvēlieties vai rezervējiet adresi, un vārteja parādīsies kopā ar to. HA vārteja aizņem divas adreses divās saskarnēs, kas vēlāk ir svarīgi kvotu pārbaudē.

Tunelis ir šīs vārtejas un partnera savienojuma pāris. Tas pārnēsā koplietoto noslēpumu un trafika selektorus, kurus sola aizsargāt. Tieši šajos selektoros sākas lielākā daļa kluso kļūdu. Tunelis, kura lokālais selektors aptver 10.0.0.0/24, nepiegādās 10.0.1.0/24, lai cik veselīgi izskatītos statuss.

Tālā puse uztur savu sarakstu, ko parasti sauc par šifrēšanas domēnu, un terminējošā aparatūra to salīdzina ar jūsējo. Neviena puse neved sarunas par selektoru, kas tai nekad netika dots.

Maršrutēšanas veids nosaka, kas nonāk maršrutu tabulā

Cloud VPN piedāvā trīs maršrutēšanas formas, un tās nesajaucas tīri. Uz politiku balstīta maršrutēšana saglabā statiskos selektoru pārus, uz maršrutiem balstīta maršrutēšana sagaida, ka statiskos maršrutus pievienosiet paši, un dinamiskā maršrutēšana paziņo prefiksus, izmantojot Cloud Router ar BGP. Izvēlieties vienu apzināti.

Dinamisks tunelis ar blakus rakstītiem statiskiem maršrutiem rada maršrutu tabulu, kas iztukšojas katru reizi, kad BGP sesija sašūpojas.

Dinamiskais ir vienīgā forma, kas ļauj aizsargātajiem prefiksiem mainīties bez tuneļa pārbūves, un tas ievelk Cloud Router objektu kopā, kas jums jāpārbauda. Statiskie selektori joprojām ir izmantojami, ja partneris ir aparatūras ugunsmūris, kas neprot BGP. Tad abiem galiem vajadzīgi tie paši diapazoni, un konkrētākajam ierakstam jāuzvar abos. Pāris, kas atšķiras par vienu apakštīklu, izveidojas un pēc tam pārnēsā pusi jūsu trafika.

Netiešais noraidījums atrodas aiz tuneļa

Ienākošais trafiks tiek novērtēts pret netiešo noraidījumu zemākajā prioritātē, un šim noteikumam nav svarīgi, ka pakete ieradās šifrēta. Kamēr ugunsmūra noteikums nenosauc lokālo diapazonu un izmantoto portu, pakete tiek atšifrēta, pārbaudīta un izmesta. VPN žurnāls visu laiku paliek tīrs, jo tunelis izdarīja tieši to, ko solīja.

Tā vietā lasiet ugunsmūra noraidījumu žurnālu, kad tunelis darbojas un pārbaude beidzas ar taimautu, pēc tam ierobežojiet noteikumu ar avota diapazonu un nepieciešamajiem portiem:

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

Viena strādājoša virziena ir ugunsmūra pavediens

Izejošais trafiks uzvedas citādi, jo netiešais atļaujas noteikums ļauj instancēm sūtīt jebkur. Datu centrs, kas nevar sasniegt VM, bieži atrodas aiz perfekti strādājoša izejas ceļa pretējā virzienā. Šī asimetrija atdala ugunsmūra izlaidumu no maršrutēšanas kļūdas, jo maršrutēšanas kļūda salauž abus virzienus uzreiz. Pārbaudiet pretējo virzienu, pirms rediģējat vēl vienu noteikumu.

Adrešu izveide arī ir kvotu operācija. Projekts, kas ir tuvu izmantoto ārējo adrešu limitam, noraida savienojumu ar kļūdu, kas izklausās pēc atļauju kļūdas.

Selektori, kvotas, tad četras pārbaudes

Konsolē izveidotie tuneļi dažreiz atgriež tukšu attālināto trafika selektoru no gcloud compute vpn-tunnels describe, kamēr ģenerētie maršruti trafiku pārnēsā pareizi. Salīdziniet, ko API reģistrē, ar diapazoniem, ko jūs faktiski aizsargājat, pirms nolemjat, ka tunelis ir nepareizs. Izveide ar API vai SDK saglabā selektoru skaidru.

Kvotas ir otra vieglā kļūda. Pieprasiet palielinājumu pirms apkopes loga, nevis tā laikā, un pārbaudiet adrešu skaitu tajā pašā projektā kā vārteja.

Strādājiet no ārpuses uz iekšu: partnera statuss, abi selektoru saraksti, maršruts katrai pusei, ienākošais noteikums avota diapazonam un portam, tad pakešu tveršana. Ierakstiet vārtejas adresi, abus selektoru sarakstus un maršrutēšanas veidu izmaiņu biļetē, kamēr tunelis ir jauns, jo nākamajam inženierim, kas pievienos apakštīklu, būs vajadzīgi visi trīs.

Saistītie raksti