ไคลเอนต์ Exchange และเซิร์ฟเวอร์ Exchange สาธารณะ | ตอนที่ 13#36

บทความปัจจุบันจะกล่าวถึงหัวข้อไคลเอ็นต์ Exchange ที่เข้าถึงบริการ Exchange จากเครือข่ายสาธารณะ
การมุ่งเน้นไปที่ "ไคลเอ็นต์ Exchange สาธารณะ" เนื่องจากลักษณะของช่องทางการสื่อสารระหว่างเซิร์ฟเวอร์ Exchange และไคลเอ็นต์ Exchange ของเขา ในสภาพแวดล้อมสาธารณะ มีอักขระที่แตกต่างจากช่องทางการสื่อสารที่ใช้งานระหว่างไคลเอนต์ Exchange และ Exchange Server ในสภาพแวดล้อมที่ถือว่าเป็นสภาพแวดล้อมแบบ "ส่วนตัว" หรือ "เครือข่ายภายใน"

ตัวละครหลักของสภาพแวดล้อมสาธารณะและความสัมพันธ์ของเซิร์ฟเวอร์ Exchange และไคลเอนต์ Exchange ของเขาคือ:

• เซิร์ฟเวอร์ Exchange แบบสาธารณะ - เพื่อให้สามารถระบุที่อยู่เซิร์ฟเวอร์ Exchange ได้ ควรกำหนดค่าเซิร์ฟเวอร์ Exchange เป็น "เซิร์ฟเวอร์ Exchange แบบสาธารณะ" คำแปลของคำนี้คือ - Exchange server ที่มี FQDN สาธารณะ, IP สาธารณะ และใบรับรองสาธารณะ นอกจากนี้ เราจะต้องทำการกำหนดค่าที่จำเป็นทั้งหมดในโครงสร้างพื้นฐาน Firewall\Proxy ที่จะอนุญาตการเข้าถึงจากไคลเอนต์ภายนอกไปยังเซิร์ฟเวอร์ Exchange “ภายใน”

• โฟลว์การค้นหาอัตโนมัติ\กระบวนการ - โฟลว์การค้นหาอัตโนมัติในสภาพแวดล้อมสาธารณะที่ไคลเอ็นต์การค้นหาอัตโนมัติจำเป็นต้องค้นหาตำแหน่งปลายทางการค้นหาอัตโนมัติของเขา จะไม่ถูกนำมาใช้โดยใช้การเข้าถึง Active Directory เนื่องจากในสภาพแวดล้อมสาธารณะ บริการ Active Directory จะไม่พร้อมใช้งาน ไคลเอนต์การค้นหาอัตโนมัติจะพยายามค้นหาตำแหน่งปลายทางการค้นหาอัตโนมัติของเขาโดยใช้โครงสร้างการตั้งชื่อที่กำหนดไว้ล่วงหน้าและโครงสร้างพื้นฐาน DNS สำหรับการกำหนดปลายทางการค้นหาอัตโนมัติที่จำเป็น

คำถามที่ 1: เซิร์ฟเวอร์ Exchange ต้องกำหนดค่าเป็นเซิร์ฟเวอร์ Exchange แบบสาธารณะหรือไม่

A1: ไม่ ทางเทคนิคแล้วเราไม่จำเป็นต้องเปิดเผยเซิร์ฟเวอร์ Exchange กับไคลเอ็นต์ Exchange ที่อยู่ในเครือข่ายสาธารณะ ในสภาพแวดล้อมการทำงานสมัยใหม่ส่วนใหญ่ “ความต้องการทางธุรกิจ” คือการเปิดใช้งานไคลเอ็นต์ Exchange ภายนอกเพื่อเข้าถึงบริการอีเมลขององค์กร แต่นี่ไม่ใช่ข้อกำหนดบังคับ

ไตรมาสที่ 2: ในสถานการณ์ที่องค์กรมีหลายไซต์ และแต่ละไซต์มีเซิร์ฟเวอร์ Exchange หลายเครื่อง เราจำเป็นต้อง "เผยแพร่" เซิร์ฟเวอร์ Exchange ที่มีอยู่ทั้งหมดหรือไม่

A2: คำตอบคือไม่ ตัวอย่างเช่น ในไซต์ที่มีเซิร์ฟเวอร์ Exchange หลายเครื่อง เราจำเป็นต้อง "เปิดเผย" เซิร์ฟเวอร์ Exchange เฉพาะเครื่องเดียวเท่านั้นที่จะทำหน้าที่เป็นตัวแทนสำหรับ "โครงสร้างพื้นฐาน Exchange ภายใน" ทั้งหมด

เมื่อไคลเอนต์ Exchange สาธารณะจัดการกับเซิร์ฟเวอร์ Exchange สาธารณะ เซิร์ฟเวอร์ Exchange จะ "รู้" วิธีกำหนดเส้นทางคำขอไปยังทรัพยากร Exchange ภายในและให้ "คำตอบ" จากทรัพยากร Exchange ภายในไปยังไคลเอนต์ Exchange ภายนอก

ในสถานการณ์สมมตินี้ เซิร์ฟเวอร์ Exchange สาธารณะจะมีข้อมูลเฉพาะตัวหรืออินเทอร์เฟซที่แตกต่างกันสองรายการ:

• อินเทอร์เฟซเดียวสำหรับโครงสร้างพื้นฐาน Exchange ภายใน\ส่วนตัว
• อินเทอร์เฟซเดียวสำหรับไคลเอนต์ Public Exchange

เซิร์ฟเวอร์ Exchange CAS ที่เปิดเผยต่อสาธารณะ | โลกทั้งสอง

เพื่อให้สามารถสาธิต "สองโลก" ของเซิร์ฟเวอร์ Exchange - อินเทอร์เฟซภายในเทียบกับอินเทอร์เฟซภายนอกและลักษณะของสภาพแวดล้อมที่แตกต่างกันนี้ ลองใช้สถานการณ์สมมติของโครงสร้างพื้นฐานที่มีอักขระต่อไปนี้:

