Wprowadzenie
Projektowanie sieci w chmurze publicznej jest jednym z wyzwań podczas adopcji chmury. Niestety podczas wielu wdrożeń możemy zauważyć jak lekceważona jest poprawna infrastruktura sieciowa w chmurze. Mimo sporej ilości dokumentacji, szkoleń oraz materiałów naukowych udostępnianych przez dostawców usług chmurowych, poprawne zaimplementowanie infrastruktury sieciowej nie jest standardem, nad czym ubolewam. Poprawna implementacja zwiększa poziom bezpieczeństwa w środowisku, ogranicza koszty oraz ułatwia zarządzanie ruchem sieciowym w naszej organizacji. Właśnie dlatego tak ważnym jest poprawne zaprojektowanie oraz stworzenie infrastruktury sieciowej.
Topologia Hub and Spoke
Jedną z topologii zalecanych przez Microsoft jest topologia Hub and Spoke, tłumaczona w dokumentacji Microsoftu jako topologia piasty i szprych. Polega ona na stworzeniu centralnej sieci, tzw. „Huba” przez który jest kierowany cały ruch sieciowy adresowany do sieci typu „Spoke”. Przykładowa infrastruktura jest ukazana na poniższym obrazku.
Jak widzicie, mamy dwie sieci w Azure typu „Spoke”, oraz jedną typu „Hub”. Sieci spoke’owe są połączone peeringiem z siecią Hub. Dodatkowo w powyższym przykładzie mamy również sieć lokalną, która jest połączona z naszym środowiskiem chmurowym za pomocą VPN Gateway’a oraz połączenia Site-to-Site. Ruch sieciowy wychodzący oraz przychodzący do sieci typu spoke jest kierowany przez sieć typu „Hub”, co pozwala na centralną analizę ruchu oraz zastosowanie dodatkowych rozwiązań z zakresu bezpieczeństwa. Przykładowo w powyższym wdrożeniu widzimy usługę Azure Firewall, która filtruje ruch przechodzący przez centralną sieć. W poniższym wpisie wdrożymy sobie sieć w topologii Hub and Spoke w chmurze publicznej, jednakże do adresowania ruchu z sieci centralnej nie użyjemy Azure Firewalla, a tańszej alternatywy w postaci VPN Gatewaya. Miej jednak w pamięci, że takie rozwiązanie nie jest wydajne w takim samym stopniu co zastosowanie Azure Firewalla oraz może powodować opóznienia, o czym Microsoft informuje w swojej dokumentacji.
Tworzenie sieci
Zaczniemy od stworzenia sobie 3 sieci wirtualnych w Azure. Ważne, aby stworzone sieci nie zawierały adresacji IP nachodzącej na siebie. Polecam wykorzystać następującą konfigurację.
Siec Hub:
Nazwa: vnet-hub-01
IP Address space: 10.0.0.0/16
Sieć spoke 1:
Nazwa: vnet-spoke-01
IP Address space: 10.1.0.0/16
Sieć spoke 2:
Nazwa: vnet-spoke-02
IP Address space: 10.2.0.0/16
Region nie ma znaczenia, jedynie warto mieć w pamięci, że w sieciach typu spoke będzie wdrażać wirtualne maszyny w celu wykonania testów, a więc powinien to być region, w którym możliwe jest stworzenie wirtualnych maszyn.
W kolejnym kroku, jak już stworzymy sieci w naszym środowisku, należy stworzyć VPN Gateway’a w naszej centralnej sieci. VPN Gateway będzie miał na celu przesyłanie ruchu wychodzącego z sieci typu spoke do docelowej sieci.
Kolejnym krokiem jest połączenie sieci typu „Spoke” z siecią centralną za pomocą peeringów. Robimy to w następujący sposób.
To samo robimy dla sieci spoke2, gdzie łączymy ją również z Hubem. Sieć spoke1 oraz spoke02, nie mają bezpośredniego peeringu między sobą, a cały ruch ma być przesyłany przez sieć centralną.
Kolejnym krokiem wymaganym do stworzenia chcianej infrastruktury jest stworzenie User-Defined Routes w Azure, które będą kierować ruch z sieci spoke’owych do VPN gatewaya.
W destination IP podajemy zakres sieciowy sieci, do której chcemy prowadzić ruch. Jeżeli odpytujemy z spoke 1 – 10.1.0.0/16, to destination IP będzie 10.2.0.0/16, czyli sieć spoke2. W kolejnym kroku przypisujemy Route Table, do naszego subnetu.
Następnym krokiem będzie powtórzenie tej operacji dla drugiej sieci typu Spoke.
Po wykonaniu tych akcji otrzymujemy w pełni funkcjonalną topologię sieci Hub and Spoke, gdzie mamy jedną sieć centralną oraz dwie spoke’owe.
Testy
Aby wykonać testy, tworzymy dwie wirtualne maszyny. Jedną w sieci spoke1 oraz jedną w sieci spoke2, w moim przypadku są to dwie wirtualne maszyny z obrazem Ubuntu. Loguję się na jedną z nich i w celu testu połączenia wykonuję prostą komendę ping wraz z adresem IP maszyny z drugiej sieci spoke. Jeżeli wszystko wykonałeś poprawnie to powinieneś zobaczyć następujący rezultat.
Podsumowanie
Stworzenie takiej topologii pozwala na wykorzystanie dodatkowych rozwiązań z zakresu bezpieczeństwa w sieci centralnej. Takimi rozwiązaniami może być przykładowo wspomniany już Azure Firewall, ale również Azure Bastion czy Network Watcher. Zawsze jednak powinieneś swoją propozycję infrastruktury sieciowej przeanalizować względem wymagań klienta, ponieważ może się okazać, że dane rozwiązanie nie będzie dopasowane do jego potrzeb.