This is an old revision of the document!
Laborator 11. Google Cloud Platform (GCP)
Cunoștințe și abilități ce vor fi dobândite
- Administrarea resurselor cloud folosind consola grafică.
- Securitate în cloud.
- Configurarea rutării în cloud.
- Accesarea serviciilor de transfer de fișiere (FTP).
Pregătire infrastructură de laborator
- Vom crea o infrastructură de rețea în cloud-ul Google.
- Fiecare student va folosi contul propriu de pe GCP. Pentru a putea crea infrastructura necesară veți primi un număr de credite pentru GCP.
Introducere
Servicii de cloud existente:
- Google Cloud Platform
- Microsoft Azure
- Amazon Web Services.
Vom discuta mai departe despre Google Cloud Platform (GCP). Serviciile pe care le vom folosi în cadrul laboratorului:
- Google Compute Engine
- Networking: VPC, Cloud NAT
Alte servicii în cloud-ul GCP:
- Cloud Storage
- Databases: AlloyDB, Cloud SQL, Cloud Bigtable
- Networking: Cloud DNS, Cloud CDN
- Cloud Monitoring
O listă completă a tuturor serviciilor oferite de Google poate fi consultată aici : GCP Services
(Google) Compute Engine oferă capacitate dinamică computațională în cloud. De asemenea, pentru a dezvolta și lansa aplicații nu mai ai nevoie să îți achiziționezi hardware-ul, acest serviciu punându-ți la dispoziție: servere virtuale, configurarea securității și networking, ajustarea spațiului de stocare.
Virtual Private Cloud (VPC) Network te ajută să pornești resursele GCP într-o rețea virtuală definită de tine. Această rețea seamănă cu o rețea tradițională unde poți configura spații de adrese, tabele de rutare, gateways și setări de securitate, dar are în plus beneficiile utilizării unui infrastructuri scalabile. Fiecare VPC creat este izolat logic de oricare alt VPC din cloud.
Două sau mai multe VPC-uri pot comunica folosind VPC Network Peering. Rețelele VPC conectate folosind VPC Network Peering pot fi în același proiect sau proiecte diferite.
Pot fi create două tipuri de rețele tip VPC:
- auto-mode - unde un subnet din fiecare regiune este automat alocat, subnet-ul fiind creat sub blocul de adrese 10.128.0.0/9 .
- custom-mode - nu sunt create subnet-uri automat și utilizatorul poate avea control complet asupra clasei de IP-uri private utilizate pentru crearea VPC-ului.
Având în vedere considerentele de mai sus, nu se pot conecta două rețele VPC create în auto-mode, dar se pot conecta două rețele, una creată auto-mode, cealaltă custom-mode cât timp nu folosesc adrese IP din aceeași clasă.
3 tipuri de adrese IP:
- adrese IP private
- adrese IP publice. O adresă publică ce a fost atribuită unei instanțe pe care am închis-o va reveni în pool-ul inițial de adrese. Când vom reporni instanța, aceasta va avea o altă adresă IP publică.
- adrese IP publice statice sunt adrese IP publice care rămân asociate pe cont până în momentul în care alegi să renunți la ele.
Subnet - interval de adrese IP într-un VPC. Poți să lansezi resursele GCP într-un subnet fie ales automat (auto-mode) fie creat la alegere (custom-mode).
În GCP avem două tipuri de IP-uri:
- Publice (atunci când resursele trebuie să aibă acces direct în Internet, de exemplu serverele web). O adresă IP publică poate fi configurată pe interfața unei mașini virtuale create în GCP. Pot fi aplicate ulterior reguli de firewall pentru a putea controla accesul către acea mașină virtuală.
- Private (atunci când resursele nu trebuie să fie accesibile din Internet, de exemplu bazele de date)
În fiecare subnet, există 4 IP-uri rezervate în intervalul primar :
- Prima este adresă de rețea
- A doua este rezervată ca adresă pentru default gateway.
- Penultima adresă este rezervată de către GCP pentru viitoare utilizări.
- Ultima este adresa de broadcast
Cloud NAT. Cloud NAT este o componentă a GCP care permite comunicarea între instanțele din VPC care nu folosesc adrese IP publice și Internet.
Cloud NAT oferă conectivitate în Internet pentru următoarele tipuri de resurse:
- Mașini virtuale din Compute Engine fără adrese IP publice/externe asociate
- Clustere de Google Kubernetes Engine (GKE)
- Instanțe de Cloud Run (aplicații containerizate), Cloud Functions (code in the cloud/FaaS), App Engine
Tabela de rutare. Fiecare subnet dintr-un VPC trebuie să aibă asociată o tabelă de rutare, definită în cadrul VPC network. Google Cloud folosește mai multe tipuri de rute:
- Generate de sistem
- Rute default ( 0.0.0.0/0 pentru IPv4 sau ::/0 pentru IPv6)
- Rute pentru subrețea (create automat pentru fiecare subrețea)
- Rute personalizate (custom)
- Statice (către diverse destinații)
- Dinamice (sesiuni BGP către un Cloud Router)
- Rute peering
- Rute policy-based (către un Network Load Balancer din GCP).
Un VPC firewall acționează ca un firewall virtual care controlează traficul pentru una sau mai multe instanțe. Putem adăuga reguli pentru fiecare firewall care să permită traficul către/de la instanțele asociate.
Prestabilit, fiecare firewall permite tot traficul de ieșire și blochează traficul de intrare. Acțiunile pentru o regulă din firewall pot fi ori “allow” ori “deny”, nu ambele.
Documentație GCP:
Topologie
Navigare
Exerciții
Acest laborator își propune configurarea unei rețele asemănătoare topoligiei de mai sus. Vom avea nevoie de crearea a 4 VPC-uri, unul în care va fi creată stația Host, iar apoi câte un VPC separat pentru Red, Green și Blue.
Stația Host va fi folosită drept Bastion, o mașină virtuală folosită doar pentru a ne conecta prin Internet la celelalte mașini, Red, Green și Blue.
Această va avea configurată o adresa IP publică, celelalte vor avea configurate doar adresa IP private, comunicând pe Internet cu ajutorul serviciului de Cloud NAT.
Următoarele exerciții constituie pașii de parcurgere pentru ca la final să putem folosi rețeaua.
00. Completare formular de feedback
Vă invităm să evaluați activitatea echipei de RL și să precizați punctele tari și punctele slabe și sugestiile voastre de îmbunătățire a materiei. Feedback-ul vostru este foarte important pentru noi să creștem calitatea materiei în anii următori și să îmbunătățim materiile pe care le veți face în continuare.
Găsiți formularul de feedback în partea dreaptă a paginii principale de RL de pe curs.pub.ro într-un frame numit FEEDBACK.
Vă mulțumim!
01. [10p] Conectare la infrastructură
În cadrul laboratorului veți lucra în echipe. Fiecare echipa va administra propria rețea virtuală. La începutul laboratorului veți primi un număr de grupa și parolă de ssh pentru acces la rețeaua voastră. Pool-ul de adrese asociat rețelei va fi sub formă <număr grupa>.0.0.0/8. Fiecare echipă are acces la rețea printr-un container bastion. Pentru a accesa acest container puteți folosi comanda:
ssh -J your_user.here@fep.grid.pub.ro -p 2000+<număr grupă> root@10.9.2.74
De exemplu, studentul John Smith din grupa 11 se va conecta folosind:
ssh -J john.smith@fep.grid.pub.ro -p 2011 root@10.9.2.74
O dată conectați vă veți afla pe container-ul bastion (“ssh”), de aici puteți apela scriptul ./goto.sh pentru a vă conecta la routere și host-uri. De exemplu, pentru a vă conecta la routerul BUCH veți apela:
./goto.sh BUCH router
Această comandă vă va oferi acces la terminalul router-ului, cu o interfață similară cu cea CISCO IOS.
Reminder comenzi generice
configure terminal- intră în modul de configurare; orice comandă dată în modul de configurare va fi aplicată asupra router-ului.ping <destination>- trimite pachete de tip ICMP către<destination>.traceroute <destination>- afișează calea pe care o ia un pachet pentru a ajunge la<destination>.exit- iese din modul curent de configurare.
Pentru a accesa host-ul conectat la router-ul BUCH veți apela:
./goto.sh BUCH host
02. [20p] Configurare eBGP
Vom configura eBGP pe router-ul LOND. Vom exporta către IXP rețeaua noastră (X.0.0.0/8) și vom importa tot ce primim de la IXP. IXP-ul este configurat astfel încât să exporte toate rutele primite de la AS-urile vecine. Pentru conectarea la IXP vom folosi rețeaua 180.22.0.0/24.
Pentru a activa și configura procesul de BGP al router-ului vom folosi comanda de mai jos:
LOND_router# configure terminal LOND_router(config)# router bgp <X> LOND_router(config-router)#
unde <X> este numărul grupei/AS-ului. Observăm schimbarea prompt-ului, sugerând modul de configurare actual.
În general, avem opțiunea să configurăm un router-id. Acest lucru poate influența criteriile de alegere a rutei în BGP. Pentru moment, nu e neapărat necesar, dar îl vom seta ca fiind IP-ul către IXP. Pe interfața ixp_22 (către IXP) a router-ului LOND este deja configurată o adresă IP. Pentru a afla adresele IP de pe interfețe putem folosi comanda de mai jos:
LOND_router# show interface brief Interface Status VRF Addresses --------- ------ --- --------- dns_<X> up default 198.0.0.<X>/24 ixp_22 up default 180.22.0.<X>/24 lo up default <X>.151.0.1/24 port_BERL up default <X>.0.2.2/24 port_PARI up default <X>.0.1.1/24 ssh up default 158.<X>.10.1/16 LOND_router#
show fără a părăsi modul de configurare actual, acestea pot fi prefixate cu do.
LOND_router(config-router)# do show interface brief Interface Status VRF Addresses --------- ------ --- --------- dns_<X> up default 198.0.0.<X>/24 ixp_22 up default 180.22.0.<X>/24 lo up default <X>.151.0.1/24 port_BERL up default <X>.0.2.2/24 port_PARI up default <X>.0.1.1/24 ssh up default 158.<X>.10.1/16 LOND_router(config-router)#
Pentru a seta router-id-ul, vom folosi comanda bgp router-id A.B.C.D, astfel:
LOND_router(config-router)# bgp router-id 180.22.0.<X> LOND_router(config-router)#
În continuare, va trebui să configurăm vecinul la care ne conectăm (IXP-ul). Urmăriți documentația comenzii și configurați IXP-ul ca peer.
IXP-ul este în AS-ul 22 și are adresa IP 180.22.0.22.
În final, va trebui să configurăm rețeaua pe care vrem să o exportăm. Urmăriți documentația comenzii pentru a exporta rețeaua <X>.0.0.0/8.
Putem verifica starea procesului de BGP astfel:
LOND_router(config-router)# do show bgp summary IPv4 Unicast Summary: BGP router identifier 180.22.0.1, local AS number 1 vrf-id 0 BGP table version 1 RIB entries 1, using 192 bytes of memory Peers 1, using 14 KiB of memory Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd PfxSnt 180.22.0.22 4 22 6 5 0 0 0 00:02:51 (Policy) (Policy) Total number of neighbors 1 LOND_router(config-router)#
State/PfxRcd și PxfSnt textul (Policy). Acest lucru înseamnă că nu exportăm și nu importăm rute datorită lipsei filtrelor. Urmăriți documentația pentru a rezolva problema.
Hint
Pentru a anula efectul unei comenzi o putem prefixa cu no .
Pentru a reporni procesul de BGP putem folosi următoarea comandă:
LOND_router# clear bgp * LOND_router#
Verificați iar starea procesului BGP.
LOND_router# show bgp summary IPv4 Unicast Summary: BGP router identifier 180.22.0.1, local AS number 1 vrf-id 0 BGP table version 2 RIB entries 3, using 576 bytes of memory Peers 1, using 14 KiB of memory Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd PfxSnt 180.22.0.22 4 22 20 23 0 0 0 00:01:58 1 2 Total number of neighbors 1 LOND_router#
Verificați conectivitatea de pe router-ul LOND către un IP din AS 21 (este preconfigurat), sau către unul din IP-urile de pe router-ul LOND din AS-urile colegilor.
LOND_router# ping 21.0.2.2 PING 21.0.2.2 (21.0.2.2) 56(84) bytes of data. 64 bytes from 21.0.2.2: icmp_seq=1 ttl=64 time=10.3 ms 64 bytes from 21.0.2.2: icmp_seq=2 ttl=64 time=4.14 ms 64 bytes from 21.0.2.2: icmp_seq=3 ttl=64 time=4.13 ms ^C --- 21.0.2.2 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2003ms rtt min/avg/max/mdev = 4.132/6.202/10.332/2.920 ms LOND_router#
Afișați tabela de rutare și observați noua intrare obținută prin BGP.
LOND_router# show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP,
O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP,
F - PBR, f - OpenFabric,
> - selected route, * - FIB route, q - queued, r - rejected, b - backup
<...>
B>* 21.0.0.0/8 [20/0] via 180.22.0.21, ixp_22, weight 1, 00:05:57
<...>
LOND_router#
03. [20p] Configurare iBGP
În cadrul acestui exercițiu vom configura iBGP pe router-ele LOND și PARI.
Comenzile sunt similare, însă, de această dată, nu e nevoie să configurăm un router-id. De asemenea, vom folosi adresele interfețelor de loopback (lo) pentru a face peering cu router-ele din același AS.
PARI_router# show ip ospf route
============ OSPF network routing table ============
<...>
N 21.151.0.1/32 [1] area: 0.0.0.0
via 21.0.1.1, port_LOND
N 21.152.0.1/32 [0] area: 0.0.0.0
directly attached to lo
N 21.153.0.1/32 [2] area: 0.0.0.0
via 21.0.1.1, port_LOND
via 21.0.3.2, port_BUCH
N 21.154.0.1/32 [1] area: 0.0.0.0
via 21.0.3.2, port_BUCH
<...>
Spre exemplu pentru a face peering între router-ele LOND și PARI vom da următoarele comenzi:
LOND_router# configure terminal LOND_router(config)# router bgp <X> LOND_router(config-router)# neighbor <X>.152.0.1 remote-as <X> LOND_router(config-router)# neighbor <X>.152.0.1 update-source lo LOND_router(config-router)#
PARI_router# configure terminal PARI_router(config)# router bgp <X> PARI_router(config-router)# neighbor <X>.151.0.1 remote-as <X> PARI_router(config-router)# neighbor <X>.151.0.1 update-source lo PARI_router(config-router)#
Mai multe informații despre acest mod de configurare găsiți aici.
Verificați dacă s-a realizat conexiunea BGP, folosind comanda show bgp summary.
04. [10p] Propagare corectă next-hop
În teorie, în urma comenzilor de le exercițiul anterior ar trebui să avem conectivitate de pe router-ul PARI către alte AS-uri.
Realitatea este alta…
PARI_router# ping 21.0.2.2 ping: connect: Network unreachable PARI_router#
Dacă ne uităm la output-ul comenzii show bgp summary putem observa că am primit totuși de la router-ul LOND rute (coloana State/PfxRcd).
PARI_router# show bgp sum IPv4 Unicast Summary: BGP router identifier <X>.152.0.1, local AS number <X> vrf-id 0 BGP table version 0 RIB entries 3, using 576 bytes of memory Peers 1, using 14 KiB of memory Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd PfxSnt <X>.151.0.1 4 2 5 6 0 0 0 00:00:54 2 0 Total number of neighbors 1 PARI_router#
Însă, dacă verificăm tabela de rutare, nu vom regăsi nicio rută către rețele din afara AS-ului nostru (spre exemplu, nu regăsim nicio rută către 21.0.0.0/8, spațiul de adrese al AS-ului preconfigurat).
PARI_router# show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP,
O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP,
F - PBR, f - OpenFabric,
> - selected route, * - FIB route, q - queued, r - rejected, b - backup
S>* 2.0.0.0/8 [1/0] unreachable (blackhole), weight 1, 02:06:23
O 2.0.1.0/24 [110/1] is directly connected, port_LOND, weight 1, 02:06:23
C>* 2.0.1.0/24 is directly connected, port_LOND, 02:06:23
O>* 2.0.2.0/24 [110/2] via 2.0.1.1, port_LOND, weight 1, 02:05:33
O 2.0.3.0/24 [110/1] is directly connected, port_BUCH, weight 1, 02:06:22
C>* 2.0.3.0/24 is directly connected, port_BUCH, 02:06:23
O>* 2.0.4.0/24 [110/2] via 2.0.3.2, port_BUCH, weight 1, 02:05:31
O 2.0.198.0/24 [110/10] is directly connected, matrix_2, weight 1, 02:06:25
C>* 2.0.198.0/24 is directly connected, matrix_2, 02:07:47
O>* 2.0.199.0/24 [110/11] via 2.0.3.2, port_BUCH, weight 1, 02:05:31
O>* 2.104.0.0/24 [110/11] via 2.0.3.2, port_BUCH, weight 1, 02:05:31
O>* 2.151.0.1/32 [110/1] via 2.0.1.1, port_LOND, weight 1, 02:05:33
C>* 2.152.0.0/24 is directly connected, lo, 02:06:24
O>* 2.152.0.1/32 [110/0] is directly connected, lo, weight 1, 02:06:23
O>* 2.153.0.1/32 [110/2] via 2.0.1.1, port_LOND, weight 1, 02:05:23
* via 2.0.3.2, port_BUCH, weight 1, 02:05:23
O>* 2.154.0.1/32 [110/1] via 2.0.3.2, port_BUCH, weight 1, 02:05:31
C>* 158.2.0.0/16 is directly connected, ssh, 02:07:58
O>* 198.0.0.0/24 [110/11] via 2.0.1.1, port_LOND, weight 1, 02:05:33
PARI_router#
Acest lucru este cauzat de faptul că ruta învățată de router-ul LOND are ca next-hop adresa IP a IXP-ului (180.22.0.22), însă router-ele interne nu au o rută către această rețea. Rutele primite de la LOND sunt “undeva în memoria router-ului”, însă până când nu va avea o rută către next-hop ele nu vor fi în tabela de rutare.
Pe router-ul LOND putem folosi următoarea comandă pentru a propaga rutele, în iBGP, către router-ul PARI, cu adresa IP a interfeței de loopback ca next-hop.
LOND_router# configure terminal LOND_router(config)# router bgp <X> LOND_router(config-router)# address-family ipv4 unicast LOND_router(config-router-af)# neighbor <X>.152.0.1 next-hop-self LOND_router(config-router-af)#
Verificați iar tabela de rutare de pe router-ul PARI și incercați să dați ping în router-ul LOND din AS 21 (ping 21.0.2.2).
05. [30p] Configurare iBGP (cont.)
Repetați pașii de la exercițiul 03 pentru a configura iBGP astfel încât să existe relații de peering între toate router-ele. Pentru asta, va trebui să realizați configurații similare cu cele de la exercițiul 03 (configurat peer, activat peer, updatare IP sursă, propagare corectă next-hop acolo unde e cazul) pentru fiecare pereche de 2 routere din topologia AS-ului:
LOND-BERLLOND-BUCHPARI-BUCHPARI-BERLBERL-BUCH
Recomandăm să vă împărțiți munca, fie per legătură (fiecare configurează câte 2-3 legături), fie per capete de legătură (pentru legătura LOND - BERL, unul din voi va configura router-ul LOND, iar celălalt router-ul BERL).
Testați conectivitatea către fiecare subrețea din AS 21 (21.0.1.0/8, 21.0.2.0/8, 21.0.3.0/8, 21.0.4.0/8) de pe aceste routere.
06. [10p] Conectivitate end-to-end
Faceți configurările necesare pe stația atașată la router-ul BUCH pentru a avea conectivitate la stațiile din celelalte AS-uri. Verificați conectivitatea (ping) cu stația din AS 21 (21.104.0.1) sau stațiile din AS-urile colegilor.
