Thông tin cơ bản về Tên miền, FQDN và địa chỉ URL | Hạ tầng sàn giao dịch |Phần 09#36

Kênh liên lạc giữa máy khách Exchange và máy chủ Exchange dựa trên một khái niệm đơn giản, trong đó máy khách Exchange đánh địa chỉ máy chủ Exchange bằng cách sử dụng tên máy chủ Exchange hoặc nếu chúng ta muốn chính xác hơn - máy chủ Exchange FQDN.

Sự đa dạng của các dịch vụ được máy chủ Exchange cung cấp cho máy khách Exchange của mình yêu cầu các dịch vụ web Exchange và kết thúc bằng các dịch vụ dành cho máy khách webmail như OWA, được máy khách Exchange triển khai để truy cập dịch vụ Exchange này bằng cách sử dụng địa chỉ URL.

Về mối quan hệ tồn tại giữa máy chủ Exchange và máy khách Outlook, tất cả thông tin này được đóng gói và chuyển đến máy khách Outlook thông qua phản hồi Tự động phát hiện do máy chủ Exchange cung cấp.

Như đã đề cập trong bài viết trước, mỗi máy chủ Exchange công khai có hai danh tính - nhận dạng riêng tư và nhận dạng công khai.

Khi Exchange cung cấp thông tin về các dịch vụ web Exchange sẵn có, thông tin được cung cấp ở hai “định dạng” khác nhau:

• Thông tin liên quan đến máy khách Outlook nội bộ
• Thông tin liên quan đến máy khách Outlook bên ngoài

Sự khác biệt chính trong thông tin được cung cấp cho máy khách Outlook nội bộ so với bên ngoài là địa chỉ URL của dịch vụ web Exchange.

• Thông tin liên quan đến máy khách Outlook nội bộ bao gồm địa chỉ URL của dịch vụ web Exchange sử dụng FQDN Exchange nội bộ.
• Thông tin liên quan đến các máy khách Outlook bên ngoài bao gồm địa chỉ URL của dịch vụ web Exchange sử dụng Exchange FQDN bên ngoài.

Khái niệm địa chỉ URL và dịch vụ web Exchange

Mặc dù rõ ràng, chúng ta đã quen với khái niệm sử dụng địa chỉ web (URL), nhưng tôi muốn dành phần sau cho chủ đề Tự động phát hiện và địa chỉ URL vì chủ đề này không đơn giản như vẻ ngoài của nó.

Trong hành trình trở thành “Chuyên gia Autodiscover”, chúng ta cần làm quen với

1. Cấu trúc của địa chỉ URL dịch vụ web Exchange
2. Phần khác bao gồm địa chỉ URL của dịch vụ web
3. Địa chỉ URL khác nhau mà Exchange cung cấp cho ứng dụng thư nội bộ và ứng dụng thư bên ngoài.

Ngoài ra, câu hỏi có thể xuất hiện có thể là:

1. Máy chủ Exchange CAS đặt địa chỉ URL cho các dịch vụ web như thế nào?
2. Chúng ta có nên “Can thiệp” vào cài đặt mặc định của địa chỉ URL dịch vụ web Exchange không?
3. Các tình huống mà chúng ta cần thực hiện “Can thiệp” này là gì?
4. Có cách thực hành tốt nhất nào cho địa chỉ URL của dịch vụ web Exchange không?

Và như thường lệ, không có câu trả lời đơn giản nào cho câu hỏi này.
Trong bài viết hiện tại, chúng tôi sẽ tập trung vào “cấu trúc vật lý” của địa chỉ URL dịch vụ web Exchange

Cấu trúc địa chỉ URL | Chế độ xem cấp cao

Hãy bắt đầu bằng một câu hỏi rất đơn giản:
Hỏi. Bạn có biết URL viết tắt của từ gì không?

A: Chà… Tôi sẽ không làm bạn nhàm chán với những cuộc thảo luận mang tính học thuật, nhưng đối với những bạn chưa biết câu trả lời, URL là viết tắt của -uniform Resource locator.

Hầu hết chúng ta đều liên kết thuật ngữ - ” URL ” với các thuật ngữ như - trình duyệt, trang web, v.v.