กฎบัตรของสภาพแวดล้อม Exchange ในสถานการณ์ของเรามีดังนี้:

• ชื่อโดเมนภายในของไดเรกทอรีที่ใช้งานอยู่คือ - o365info.local
• ชื่อโดเมนสาธารณะคือ - o365info.com
• ที่อยู่อีเมลของผู้ใช้องค์กรจะขึ้นอยู่กับส่วนต่อท้ายของอีเมล - o365info.com
• ไซต์ไดเรกทอรี Exchange\Active - องค์กรมีไซต์ Exchange\Active Directory สองไซต์: ไซต์นิวยอร์กและไซต์ Los Angles (ไซต์นิวยอร์กเป็นสำนักงานใหญ่ของบริษัท)
• ชื่อของเซิร์ฟเวอร์ Exchange CAS ในไซต์นิวยอร์กคือ - exo1.o365info.local
• ชื่อของเซิร์ฟเวอร์ Exchange CAS ในไซต์ Los Angles คือ - exo2.o365info.local
• John เป็นผู้ใช้ขององค์กรที่กล่องจดหมายของเขาโฮสต์อยู่บน New York Exchange Site
• อลิซ เป็นผู้ใช้ขององค์กรที่กล่องจดหมายของเขาโฮสต์อยู่บนไซต์แลกเปลี่ยน Los Angles

เซิร์ฟเวอร์ Exchange CAS - รูปแบบการตั้งชื่อ FQDN ภายในและภายนอก

งานหลักอย่างหนึ่งในการวางแผนหรือสร้างโครงสร้างพื้นฐาน Exchange คือหัวข้อของโครงร่างการตั้งชื่อ (เนมสเปซ) ที่รวม FQDN ของเซิร์ฟเวอร์ Exchange ภายในและภายนอก

ผลลัพธ์ขึ้นอยู่กับสถานการณ์เฉพาะขององค์กร และบริการที่องค์กรต้องการหรือต้องการมอบให้กับไคลเอ็นต์อีเมลภายในและภายนอก

ในตัวอย่างของเรา เราจะตรวจสอบสถานการณ์ทางเลือกที่แตกต่างกันสามสถานการณ์ ของไคลเอนต์ Exchange สาธารณะที่ต้องการเข้าถึงเซิร์ฟเวอร์ Exchange ของตน (ไปยังเซิร์ฟเวอร์ Exchange ที่หันหน้าเข้าหาสาธารณะ)

หลายครั้ง องค์กรขนาดเล็กและขนาดกลางจะ "เปิดเผย" เซิร์ฟเวอร์ Exchange CAS เพียงเซิร์ฟเวอร์เดียวเท่านั้นที่จะทำหน้าที่เป็น "เซิร์ฟเวอร์ Exchange CAS สาธารณะ"

ในสถานการณ์ของบริษัทองค์กรซึ่งมีไซต์หลายแห่งในตำแหน่งที่ตั้งทางภูมิศาสตร์ที่แตกต่างกัน โครงสร้างพื้นฐานสาธารณะของ Exchange จะมี "เซิร์ฟเวอร์ Exchange CAS สาธารณะที่เชื่อมต่อกับสาธารณะ" มากกว่าหนึ่งเครื่อง

ตัวอย่างเช่น แต่ละไซต์ของบริษัทสามารถมี “เซิร์ฟเวอร์ Exchange CAS สาธารณะ” ได้

ในส่วนต่อไปนี้ เราจะตรวจสอบสถานการณ์ที่แตกต่างกันสี่สถานการณ์:

• สถานการณ์สมมติ 1 และสถานการณ์สมมติ 2 จะสาธิตโครงสร้างพื้นฐาน Exchange ที่มี "เซิร์ฟเวอร์ Exchange CAS สาธารณะที่หันเข้าหาสาธารณะ" เพียงแห่งเดียว
• สถานการณ์ 3 และสถานการณ์ 4 จะอธิบายโครงสร้างพื้นฐานของ Exchange ที่ใช้ “เซิร์ฟเวอร์ Exchange CAS สาธารณะ” สำหรับไซต์ Exchange ของบริษัทแต่ละไซต์ (เซิร์ฟเวอร์ Exchange สาธารณะหลายเซิร์ฟเวอร์)

เราจะเริ่มต้นด้วยสถานการณ์ที่เรียบง่ายและก้าวไปสู่สถานการณ์ที่ซับซ้อนหรือขั้นสูงยิ่งขึ้น

ในตารางต่อไปนี้ เราจะเห็นรูปแบบการตั้งชื่อที่เลือกไว้สำหรับองค์กรเฉพาะ (o365info.com )

เซิร์ฟเวอร์ New York Exchange CAS

เซิร์ฟเวอร์ Exchange CAS ของไซต์นิวยอร์กได้รับการกำหนดค่าเป็น "เซิร์ฟเวอร์ Exchange CAS สาธารณะ"

ชื่อภายในหรือส่วนตัวของ “เซิร์ฟเวอร์ New York Exchange CAS” คือ - exo1.o365info.local

เราจะใช้ "ชื่อสาธารณะ" สามชื่อสำหรับ "เซิร์ฟเวอร์ New York Exchange CAS":

• autodiscover.o365info.com
• mail.o365info.com
• owa.o365info.com

เซิร์ฟเวอร์ Los Angles Exchange CAS

ชื่อภายในหรือส่วนตัวของ “เซิร์ฟเวอร์ Los Angles Exchange CAS” คือ - exo2.o365info.local

เราจะใช้ "ชื่อสาธารณะ" สองชื่อสำหรับ "เซิร์ฟเวอร์ Los Angles Exchange CAS":

• mail-la.o365info.com
• owa-la.o365info.com

การพิจารณาเพิ่มเติม

