Citrix NetScaler meerdere VIPs

[Jazzy]

Ik probeer de Citrix NetScaler door te krijgen om in te zetten als load balancer voor een HTTPS service. Het gaat om Exchange 2013 dus ik wil al het verkeer op één hostnaam/IP, SSL Offloading, reencryptie en een monitor per virtual directory. Wat ik nu doe:

• Maak een Content Switching Virtual Server (VIP + poort 443)
• Maak een Load Balancing Virtual Server per virtual directory (/owa, /ecp). Bind aan elke LB VS een niet gebruikt, NS intern IP adres.
• Maak een SSL Service Group, bind twee services aan de Service Group en bind de Service Group aan de LB Virtual Servers
• Bind een SSL certifciaat aan de CS en LB Virtual Servers, maak Monitors aan en bind ze aan de LB Virtual Servers.
• maak CS policies en bind deze aan de CS VS.

Dit werkt prima. In DNS pas ik het record aan naar de VIP en mijn service werkt.

Nu zou ik exact dezelfde CS en LB VS ook op een ander IP-adres willen laten luisteren, misschien in het zelfde subnet of zelfs op een andere interface. Ik begrijp dat ik geen tweede VIP aan een VS kan binden, moet ik in dit geval dan de hele config dupliceren? Of kan ik volstaan met een duplicaat CS VS met een ander VIP en dan de zelfde cert, monitors en cs policy binden?

O ja, ik gebruik versie 10.5.

[Wim-Bart]

Je kan op 1 CS meerdere domeinnamen hosten, de rest is gewoon dupliceren. De exacte inrichting kan ik niet geven want dat pleeg ik broodroof van mezelf ;-)

[ Voor 35% gewijzigd door Wim-Bart op 27-07-2014 04:14 ]

[Jazzy]

Ik heb het niet over meerdere domeinnamen maar over een ander VIP. Denk bijvoorbeeld aan het aanbieden van dezelfde dienst vanuit het interne netwerk en ook vanaf het internet, in elke subnet heb ik een VIP beschikbaar waarop ik precies hetzelfde aan wil bieden.

Mijn vraag is dus, maak ik een duplicaat CS VS aan met een ander VIP en kan ik de rest hergebruiken? Of is er een betere of andere manier om dit met een NetScaler te doen?

[Wim-Bart]

In theorie is een hoop mogelijk, bijvoorbeeld je hebt een VS voor LDAP gebruikt, deze kan je hergebruiken, een VS voor interne WI, kan je ook hergebruiken.

De theorie is dat een VIP of MIP een service draait en dat je deze service via een andere VIP, MIP kan ontsluiten. Je kan zelfs een intern netwerk definieeren wat alleen op de Netscaler aanwezig is. Daar maak je VIP's op die services aanbieden zoals een LDAP, WI, RADIUS et cetera, en deze kan je weer gebruiken in andere VS's,

[Jazzy]

Ah, ik begin het te snappen. Dus ik zou in dit geval gewoon een eenvoudige Laod Balancing VS kunnen maken met een VIP in het goede netwerk en die naar de Content Switching Virtual Server laten wijzen.

Dit is (een deel van) mijn config nu:

code:

add cs vserver vserver-cs-exchange-https SSL 123.123.123.123 443
add lb vserver vserver-lb-exchange-owa ssl 10.0.0.1 443
add lb vserver vserver-lb-exchange-ecp ssl 10.0.0.2 443
add servicegroup servicegroup-exchange-https SSL
bind servicegroup servicegroup-exchange-https 192.168.1.1 443
bind servicegroup servicegroup-exchange-https 192.168.1.2 443
bind lb vserver vserver-lb-exchange-owa servicegroup-exchange-https
bind lb vserver vserver-lb-exchange-ecp servicegroup-exchange-https
bind ssl vserver vserver-cs-exchange-https -certkeyName wildcard
bind ssl vserver vserver-lb-exchange-owa -certkeyName wildcard
bind ssl vserver vserver-lb-exchange-ecp -certkeyName wildcard
add lb mon monitor-exchange-owa HTTP-ECV -interval 30 -secure YES -send "GET /owa/healthcheck.htm" -recv "200 OK"
add lb mon monitor-exchange-ecp HTTP-ECV -interval 30 -secure YES -send "GET /ecp/healthcheck.htm" -recv "200 OK"
bind lb monitor monitor-exchange-owa servicegroup-exchange-https
bind lb monitor monitor-exchange-ecp servicegroup-exchange-https
add cs policy pol-exchange-owa -url "/owa/*"
add cs policy pol-exchange-ecp -url "/ecp/*"
bind cs vserver vserver-cs-exchange-https -lbvserver vserver-lb-exchange-owa
bind cs vserver vserver-cs-exchange-https vserver-lb-exchange-owa -policyName pol-exchange-owa
bind cs vserver vserver-cs-exchange-https vserver-lb-exchange-ecp -policyName pol-exchange-ecp

Nu luistert mijn CS VS dus op 123.123.123.123 maar ik wil dat hij ook luistert op 192.168.1.5.

Ik heb een LB VS toegevoegd met dit VIP en dacht de service 123.123.123.123 dan te kunnen binden, maar dat gaat niet: Resource already exists

[ Voor 82% gewijzigd door Jazzy op 28-07-2014 09:54 ]

[Jazzy]

Om mijn vraag zefl te beantwoorden, ik moest gewoon een tweede Content Switching Virtual Server aanmaken met het nieuwe VIP. Vervolgens het certificaat en de bestaande CS Policies binden en klaar is Kees.

Jazzy schreef op zondag 27 juli 2014 @ 11:08:
Mijn vraag is dus, maak ik een duplicaat CS VS aan met een ander VIP en kan ik de rest hergebruiken?

Het antwoord op deze vraag was dus gewoon ja.

[ Voor 38% gewijzigd door Jazzy op 28-07-2014 12:20 ]

[Wim-Bart]

En zie hier de mogelijkheden van de Netscaler. Daarnaast kan je ook nog leuke rewrite rules maken, zodat je bijvoorbeeld https://webmail.mijndomein.nl automatisch naar https://webmail.mijndomein.nl/owa vertaald. Je kan een CS ook gebruiken om bijvoorbeeld meerdere klanten te bedienen. Voorbeeld:

https://klanta.onzeexchange.com gaat naar een VS die klant a bediend, https://klantb...... gaat naar een VS die klant B bediend.

[Fr0zenFlame]

Hallo,

Heb een vraag die hier wel bij aansluit denk ik, helaas kan ik het nergens anders vinden
Op mn netscaler heb ik ook een x aantal VIPs allemaal verwijzend naar verschillende servers, voor elke server een subdomein_domein.nl_443 en een subdomein_domein.nl_80, maar nu komt het verzoek dat er twee verschillende subdomeinen (records) moeten worden aangemaakt richting een en dezelfde server, ook weer een _80 en een _443, voor de eerst was dit natuurlijk geen probleem, maar zodra ik het tweede subdomein configureer krijg ik de melding "Resource already exists" (Ze verwijzen natuurlijk naar dezelfde server).

Is hier een workarround of andere oplossing voor?


Netscaler menu:
Traffic Management > Load Balancing > Virtual Servers

Netscaler firmware:
NS10.1: Build 112.15.nc

Doel:
Het uiteindelijke doel is het koppelen van een PUBLIEK IP (hebben we beperkt aantal van) aan een DMZ IP (ook een beperkte scope) zodat we een bepaalde webserver/service via een subdomein (publiek IP) kunnen aanbieden over de netscaler zodat we ook daar de SSL offloading kunnen doen.