“Trình duyệt” chỉ là một ví dụ về “khách hàng” có thể sử dụng các dịch vụ dựa trên web.

Trên thực tế, có nhiều loại “máy khách” có thể sử dụng các dịch vụ dựa trên web.
Ví dụ: Outlook là một máy khách phụ thuộc nhiều vào các dịch vụ web Exchange.

Cấu trúc địa chỉ URL

Địa chỉ URL giống như một câu đố, được tạo thành từ nhiều phần.

Việc “xin” địa chỉ URL sẽ “khai báo” giao thức (ngôn ngữ) mà máy khách và máy chủ sẽ sử dụng. Trong môi trường dựa trên Exchange, các dịch vụ web được cung cấp bằng cách sử dụng giao thức HTTP và giao thức HTTPS (phiên bản được mã hóa của giao thức HTTP).

“Phần giữa” của địa chỉ URL, bao gồm thông tin về máy chủ hoặc tên “thành phần” sẽ cung cấp dịch vụ web.

Hầu hết các quy ước đặt tên mà chúng tôi sử dụng để “trỏ vào” máy chủ cung cấp các dịch vụ web cụ thể dựa trên quy ước đặt tên FQDN (tên miền đủ điều kiện).

“Phần cuối cùng” hoặc “phần bên phải” của địa chỉ URL bao gồm đường dẫn cho các dịch vụ web cụ thể. “Đường dẫn” không phải là phần bắt buộc của địa chỉ URL.

Chúng tôi sử dụng tùy chọn “cách” trong trường hợp máy chủ cụ thể cung cấp một số dịch vụ web hoặc chúng tôi muốn trỏ máy khách đến một thư mục hoặc tệp cụ thể.

Ví dụ: máy chủ Exchange CAS cung cấp nhiều loại dịch vụ web. Khi máy khách Exchange cần một dịch vụ web cụ thể từ máy chủ Exchange CAS, máy khách Exchange sẽ phải đánh địa chỉ máy chủ Exchange CAS bằng cách sử dụng URL bao gồm tên máy chủ Exchange CAS + đường dẫn của dịch vụ web cụ thể.

Trong bài viết này, chúng tôi sẽ chỉ tập trung vào “phần giữa” (tên máy chủ hoặc tên FQDN) của địa chỉ URL dịch vụ web Exchange vì trong trường hợp chúng tôi cần định cấu hình hoặc điều chỉnh địa chỉ URL của một dịch vụ web Exchange cụ thể, chúng tôi sẽ cập nhật hoặc đặt phần liên quan đến tên máy chủ Exchange.

Trường hợp chúng tôi cập nhật phần “đường dẫn” của địa chỉ URL dịch vụ web Exchange là rất hiếm và không được khuyến nghị.

Tên máy chủ so với tên FQDN

Tên máy chủ là tên logic mà chúng tôi sử dụng để đặt địa chỉ cho một “phần tử” mạng cụ thể.
Chúng tôi có thể định nghĩa thuật ngữ tên máy chủ là “tên đơn” hoặc “tên một từ”.

Thuật ngữ FQDN là viết tắt của - Complete Qualified Domain Name.
Đối với tôi, từ FQDN luôn nghe có vẻ lạ.

Thuật ngữ - “Tên miền đủ điều kiện” xác định quy ước đặt tên, nhưng thuật ngữ FQDN liên quan đến “Tên máy chủ đầy đủ” so với thuật ngữ - “Máy chủ” xếp hạng bằng một tên máy chủ duy nhất.

FQDN được tạo bằng cách sử dụng công thức sau:

Để có thể hiểu rõ hơn sự khác biệt giữa thuật ngữ tên máy chủ và thuật ngữ tên FQDN, chúng ta có thể liên quan đến “địa chỉ con người” tiêu chuẩn. ”

Khi chúng tôi đề cập đến ai đó bằng tên - John, điều này tương đương với thuật ngữ tên máy chủ. Cái tên “John” không thể được coi là một định danh duy nhất.

Trong trường hợp chúng tôi cần gửi một gói hàng cho John, chúng tôi sẽ cần sử dụng một địa chỉ sẽ là mã định danh duy nhất và sẽ cho phép chúng tôi chắc chắn rằng gói hàng đó đã được gửi đến người nhận đích được yêu cầu.