DNS สาธารณะและบันทึก A
ชื่อสาธารณะนี้จะต้อง "ลงทะเบียน" อีกครั้งที่ DNS สาธารณะ และแมปกับ IP สาธารณะ "New York + Los Angles Exchange CAS server"

ที่อยู่ IP สาธารณะ

ในสถานการณ์ของเรา แม้ว่าเซิร์ฟเวอร์ Exchange สาธารณะจะมีชื่อโฮสต์หลายชื่อ แต่มีที่อยู่ IP สาธารณะเพียงที่อยู่เดียวเท่านั้นที่ได้รับการจัดสรรให้กับ "เซิร์ฟเวอร์ New York Exchange CAS ”

โปรแกรมรับส่งเมลไม่ได้ "สนใจ" ในข้อเท็จจริงนี้

เหตุผลในการใช้ชื่อโฮสต์หลายชื่อ (FQDN) มีไว้เพื่อความสะดวกเท่านั้น

ตัวอย่างเช่น โดยส่วนใหญ่ รูปแบบการตั้งชื่อที่เป็นที่นิยมสำหรับการเข้าถึงบริการเว็บเมลของ Exchange คือการใช้ชื่อโฮสต์ เช่น - owa.o365info.com

แลกเปลี่ยนใบรับรองสาธารณะของเซิร์ฟเวอร์ CAS

ใบรับรองที่มอบให้แก่ไคลเอนต์เมลภายนอกโดย “เซิร์ฟเวอร์ Exchange แบบสาธารณะ” จะต้องรวมชื่อ FQDN ที่แตกต่างกันทั้งหมดที่เรากล่าวถึง

