1. Wprowadzenie
Wewnętrzny regionalny system równoważenia obciążenia TCP serwera proxy z łącznością hybrydową umożliwia udostępnianie klientom w sieci VPC usługi hostowanej w środowiskach lokalnych lub innych środowiskach chmurowych.
Jeśli chcesz udostępnić usługę hybrydową w innych sieciach VPC, możesz użyć usługi Private Service Connect do opublikowania usługi. Umieszczając przyłącze usługi przed wewnętrznym regionalnym systemem równoważenia obciążenia TCP proxy, możesz umożliwić klientom w innych sieciach VPC dostęp do usług hybrydowych działających w środowiskach lokalnych lub w innych chmurach.
Co utworzysz
W tym ćwiczeniu utworzysz wewnętrzny system równoważenia obciążenia TCP serwera proxy z połączeniem hybrydowym z usługą lokalną za pomocą grupy punktów końcowych sieci. Sieć VPC konsumenta będzie mogła komunikować się z usługą lokalną.
Czego się nauczysz
- Tworzenie wewnętrznego systemu równoważenia obciążenia serwera proxy TCP z usługą backendu hybrydowej grupy punktów końcowych sieci
- Jak utworzyć usługę producenta Private Service Connect (przyłącze usługi) i konsumenta (regułę przekierowania)
- Jak testować i weryfikować komunikację między usługą konsumenta a usługą producenta
Czego potrzebujesz
- Ustanowione sieci hybrydowe, np.sieć VPN o wysokiej dostępności, Interconnect, SW-WAN
- Projekt Google Cloud
Nawiązywanie połączeń hybrydowych
Środowiska Google Cloud oraz lokalne lub inne środowiska chmurowe muszą być połączone za pomocą połączenia hybrydowego, które wykorzystuje przyłącza VLAN Cloud Interconnect lub tunele Cloud VPN z routerem Cloud Router. Zalecamy używanie połączenia o wysokiej dostępności.
Router Cloud Router z włączonym globalnym routingiem dynamicznym dowiaduje się o konkretnym punkcie końcowym za pomocą protokołu BGP i programuje go w sieci VPC w Google Cloud. Regionalne dynamiczne przekierowywanie nie jest obsługiwane. Trasy statyczne również nie są obsługiwane.
Sieć VPC Google Cloud, której używasz do konfigurowania Cloud Interconnect lub Cloud VPN, jest tą samą siecią, której używasz do konfigurowania wdrożenia hybrydowego równoważenia obciążenia. Sprawdź, czy zakresy CIDR podsieci sieci VPC nie powodują konfliktu z zakresami CIDR sieci zdalnych. Gdy adresy IP się pokrywają, trasy podsieci mają wyższy priorytet niż połączenia zdalne.
Instrukcje znajdziesz poniżej:
Niestandardowe rozgłaszanie tras
Podsieci poniżej wymagają niestandardowego rozgłaszania z routera Cloud Router do sieci lokalnej, co zapewnia aktualizację reguł zapory sieciowej w sieci lokalnej.
Podsieć | Opis |
172.16.0.0/23 | Podsieć serwera proxy TCP używana do bezpośredniej komunikacji z usługą lokalną |
130.211.0.0/22, 35.191.0.0/16 |
2. Zanim zaczniesz
Aktualizowanie projektu, aby obsługiwał ćwiczenia z programowania
W tym laboratorium wykorzystywane są zmienne $variables, które ułatwiają wdrażanie konfiguracji gcloud w Cloud Shell.
W Cloud Shell wykonaj te czynności:
gcloud config list project
gcloud config set project [YOUR-PROJECT-NAME]
psclab=YOUR-PROJECT-NAME
echo $psclab
3. Konfiguracja producenta
Utwórz sieć VPC producenta
W Cloud Shell wykonaj te czynności:
gcloud compute networks create producer-vpc --project=$psclab --subnet-mode=custom
Utwórz podsieci producenta
W Cloud Shell wykonaj te czynności:
gcloud compute networks subnets create subnet-201 --project=$psclab --range=10.10.1.0/24 --network=producer-vpc --region=us-central1
Utwórz podsieci serwera proxy TCP
Przydzielanie serwerów proxy odbywa się na poziomie sieci VPC, a nie systemu równoważenia obciążenia. W każdym regionie sieci wirtualnej (VPC), w którym używasz systemów równoważenia obciążenia opartych na Envoy, musisz utworzyć podsieć tylko-proxy . Jeśli w tym samym regionie i tej samej sieci VPC wdrożysz kilka systemów równoważenia obciążenia, będą one współużytkować tę samą podsieć tylko-proxy na potrzeby równoważenia obciążenia.
- Klient nawiązuje połączenie z adresem IP i portem reguły przekierowania systemu równoważenia obciążenia.
- Każde proxy nasłuchuje na adresie IP i porcie określonym przez odpowiednią regułę przekierowania systemu równoważenia obciążenia. Jeden z serwerów proxy odbiera i zamyka połączenie sieciowe klienta.
- Serwer proxy nawiązuje połączenie z odpowiednią maszyną wirtualną backendu lub punktem końcowym w grupie NEG, zgodnie z mapą URL i usługami backendu systemu równoważenia obciążenia.
Podsieci tylko-proxy musisz utworzyć niezależnie od tego, czy Twoja sieć jest w trybie automatycznym czy niestandardowym. Podsieć tylko dla proxy musi zawierać co najmniej 64 adresy IP. Odpowiada to długości prefiksu /26 lub krótszej. Zalecany rozmiar podsieci to /23 (512 adresów tylko-proxy).
W Cloud Shell wykonaj te czynności:
gcloud compute networks subnets create proxy-subnet-us-central \
--purpose=REGIONAL_MANAGED_PROXY \
--role=ACTIVE \
--region=us-central1 \
--network=producer-vpc \
--range=172.16.0.0/23
Tworzenie podsieci NAT Private Service Connect
Utwórz co najmniej jedną dedykowaną podsieć do używania z usługą Private Service Connect. Jeśli do publikowania usługi używasz konsoli Google Cloud, możesz utworzyć podsieci w trakcie tej procedury. Utwórz podsieć w tym samym regionie co system równoważenia obciążenia usługi. Nie możesz przekonwertować zwykłej podsieci na podsieć Private Service Connect.
W Cloud Shell wykonaj te czynności:
gcloud compute networks subnets create psc-nat-subnet --network=producer-vpc --region=us-central1 --range=100.100.10.0/24 --purpose=private-service-connect
Tworzenie reguł zapory sieciowej producenta
Skonfiguruj reguły zapory sieciowej, aby zezwolić na ruch między punktami końcowymi Private Service Connect a przyłączem usługi. W tym przewodniku utworzono regułę zapory sieciowej Ingress zezwalającą podsieci NAT 100.100.10.0/24 na dostęp do przyłącza usługi Private Service Connect (wewnętrznego systemu równoważenia obciążenia).
W Cloud Shell wykonaj te czynności:
gcloud compute --project=$psclab firewall-rules create allow-to-ingress-nat-subnet --direction=INGRESS --priority=1000 --network=producer-vpc --action=ALLOW --rules=all --source-ranges=100.100.10.0/24
W Cloud Shell utwórz regułę fw-allow-health-check, która umożliwi kontroli stanu Google Cloud dotarcie do usługi lokalnej (usługi backendu) na porcie TCP 80.
gcloud compute firewall-rules create fw-allow-health-check \
--network=producer-vpc \
--action=allow \
--direction=ingress \
--source-ranges=130.211.0.0/22,35.191.0.0/16 \
--rules=tcp:80
Utwórz regułę zapory sieciowej ruchu przychodzącego, która umożliwi usługom lokalnym komunikację z podsiecią serwera proxy na porcie 80.
gcloud compute firewall-rules create fw-allow-proxy-only-subnet \
--network=producer-vpc \
--action=allow \
--direction=ingress \
--source-ranges=172.16.0.0/23 \
--rules=tcp:80
Konfigurowanie grupy punktów końcowych sieci z hybrydową łącznością
Podczas tworzenia sieci NEG użyj STREFY,która minimalizuje odległość geograficzną między Google Cloud a Twoim środowiskiem lokalnym lub innym środowiskiem Cloud. Jeśli na przykład hostujesz usługę w środowisku lokalnym we Frankfurcie w Niemczech, podczas tworzenia NEG możesz określić strefę Google Cloud europe-west3-a.
Jeśli korzystasz z usługi Cloud Interconnect, STREFA użyta do utworzenia NEG powinna znajdować się w tym samym regionie, w którym skonfigurowano przyłącze połączenia międzysieciowego Cloud Interconnect.
Listę dostępnych regionów i stref znajdziesz w dokumentacji Compute Engine: dostępne regiony i strefy.
W Cloud Shell utwórz grupę punktów końcowych sieci połączonych hybrydowo za pomocą polecenia gcloud compute network-endpoint-groups create.
gcloud compute network-endpoint-groups create on-prem-service-neg \
--network-endpoint-type=NON_GCP_PRIVATE_IP_PORT \
--zone=us-central1-a \
--network=producer-vpc
W Cloud Shell dodaj do hybrydowej grupy NEG punkt końcowy IP:Port środowiska lokalnego.
gcloud compute network-endpoint-groups update on-prem-service-neg \
--zone=us-central1-a \
--add-endpoint="ip=192.168.1.5,port=80"
Konfigurowanie systemu równoważenia obciążenia
W tych krokach skonfigurujesz system równoważenia obciążenia (regułę przekierowania) i powiążesz go z grupą punktów końcowych sieci.
W Cloud Shell utwórz regionalną kontrolę stanu przekazywaną do usługi lokalnej.
gcloud compute health-checks create tcp on-prem-service-hc \
--region=us-central1 \
--use-serving-port
W Cloud Shell utwórz usługę backendu dla backendu lokalnego.
gcloud compute backend-services create on-premise-service-backend \
--load-balancing-scheme=INTERNAL_MANAGED \
--protocol=TCP \
--region=us-central1 \
--health-checks=on-prem-service-hc \
--health-checks-region=us-central1
W Cloud Shell dodaj backend hybrydowej grupy NEG do usługi backendu. W przypadku MAX_CONNECTIONS wpisz maksymalną liczbę równoczesnych połączeń, które backend powinien obsługiwać.
gcloud compute backend-services add-backend on-premise-service-backend \
--network-endpoint-group=on-prem-service-neg \
--network-endpoint-group-zone=us-central1-a \
--region=us-central1 \
--balancing-mode=CONNECTION \
--max-connections=100
W Cloud Shell utwórz docelowy serwer proxy.
gcloud compute target-tcp-proxies create on-premise-svc-tcpproxy \
--backend-service=on-premise-service-backend \
--region=us-central1
W Cloud Shell utwórz regułę przekierowania (wewnętrzny system równoważenia obciążenia).
Utwórz regułę przekierowania za pomocą polecenia gcloud compute forwarding-rules create.
Zastąp FWD_RULE_PORT pojedynczym numerem portu z zakresu od 1 do 65 535. Reguła przekierowania przekazuje tylko pakiety z pasującym portem docelowym.
gcloud compute forwarding-rules create tcp-ilb-psc \
--load-balancing-scheme=INTERNAL_MANAGED \
--network=producer-vpc \
--subnet=subnet-201 \
--ports=80 \
--region=us-central1 \
--target-tcp-proxy=on-premise-svc-tcpproxy \
--target-tcp-proxy-region=us-central1
Uzyskiwanie adresu IP wewnętrznego systemu równoważenia obciążenia
gcloud compute forwarding-rules describe tcp-ilb-psc --region=us-central1 | grep -i IPAddress:
Example output:
gcloud compute forwarding-rules describe tcp-ilb-psc --region=us-central1 | grep -i IPAddress:
IPAddress: 10.10.1.2
4. Weryfikowanie systemu równoważenia obciążenia
W konsoli Cloud otwórz Usługi sieciowe → Równoważenie obciążenia → Systemy równoważenia obciążenia. Pamiętaj, że wartość 1 NEG jest zielona, co oznacza, że kontrola stanu usługi lokalnej została przeprowadzona pomyślnie.
Wybranie opcji ‘on-premise-service-backend' spowoduje wyświetlenie adresu IP frontendu.
5. Wyświetlanie zapamiętanych tras z lokalnego środowiska
Otwórz Sieć VPC → Trasy. Zwróć uwagę na podsieć usługi lokalnej 192.168.1.0/27.
6. Sprawdzanie połączenia z usługą lokalną
W sieci VPC producentów utworzymy maszynę wirtualną, aby przetestować połączenie z usługą lokalną. Następnie skonfigurujemy przyłącze usługi.
W Cloud Shell utwórz instancję testową w sieci VPC producenta.
gcloud compute instances create test-box-us-central1 \
--zone=us-central1-a \
--image-family=debian-10 \
--image-project=debian-cloud \
--subnet=subnet-201 \
--no-address
Aby umożliwić IAP połączenie z instancjami maszyn wirtualnych, utwórz regułę zapory sieciowej, która:
- Dotyczy wszystkich instancji maszyn wirtualnych, które mają być dostępne przez IAP.
- Zezwala na ruch przychodzący z zakresu adresów IP 35.235.240.0/20. Ten zakres zawiera wszystkie adresy IP, których IAP używa do przekierowywania TCP.
W Cloud Shell utwórz instancję testową w sieci VPC producenta.
gcloud compute firewall-rules create ssh-iap \
--network producer-vpc \
--allow tcp:22 \
--source-ranges=35.235.240.0/20
Zaloguj się w Cloud Shell na test-box-us-central1 za pomocą IAP, aby sprawdzić łączność z usługą lokalną, wykonując polecenie curl względem adresu IP systemu równoważenia obciążenia. Ponów próbę, jeśli nastąpi przekroczenie limitu czasu.
gcloud compute ssh test-box-us-central1 --project=$psclab --zone=us-central1-a --tunnel-through-iap
Wykonaj polecenie curl, aby sprawdzić połączenie z usługą lokalną. Po zweryfikowaniu zamknij maszynę wirtualną i wróć do wiersza poleceń Cloud Shell. Zastąp adres IP wewnętrznego systemu równoważenia obciążenia adresem wyznaczonym w krokach 3 i 4.
deepakmichael@test-box-us-central1:~$ curl -v 10.10.1.2
* Expire in 0 ms for 6 (transfer 0x55b9a6b2f0f0)
* Trying 10.10.1.2...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x55b9a6b2f0f0)
* Connected to 10.10.1.2 (10.10.1.2) port 80 (#0)
> GET / HTTP/1.1
> Host: 10.10.1.2
> User-Agent: curl/7.64.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Content-Type: text/html; charset=utf-8
< Accept-Ranges: bytes
< ETag: "3380914763"
< Last-Modified: Mon, 05 Dec 2022 15:10:56 GMT
< Expires: Mon, 05 Dec 2022 15:42:38 GMT
< Cache-Control: max-age=0
< Content-Length: 37
< Date: Mon, 05 Dec 2022 15:42:38 GMT
< Server: lighttpd/1.4.53
<
Welcome to my on-premise service!!
7. Tworzenie przyłącza usługi Private Service Connect
W kolejnych krokach utworzymy przyłącze usługi. Po sparowaniu go z punktem końcowym konsumenta uzyskamy dostęp do usługi lokalnej bez konieczności korzystania z połączenia równorzędnego VPC.
Utwórz połączenie z usługą
W Cloud Shell utwórz połączenie z usługą.
gcloud compute service-attachments create service-1 --region=us-central1 --producer-forwarding-rule=tcp-ilb-psc --connection-preference=ACCEPT_AUTOMATIC --nat-subnets=psc-nat-subnet
Opcjonalnie: jeśli używasz współdzielonego środowiska VPC, utwórz przyłącze usługi w projekcie usługi.
gcloud compute service-attachments create service-1 --region=us-central1 --producer-forwarding-rule=tcp-ilb-psc --connection-preference=ACCEPT_AUTOMATIC --nat-subnets=projects/<hostproject>/regions/<region>/subnetworks/<natsubnet>
Weryfikowanie załącznika usługi TCP
gcloud compute service-attachments describe service-1 --region us-central1
8. Opcjonalnie: otwórz kolejno Usługi sieciowe → Private Service Connect, aby wyświetlić nowo utworzone przyłącze usługi.
Kliknięcie Service-1 spowoduje wyświetlenie większej liczby szczegółów, w tym identyfikatora URI przyłącza usługi używanego przez konsumenta do nawiązania połączenia Private Service Connection. Zapisz URI, ponieważ będzie on potrzebny w dalszym kroku.
Szczegóły przyłącza usługi: projects/<projectname>/regions/us-central1/serviceAttachments/service-1
9. Konfiguracja konsumencka
Tworzenie sieci VPC konsumenta
W Cloud Shell wykonaj te czynności:
gcloud compute networks create consumer-vpc --project=$psclab --subnet-mode=custom
Tworzenie podsieci konsumenta
W Cloud Shell utwórz podsieć GCE.
gcloud compute networks subnets create subnet-101 --project=$psclab --range=10.100.1.0/24 --network=consumer-vpc --region=us-central1
W Cloud Shell utwórz podsieć punktu końcowego klienta.
gcloud compute networks subnets create subnet-102 --project=$psclab --range=10.100.2.0/24 --network=consumer-vpc --region=us-central1
Utwórz punkt końcowy klienta (regułę przekierowania)
W Cloud Shell utwórz statyczny adres IP, który będzie używany jako punkt końcowy klienta.
gcloud compute addresses create psc-consumer-ip-1 --region=us-central1 --subnet=subnet-102 --addresses 10.100.2.10
Użyjmy wygenerowanego wcześniej identyfikatora URI przyłącza usługi, aby utworzyć punkt końcowy klienta.
W Cloud Shell utwórz punkt końcowy klienta.
gcloud compute forwarding-rules create psc-consumer-1 --region=us-central1 --network=consumer-vpc --address=psc-consumer-ip-1 --target-service-attachment=projects/$psclab/regions/us-central1/serviceAttachments/service-1
10. Weryfikowanie usługi Private Service Connect konsumenta – sieć VPC konsumenta
W sieci VPC konsumenta sprawdź, czy połączenie Private Service Connect zostało utworzone, klikając Usługi sieciowe → Private Service Connect → Połączone punkty końcowe. Zwróć uwagę na utworzone wcześniej połączenie psc-consumer-1 i odpowiadający mu adres IP.
Po wybraniu psc-consumer-1 wyświetlą się dodatkowe informacje, w tym identyfikator URI przyłącza usługi.
11. Weryfikowanie usługi Private Service Connect konsumenta – sieć VPC producenta
W sieci VPC producenta sprawdź, czy połączenie Private Service Connect zostało utworzone, klikając Usługi sieciowe → Private Service Connect → Opublikowana usługa. Zwróć uwagę, że połączenie opublikowanej usługi 1 wskazuje teraz 1 regułę przekierowania (punkt końcowy połączenia).
12. Tworzenie prywatnej strefy DNS i rekordu A
Utwórz prywatną strefę DNS mapowaną na punkt końcowy połączenia PSC, aby umożliwić bezproblemowy dostęp do producenta z dowolnego hosta w sieci VPC.
Z Cloud Shell
gcloud dns --project=$psclab managed-zones create codelab-zone --description="" --dns-name="codelab.net." --visibility="private" --networks="consumer-vpc"
gcloud dns --project=$psclab record-sets create service1.codelab.net. --zone="codelab-zone" --type="A" --ttl="300" --rrdatas="10.100.2.10"
13. Sprawdzanie dostępu konsumenta do usługi producenta za pomocą maszyny wirtualnej
W sieci VPC konsumentów utworzymy maszynę wirtualną, aby przetestować połączenie z usługą lokalną, uzyskując dostęp do punktu końcowego konsumenta service1.codelabs.net.
W Cloud Shell utwórz instancję testową w sieci VPC klienta.
gcloud compute instances create consumer-vm \
--zone=us-central1-a \
--image-family=debian-10 \
--image-project=debian-cloud \
--subnet=subnet-101 \
--no-address
Aby umożliwić IAP połączenie z instancjami maszyn wirtualnych, utwórz regułę zapory sieciowej, która:
- Dotyczy wszystkich instancji maszyn wirtualnych, które mają być dostępne przez IAP.
- Zezwala na ruch przychodzący z zakresu adresów IP 35.235.240.0/20. Ten zakres zawiera wszystkie adresy IP, których IAP używa do przekierowywania TCP.
W Cloud Shell utwórz instancję testową w sieci VPC klienta.
gcloud compute firewall-rules create ssh-iap-consumer \
--network consumer-vpc \
--allow tcp:22 \
--source-ranges=35.235.240.0/20
Zaloguj się na maszynie wirtualnej consumer-vm za pomocą IAP w Cloud Shell, aby sprawdzić połączenie z usługą lokalną, wykonując polecenie curl względem usługi DNS FQDN service1.codelab.net. Jeśli wystąpi przekroczenie limitu czasu, spróbuj ponownie.
gcloud compute ssh consumer-vm --project=$psclab --zone=us-central1-a --tunnel-through-iap
Wykonaj polecenie curl, aby sprawdzić połączenie z usługą lokalną. Po zweryfikowaniu zamknij maszynę wirtualną i wróć do wiersza poleceń Cloud Shell.
W Cloud Shell wykonaj polecenie curl.
$ curl -v service1.codelab.net
* Trying 10.100.2.10...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x5650fc3390f0)
* Connected to service1.codelab.net (10.100.2.10) port 80 (#0)
> GET / HTTP/1.1
> Host: service1.codelab.net
> User-Agent: curl/7.64.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Content-Type: text/html; charset=utf-8
< Accept-Ranges: bytes
< ETag: "3380914763"
< Last-Modified: Mon, 05 Dec 2022 15:10:56 GMT
< Expires: Mon, 05 Dec 2022 15:15:41 GMT
< Cache-Control: max-age=0
< Content-Length: 37
< Date: Mon, 05 Dec 2022 15:15:41 GMT
< Server: lighttpd/1.4.53
<
Welcome to my on-premise service!!
Poniżej znajduje się przykładowy zrzut z usługi lokalnej. Zwróć uwagę, że adres IP źródła 172.16.0.2 pochodzi z zakresu podsieci serwera proxy TCP 172.16.0.0/23.
14. Zwalnianie miejsca po stronie producenta
Usuwanie komponentów Producer
W Cloud Shell usuń komponenty producenta.
gcloud compute instances delete test-box-us-central1 --zone=us-central1-a --quiet
gcloud compute service-attachments delete service-1 --region=us-central1 --quiet
gcloud compute forwarding-rules delete tcp-ilb-psc --region=us-central1 --quiet
gcloud compute target-tcp-proxies delete on-premise-svc-tcpproxy --region=us-central1 --quiet
gcloud compute backend-services delete on-premise-service-backend --region=us-central1 --quiet
gcloud compute network-endpoint-groups delete on-prem-service-neg --zone=us-central1-a --quiet
gcloud compute networks subnets delete psc-nat-subnet subnet-201 proxy-subnet-us-central --region=us-central1 --quiet
gcloud compute firewall-rules delete ssh-iap fw-allow-proxy-only-subnet allow-to-ingress-nat-subnet fw-allow-health-check --quiet
gcloud compute health-checks delete on-prem-service-hc --region=us-central1 --quiet
gcloud compute networks delete producer-vpc --quiet
15. Zwalnianie miejsca na dane konsumentów
Usuwanie komponentów konsumenta
W Cloud Shell usuń komponenty konsumenta.
gcloud compute instances delete consumer-vm --zone=us-central1-a --quiet
gcloud compute forwarding-rules delete psc-consumer-1 --region=us-central1 --quiet
gcloud compute addresses delete psc-consumer-ip-1 --region=us-central1 --quiet
gcloud compute networks subnets delete subnet-101 subnet-102 --region=us-central1 --quiet
gcloud compute firewall-rules delete ssh-iap-consumer --quiet
gcloud dns record-sets delete service1.codelab.net --type=A --zone=codelab-zone --quiet
gcloud dns managed-zones delete codelab-zone --quiet
gcloud compute networks delete consumer-vpc --quiet
16. Gratulacje
Gratulacje, udało Ci się skonfigurować i zweryfikować Private Service Connect za pomocą serwera proxy TCP.
Infrastruktura producenta została utworzona, a w sieci VPC producenta dodano przyłącze usługi wskazujące usługę lokalną. Wiesz już, jak utworzyć punkt końcowy konsumenta w sieci VPC konsumenta, który umożliwia połączenie z usługą lokalną.
Co dalej?
Sprawdź te ćwiczenia z programowania:
- Używanie usługi prywatnej do publikowania i korzystania z usług w GKE
- Publikowanie i korzystanie z usług za pomocą Private Service Connect