Trong trường hợp này, chúng tôi sẽ sử dụng địa chỉ “Đầy đủ” hoặc “hoàn chỉnh” của John bao gồm họ, địa chỉ đường phố, thành phố, v.v.

Chúng ta có thể nói rằng “Địa chỉ đầy đủ” của John giống hệt với kịch bản trong đó chúng ta đánh địa chỉ một máy chủ cụ thể bằng cách sử dụng FQDN của anh ta trong môi trường mạng.

Về mặt kỹ thuật, trong mạng nội bộ, chúng ta có thể đánh địa chỉ một “máy chủ” cụ thể bằng cách chỉ sử dụng tên máy chủ, nhưng trong hầu hết các trường hợp, phương pháp ưa thích để đánh địa chỉ “máy chủ” hoặc máy chủ cung cấp dịch vụ là sử dụng FQDN của máy chủ.

Trong môi trường mạng công cộng, cách duy nhất để đánh địa chỉ các máy chủ là sử dụng FQDN của chúng.

Tên miền

Tên miền cũng là quy ước đặt tên dựa trên một cấu trúc cụ thể.
Tên miền chính thức được xây dựng từ tên tổ chức và hậu tố tên miền.

Hậu tố tên miền

Mỗi tên miền đều có một hậu tố (giống như mỗi dấu đầu dòng đều có một địa chỉ). Tên miền có thể được phân loại là riêng tư hoặc công khai.

Hậu tố tên miền riêng

Hậu tố tên miền riêng dựa trên hậu tố không công khai (và vâng, tôi biết rằng câu này không rõ ràng lắm).
Nói cách khác - hậu tố tên miền riêng không thể được xuất bản trên mạng công cộng. Trong trường hợp chúng tôi muốn sử dụng hậu tố tên miền riêng, về mặt kỹ thuật, chúng tôi có thể tạo ra bất kỳ tên nào mà chúng tôi muốn.

Ví dụ: tùy chọn khả dụng cho hậu tố tên miền riêng có thể là blab la và tên miền đầy đủ có thể là - o365info.blabla

Hậu tố tên miền công cộng.

Hậu tố tên miền công cộng dựa trên hậu tố công khai.
Trong trường hợp chúng tôi muốn sử dụng hậu tố tên miền công cộng, chúng tôi sẽ cần mua tên miền từ nhà cung cấp công cộng và số lượng tên miền công cộng có hạn hậu tố mà chúng ta có thể lựa chọn.

Máy chủ có hậu tố tên miền công cộng có thể xuất bản và có thể được truy cập bởi các máy chủ trên mạng bên ngoài (và cả các máy chủ từ mạng nội bộ\riêng tư).

Trong sơ đồ sau, chúng ta có thể xem ví dụ về tên miền có hậu tố tên miền riêng - o365info.lcoal

Và ví dụ bổ sung về tên miền công cộng như - o365info.com

Tên miền Active Directory

Mọi Active Directory đều phải có một tên miền.

Tên miền Active Directory được bảo vệ bởi người cài đặt máy chủ DC đầu tiên. Quản trị viên Active Directory có thể quyết định chọn loại miền nào làm hậu tố tên miền Active Directory.

Trong trường hợp quản trị viên muốn sử dụng tên miền riêng cho Active Directory thì hậu tố tên miền chung là - local

Hậu tố tên miền “local” không được công bố trên mạng công cộng.

Trong sơ đồ sau, chúng ta có thể xem ví dụ về các tùy chọn có sẵn cho Quản trị viên Active Directory.

Quản trị viên Active Directory có thể chọn sử dụng “không gian tên nội bộ” cho Active Directory chẳng hạn như - o365info.lcoal hoặc “không gian tên bên ngoài ” chẳng hạn như - o365info.com .
Hậu tố “com ” là hậu tố tên miền công cộng.

Tên miền Active Directory và cơ sở hạ tầng Exchange

Cơ sở hạ tầng Exchange được “Tích hợp” hoặc “đan xen” vào cơ sở hạ tầng Active Directory.

