Piszki Lab

Analiza przypadku w języku przodków…

Horizon View 6.0: balansowanie ruchem za pomocą BIG-IP F5 (bez użycia iApp)

| 0 comments

Przy tak postawionym tytule, należy od razu odpowiedzieć na pytanie, czemu mamy balansować ruchem bez użycia tak fajnego rozwiązania jakim jest iApp (for View)? Odpowiedź jest prosta, używając iApp, nie zrobisz niczego, czego nie przewidzieli jej twórcy (na przykład, nie przewidzieli używania polityk bezpieczeństwa oraz nie ma obsługi protokołu BLAST). Podstawową zaletą iApp jest szybkość wdrożenia, kilka kliknięć i gotowe. Ręcznie trwa to trochę dłużej ale efekt jest ten sam a możliwości dużo większe. W opisanej przeze mnie konfiguracji, użyłem balansowania ruchem na poziomie serwerów połączeń z pominięciem serwerów bezpieczeństwa. Uważam, że balansowanie serwerami bezpieczeństwa nie ma sensu, w końcu F5 ma je zastąpić! Oczywiście w naszej sieci istnieją takie serwery, są one tradycyjną furtką bezpieczeństwa dla użytkowników uprzywilejowanych (VIP), czyli głównie administratorów. To samo dotyczy sieci wewnętrznej, można jednocześnie łączyć się poprzez F5 (User) lub bezpośrednio na dany serwer połączeń (VIP). Taka konfiguracja daje nam duży stopień elastyczności i odporności na potencjalne awarie oraz spore możliwości dla Administratorów.

Przechwytywanie

Zgodnie z tym co widać na rysunku, na wstępie musimy spełnić kilka warunków. Na zewnętrznym firewallu należy otworzyć i przekierować na odpowiedni adres w F5 (w moim przypadku 172.18.31.130) następujące porty, TCP: 80, 443, 8443, 4127, UDP:4127. Stworzyć na zewnętrznym serwerze DNS rekord (view.pulab.pl) który w sieci LAN będzie rozwiązywał się lokalnym adresem F5 (NAT). Sama konfiguracja Horizon View nie odbiega od standardu, w naszym przypadku połączenie do maszyn jest szyfrowane, istnieje możliwość podłączenia się poprzez BLAST. Ze względu na obciążenia sieci, serwery połączeń nie funkcjonują jako proxy dla protokołu PCoIP.

Konfiguracja “Connection Server”:

fv2

Konfiguracja “Security Server”:

fv3

BIG-IP F5 można wykorzystać do terminowania połączeń SSL (offload). Aby taki serwer połączeń uruchomił się na porcie 80, należy w katalogu C:\Program Files\VMware\VMware View\Server\sslgateway\conf stworzyć plik o nazwie locked.properties z zawartością serverProtocol=http (i zrestartować usługę). Dodatkową zaletą takiej konfiguracji jest też to, że nie trzeba tworzyć wirtualnego serwera (na F5) na porcie 80 w celu przekierowania ruchu. Port 80 zostanie przekierowany na 443 przez serwer połączeń (przy połączeniu przez przeglądarkę). Przechodzimy do F5, na początku stworzymy wszystkie potrzebne profile. Zaczynamy od Client-SSL, w naszym przypadku mamy certyfikat typu Wildcard i jeden profil który używamy przy wszystkich wirtualnych serwerach (PULAB):

fv6

W opisywanej konfiguracji, adres view.pulab.pl (dostępny przez F5 z zewnątrz i z wewnątrz) będzie posługiwał się ww. certyfikatem wildcard, natomiast wszystkie serwery połączeń będą miały własne certyfikaty wystawione przez lokalne CA. W kolejnym kroku tworzymy profil utrzymania połączeń (persistence):

fv5

Tworzymy profil HTTP dla połączeń na porcie 443:

fv4

Tworzymy monitor dla “Connection Server” (zgodnie z dokumentacją Horizon View):fv7

Teraz tworzymy pule serwerów, zaczynamy od HTTPS, port 443, health monitor jak wyżej:

fv9

Pula HTTP, potrzebna do wykonania offloadu SSL na F5, health monitor jak wyżej:

fv8

Pula PCoIP, port 4172, health monitor “gateway_icmp” (należy na firewallu wszystkich “Connection Server” dodać regułę ICMP/PING):

fv10

Pula BLAST, port 8443, monitor “gateway_icmp”:

fv11

W kolejnym kroku przechodzimy do stworzenia wirtualnych serwerów, zaczynamy od Horizon-View-HTTPS (SNAT->AutoMap). Jak widać na rysunkach, nie używamy profilu SSL dla serwera a pula serwerów to HTTP, przy takiej konfiguracji wykonywany jest offloading SSL na F5:

fv22

fv20

Następnie tworzymy wirtualny serwer odpowiedzialny za obsługę BLAST/HTML (SNAT->AutoMap), w tym wypadku połączenie do serwera jest szyfrowane(offload SSL nie jest wspierany przy BLAST):

fv14

fv17

W ostatnim kroku tworzymy serwery wirtualne do obsługi protokołu PCoIP (UDP/TCP):

fv16

fv18

fv19

Mapa naszych wirtualnych serwerów przedstawia się następująco:

fv1

Taka konfiguracja działa bardzo sprawnie i wydajnie. Opisane rozwiązanie w wersji pierwotnej zostało przetestowane w BIG-IP F5 VE, jednak ze względu na ograniczenia przepustowości, wersja F5 VE nadaje się jedynie do małych środowisk testowych. Pozdrawiam i życzę udanych testów.

Oceń ten artykuł:
[Total: 0 Average: 0]

Dodaj komentarz

Required fields are marked *.