Azure Traffic Manager SSL-Setup (nicht klassisch)

Ich habe einen Azure-API-App-Dienst, für den ich "Prioritäts" -Verkehrsverwaltung konfigurieren möchte (dies ist der neue Traffic-Manager, nicht klassisch). Ich habe den Dienst in zwei separaten Azure-Regionen bereitgestellt und eine Traffic Manager-Instanz konfiguriert, um das Prioritätsrouting für die beiden Dienstinstanzen auszuführen. Die Dienste haben die folgenden benutzerdefinierten Domain-Konfigurationen:Azure Traffic Manager SSL-Setup (nicht klassisch)

foo1.mydomain.com

foo2.mydomain.com

Ich habe A-Datensätze für beide Teilbereiche an den jeweiligen Service-IP-Adressen Azure App zeigt.

Ich habe auch ein Wildcard-Zertifikat an die Dienste angeschlossen und alles funktioniert gut, wenn ich zu https://foo1.mydomain.com oder https://foo2.mydomain.com navigieren. Die Traffic Manager-Endpunktüberwachung zeigt beide Endpunkte als online und aktiviert an.

Nun möchte ich, dass Clients Anfragen an einen Vanity-Endpunkt richten: foo.mydomain.com, für den ich einen CNAME erstellt habe. Der CNAME wird auf die Traffic-Manager-Instanz-URL myapi.trafficmanager.net verwiesen.

Wenn ich versuche, die Vanity-URL mithilfe von SSL/TLS aufzulösen, d. H. https://foo.mydomain.com, erhalte ich einen Zertifikatfehler, da der Traffic Manager ein * .azurewebsited.net-Zertifikat anfügt. Wenn ich versuche, die Vanity-URL ohne SSL/TLS aufzulösen, d. H. http://foo.mydomain.com, erhalte ich eine Nachricht 404 und "Web-App nicht gefunden". Auch hier führt die Auflösung der einzelnen Endpunkte explizit wie erwartet zu 200 zurück.

Meine Frage: Wie konfiguriere ich Azure Traffic Manager richtig, um das Prioritätsrouting für zwei benutzerdefinierte Domänennamen mit meinem SSL/TLS-Zertifikat und einer Vanity-URL durchzuführen?

Dig Ausgabe als Referenz:

Justins-Laptop:~ jtw$ dig foo.mydomain.com 

; <<>> DiG 9.8.3-P1 <<>> foo.mydomain.com 
;; global options: +cmd 
;; Got answer: 
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4088 
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0 

;; QUESTION SECTION: 
;foo.mydomain.com.  IN A 

;; ANSWER SECTION: 
foo.mydomain.com. 299 IN CNAME myapi.trafficmanager.net. 
myapi.trafficmanager.net. 299 IN CNAME foo1.mydomain.com. 
foo1.mydomain.com. 299 IN A 192.168.1.1 //the actual IP of my first priority endpoint is returned here 

;; Query time: 369 msec 
;; SERVER: 8.8.8.8#53(8.8.8.8) 
;; WHEN: Sun Jul 3 11:13:59 2016 
;; MSG SIZE rcvd: 112

Quelle

2016-07-02 JT Wolgamott

Bitte sehen https://azure.microsoft.com/en-gb/documentation/articles/traffic-manager-how-traffic-manager-works/

Seit Traffic Manager auf der DNS-Ebene arbeiten, das Zertifikat, das Sie (* .azurewebsites.net) sehen kommt aus dem App-Service werden muß, nicht von Traffic Managern. Sie müssen Ihren App-Dienst so konfigurieren, dass das richtige SSL-Zertifikat verwendet wird.

Ich empfehle, dass Sie versuchen, alles ohne Traffic Manager arbeiten zu lassen, wobei Ihre Vanity-Domain foo.mydomain.com als CNAME auf einen Ihrer Endpunkte (foo1.mydomain.com) eingerichtet wird. Wechseln Sie dann den CNAME, um auf den anderen Endpunkt (foo2.mydomain.com) zu zeigen, und stellen Sie erneut sicher, dass alles funktioniert. Da zu diesem Zeitpunkt keine Probleme mit Traffic Manager auftreten können, sind sie einfacher zu debuggen.

Sobald dies funktioniert, führen Sie Traffic Manager erneut in die CNAME-Kette ein.

Grüße,

Jonathan Tuliani, Program Manager, Azure Networking - DNS und Traffic Manager

Quelle

2016-07-04 11:03:57

Danke Jonathan. Das hat mich in die richtige Richtung geleitet. Mir war nicht klar, dass ich den Namen der Vanity-Domain zuweisen und das Zertifikat an beide Endpunkte an die Vanity-Domain binden musste. Sobald ich das getan habe, hat alles wie erwartet funktioniert. –

Gern geschehen! Bitte up-vote, damit andere sehen können ... danke. Schön, dass es jetzt für dich funktioniert. –

Traffic Manager ist nichts angebracht, da es nicht ein Web-Server ist, ist es ein nur ein smarter-als-your-Durchschnitt-bear-Nameserver.

neu definieren Ihre Traffic-Manager-Endpunkte wie:

foo.domain.com 
bar.domain.com

Statt .azurewebsites.net Domains.

Quelle

2016-07-02 20:44:36 evilSnobu

Beziehen Sie sich auf den Traffic Manager "classic"? Ich verstehe, dass Traffic Manager wirklich nur eine DNS-Komponente ist. Mein Problem ist, dass der neue Traffic Manager scheinbar keinen Vanity-Einstiegspunkt unterstützt, der zu einem der vielen zugrunde liegenden SSL/TLS-Endpunkte führt. –

Derzeit kann Traffic Manager (ARM oder ASM) nicht hinter einer Root-Level-Domain (@) 'domain.com' sitzen. Sie müssen stattdessen "something.domain.com" tun. Aber Sie erwähnen __vanity__ domain und 'foo.mydomain.com', wenn Sie also richtig sind, fallen Sie nicht unter diese Einschränkung. – evilSnobu

Nur um die Dinge zu verdeutlichen, ändern Sie Ihre Frage mit der Ausgabe von 'dig your.public-facing-domain.com' und redigieren Sie alles, was Sie für notwendig halten. Sie können http://digwebinterface.com verwenden, wenn Sie keine Linux-Box zur Hand haben. – evilSnobu

Der Name Vanity-Domäne an jeden Endpunkt App-Dienst zugewiesen werden muss und das Zertifikat muss das Individuum gebunden sein Endpunkte dh foo1 und foo2 sowie der Vanity-Endpunkt. Sie müssen das Zertifikat an die Vanity-Domäne in allen App-Diensten binden, die als Endpunkte verwendet werden..

Die DNS-Konfiguration muss wie folgt lauten:

einen A-Datensatz für jede App Service-Endpunkt-Domäne, indem er auf die IP-Adresse von Azure für den App-Dienst zugewiesen.

Ein CNAME, der von der Vanity-Domain auf die Domäne * .trafficmanager.net verweist.

Quelle

2016-07-05 15:10:39

Azure Traffic Manager SSL-Setup (nicht klassisch)

Antwort

Verwandte Themen