Cơ sở hạ tầng trao đổi không thể “sống” bên ngoài Active Directory hay nói cách khác; Active Directory đóng vai trò là nền tảng cho cơ sở hạ tầng Exchange và cơ sở hạ tầng Exchange được “ràng buộc” với ranh giới của khu rừng Active Directory.

FQDN mặc định của từng máy chủ Exchange

FQDN mặc định của mỗi máy chủ Exchange được xây dựng từ tên máy chủ Exchange + tên miền Active Directory cục bộ.

Trong trường hợp chúng ta sử dụng hậu tố tên miền riêng cho miền Active Directory, Exchange sẽ “kế thừa” tên miền Active Directory và kết quả là tất cả các máy chủ Exchange FQDN sẽ có hậu tố tên miền riêng Active Directory.

Về mặt lý thuyết, không có “tác hại” nào trong tình huống này, nhưng vấn đề đã xảy ra do tính chất khác nhau của cơ sở hạ tầng Active Directory so với cơ sở hạ tầng Exchange.

Khi chúng ta liên quan đến cơ sở hạ tầng Active Directory, giả định cơ bản là chúng ta sẽ không bao giờ muốn\cần đưa cơ sở hạ tầng Active Directory ra mạng công cộng hoặc cho phép máy chủ bên ngoài truy cập vào Active Directory nội bộ.

Khi liên quan đến cơ sở hạ tầng Exchange, khái niệm “ẩn” máy chủ nội bộ hoặc ngăn chặn các máy chủ bên ngoài truy cập vào các máy chủ riêng không thể thực hiện được. Hầu hết thời gian, chúng ta sẽ cần “hiển thị” một số Máy chủ Exchange (Máy chủ Exchange công khai) để các máy chủ bên ngoài như máy khách Exchange bên ngoài sẽ có thể giao tiếp với máy chủ Exchange.

Để có thể đáp ứng yêu cầu - “xuất bản tài nguyên Exchange”, chúng tôi sẽ cần sử dụng tên miền công cộng để xuất bản máy chủ được yêu cầu.

Ví dụ: các máy khách Exchange bên ngoài sẽ đánh địa chỉ máy chủ Exchange CAS công khai bằng cách sử dụng FQDN chẳng hạn như - mail.o365info.com

Hai danh tính của máy chủ Exchange CAS công khai

Trong trường hợp máy chủ Exchange CAS là “Máy chủ Exchange công khai” và Active Directory dựa trên tên miền riêng thì kết quả là-
Máy chủ Exchange CAS sẽ có hai “danh tính” khác nhau.

1. Nội bộ - Nhận dạng “Active Directory”
2. Danh tính công cộng

Thuật ngữ “danh tính” mô tả FQDN mà máy chủ Exchange CAS sẽ sử dụng.

• Khi máy khách Exchange cần đánh địa chỉ máy chủ Exchange CAS, máy khách Exchange sẽ đánh địa chỉ danh tính công khai hoặc riêng tư (FQDN) của máy chủ Exchange CAS.
• Khi máy khách Exchange cần sử dụng một dịch vụ web Exchange cụ thể, máy khách Exchange sẽ sử dụng địa chỉ URL bao gồm danh tính riêng tư hoặc công khai (FQDN) của máy chủ Exchange cung cấp dịch vụ web Exchange cụ thể.

Trao đổi dịch vụ web và địa chỉ URL

Máy chủ Exchange, cung cấp nhiều dịch vụ web cho khách hàng Exchange của mình.

Cách mà máy chủ Exchange CAS “tiết lộ” một dịch vụ web Exchange cụ thể là sử dụng địa chỉ URL. Nói cách khác - Máy khách Exchange truy cập dịch vụ web Exchange bằng cách sử dụng địa chỉ URL.

Trong phần này, tôi muốn tập trung vào một phần rất cụ thể của địa chỉ URL mà chúng tôi sử dụng cho các dịch vụ web Exchange - FQDN.

Trong phần trước, chúng tôi thảo luận về một kịch bản trong đó Active Directory dựa trên tên miền riêng và chúng tôi cũng thảo luận về nhu cầu sử dụng tên miền bổ sung: tên miền công cộng, được sử dụng bởi máy chủ Exchange đối diện công cộng cần liên lạc với các máy khách Exchange bên ngoài.

