Az Office 365-végpontok kezelése
A legtöbb vállalati szervezetnek, amely több irodahellyel és egy csatlakozó WAN-nal rendelkezik, konfigurálnia kell az Office 365 hálózati kapcsolatát. A hálózat optimalizálásához küldjön minden megbízható Office 365-ös hálózati kérést közvetlenül a tűzfalon keresztül, megkerülve az összes további csomagszintű ellenőrzést vagy feldolgozást. Ez csökkenti a késést és a szegélyhálózati kapacitásra vonatkozó követelményeket. Az Office 365 hálózati forgalmának azonosítása az első lépés a felhasználók optimális teljesítményének biztosításában. További információt az Office 365 hálózati kapcsolati alapelvei között talál.
A Microsoft azt javasolja, hogy az Office 365-beli IP-cím és URL-webszolgáltatás használatával érje el az Office 365 hálózati végpontjait és azok folyamatban lévő módosításait.
Függetlenül attól, hogy hogyan kezeli az Office 365 létfontosságú hálózati forgalmát, az Office 365-nek internetkapcsolatra van szüksége. Az egyéb hálózati végpontok, ahol szükség van a csatlakozásra, az Office 365 IP-címe és URL-cím webszolgáltatásában nem szereplő további végpontok jelennek meg.
Az Office 365 hálózati végpontok használatának menete a vállalati szervezeti hálózati architektúrától függ. Ez a cikk számos módszert ismertet, amellyel a vállalati hálózati architektúrák integrálhatók az Office 365 IP-címeivel és URL-címeivel. A legegyszerűbben úgy választhatja ki a megbízható hálózati kéréseket, ha az Office 365 automatikus konfigurálását támogató SD-WAN-eszközöket használ az egyes irodai helyeken.
SD-WAN az Office 365 létfontosságú hálózati forgalmának helyi ági kimenő forgalmához
Minden fiókiroda helyén megadhat egy SD-WAN-eszközt, amely úgy van konfigurálva, hogy az Office 365 Optimize végpontkategória vagy az Optimalizálás és engedélyezés kategóriák forgalmát közvetlenül a Microsoft hálózatára irányítja. Az egyéb hálózati forgalom, beleértve a helyszíni adatközpont forgalmát, az általános internetes webhelyek forgalmát és az Office 365 alapértelmezett kategóriavégpontjai felé irányuló forgalmat egy másik helyre küldi, ahol nagyobb hálózati szegélyhálózat található.
A Microsoft SD-WAN-szolgáltatókkal együttműködve teszi lehetővé az automatizált konfigurációt. További információt az Office 365 Hálózatkezelési partnerprogramban talál.
PAC-fájl használata a létfontosságú Office 365-forgalom közvetlen útválasztásához
PAC- vagy WPAD-fájlok használatával kezelheti az Office 365-höz társított, de ip-címmel nem rendelkező hálózati kérelmeket. A proxyn vagy szegélyeszközön keresztül küldött tipikus hálózati kérések növelik a késést. Bár az SSL-megszakítás és -vizsgálat hozza létre a legnagyobb késést, más szolgáltatások, például a proxyhitelesítés és a hírnévkeresés rossz teljesítményt és rossz felhasználói élményt okozhatnak. Emellett ezeknek a szegélyhálózati eszközöknek elegendő kapacitásra van szükségük az összes hálózati kapcsolatkérés feldolgozásához. Javasoljuk, hogy közvetlen Office 365-ös hálózati kérések esetén kerülje meg a proxy- vagy ellenőrzőeszközöket.
A Get-PacFile PowerShell-gyűjtemény egy PowerShell-parancsfájl, amely beolvassa a legújabb hálózati végpontokat az Office 365 IP-címéről és URL-cím webszolgáltatásából, és létrehoz egy PAC-mintafájlt. Módosíthatja a szkriptet, hogy integrálva legyen a meglévő PAC-fájlkezeléssel.
Megjegyzés
Az Office 365-végpontokhoz való közvetlen csatlakozás biztonsági és teljesítménybeli szempontjairól az Office 365 hálózati kapcsolati alapelvei című témakörben talál további információt.