โปรดทราบว่าเซิร์ฟเวอร์สาธารณะจะมีชื่อภายใน (FQDN's) ของ "เซิร์ฟเวอร์ New York และ Los Angles Exchange CAS"
ไคลเอ็นต์อีเมลภายนอกไม่เกี่ยวข้องกับ "ภายใน FQDN's " และไม่จำเป็นต้องยืนยัน " FQDN ภายใน ”

ชื่อภายในนี้จะถูกใช้โดยไคลเอนต์เมลภายในที่เชื่อมต่อเซิร์ฟเวอร์ Exchange CAS จาก "ภายใน" ของเครือข่ายส่วนตัวขององค์กรเท่านั้น

เซิร์ฟเวอร์ Exchange CAS ที่เปิดเผยต่อสาธารณะ | รูปแบบการตั้งชื่อและบริการแลกเปลี่ยน

คำถามง่ายๆ ที่เราสามารถถามตัวเองได้ก็คือ - เหตุใดจึงต้องใช้ชื่อสาธารณะมากกว่าหนึ่งชื่อ และเราเลือก “ชื่อเฉพาะ” เหล่านี้ว่าอะไร?

คำตอบก็คือชื่อสาธารณะเหล่านี้เป็นไปตามแบบแผนการตั้งชื่อมาตรฐาน ในทางเทคนิคแล้ว เราสามารถใช้ชื่อสาธารณะเพียงชื่อเดียว เลือกชื่อสาธารณะเพิ่มเติม หรือเลือกชื่อโฮสต์อื่นได้ (ยกเว้นชื่อโฮสต์ Autodiscover ที่ถือว่าเป็นชื่อที่สงวนไว้)

ชื่อสาธารณะที่เลือกสำหรับ "เซิร์ฟเวอร์ Exchange แบบสาธารณะ" เป็นเพียง "ชื่อมาตรฐาน" ที่ใช้ส่วนใหญ่

FQDN สาธารณะของการค้นหาอัตโนมัติ

ไคลเอนต์ Exchange ภายนอก (ไคลเอนต์ Autodiscover) ที่จะค้นหาจุดสิ้นสุดการค้นหาอัตโนมัติจะค้นหาชื่อโฮสต์เฉพาะ - autodiscover.o365info.com

ด้วยเหตุนี้ ชื่อโฮสต์นี้จึงเป็นชื่อบังคับ และเราไม่สามารถเลือกชื่ออื่นหรือชื่ออื่นได้

แลกเปลี่ยนบริการเว็บเมลสาธารณะ FQDN

ไคลเอนต์เว็บเมลภายนอกจะกล่าวถึงเซิร์ฟเวอร์ Exchange สาธารณะโดยใช้ชื่อโฮสต์ - owa.o365info.com

องค์กรหลายแห่งใช้หลักการตั้งชื่อ - OWA + <ชื่อโดเมนสาธารณะ> สำหรับการเผยแพร่บริการ Exchange ที่ให้ตัวเลือกจดหมายภายนอกในการเข้าถึงกล่องจดหมายของตนโดยใช้เว็บเบราว์เซอร์ (เว็บเมลไคลเอ็นต์ ).
ตามที่กล่าวไว้ก่อนหน้านี้ องค์กรสามารถเลือกชื่อใดก็ได้ที่เหมาะกับความต้องการของเขา และไม่มีข้อกำหนดบังคับในการเลือกชื่อโฮสต์เฉพาะ (OWA)

“FQDN สาธารณะทั่วไป” ของเซิร์ฟเวอร์ Exchange สาธารณะ

ชื่อโฮสต์สาธารณะ - mail.o365info.com จะถูกใช้สำหรับบริการเว็บ Exchange ที่เหลือทั้งหมด เช่น - บริการความพร้อมใช้งาน (เวลาว่าง\ไม่ว่าง), การตอบกลับอัตโนมัติ (ออก ของสำนักงาน) การส่งข้อความแบบรวม และอื่นๆ

โดยส่วนใหญ่แล้ว ชื่อสาธารณะนี้ (mail.o365info.com) จะใช้ในการเผยแพร่บันทึก Exchange MX ด้วย

เว็บไซต์ลอส แองเกิลส์

“เซิร์ฟเวอร์ Exchange แบบสาธารณะ เซิร์ฟเวอร์ Los Angles Exchange” จะต้องใช้ชื่อโฮสต์อื่น เนื่องจากเราไม่สามารถใช้ชื่อโฮสต์เดียวกันสำหรับเซิร์ฟเวอร์ Exchange อื่นได้

หมายเหตุ - ในสถานการณ์สุดท้าย เราจะตรวจสอบข้อยกเว้นสำหรับกฎนี้ ความสามารถในการใช้ชื่อโฮสต์เดียวกันสำหรับเซิร์ฟเวอร์ Exchange อื่นสามารถนำไปใช้ได้โดยใช้ GeoDNS

บริการเว็บเมล Los Angles Exchange FQDN สาธารณะ

ไคลเอ็นต์เว็บเมลภายนอกจะระบุถึงเซิร์ฟเวอร์ Exchange สาธารณะโดยใช้ชื่อโฮสต์ - owa-la.o365info.com

Los Angles - “FQDN สาธารณะทั่วไป ” ของเซิร์ฟเวอร์ Exchange สาธารณะ

ชื่อโฮสต์สาธารณะ - mail-la.o365info.com จะถูกใช้สำหรับบริการเว็บ Exchange ที่เหลือทั้งหมด เช่น - บริการความพร้อมใช้งาน (เวลาว่าง\ไม่ว่าง), การตอบกลับอัตโนมัติ (ไม่อยู่ที่สำนักงาน) การส่งข้อความแบบครบวงจรและอื่นๆ

การเข้าถึงไคลเอ็นต์อีเมล Exchange ภายนอก - สถานการณ์

ในส่วนต่อไปนี้ เราจะตรวจสอบตัวเลือกสองสามตัวของ - ”สถานการณ์การเข้าถึงไคลเอนต์ Exchange ภายนอก”

คำอธิบายของเวิร์กโฟลว์ในแต่ละสถานการณ์ไม่รวมรายละเอียดทั้งหมดที่เกี่ยวข้องกับกระบวนการสื่อสารระหว่างไคลเอนต์จดหมาย Exchange และเซิร์ฟเวอร์ Exchange CAS ที่เปิดเผยต่อสาธารณะ

วัตถุประสงค์หลักคือเพียงเพื่อให้มุมมองระดับสูงของช่องทางการสื่อสารที่นำไปใช้ระหว่างไคลเอนต์ Exchange สาธารณะและเซิร์ฟเวอร์ Exchange สาธารณะ

• วิธีที่ไคลเอ็นต์ Autodiscover สาธารณะค้นหาตำแหน่งปลายทางของ Autodiscover
• เซิร์ฟเวอร์ Exchange ที่หันหน้าไปทางสาธารณะระบุตัวเองโดยการจัดเตรียมใบรับรองสาธารณะได้อย่างไร
• ไคลเอ็นต์การค้นหาอัตโนมัติได้รับข้อมูลการค้นหาอัตโนมัติที่จำเป็นอย่างไร (การตอบสนองของเซิร์ฟเวอร์การค้นหาอัตโนมัติ)

หมายเหตุ - มีวิธีการค้นหาอัตโนมัติเพิ่มเติมโดยยึดตามบันทึก SRV ที่ช่วยให้เราใช้ชื่ออื่นสำหรับ "เซิร์ฟเวอร์ Exchange CAS สาธารณะ" ที่ให้บริการการค้นหาอัตโนมัติ แต่เราจะไม่ตรวจสอบตัวเลือกนี้ในบทความปัจจุบัน

1. ที่อยู่ URL ของ ECP
   ECP (แผงควบคุม Exchange) ถูกใช้โดยไคลเอ็นต์เว็บเมล เช่น OWA เพื่อจัดการและกำหนดการตั้งค่าผู้ใช้จำนวนมากโดยใช้เว็บอินเทอร์เฟซของ OWA
2. ที่อยู่ URL ของ EWS - URL ของ EWS (Exchange Web Services) ถูกใช้โดย Exchange เพื่อให้บริการเว็บที่หลากหลาย เช่น บริการความพร้อมใช้งาน (เวลาว่าง/ไม่ว่าง), เล่นซ้ำอัตโนมัติ (ไม่อยู่ที่สำนักงาน), เคล็ดลับเมล และอื่นๆ

สถานการณ์ที่ 1: บริการจดหมาย Exchange สำหรับไคลเอนต์จดหมายภายนอก | สถานการณ์ที่เรียบง่าย

ในสถานการณ์สมมตินี้ จอห์นกำลังพยายามเข้าถึงกล่องจดหมายของเขาที่โฮสต์บนไซต์ New York Exchange จากเครือข่ายสาธารณะ John ต้องการสร้างโปรไฟล์เมล Outlook ใหม่

ข้อมูลที่ John จะต้องระบุคือ - ที่อยู่อีเมลของเขา (John@o365info.com ) + ข้อมูลประจำตัวผู้ใช้ของเขา

ในสถานการณ์นี้ เราจะ "เพิกเฉย" ไซต์ Exchange ของบริษัทอื่น (Los Angles) และมุ่งเน้นไปที่เวิร์กโฟลว์การค้นหาอัตโนมัติเมื่อไคลเอ็นต์อีเมลภายนอกเข้าถึง "เซิร์ฟเวอร์ Exchange CAS สาธารณะในนิวยอร์ก"

ขั้นตอนที่ 1: โปรแกรมรับส่งเมลภายนอก | กระบวนการค้นหาอัตโนมัติ

เนื่องจาก John อยู่ในเครือข่ายสาธารณะ วิธีการค้นหาอัตโนมัติซึ่งไคลเอนต์ Autodiscover เชื่อมต่อ Active Directory ในเครื่องเพื่อรับข้อมูลเกี่ยวกับเซิร์ฟเวอร์ Exchange CAS ที่มีอยู่จึงไม่พร้อมใช้งานสำหรับเขา เนื่องจาก Active Directory ภายในไม่ได้ "เปิดเผย" กับเครือข่ายสาธารณะ

ในกรณีนั้น กระบวนการค้นหาอัตโนมัติของ "การค้นหาจุดสิ้นสุดการค้นหาอัตโนมัติที่เป็นไปได้" จะถูกนำไปใช้โดยการค้นหาชื่อโฮสต์จุดสิ้นสุดการค้นหาอัตโนมัติ ซึ่งแยกมาจากที่อยู่อีเมลของผู้รับ
ในตัวอย่างของเรา จอห์นจะค้นหาจุดสิ้นสุดการค้นหาอัตโนมัติโดย ใช้ชื่อโฮสต์ - o365info.com (หมายเลข 1)

ในสถานการณ์สมมติของเรา ชื่อโฮสต์นี้ไม่ได้รับการเผยแพร่ และเนื่องจากไคลเอนต์ Autodiscover จะไม่พบชื่อโฮสต์ดังกล่าว ไคลเอนต์ Autodiscover จะสร้างแบบสอบถาม DNS ใหม่เพื่อค้นหาชื่อโฮสต์ - autodiscover.o365info.com

ขั้นตอนที่ 2: เชื่อมต่อเซิร์ฟเวอร์ Exchange CAS สาธารณะ

ในสถานการณ์ของเรา องค์กรใช้ "เซิร์ฟเวอร์ New York Exchange CAS" เป็นเซิร์ฟเวอร์ Exchange CAS ที่เปิดเผยต่อสาธารณะ

โปรแกรมรับส่งเมลภายนอกจะเริ่มต้นการพยายามเชื่อมต่อกับเซิร์ฟเวอร์ Exchange สาธารณะโดยใช้โปรโตคอล HTTPS
โปรแกรมรับส่งเมลจะขอให้เซิร์ฟเวอร์พิสูจน์ตัวตนโดยจัดเตรียมใบรับรองสาธารณะ (หมายเลข 2 ).

ขั้นตอนที่ 3 - ตรวจสอบใบรับรองสาธารณะของเซิร์ฟเวอร์ Exchange

ไคลเอนต์เมลจะตรวจสอบว่าใบรับรองเซิร์ฟเวอร์รวม FQDN - autodiscover.o365info.com

ในกรณีที่ไคลเอ็นต์อีเมลภายนอกยืนยันว่าใบรับรอง Exchange เป็น "ตกลง" ไคลเอ็นต์จะระบุข้อมูลระบุตัวตนของเขาด้วย (ชื่อผู้ใช้และรหัสผ่าน)

ขั้นตอนที่ 4 - คำขอไคลเอ็นต์ Exchange จากเซิร์ฟเวอร์ Exchange เพื่อจัดเตรียมไฟล์ autodiscover.xml

โปรแกรมรับส่งอีเมลภายนอกจะขอจากเซิร์ฟเวอร์ Exchange เพื่อมอบไฟล์ autodiscover.xml ที่จำเป็น (หมายเลข 4)

ขั้นตอนที่ 5 - เซิร์ฟเวอร์ Exchange มอบการตอบสนองการค้นหาอัตโนมัติให้กับไคลเอนต์ Exchange (autodiscover.xml)

เซิร์ฟเวอร์ Exchange ส่งโปรแกรมรับส่งเมลภายนอกตามการตอบสนองการค้นหาอัตโนมัติที่จำเป็น (หมายเลข 5)

ในภาพหน้าจอต่อไปนี้ เราจะเห็นตัวอย่างเล็กๆ ของเนื้อหาของไฟล์ autodiscover.xml

• บริการ Exchange EWS - เราจะเห็นว่าที่อยู่ URL ของบริการ Exchange EWS นั้นให้มาโดยใช้ชื่อโฮสต์ - o365info.com
• Exchange ECP - ที่อยู่ URL ของแผงควบคุม Exchange (ที่อยู่เว็บที่ไคลเอ็นต์เว็บเมลใช้เพื่อกำหนดการตั้งค่าผู้ใช้) รวมถึงชื่อโฮสต์ - o365info.com

สถานการณ์ที่ 2: บริการจดหมาย Exchange สำหรับไคลเอนต์จดหมายภายนอก | เซิร์ฟเวอร์ Exchange CAS สาธารณะเดี่ยว | ไซต์แลกเปลี่ยนหลายแห่ง

ในสถานการณ์ถัดไป อลิซกำลังพยายามเชื่อมต่อกับกล่องจดหมายของเธอจากเครือข่ายสาธารณะ

ตามที่กล่าวไว้ องค์กรมีไซต์ Exchange สองแห่ง กล่องจดหมายของ Alice ที่โฮสต์บนเซิร์ฟเวอร์ Exchange CAS ซึ่งอยู่ในไซต์ Los Angeles
เซิร์ฟเวอร์ Exchange CAS ในไซต์ Los Angles นั้นเป็น "เซิร์ฟเวอร์ Exchange CAS ที่ไม่เปิดเผยต่อสาธารณะ"

กล่าวง่ายๆ ก็คือ ไคลเอนต์เมลภายนอกไม่สามารถเชื่อมต่อเซิร์ฟเวอร์ Exchange นี้โดยตรงได้

เพื่อให้สามารถให้บริการอีเมลไปยังไคลเอนต์เมลภายนอกได้ เซิร์ฟเวอร์ Exchange CAS ที่เลือกเป็น "ตัวแทน" ซึ่งจะมีความพร้อมใช้งานสาธารณะ (เซิร์ฟเวอร์ Exchange CAS สาธารณะ) คือเซิร์ฟเวอร์ Exchange CAS จากไซต์นิวยอร์ก

ขั้นตอนที่ 1: โปรแกรมรับส่งเมลภายนอก | กระบวนการค้นหาอัตโนมัติ

เมื่อ Alice เริ่ม Outlook ไคลเอ็นต์ Outlook จะพยายามค้นหาจุดสิ้นสุดการค้นหาอัตโนมัติ

ในกรณีดังกล่าว กระบวนการค้นหาอัตโนมัติจะถูกนำไปใช้โดยการค้นหาชื่อโฮสต์จุดสิ้นสุดการค้นหาอัตโนมัติ ซึ่งแยกมาจากที่อยู่อีเมลของผู้รับ

ในตัวอย่างของเรา ไคลเอนต์ Alice Outlook จะค้นหาจุดสิ้นสุดการค้นหาอัตโนมัติโดยใช้ชื่อโฮสต์ - o365info.com (หมายเลข 1)
ในตัวของเรา สถานการณ์สมมติ ชื่อโฮสต์นี้ไม่ได้รับการเผยแพร่ และเนื่องจากไคลเอนต์ Autodiscover จะไม่พบชื่อโฮสต์ดังกล่าว ไคลเอนต์ Autodiscover จะสร้างแบบสอบถาม DNS ใหม่เพื่อค้นหาชื่อโฮสต์ - autodiscover.o365info.com

ขั้นตอนที่ 2: การเชื่อมต่อเซิร์ฟเวอร์ Exchange CAS สาธารณะ

ในสถานการณ์ของเรา องค์กรใช้ "เซิร์ฟเวอร์ New York Exchange CAS" เป็นเซิร์ฟเวอร์ Exchange สาธารณะ

โปรดทราบว่ากล่องจดหมายของ Alice อยู่บนเซิร์ฟเวอร์ Exchange CAS ที่ไซต์ Los Angles

โปรแกรมรับส่งเมลภายนอกจะเริ่มต้นการพยายามเชื่อมต่อกับเซิร์ฟเวอร์ Exchange สาธารณะโดยใช้โปรโตคอล HTTPS
โปรแกรมรับส่งเมลจะขอให้เซิร์ฟเวอร์พิสูจน์ตัวตนโดยจัดเตรียมใบรับรองสาธารณะ (หมายเลข 2 ).

ขั้นตอนที่ 3 - ตรวจสอบใบรับรองสาธารณะของเซิร์ฟเวอร์ Exchange

ไคลเอนต์เมลจะตรวจสอบว่าใบรับรองเซิร์ฟเวอร์รวม FQDN -autodiscover.o365info.com

ในกรณีที่ไคลเอ็นต์อีเมลภายนอกยืนยันว่าใบรับรอง Exchange เป็น "ตกลง" ไคลเอ็นต์จะระบุข้อมูลระบุตัวตนของเขาด้วย (ชื่อผู้ใช้และรหัสผ่าน)

ขั้นตอนที่ 4 - การร้องขอจากเซิร์ฟเวอร์ Exchange เพื่อจัดเตรียมไฟล์ autodiscover.xml

โปรแกรมรับส่งอีเมลภายนอกจะขอจากเซิร์ฟเวอร์ Exchange เพื่อจัดเตรียมไฟล์ autodiscover.xml ที่จำเป็น (หมายเลข 4)

ขั้นตอนที่ 5 - Exchange จัดเตรียม autodiscover.xml ให้กับเมลไคลเอ็นต์

เซิร์ฟเวอร์ Exchange จะส่งไฟล์ autodiscover.xml ที่จำเป็นไปยังโปรแกรมรับส่งเมลภายนอก (หมายเลข 5)

ในแผนภาพต่อไปนี้ เราจะเห็นตัวอย่างจากเนื้อหาของไฟล์ autodiscover.xml

• บริการ Exchange EWS - เราจะเห็นว่าที่อยู่ URL ของบริการ Exchange EWS นั้นให้มาโดยใช้ชื่อโฮสต์ - o365info.com
• Exchange ECP - ที่อยู่ URL ของแผงควบคุม Exchange (ที่อยู่เว็บที่ไคลเอ็นต์เว็บเมลใช้เพื่อกำหนดการตั้งค่าผู้ใช้) รวมถึงชื่อโฮสต์ -
  o365info.com

ขั้นตอนที่ 6 - เข้าถึงข้อมูลกล่องจดหมายโดยไคลเอนต์เมลภายนอก | กลไกของพร็อกซี

โปรดใส่ใจกับข้อเท็จจริงที่น่าสนใจว่า Alice ไม่สามารถเชื่อมต่อเซิร์ฟเวอร์ Los Angles Exchange CAS ของเธอได้โดยตรง - exo2.0365info.com

แต่ละครั้งที่ Alice ต้องการเข้าถึงข้อมูลในกล่องจดหมายของเธอ คำขอจะไปถึงเซิร์ฟเวอร์ New York Exchange (เซิร์ฟเวอร์ Exchange ที่พร้อมใช้งานสาธารณะ) เซิร์ฟเวอร์ New York Exchange จะสร้างแบบสอบถาม LDAP เพื่อค้นหาเซิร์ฟเวอร์ Exchange CAS ที่โฮสต์กล่องจดหมายของ Alice

เมื่อเซิร์ฟเวอร์ New York Exchange CAS พบว่าเซิร์ฟเวอร์ Exchange CAS ที่โฮสต์กล่องจดหมายของ Alice คือ exo2.0365info.com เขาจะสร้างคำขอเชื่อมต่อโดยขอให้ "ดึงข้อมูล" จากกล่องจดหมายของอลิซ (หมายเลข 6)

วิธีการที่เซิร์ฟเวอร์ Exchange CAS ส่งบันทึกข้อมูลจากเซิร์ฟเวอร์ Exchange CAS อื่น (เซิร์ฟเวอร์ Exchange CAS ที่ให้การเข้าถึงกล่องจดหมายของผู้ใช้ที่จำเป็น) ซึ่งเรียกว่า “Proxy. ”

ขั้นตอนที่ 7 - ส่งคืนข้อมูลที่ต้องการ

เซิร์ฟเวอร์ Los Angles Exchange CAS (exo2.0365info.com) ส่งคืนข้อมูลกล่องจดหมายที่จำเป็นไปยังเซิร์ฟเวอร์ New York Exchange CAS (exo1.0365info. ดอทคอม)

เซิร์ฟเวอร์ New York Exchange ส่งหรือให้ข้อมูลกล่องจดหมายที่จำเป็นไปยังไคลเอนต์เมลภายนอก (หมายเลข 7 และหมายเลข 8)

คำนำหน้า

สถานการณ์สองสถานการณ์ต่อไปนี้เกี่ยวข้องกับโครงสร้างพื้นฐานของ Exchange ที่มีไซต์ Exchange หลายแห่งและเพิ่มเติม เซิร์ฟเวอร์ Exchange CAS สาธารณะต่างๆ

ตามทฤษฎีแล้ว อาจมี "จุดโฟกัส" เพียงจุดเดียวเท่านั้นที่แสดงถึงจุดสิ้นสุดการค้นหาอัตโนมัติของโดเมน

ในภายหลัง (ในสถานการณ์ 4) เราจะดูวิธีการใช้โครงสร้างพื้นฐานเครือข่ายอื่นที่จะช่วยให้เราแทนที่ข้อจำกัดทางทฤษฎีนี้ได้

สถานการณ์ที่ 3: บริการจดหมาย Exchange สำหรับไคลเอนต์จดหมายภายนอก | เซิร์ฟเวอร์ Exchange CAS สาธารณะหลายตัว | ไซต์แลกเปลี่ยนหลายแห่ง

ในสถานการณ์สมมติต่อไปนี้ แต่ละไซต์ Exchange จะแสดงโดยเซิร์ฟเวอร์ Exchange สาธารณะ

ก่อนที่เราจะเริ่มต้นด้วยรายละเอียดของเวิร์กโฟลว์การค้นหาอัตโนมัติ สิ่งสำคัญคือต้องเข้าใจว่าไคลเอนต์การค้นหาอัตโนมัติรู้วิธีค้นหาชื่อโฮสต์ที่กำหนดไว้ล่วงหน้าซึ่งแสดงถึงจุดสิ้นสุดการค้นหาอัตโนมัติ

ในตัวอย่างของเรา ชื่อจุดสิ้นสุด Autodiscover ที่ไคลเอ็นต์เมลภายนอกจะค้นหาคือ - autodiscover.o365info.com

ความท้าทายที่เราเผชิญอยู่ในขณะนี้คือ “เราจะเผยแพร่เซิร์ฟเวอร์ Exchange CAS สาธารณะสองตัวที่แตกต่างกันโดยใช้ชื่อโฮสต์เดียวกันได้อย่างไร

เราควรชี้ autodiscover.o365info.com ระเบียน DNS ไปยัง New York siteExchange CAS server ไปที่ หรือเราควรชี้
autodiscover o365info.com บันทึก DNS ไปยังไซต์ Los Angles แลกเปลี่ยนเซิร์ฟเวอร์ CAS บน ?

ในสถานการณ์ของเรา เราจะยังคงชี้บันทึก autodiscover.o365info.com ไปยังที่อยู่ IP สาธารณะของเซิร์ฟเวอร์ CAS สาธารณะของ New York Exchange

เมื่อไคลเอนต์จดหมายภายนอกที่กล่องจดหมายของตนโฮสต์อยู่ที่ไซต์ Los Angles จะเชื่อมต่อสาธารณะกำลังเผชิญกับเซิร์ฟเวอร์ New York Exchange CAS เซิร์ฟเวอร์สาธารณะที่เผชิญกับ New York Exchange CAS เซิร์ฟเวอร์จะตอบกลับพร้อมข้อความเปลี่ยนเส้นทางเฉพาะที่จะชี้ไคลเอ็นต์จดหมายภายนอกไปที่ “เซิร์ฟเวอร์ CAS Exchange Los angles ที่หันหน้าเข้าหาสาธารณะ”

เพื่อให้เวิร์กโฟลว์การค้นหาอัตโนมัติ "เข้าใจง่าย" มากขึ้น ฉันจะละเว้นบางส่วนของกระบวนการ

ขั้นตอนที่ 1, 2, 3 และ 4 - โปรแกรมรับส่งเมลภายนอกค้นหาที่อยู่ IP สาธารณะของโฮสต์ - autodiscover.o365info.com และพยายามสร้างเซสชัน HTTPS

โปรแกรมรับส่งเมลภายนอกจะขอใบรับรองเซิร์ฟเวอร์และตรวจสอบว่าใบรับรองนั้นถูกต้อง

เนื่องจากการทดสอบใบรับรองเสร็จสมบูรณ์แล้ว ไคลเอ็นต์เมลภายนอกจึงถือว่าเขาเข้าถึง "เซิร์ฟเวอร์ Exchange CAS ที่ถูกต้อง ”

ไคลเอนต์เมลจะร้องขอไฟล์ autodiscover.xml จากเซิร์ฟเวอร์

ในตอนนี้ ข้อแตกต่างที่สำคัญระหว่างสถานการณ์ข้างต้น: แทนที่จะจัดเตรียมไฟล์ autodiscover.xml ที่จำเป็นให้กับไคลเอ็นต์จดหมาย เซิร์ฟเวอร์ Exchange CAS ของ New York Public จะส่งข้อความเปลี่ยนเส้นทาง

ข้อความการเปลี่ยนเส้นทางรวมถึงชื่อโฮสต์ที่ใช้โดยเซิร์ฟเวอร์ Exchange CAS ของ Los Angles Public

ในสถานการณ์ของเรา ชื่อโฮสต์คือ - mail-la.o365info.com

ตอนนี้ การเดินทางของโปรแกรมรับส่งเมลภายนอกเริ่มต้นใหม่อีกครั้ง

ไคลเอ็นต์อีเมลภายนอกจะต้องได้รับที่อยู่ IP สาธารณะของโฮสต์ -
mail-la.o365info.com

หลังจากที่ไคลเอนต์เมลภายนอกได้รับที่อยู่ IP สาธารณะที่จำเป็นแล้ว ไคลเอนต์เมลจะตรวจสอบว่าโฮสต์ - mail-la.o365info.com สามารถสื่อสารโดยใช้โปรโตคอล HTTPS ได้หรือไม่

ในกรณีที่เซิร์ฟเวอร์ Exchange ของ Los Angles Public หันหน้าไปทาง Exchange นั้น "เปิด" เพื่อการสื่อสารโดยใช้พอร์ต 443 ไคลเอนต์เมลภายนอกจะส่งคำขอใบรับรองเซิร์ฟเวอร์

เมื่อเซิร์ฟเวอร์ Exchange CAS ของ Los Angles Public ยื่นใบรับรอง ไคลเอ็นต์อีเมลจะตรวจสอบว่าใบรับรองเซิร์ฟเวอร์มีชื่อโฮสต์ -
mail-la.o365info.com

หลังจากเสร็จสิ้นกระบวนการตรวจสอบความถูกต้องร่วมกัน ไคลเอนต์เมลภายนอกจะร้องขอไฟล์ autodiscover.xml

ในแผนภาพต่อไปนี้ เราจะเห็น; เราจะเห็นตัวอย่างเล็กๆ น้อยๆ จากเนื้อหาของไฟล์ autodiscover.xml

โปรดทราบว่าที่อยู่ URL รวมถึง FQDN สาธารณะที่ "เป็น" ของเซิร์ฟเวอร์ Exchange CAS ของ Los Angles Public

สถานการณ์ที่ 4: บริการจดหมาย Exchange สำหรับไคลเอนต์จดหมายภายนอก | เซิร์ฟเวอร์ Exchange CAS สาธารณะหลายตัว | ไซต์แลกเปลี่ยนหลายแห่ง | จีโอดีเอ็นเอส

ในสถานการณ์ต่อไปนี้ เราจะตรวจสอบวิธีแก้ปัญหาที่ดีโดยอิงตามการใช้คุณสมบัติที่อธิบายว่าเป็น GeoDNS

คำว่า “GeoDNS” อธิบายเทคโนโลยีของ “เซิร์ฟเวอร์ DNS อัจฉริยะ”

แทนที่จะเป็นเซสชัน DNS มาตรฐานที่ไคลเอนต์ DNS สอบถามเซิร์ฟเวอร์ DNS สำหรับชื่อโฮสต์เฉพาะและเซิร์ฟเวอร์ DNS ตอบกลับโดยใช้ข้อมูลที่เขามีในฐานข้อมูลของเขา คุณสมบัติของ GeoDNS ช่วยให้เซิร์ฟเวอร์ DNS สามารถจดจำตำแหน่งทางภูมิศาสตร์ของเขาได้ “ลูกค้า” และจากข้อมูลนี้ให้คำตอบที่แตกต่างกัน

ในสถานการณ์ต่อไปนี้ เราจะใช้ตัวเลือกของ GeoDNS สำหรับการเผยแพร่ข้อมูลเกี่ยวกับบันทึกการค้นหาอัตโนมัติ

ชื่อโฮสต์ - การค้นหาอัตโนมัติจะชี้ไปที่เซิร์ฟเวอร์ Exchange สองเครื่องในเวลาเดียวกัน

เมื่อผู้ใช้ที่มีตำแหน่งทางภูมิศาสตร์อยู่ในนิวยอร์กสอบถามเซิร์ฟเวอร์ DNS เกี่ยวกับชื่อโฮสต์ - autodiscover.o365info.com เซิร์ฟเวอร์ DNS จะ "รับรู้" ตำแหน่งทางภูมิศาสตร์ของเขาและให้ข้อมูลแก่เขา ที่อยู่ IP สาธารณะของ “เซิร์ฟเวอร์ Exchange สาธารณะของนิวยอร์ก”

เช่นเดียวกับไคลเอนต์ Exchange ที่ตำแหน่งทางภูมิศาสตร์ของพวกเขาอยู่ที่ Los Angles

แต่ละครั้งที่โปรแกรมรับส่งเมล “ลอสแอนเจลิส ” จะสอบถาม DNS สำหรับ IP สาธารณะของโฮสต์- autodiscover.o365info.com เซิร์ฟเวอร์ DNS จะให้ที่อยู่ IP สาธารณะแก่เขา ของ “เซิร์ฟเวอร์ Exchange สาธารณะของ Los Angles”

John เป็นผู้ใช้ที่กล่องจดหมายของเขาโฮสต์อยู่ที่ไซต์ New York Exchange และ Alice เป็นผู้ใช้ที่กล่องจดหมายของเขาโฮสต์อยู่ที่ไซต์ Los Angles Exchange

สมมติว่าทั้งสองได้ผ่านทุกขั้นตอนในการค้นหาเซิร์ฟเวอร์ Exchange CAS ที่เปิดเผยต่อสาธารณะ การตรวจสอบสิทธิ์ และอื่นๆ

เมื่อ John ถาม “จุดสิ้นสุดการค้นหาอัตโนมัติ ” ของเขาสำหรับไฟล์ autodiscover.xml ที่มีข้อมูลที่จำเป็นเกี่ยวกับบริการ Exchange สาธารณะที่มีอยู่ คำตอบจะถูกส่งโดยเซิร์ฟเวอร์ Exchange CAS ของ New York Public และจะมีชื่อโฮสต์สาธารณะ (FQDN) ที่ ถูก "แมป" กับที่อยู่ IP สาธารณะของเซิร์ฟเวอร์ Exchange CAS ของ New York Public

เมื่อ Alice ได้รับ autodiscover.xml เนื้อหาของไฟล์จะมีข้อมูลที่แตกต่างกันซึ่งชี้ไปยังชื่อโฮสต์สาธารณะของเซิร์ฟเวอร์ Exchange CAS ของ Los Angles Public