Trong kịch bản này, chúng ta sẽ cần triển khai một kịch bản mà tôi mô tả là “hai danh tính khác nhau” sẽ gán cho máy chủ Exchange đối mặt với Công chúng. Bản sắc bên ngoài và bản sắc bên trong.

Ví dụ 1 - Máy khách Outlook đang tìm kiếm máy chủ Exchange CAS

Khi máy khách Outlook cố gắng định vị máy chủ Exchange CAS sẵn có, quy trình sau sẽ được triển khai.

• Một máy khách Outlook nội bộ (máy khách Outlook nằm trên mạng nội bộ của công ty), sẽ đánh địa chỉ máy chủ Exchange CAS bằng cách sử dụng “FQDN riêng” của mình.
• Một máy khách Outlook bên ngoài (máy khách Outlook nằm trên mạng nội bộ của công ty), sẽ đánh địa chỉ máy chủ Exchange CAS bằng cách sử dụng “FQDN công khai” của nó.

Ví dụ 2 - xuất bản thông tin về dịch vụ web Exchange

Khi máy chủ Exchange CAS trả lời yêu cầu Tự động phát hiện, phản hồi Tự động phát hiện sẽ bao gồm hai loại thông tin về dịch vụ web Exchange:

• Thông tin dành cho máy khách Tự động phát hiện nội bộ, dựa trên địa chỉ URL bao gồm FQDN riêng của máy chủ Exchange cung cấp dịch vụ web Exchange cụ thể.
• Thông tin dành cho các máy khách Tự động phát hiện bên ngoài, dựa trên địa chỉ URL bao gồm FQDN công khai của máy chủ Exchange cung cấp dịch vụ web Exchange cụ thể.

Trao đổi dịch vụ web và cấu trúc địa chỉ URL

Exchange server, cung cấp nhiều dịch vụ dựa trên web. Mỗi dịch vụ web Exchange khác nhau được “đại diện” bằng một địa chỉ URL chuyên dụng.

Mặc dù chúng tôi sử dụng URL chuyên dụng của các dịch vụ web Exchange khác nhau nhưng địa chỉ URL mà chúng tôi sử dụng dựa trên cấu trúc cơ bản được sử dụng trong tất cả các địa chỉ URL của dịch vụ web Exchange.

Địa chỉ URL dịch vụ web Exchange “chuẩn” sẽ bao gồm bốn phần:

1. Tên giao thức

Phần đầu tiên của địa chỉ URL là tên giao thức.
Các dịch vụ web Exchange được triển khai bằng cách sử dụng giao thức HTTP hoặc HTTPS.
Hầu hết thời gian, giao tiếp giữa máy chủ Exchange và máy khách của anh ta sẽ được thực hiện bằng cách sử dụng Giao thức HTTPS.

2. Tên FQDN

Tên FQDN là “Tên máy chủ đầy đủ” bao gồm tên máy chủ + tên miền.

Trong trường hợp máy chủ Exchange không tiếp xúc với mạng công cộng, FQDN của máy chủ Exchange CAS được xây dựng từ “tên máy chủ chính xác” (tên NetBIOS của máy chủ) + tên miền Active Directory nội bộ.

Trong trường hợp máy chủ Exchange CAS được định cấu hình là “Máy chủ Exchange công khai”, máy chủ Exchange CAS “lộ diện” bằng cách sử dụng FQDN công cộng và ngoài ra, hầu hết thời gian có thể và sẽ có một vài tên FQDN.

Nhu cầu có nhiều hơn một “FQDN công khai” phụ thuộc vào các dịch vụ mà “Máy chủ Exchange công khai” cung cấp.

3. Tên thư mục

Đối với mỗi dịch vụ web mà Exchange cung cấp, đều có một “thư mục ảo chuyên dụng”.

Ví dụ: dịch vụ Tự động phát hiện của máy chủ Exchange được triển khai bằng cách sử dụng thư mục chuyên dụng có tên - Tự động phát hiện.