1. ábra – Egyszerű vállalati hálózat szegélyhálózata
A PAC-fájl az 1. ábrán szereplő 1. pontban van üzembe helyezve a webböngészőkben. Ha PAC-fájlt használ az Office 365 létfontosságú hálózati forgalmának közvetlen kimenő forgalmához, engedélyeznie kell a hálózati szegélyhálózati tűzfalon az ezen URL-címek mögötti IP-címekhez való kapcsolódást is. Ehhez be kell kérnie az IP-címeket a PAC-fájlban megadott Office 365-végpontkategóriákhoz, és létre kell hoznia a tűzfal ACL-eit ezen címek alapján. A tűzfal az 1. ábrán a 3. pont.
Ha úgy dönt, hogy csak a kategóriavégpontok optimalizálása érdekében végez közvetlen útválasztást, a proxykiszolgálónak küldött összes szükséges Engedélyezési kategóriavégpontnak szerepelnie kell a proxykiszolgálón a további feldolgozás megkerüléséhez. Az SSL-törés, az Ellenőrzés és a Proxyhitelesítés például nem kompatibilis az Optimize és az Allow kategóriavégpontokkal. A proxykiszolgáló az 1. ábra 2. pontja.
A gyakori konfiguráció az, hogy a proxykiszolgálóról érkező összes kimenő forgalom feldolgozása nélkül engedélyezi a proxykiszolgálót elérő Office 365-ös hálózati forgalom cél IP-címeinek feldolgozását. Az SSL-megszakítással és -vizsgálattal kapcsolatos problémákról további információt a Külső hálózati eszközök vagy megoldások használata az Office 365-ös forgalomon című témakörben talál.
A Get-PacFile szkript kétféle PAC-fájlt fog létrehozni.
| Típus | Leírás |
|---|---|
| 1 |
Küldje el a közvetlen optimalizált végpontforgalmat és minden mást a proxykiszolgálónak. |
| 2 |
Az Optimize és az Allow végponti forgalom közvetlen küldése és minden más a proxykiszolgálóra. Ezzel a típussal az Office 365-höz támogatott összes ExpressRoute-forgalmat elküldheti az ExpressRoute hálózati szegmenseibe, és minden mást a proxykiszolgálóra. |
Íme egy egyszerű példa a PowerShell-szkript meghívására:
Get-PacFile -ClientRequestId b10c5ed1-bad1-445f-b386-b919946339a7
Számos paramétert adhat át a szkriptnek:
| Paraméter | Leírás |
|---|---|
| ClientRequestId |
Ez kötelező, és a hívást kezdeményező ügyfélszámítógépet képviselő webszolgáltatásnak átadott GUID. |
| Példány |
Az Office 365 szolgáltatáspéldány, amely alapértelmezés szerint globális. Ezt a webszolgáltatásnak is átadja a szolgáltatás. |
| TenantName (Bérlő neve) |
Az Office 365-ös bérlő neve. Át lett adva a webszolgáltatásnak, és lecserélhető paraméterként használható egyes Office 365 URL-címekben. |
| Típus |
A létrehozni kívánt proxy PAC-fájl típusa. |
Íme egy másik példa a PowerShell-szkript további paraméterekkel való meghívására:
Get-PacFile -Type 2 -Instance Worldwide -TenantName Contoso -ClientRequestId b10c5ed1-bad1-445f-b386-b919946339a7
A proxykiszolgáló megkerüli az Office 365 hálózati forgalmának feldolgozását
Ha a PAC-fájlokat nem használja a közvetlen kimenő forgalomhoz, a proxykiszolgáló konfigurálásával továbbra is meg szeretné kerülni a feldolgozást a hálózati szegélyhálózaton. Egyes proxykiszolgáló-szállítók engedélyezték ennek automatikus konfigurálását az Office 365 hálózatkezelési partnerprogramjában leírtak szerint.
Ha manuálisan végzi el ezt a műveletet, le kell kérnie az Optimalizálás és engedélyezés végpontkategória-adatokat az Office 365 IP-címéről és URL-cím webszolgáltatásáról, és konfigurálnia kell a proxykiszolgálót, hogy megkerülje ezeknek a feldolgozását. Fontos, hogy elkerülje az SSL-törést, valamint az Optimalizálás és engedélyezés kategóriavégpontokhoz tartozó vizsgálat és proxyhitelesítést.
Az Office 365 IP-címeinek és URL-címeinek módosítása
A hálózati szegélyhálózat megfelelő konfigurációjának kiválasztása mellett fontos, hogy változáskezelési folyamatot vezessen be az Office 365-végpontokhoz. Ezek a végpontok rendszeresen változnak, és ha nem kezeli a módosításokat, előfordulhat, hogy egy új IP-cím vagy URL-cím hozzáadása után a felhasználók blokkolva vannak, vagy gyenge a teljesítményük.
Az Office 365 IP-címeinek és URL-címeinek módosításai általában minden hónap utolsó napjának közelében jelennek meg. Előfordulhat, hogy a módosítást az ütemezésen kívül teszik közzé a működési, támogatási vagy biztonsági követelmények miatt.
Ha közzétesz egy olyan módosítást, amely miatt el kell cselekednie egy IP-cím vagy URL-cím hozzáadása miatt, 30 napos értesítést kell kapnia a módosítás közzétételétől kezdve addig, amíg az adott végponton office 365-szolgáltatás nem található. Ez érvényes dátumként jelenik meg. Bár erre az értesítési időszakra törekszünk, előfordulhat, hogy az üzemeltetési, támogatási vagy biztonsági követelmények miatt ez nem mindig lehetséges. Azok a módosítások, amelyek nem igényelnek azonnali beavatkozást a kapcsolat fenntartásához, például eltávolított IP-címek vagy URL-címek, vagy kevésbé jelentős módosítások, nem tartalmaznak előzetes értesítést. Ezekben az esetekben a rendszer nem ad meg hatálybalépési dátumot. Függetlenül attól, hogy milyen értesítést kap, az egyes módosításokhoz a szolgáltatás várt aktív dátumát soroljuk fel.
Értesítés módosítása a webszolgáltatással
Az Office 365 IP-címe és URL-webszolgáltatása segítségével értesítést kaphat a változásról. Javasoljuk, hogy óránként egyszer hívja meg a /version webes metódust az Office 365-höz való csatlakozáshoz használt végpontok verziójának ellenőrzéséhez. Ha ez a verzió a használt verzióhoz képest változik, akkor le kell kapnia a legújabb végpontadatokat a /endpoints webes metódusból, és opcionálisan le kell kapnia a /changes webes metódus különbségeit. Nem szükséges meghívni a /endpoints vagy /changes webes metódusokat, ha nem történt változás a talált verzióban.
További információ: Office 365 IP-cím és URL-webszolgáltatás.
Értesítés módosítása RSS-hírcsatornák használatával
Az Office 365 IP-címe és URL-webszolgáltatása olyan RSS-hírcsatornát biztosít, amelyre előfizethet az Outlookban. Az IP-címek és URL-címek mindegyik Office 365-szolgáltatáspéldány-specifikus lapján találhatók az RSS URL-címekre mutató hivatkozások. További információ: Office 365 IP-cím és URL-webszolgáltatás.
Változásértesítések és jóváhagyások felülvizsgálata a Power Automate használatával
Tisztában vagyunk azzal, hogy továbbra is szükség lehet manuális feldolgozásra a hálózati végpont minden hónapban végrehajtott módosításaihoz. A Power Automate használatával létrehozhat egy folyamatot, amely e-mailben értesíti Önt, és opcionálisan jóváhagyási folyamatot futtat a módosításokhoz, ha az Office 365-ös hálózati végpontok módosulnak. A felülvizsgálat befejezése után a folyamat automatikusan elküldheti e-mailben a módosításokat a tűzfalnak és a proxykiszolgáló felügyeleti csapatának.
A Power Automate-mintáról és -sablonról az Office 365 IP-címeinek és URL-címeinek módosításáról szóló e-mail küldése a Power Automate használatával című témakörben olvashat.
Gyakori kérdések az Office 365 hálózati végpontjairól
Tekintse meg az Office 365 hálózati kapcsolatával kapcsolatos gyakori kérdéseket.
Hogyan küldhetek be kérdést?
Kattintson az alsó hivatkozásra annak jelzéséhez, hogy a cikk hasznos volt-e vagy sem, és küldje el a további kérdéseket. Figyeljük a visszajelzéseket, és itt frissítjük a kérdéseket a leggyakrabban feltett kérdésekkel.
Hogyan állapíthatom meg a bérlőm helyét?
A bérlő helye az adatközpont-térkép segítségével határozható meg a legjobban.
Megfelelő társviszonyt létesítek a Microsofttal?
A társviszony-létesítési helyek részletesebb leírását a Microsofttal való társviszony-létesítés ismerteti.
Globálisan több mint 2500 isp társviszony-létesítési kapcsolattal és 70 jelenléti ponttal zökkenőmentesen lehet kapcsolatot létesíteni a hálózatról a miénkkel. Nem árt, ha néhány percet azzal töltünk, hogy meggyőződjünk arról, hogy az isp társviszony-létesítési kapcsolata a legoptimálisabb. Íme néhány példa a jó és nem annyira jó társviszony-létesítési kézitásokra a hálózatunk számára.
A közzétett listán nem szereplő IP-címekre irányuló hálózati kéréseket látok, kell hozzáférést biztosítnom hozzájuk?
Csak azoknak az Office 365-kiszolgálóknak az IP-címeit adjuk meg, amelyekhez közvetlenül kell átirányítani. Ez nem az összes OLYAN IP-cím átfogó listája, amelynél hálózati kérelmeket fog látni. Megjelennek a Microsoftnak és külső tulajdonú, közzé nem helyezett IP-címeknek küldött hálózati kérelmek. Ezeket az IP-címeket a rendszer dinamikusan hozza létre vagy kezeli oly módon, hogy megakadályozza a változások időben történő értesítését. Ha a tűzfal nem tudja engedélyezni a hozzáférést a hálózati kérések teljes tartománynevei alapján, a kérések kezeléséhez használjon PAC- vagy WPAD-fájlt.
Látja az Office 365-höz társított IP-címet, amelyről további információt szeretne kapni?
- Ellenőrizze, hogy az IP-cím szerepel-e egy nagyobb közzétett tartományban egy CIDR-kalkulátor használatával, például IPv4 vagy IPv6 esetén. A 40.96.0.0/13 például tartalmazza a 40.103.0.1 IP-címet annak ellenére, hogy a 40,96 nem felel meg a 40.103-nak.
- Ellenőrizze, hogy egy partner rendelkezik-e az IP-címmel egy whois-lekérdezéssel. Ha a Microsoft tulajdonában van, előfordulhat, hogy belső partner. Számos partnerhálózati végpont az alapértelmezett kategóriába tartozik, amelyhez az IP-címek nincsenek közzétéve.
- Előfordulhat, hogy az IP-cím nem része az Office 365-nek vagy függőségnek. Az Office 365 hálózati végpontjainak közzététele nem tartalmazza az összes Microsoft hálózati végpontot.
- Ellenőrizze a tanúsítványt. Egy böngészőben csatlakozzon az IP-címhez HTTPS://<IP_ADDRESS> használatával, és ellenőrizze a tanúsítványon felsorolt tartományokat, hogy megértse, mely tartományok vannak társítva az IP-címmel. Ha ez egy Microsoft tulajdonában lévő IP-cím, és nem szerepel az Office 365 IP-címeinek listáján, akkor valószínű, hogy az IP-cím egy Microsoft CDN-hez, például MSOCDN.NET vagy egy másik Microsoft-tartományhoz van társítva közzétett IP-adatok nélkül. Ha a tanúsítványon található tartomány az az, ahol az IP-címet listázzuk, kérjük, tudassa velünk.
Egyes Office 365 URL-címek a CNAME rekordokra mutatnak a DNS A rekordjai helyett. Mi a teendőm a CNAME rekordokkal?
Az ügyfélszámítógépek egy DNS A- vagy AAAA-rekordot igényelnek, amely egy vagy több IP-címet tartalmaz a felhőszolgáltatáshoz való csatlakozáshoz. Az Office 365 egyes URL-címeI A vagy AAAA rekordok helyett CNAME rekordokat mutatnak. Ezek a CNAME rekordok köztesek, és több is lehet egy láncban. Ezek végül mindig egy IP-cím A vagy AAAA rekordját fogják feloldani. Vegyük például az alábbi DNS-rekordok sorozatát, amelyek végül az IP-cím IP_1 lesznek feloldva:
serviceA.office.com -> CNAME: serviceA.domainA.com -> CNAME: serviceA.domainB.com -> A: IP_1
Ezek a CNAME-átirányítások a DNS normál részét képezik, és átláthatók az ügyfélszámítógép és a proxykiszolgálók számára. Ezek a terheléselosztáshoz, a tartalomkézbesítési hálózatokhoz, a magas rendelkezésre álláshoz és a szolgáltatási incidensek elhárításához használhatók. A Microsoft nem teszi közzé a köztes CNAME rekordokat, azok bármikor változhatnak, és nem kell a proxykiszolgálón engedélyezettként konfigurálnia őket.
A proxykiszolgáló ellenőrzi a kezdeti URL-címet, amely a fenti példában serviceA.office.com, és ez az URL-cím szerepelne az Office 365 közzétételi szolgáltatásában. A proxykiszolgáló az ADOTT URL-cím DNS-feloldását kéri egy IP-címre, és vissza fogja kapni IP_1. Nem ellenőrzi a köztes CNAME átirányítási rekordokat.
A nem módosítható konfigurációk vagy a közvetett Office 365 teljes tartományneveken alapuló engedélyezési lista használata nem ajánlott, a Microsoft nem támogatja, és ismert, hogy ügyfélkapcsolati problémákat okoz. A CNAME átirányítást letiltó vagy az Office 365 DNS-bejegyzéseit egyébként helytelenül feloldó DNS-megoldások megoldhatók DNS-továbbítókon keresztül, engedélyezett DNS-rekurzióval vagy DNS-gyökérmutatók használatával. Számos külső gyártótól származó szegélyhálózati termék natív módon integrálja az ajánlott Office 365-végpontot, hogy az Office 365 IP-cím és URL-webszolgáltatás használatával engedélyezési listát tartalmazzon a konfigurációjukban.
Miért látok olyan neveket, mint a nsatc.net vagy a akadns.net a Microsoft-tartománynevekben?
Az Office 365 és más Microsoft-szolgáltatások számos külső szolgáltatást használnak, például az Akamai és a MarkMonitor szolgáltatást az Office 365-élmény javításához. A lehető legjobb élmény érdekében ezeket a szolgáltatásokat a jövőben módosíthatjuk. A külső tartományok tartalmakat, például CDN-eket tárolhatnak, vagy egy szolgáltatást, például egy földrajzi forgalomkezelő szolgáltatást üzemeltethetnek. A jelenleg használt szolgáltatások közé tartoznak a következők:
A MarkMonitor akkor van használatban, ha .nsatc.net tartalmazó* kérelmeket lát. Ez a szolgáltatás tartománynév-védelmet és monitorozást biztosít a rosszindulatú viselkedés elleni védelem érdekében.
Az ExactTarget akkor van használatban, ha a .exacttarget.com felé* irányuló kéréseket látja. Ez a szolgáltatás biztosítja az e-mail-hivatkozások kezelését és a rosszindulatú viselkedés elleni figyelést.
Az Akamai akkor van használatban, ha olyan kéréseket lát, amelyek az alábbi teljes tartománynevek egyikét tartalmazzák. Ez a szolgáltatás geo-DNS- és tartalomkézbesítési hálózati szolgáltatásokat kínál.
*.akadns.net
*.akam.net
*.akamai.com
*.akamai.net
*.akamaiedge.net
*.akamaihd.net
*.akamaized.net
*.edgekey.net
*.edgesuite.net
Az Office 365-höz a lehető legkisebb kapcsolattal kell rendelkeznem
Mivel az Office 365 olyan szolgáltatáscsomag, amely az interneten keresztüli működésre épül, a megbízhatóság és a rendelkezésre állás ígéretei számos szabványos internetszolgáltatás rendelkezésre állásán alapulnak. Az Office 365 használatához például a szabványos internetes szolgáltatásoknak , például a DNS-nek, a CRL-nek és a CDN-nek elérhetőnek kell lenniük, ahogyan a legtöbb modern internetes szolgáltatás használatához elérhetőknek kell lenniük.
Az Office 365 csomag fő szolgáltatási területekre oszlik. Ezek szelektíven engedélyezhetők a kapcsolatokhoz, és van egy közös terület, amely mindenki számára függőség, és mindig szükséges.
| Szolgáltatási terület | Leírás |
|---|---|
| Exchange |
Az Exchange Online és az Exchange Online védelme |
| SharePoint |
SharePoint Online és OneDrive Vállalati verzió |
| Skype Vállalati online verzió és Microsoft Teams |
Skype Vállalati verzió és Microsoft Teams |
| Közös |
Office 365 Pro Plus, Office böngészőben, Azure AD és egyéb gyakori hálózati végpontok |
Az alapvető internetes szolgáltatások mellett léteznek külső szolgáltatások is, amelyek csak a funkciók integrálására használhatók. Bár ezek az integrációhoz szükségesek, az Office 365-végpontokról szóló cikkben választhatóként vannak megjelölve, ami azt jelenti, hogy a szolgáltatás alapvető funkciói továbbra is működni fognak, ha a végpont nem érhető el. Minden szükséges hálózati végpont true (igaz) értékűre állítja a szükséges attribútumot. Az opcionális hálózati végpontok esetén a szükséges attribútum false (hamis) értékre lesz állítva, és a Notes attribútum részletezi a hiányzó funkciókat, amelyekre számítania kell, ha a kapcsolat le van tiltva.
Ha az Office 365-öt próbálja használni, és nem találja a külső féltől származó szolgáltatásokat, győződjön meg arról, hogy a jelen cikkben kötelezőként vagy választhatóként megjelölt összes teljes tartománynév engedélyezve van a proxyn és a tűzfalon keresztül.
Hogyan tilthatom le a Microsoft fogyasztói szolgáltatásaihoz való hozzáférést?
A bérlőkorlátozási funkció mostantól támogatja az összes microsoftos fogyasztói alkalmazás (MSA-alkalmazás), például a OneDrive, a Hotmail és a Xbox.com használatát. Ez egy külön fejlécet használ a login.live.com végponthoz. További információ: SaaS-felhőalkalmazásokhoz való hozzáférés kezelése bérlői korlátozások használatával.
A tűzfal ip-címeket igényel, és nem tudja feldolgozni az URL-címeket. Hogyan konfigurálhatom az Office 365-höz?
Az Office 365 nem adja meg az összes szükséges hálózati végpont IP-címét. Néhány csak URL-címként van megadva, és alapértelmezettként van kategorizálva. A kötelező alapértelmezett kategóriában lévő URL-címeket proxykiszolgálón keresztül kell engedélyezni. Ha nem rendelkezik proxykiszolgálóval, tekintse meg, hogyan konfigurálta a felhasználók által a webböngésző címsorába beírt URL-címekre vonatkozó webes kéréseket; A felhasználó sem ad meg IP-címet. Az Office 365 alapértelmezett, IP-címeket nem tartalmazó kategória URL-címeit ugyanúgy kell konfigurálni.
Kapcsolódó témakörök
Office 365 IP-cím és URL-webszolgáltatás
Microsoft Azure-adatközpont IP-tartományai
Nyilvános Microsoft IP-címterület
A Microsoft Intune hálózati infrastruktúrával kapcsolatos követelményei
Az Office 365 URL-címei és IP-cím tartományai.
Az Office 365-höz készült ExpressRoute kapcsolatainak kezelése