Khi máy khách Exchange cần nhận một dịch vụ cụ thể, máy khách Exchange sẽ cần biết và sử dụng địa chỉ URL bao gồm “tên thư mục” cụ thể đại diện cho các dịch vụ cụ thể mà mình cần.

4. Tên tập tin

Phần cuối cùng của địa chỉ URL có thể bao gồm tên tệp. Ví dụ: Trong trường hợp dịch vụ Tự động phát hiện, địa chỉ URL mà ứng dụng Tự động phát hiện sử dụng chứa tên của tệp cụ thể mà ứng dụng khách yêu cầu từ máy chủ.
Máy khách Tự động phát hiện sẽ yêu cầu một tệp có tên - autodiscover.xml

Ví dụ về địa chỉ URL tự động phát hiện bên trong và bên ngoài

Để có thể minh họa khái niệm "danh tính kép" của máy chủ Exchange CAS " hãy xem lại địa chỉ URL Tự động phát hiện được sử dụng bởi các máy khách Exchange nội bộ so với địa chỉ URL Tự động phát hiện được các máy khách Exchange bên ngoài sử dụng.

Điều lệ kịch bản:

Một tổ chức sử dụng tên miền riêng làm tên miền Active Directory.
Tên miền Active Directory là - o365info.local

Tên miền công cộng của tổ chức là - o365info.com

Tên máy chủ Exchange CAS là - exo1

Trong một trường hợp, máy chủ Exchange CAS phục vụ các máy khách Exchange nội bộ và cũng trợ giúp các máy khách Exchange công cộng hoặc bên ngoài.

Trong sơ đồ sau, chúng ta có thể thấy cấu trúc cơ bản của địa chỉ URL dịch vụ web Tự động phát hiện.

Địa chỉ URL tự động phát hiện | khách hàng Exchange nội bộ

Trong ví dụ của chúng tôi, máy chủ Exchange CAS sẽ tự động đăng ký tại SCP của Active Directory bằng cách sử dụng tên máy chủ sau - ex01.o365info.local

Nếu chúng tôi muốn chính xác hơn, máy chủ Exchange CAS sẽ đăng ký địa chỉ URL Tự động phát hiện trong SCP của Active Directory bằng cách sử dụng URL sau:
https://ex01.o365info.local /autodiscover/autodiscover.xml

Khi máy khách Outlook nội bộ bắt đầu quá trình Tự động phát hiện, máy khách Outlook sẽ lấy địa chỉ URL của dịch vụ Tự động phát hiện Exchange từ On-Premise Active Directory và “trích xuất” từ địa chỉ URL tên máy chủ máy chủ Exchange CAS - ex01.o365info.local và truy vấn DNS nội bộ cho tên máy chủ này.
“Câu trả lời ” DNS sẽ bao gồm địa chỉ IP nội bộ\riêng tư của máy chủ Exchange CAS.

Địa chỉ URL tự động phát hiện | máy khách Exchange bên ngoài

Trong ví dụ của chúng tôi, khi một ứng dụng thư bên ngoài như Outlook cần tạo cấu hình thư Outlook mới cho John@o365info.com , Outlook “giả định ” rằng địa chỉ URL Tự động phát hiện là theo dõi: https://autodiscover.o365info.com/autodiscover/autodiscover.xml

Để có thể kết nối máy chủ Exchange công khai, Outlook sẽ “trích xuất” tên FQDN của máy chủ Exchange từ địa chỉ Tự động phát hiện công khai.

Trong trường hợp của chúng tôi - autodiscover.o365info.com

Máy khách Outlook sẽ đánh địa chỉ máy chủ DNS công cộng và gửi truy vấn tìm kiếm thông tin về địa chỉ IP công cộng của máy chủ này.

Trao đổi danh tính kép | sử dụng FQDN giống hệt hoặc khác nhau?

Một trong những quyết định cơ bản và quan trọng nhất mà chúng tôi có với tư cách là quản trị viên Exchange là quyết định về cơ sở hạ tầng không gian tên Exchange.

Giả định cơ bản của chúng tôi là một phần cơ sở hạ tầng Exchange sẽ được định cấu hình dưới dạng Công khai và vì lý do này, Exchange sẽ cần phục vụ các máy khách Exchange nội bộ + bên ngoài.

Nói cách khác, máy chủ Exchange đối mặt với công chúng sẽ có hai giao diện khác nhau.

Tùy chọn 1 - sử dụng một không gian tên riêng biệt

Trong trường hợp này, mỗi máy chủ Exchange đối mặt với Công chúng sẽ sử dụng một không gian tên khác nhau cho mỗi “danh tính” của mình.

Để chứng minh khái niệm này, hãy sử dụng kịch bản sau:

• Tên miền Active Directory nội bộ là - o365info.local
• Tên miền công cộng của tổ chức là - o365info.com

Ví dụ

• “Danh tính nội bộ” của máy chủ Exchange sẽ được biểu thị bằng tên máy chủ - ex01.o365info.local
• “Danh tính bên ngoài” của máy chủ Exchange sẽ được biểu thị bằng tên máy chủ - mail.o365info.com và autodiscover.o365info.com

Máy khách Exchange nội bộ cần đánh địa chỉ máy chủ Exchange, tìm kiếm cơ sở hạ tầng Tự động phát hiện sẽ đánh địa chỉ máy chủ Exchange bằng cách sử dụng tên máy chủ - ex01.o365info.local

Máy khách Exchange bên ngoài sẽ cần đánh địa chỉ máy chủ Exchange, tìm kiếm cơ sở hạ tầng Tự động phát hiện sẽ đánh địa chỉ máy chủ Exchange bằng cách sử dụng tên máy chủ - autodiscover.o365info.com

Tùy chọn 2 - sử dụng không gian tên thống nhất

Trong trường hợp này, chúng tôi sẽ sử dụng cùng một không gian tên cho mỗi “danh tính” máy chủ Exchange.

Để chứng minh khái niệm này, hãy sử dụng kịch bản sau:

• Tên miền Active Directory nội bộ là - o365info.local
• Tên miền công cộng của tổ chức là - o365info.com

Sự khác biệt chính là trong trường hợp này, chúng tôi sẽ không sử dụng tên miền Active Directory cục bộ như một phần của tên máy chủ Exchange.

Trong kịch bản mà tôi mô tả là một không gian tên hợp nhất, máy chủ Exchange sẽ được “xuất bản” cho máy khách Exchange nội bộ và bên ngoài bằng cách sử dụng không gian tên miền công cộng.

• “Danh tính nội bộ” của máy chủ Exchange sẽ được thể hiện bằng tên máy chủ - mail.o365info.com và autodiscover.o365info.com
• “Danh tính bên ngoài” của máy chủ Exchange sẽ được biểu thị bằng tên máy chủ - mail.o365info.com và autodiscover.o365info.com

Máy khách Exchange nội bộ cần đánh địa chỉ máy chủ Exchange, tìm kiếm cơ sở hạ tầng Tự động phát hiện sẽ đánh địa chỉ máy chủ Exchange bằng cách sử dụng tên máy chủ - autodiscover.o365info.com

Máy khách Exchange bên ngoài sẽ cần đánh địa chỉ máy chủ Exchange, tìm kiếm cơ sở hạ tầng Tự động phát hiện sẽ đánh địa chỉ máy chủ Exchange bằng cách sử dụng tên máy chủ - autodiscover.o365info.com

Trước đây, “xu hướng” nhấn mạnh sự khác biệt tồn tại giữa “môi trường Exchange nội bộ” và “môi trường Exchange bên ngoài”. ”

Lý do cho xu hướng này dựa trên giả định rằng việc sử dụng một không gian tên riêng biệt sẽ bảo mật hơn vì sự “tách biệt” bảo vệ cơ sở hạ tầng Exchange nội bộ khỏi sự truy cập không mong muốn của các máy chủ bên ngoài.

Ý kiến của tôi là “sự phân tách logic” không thực sự bảo vệ cơ sở hạ tầng Exchange nội bộ vì trên thực tế, việc bảo vệ và phân tách sẽ được thực hiện bằng các giải pháp khác nhau.

Việc sử dụng khái niệm namespace tách biệt sẽ khiến công việc của quản trị viên Exchange trở nên phức tạp hơn và khiến người dùng bối rối hơn.