سايت خدمات پشتيباني – برگه 5 – پشتیبانی VoIP|پشتیبانی شبکه|ویپ |تجهیزات شبکه

آشنایی با پروتکل احراز هویت DKIM ایمیل

Posted on نوامبر 22, 2021 by tilatel

(DomainKeys Identified Mail (DKIM پیچیده ترین پروتکل تصدیق ایمیل می باشد، این مقاله به صورت اختصاصی به معرفی پروتکل DKIM خواهیم پرداخت. با ما همراه باشید:

(DomainKeys Identified Mail (DKIM یک پروتکل است که به سازمان ها اجازه می دهد تا انتقال پیام را به گونه ای که توسط ارائه دهندگان ایمیل قابل تایید باشد، انجام دهند. این تاییدیه توسط احراز هویت رمزنگاری شده (Cryptographic authentication) و از طریق کلید های Public و Private انجام می پذیرد.

DKIM کمی پیچیده می باشد، در ادامه سعی می کنیم، به زبانی ساده آن را برای شما شرح دهیم.

گام اول: شناسایی عناصر یک پیغام برای Sign در DKIM

یک فرستنده ایمیل ابتدا باید تصمیم بگیرد که کدام Elements های یک ایمیل را می خواهد در فرایند Sign قرار دهد، آن ها باید تصمیم بگیرند که کل پیام (Header,Body) یا فقط یک یا چند فیلد خاص در هدر ایمیل در جریان این فرایند رمزنگاری قرار بگیرد.، Element هایی که قرار است در Sign DKIM قرار بگیرند نباید در حین انتقال پیام تغییر کنند، در غیر اینصورت احراز هویت DKIM رد یا Fail می شود.

برای مثال، اگر یک ایمیل از Yahoo به Gmail forward شود، یاهو یک متن در بالای ایمیل مانند (forward By yahoo mail) اضافه می کند و Body ایمیل دچار تغییر می شود، اگر Body جز Element های امضا شده در فرایند DKIM باشد، احراز هویت در ایمیل Forward شده Fail خواهد شد.

با این حال، اگر تنها یک Element از Header مانند فیلد From در فرایند امضای DKIM قرار گرفته باشد، و ایمیل از Yahoo به Gmail forward شود، احراز هویت DKIM تایید می شود، زیرا آن بخشی از ایمیل که تغییر کرده است در فرایند امضای DKIM قرار نگرفته بوده است.

گام دوم: فرایند رمزنگاری

فرستنده باید یک سری تنظمیات بر روی Platform ایمیل خود انجام دهد، که به صورت خودکار یک Hash از Element هایی که قرار است در فرایند Sign قرار بگیرند ساخته شود. فرایند Hash، متن را تبدیل به یک رشته متنی منحصر بفرد می کند.

<From: Ehsan Ataei <IT@PardisMail.com

Subject: Testing

:Maps to the following unique hash string

3303baf8986f910720abcfa607d81f53

قبل از ارسال ایمیل، رشته متنی Hash شده با استفاده از Private Key رمزنگاری می شود، کلید خصوصی از ترکیب نام دامنه و Selector (هر اسمی امکان پذیر می باشد، بیشتر بر اساس نوع کاربری ایمیل انتخاب می شود) ساخته می شود، که به شما این قابلیت را می دهد که چندین کلید خصوصی قانونی برای یک دامنه داشته باشید( که برای مدیریت ایمیل و اهداف امنیتی مهم می باشد)، و فقط فرستنده به کلید خصوصی دسترسی دارد. بعد از کامل شدن فرایند رمزنگاری ایمیل ارسال می شود.

گام سوم: تایید DKIM Signature با کلید عمومی:

Mail سرور گیرنده بعد از دریافت ایمیل، متوجه می شود که ایمیل دارای امضای DKIM می باشد، که نشان دهنده نام دامین و Selector است که فرایند رمزنگاری را امضا کرده اند، دریافت کننده ایمیل یک پرس و جو Query DNS برای پیدا کردن کلید عمومی براسا Domain\Selector برای تایید امضا انجام می دهد.

کلید عمومی دارای خصوصیات منحصربفردی است که تنها با کلید خصوصی که ایمیل را امضا کرده است، مطابقت دارد،که به عنوان keypair match هم شناخته می شود، که ارائه دهندگان ایمیل را قادر به رمزگشایی امضای DKIM و بدست آوردن رشته اصلی Hash میسازد.

ارائه دهندگان ایمیل سپس با استفاده از Element های شرکت کننده در امضای DKIM دوباره یک Hash از این عناصر میسازد، سپس هش را با هش بدست امده از DKIM Hash مقایسه می کند، اگر دو Hash با هم مطابقت داشته باشند، ما می دانیم که:

دامنه با امضای DKIM مالک ایمیل می باشد، در غیر اینصورت فرایند رمزگشایی در وهله اول کار نخواهد کرد.
عناصر ایمیل که توسط DKIM امضا شده بودند در هنگام ارسال تغییری نکرده اند (زیرا اگر تغییر کرده بودند، Hash ها با یکدیگر مطابقت نداشتند).

ارائه دهندگان ایمیل که امضای DKIM را تایید می کنند، می توانند از اطلاعات مربوط به امضاکننده به عنوان بخشی از یک برنامه برای کاهش حملات Spam,Spoofing و Phishing استفاده کنند، هر چند که DKIM به دریافت کنندگان ایمیل برای انجام، اقدامی خاص کمک نمی کند، بستگی به پیاده سازی DKIM می توان اطمینان حاصل کرد که پیام در نقل و انتقالات دستخوش تغییرات بوده است یا خیر

مشکل DKIM این است که به دلیل اجرای سخت پیاده سازی، فرستنده های کمتری آن را قبول کرده اند، این نقطه ضعف بدان معنی است که عدم وجود امضای DKIM لزوما نشان دهنده جعلی بودن ایمیل نیست، بنابراین DKIM یک راه قابل اعتماد برای تایید هویت فرستنده نیست، علاوه بر این DKIM برای کاربر نهایی غیر فنی قابل مشاهده نیست، و هیچ کاری برای جلوگیری از جعل هویت Header From دامین نمی کند.

DMARC، آخرین و پیشرفته ترین پروتکل در احراز هویت ایمیل می باشد و این مشکل را با تضمین اینکه دامنه قابل مشاهده برای کاربر نهایی همان دامنه ای است که توسط SPF و DKIM بررسی و تایید شده است حل می کند. علاوه بر این، ارائه دهندگان صندوق پستی را با دستورالعمل مشخصی در مورد اینکه کدام ایمیل ها باید توسط DKIM احراز هویت شوند و کدامیک نه کمک رسانی می کند.

آشنایی با پروتکل احراز هویت SPF ایمیل

Posted on نوامبر 22, 2021نوامبر 22, 2021 by tilatel

احراز هویت ایمیل، می تواند کاری بسیار فنی و گیچ کننده باشد.

حتی متخصصان امنیت با تجربه هم نیاز به کمک و هدایت در این حوزه دارند، و توضیح آن برای افراد غیرفنی براحتی قابل هضم نیست.

در این مقاله قصد داریم تا شما را با مهمترین پروتکل های احراز هویت ایمیلآشناکنیم، پروتکل هایی مانند :

SPF(Sender Policy Framework)

،DKIM(Domain Keys Identified Mail)

DMARC(Domain-Based Message Authentication,Reporting & Conformance)

Two “From” Addresses:

پیغام های ایمیل شامل دو آدرس “from” هستند(Envelope from(return path or mfrom و (Header from(Friendly From.

Envelope from آدرس برگشتی است، و به میل سرورها مسیر بازگشت را می گوید، Enveloper from در هدر پیام های ایمیل مخفی می باشد که شامل جزئیات فنی سرورها است، که برای فهمیدن اینکه چه کسی ایمیل را ارسال کرده و یا از چه نرم افزاری برای ساخت آن استفاده شده است.

آدرس Header from آدرس قرار گرفته در فیلد From می باشد که برای همه کاربران قابل مشاهده می باشد.

هر دوی این ها آدرس ها توسط مجرمان سایبری به براحتی قابل جعل و کلاهبرداری می باشد، این مرحله ای است که تایید و احراز هویت ایمیل وارد می شود.

(SPF (Sender Policy Framework:

SPF یک پروتکل احراز هویت ایمیل می باشد، که به مالک یک دامین اجازه می دهد که مشخص کند،که کدام میل سرورها برای ارسال ایمیل از این دامنه استفاده می شود.

کمپانی های ارسال ایمیل رکوردهای SPF را در DNS منتشر می کنند، این رکوردها، لیست آدرس های IP مجاز برای ارسال ایمیل برروی دامنه ها را مشخص می کنند.

در طی بررسی SPF، ارائه دهندگان ایمیل،تایید رکورد SPF را با جستجو کردن نام دامنه ذکر شده درآدرس Envelope from را در DNS بررسی می کند، اگر آدرس IP ارسال ایمیل روی دامین در رکورد SPF نباشد، ایمیل دراحراز هویت SPF رد می شود.

یک دامین محافظت شده با SPF کمتر برای phishers جذاب می باشد، بنابراین کمتر به لیست های Spam اضافه می شود.

اما SPF دارای چند مشکل عمده می باشد.

فقط به این دلیل که یک پیام فاقد SPF است، به این معنا نیست که همیشه مسدود می شود، این یکی از چندین فاکتوری است که ارائه دهندگان ایمیل برای Spam در نظر می گیرند.
SPF هنگامی که یک پیام forward می شود، از بین می رود.
به روز نگه داشن رکوردSPF کمی زمانبر می باشد.
SPF نمی تواند هیچ کاری برای محافظت در برابر مجرمان اینترنتی که نام یا آدرس”Header from” را در پیغام خود جعل می کنند، انجام بدهد.

نحوه ی ساخت و کانفیگ Relay Connector در Exchange Server 2016

Posted on نوامبر 21, 2021 by tilatel

در بسیاری از نرم افزارهای امروزی مانند Veeam Backup ، کنسول های آنتی ویروس، مانیتورینگ، نرم افزارهای CRM و … امکانی برای ارسال گزارشات به ایمیل گذاشته شده است، که نیاز به وارد کردن یک SMTP سرور دارد، امروز یاد می گیریم چطوری یک Relay Connector در Exchange ایجاد کنیم.

که این نرم افزار ها بتونن در شبکه داخلی بدون Authentication از SMTP سرور Exchange استفاده کنند.

روش اول از طریق PowerShell:

Exchange Managment Powershell را باز نمایید و مراحل زیر را دنبال کنید.

با دستور زیر ابتدا یک Receive Connector با نام Relay که فقط IP های 10.128.57.54 و 10.128.57.55 مجاز به استفاده از اون هستند می سازیم

New-ReceiveConnector -Name “Relay” -RemoteIPRanges (“10.128.57.54″,”10.128.57.55”) -TransportRole “FrontendTransport” -Bindings (“0.0.0.0:25”) -Usage “Custom” “-Server Servername.PardisMail.Com”

با دستور زیر در Receive Connector بالا که ساختیم اجازه استفاده از این Connector رو به همه یوزر ها می دهیم.

“Set-ReceiveConnector -Identity “Servername\Relay” -PermissionGroups “AnonymousUsers

با دستور زیر اجازه دریافت از هر گیرنده ای رو برای Receive Connector صادر می کنیم.

“Get-ReceiveConnector “Servername\Relay” | Add-ADPermission -User “NT AUTHORITY\ANONYMOUS LOGON” -ExtendedRights “Ms-Exch-SMTP-Accept-Any-Recipient

روش دوم از طریق GUI

به قسمت Receive Connector در MailFlow بروید و روی + کلیک نمایید و مطابق شکل پیش برید:

رنج شبکه بالا رو پاک کنید و رنج IP هایی که قراره از Relay Connector استفاده کنند را وارد کنید.

بر روی Connector ساخته شده کلیک کنید و به قسمت Security رفته و تیک گزینه Anonymous users را بزنید.

حال باید Exchange Managment PowerShell را بازکنید و به Receive Connector اجازه دریافت از هر گیرنده ای رو صادر کنید.

“Get-ReceiveConnector “Servername\Relay” | Add-ADPermission -User “NT AUTHORITY\ANONYMOUS LOGON” -ExtendedRights “Ms-Exch-SMTP-Accept-Any-Recipient”

کار تمامه فقط کافیه در Application های خودتون آدرسSMTP خودتون رو وارد کنید مانند شکل زیر در نرم افزار Veeam Backup & Replication

معرفی Protocol Logging در Exchange Server 2013

Posted on نوامبر 20, 2021نوامبر 20, 2021 by tilatel

در این مقاله به معرفی Protocol Logging در Exchange Server 2013 می پردازیم.با ما همراه باشید

پروتکل لاگینگ (Protocol Logging) کلیه رخدادهای SMTP بین ایمیل سرورها را ثبت می کند. این گفتگوهای SMTP بین Send Connector سرور ارسال کننده ایمیل و Receive Connector سرور دریافت کننده ایمیل در Front End Transport Services سرور Client Access، Transport Service روی Mailbox Server و Mailbox Transport Service روی سرورهای Mailbox رخ می دهد. از طریق پروتکل لاگینگ (Protocol Logging) می توانیم مشکلات مربوط به ارسال و دریافت ایمیل را مشخص کنیم.

به صورت پیش فرض پروتکل لاگینگ روی کلیه کانکتورهای مربوط به ارسال و دریافت غیرفعال می باشد. پروتکل لاگینگ به ازای هر کانکتورها قابل فعال یا غیرفعال شدن می باشد. سایر آپشن های مربوط به پروتکل لاگینگ روی کلیه کانکتورهای ارسال و کلیه کانکتورهای دریافت در Transport Service سرور تنظیم می شوند. فایلهای مربوط به پروتکل لاگها و پروتکل آپشن های همه Receive Connector ها یا همان کانکتورهای دریافت در یک Transport Service به صورت مشترک در یکجا ذخیره می شوند. این پروتکل لاگ ها و پروتکل آپشن ها با پروتکل لاگ ها و پروتکل آپشن های Send Connector های همان سرور متفاوت می باشد.
آپشن های ذیل برای پروتکل لاگ کلیه Send Connector ها یا Receive Connector های Transport Service روی Exchange Server قابل تنظیم می باشد:
– تعیین مسیر نگهداری فایلهای پروتکل لاگ مربوط به کانکتور ارسال و کانکتور دریافت.
– تعیین حداکثر سایز فایلهای پروتکل لاگ برای کانکتور ارسال و کانکتور دریافت. حجم پیش فرض 10 مگابایت می باشد.
– تعیین حداکثر حجم فولدر مربوط به ذخیره سازی فایلهای پروتکل لاگ برای کانکتور ارسال و کانکتور دریافت. حجم پیش فرض 250 مگابایت می باشد.
– تعیین حداکثر مدت نگهداری فایلهای پروتکل لاگ برای کانکتور ارسال و کانکتور دریافت. مدت زمان پیش فرض 30 روز می باشد.
به صورت پیش فرض Exchange Server فایلهای لاگ را پس از حجم و زمان مجاز پاک می کند تا امکان مدیریت فضای هارددیسک فراهم شود.
یک Send Connector خاص به نام Intra-organization در هر سرور با رول Transport Service ایمیل سرورها و Client Access سرورها وجود دارد. این کانکتور به صورت پیش فرض ساخته می شود و نیازی به کانفیگ ندارد. کانکتور ارسال کننده intra-organization برای Transport Services های ذیل استفاده می شود:
– Transport Services روی Mailbox سرورها
o رله کردن ایمیل های ارسالی به Transport Service و Mailbox Transport Service روی سایر Exchange Server های 2013 در همان Organization
o رله کردن ایمیلهای ارسالی به سایر Exchange Server های 2007 یا 2010 در همان Organization
o رله کردن ایمیلهای ارسالی به Edge Transport سرور
– Front End Transport Services روی Client Access سرورها
o رله کردن ایمیل های ارسالی به Transport Service روی Mailbox Server Exchange 2013
Send Connector دیگری معادل همان Send Connector intra-organization به نام mailbox delivery send connector در Mailbox Transport Service سرورهای Mailbox وجود دارد. این کانکتور هم به صورت پیش فرض ساخته و کانفیگ می شود و به صورت مخفی می باشد. Mailbox delivery send connector برای رله کردن ایمیلهای ارسالی به Transport Service و Mailbox Transport Service در Organization استفاده می شود.
به صورت پیش فرض پروتکل لاگینگ برای این کانکتور نیز غیرفعال می باشد. شما می توانید از طریق کامند نسبت به فعال یا غیرفعال سازی پروتکل لاگینک اقدام نمایید.
ساختار فایلهای پروتکل لاگ
به صورت پیش فرض فایلهای پروتکل لاگ در مسیرهای زیر قرار دارد:
– فایلهای پروتکل لاگ کانکتور دریافت کننده برای Transport Service روی میل باکس

o servers %ExchangeInstallPath%TransportRoles\Logs\Hub\ProtocolLog\SmtpReceive

– فایلهای پروتکل لاگ کانکتور دریافت کننده برای Mailbox Transport Service روی میل باکس

o servers %ExchangeInstallPath%TransportRoles\Logs\Mailbox\ProtocolLog\SmtpReceive

– فایلهای پروتکل لاگ کانکتور دریافت کننده برای Front End Transport Service روی Client Access

o servers %ExchangeInstallPath%TransportRoles\Logs\FrontEnd\ProtocolLog\SmtpReceive

– فایلهای پروتکل لاگ ارسال کننده برای Transport Service روی میل باکس

o servers %ExchangeInstallPath%TransportRoles\Logs\Hub\ProtocolLog\SmtpSend

– فایلهای پروتکل لاگ ارسال کننده برای Mailbox Transport Service روی میل باکس

o servers %ExchangeInstallPath%TransportRoles\Logs\Mailbox\ProtocolLog\SmtpSend

– فایلهای پروتکل لاگ ارسال کننده برای Front End Transport Service روی Client Access

o servers %ExchangeInstallPath%TransportRoles\Logs\FrontEnd\ProtocolLog\SmtpSend

فرمت نامگذاری برای لاگ فایلها در هر کدام از فولدرهای پروتکل لاگ به صورت prefixyyyymmdd-nnnn.log می باشد. متغیرها به صورت ذیل می باشند:
– متغیر Prefix برای کانکتور ارسال کننده SEND و برای کانکتور د ریافت کننده RECV می باشد.
– متغیر yyyymmdd نمایانگر زمان ایجاد فایل با فرمت UTC می باشد. متغیر yyyy برای سال، mm برای ماه و dd برای روز می باشد.
– متغیر nnnn برای ارزش تعداد فایلها در روز می باشد که از 1 شروع می شود.
اطلاعات در لاگ فایلها ذخیره می شوند تا جایی که حجم فایل به سقف مجاز خود برسد و سپس فایل جدیدی با شماره جدید ایجاد می شود. این پروسه در طول روز تکرار می شود. سیستم Circular Logging فایلهای تاریخ گذشته را حذف می کند وقتی که حجم فولدر از حد مجاز گذشته باشد.
پروتکل لاگ ها فایلهای TXT ای هستند که دیتاها را به صورت تقسیم بندی شده توسط Comma ایجاد نموده اند. هر پروتکل لاگ شامل Header ی می باشد که اطلاعات ذیل را در بر دارد:
– #Software نام نرم افزاری که فایل پروتکل لاگ را ایجاد نموده است. معمولا این اسم Microsoft Exchange Server می باشد.
– #Version ورژن نرم افزاری که فایل پروتکل لاگ را ایجاد نموده است. برای Exchange Server 2013 این مقدار 15.0.0.0 می باشد.
– #Log-Type مشخص می کند که فایل پروتکل لاگ مربوط به SMTP Receive Protocol Log می باشد یا SMTP Send Protocol Log
– #Date زمان ایجاد فایل را مشخص می کند.
– #Fields نام فیلد با کاما جداشده که برای فایل پروتکل لاگ استفاده می شود.
اطلاعاتی که در پروتکل فایل ذخیره می شود
پروتکل لاگ هر رخداد مربوط به SMTP را در یک خط جداگانه ذخیره می کند. اطلاعات ذخیره شده در هر خط توسط نام فیلد سازماندهی می شود. این فیلدها توسط کاما از هم جدا می شوند. در ذیل به بررسی فیلدهای مختلف می پردازیم.
– date-time زمان هر رخداد.
– connector-id نام Distinguished name (DN) کانکتور مربوط به آن رخداد
– session-id GUID که برای هر STMP Session یکتا می باشد اما برای کلیه رخدادهای مربوط به همان Session مشترک می باشد
– sequence-number شماره اندازی که از 0 شروع می شود و به ازای هر رخداد به مقدار آن افزوده می شود
– local-endpoint آیپی و پورت مربوط به مقصد لوکال که به صورت <ip address>:<port> می باشد
– remote-endpoint آیپی و پورت مربوط به مقصد اینترنتی
– event تک کاراکتری که رخداد پروتکل را معرفی می کند.

o + Connect

o – Disconnect

o > Send

o < Receive

o * Information

– Data توضیحات مربوط به رخداد SMTP
– Context اطلاعاتی متنی که احتمالا مرتبط به رخداد پیش آمده می باشد
یک گفتگوی ساده SMTP که برای ارسال یا دریافت می باشد، رخدادهای زیادی را در بر دارد در محل های مرتبط ذخیره می کند. این رخدادها در خطوط مختلف در لاگ فایلهای نوشته و ذخیره می شوند. مفدار زیادی گفتگوی SMTP برای ارسال یا دریافت ایمیل ممکن است به صورت همزمان انجام شود. که این باعث در هم آمیختگی متنهای داخل پروتکل لاگ می شود. شما از طریق session-id و sequence-number می توانید این دیتاها را مرتب کنید تا سریعتر به دیتا مورد نظر برسید.

بررسی و درک Receive Connector های پیش فرض در Exchange Server 2016

Posted on نوامبر 20, 2021مارس 27, 2022 by tilatel

وقتی که Exchange Server 2016 را نصب می کنید، پنج Receive Connector را مشاهده می کنید که به صورت پیش فرض ایجاد شده است. در این مرحله ممکن است برای شما سوال پیش بیاید که این کانکتورها چه هستند و کاربرد آنها چیست. دانستن این کانکتورهای پیش فرض برای درک کردن اینکه چگونه ایمیل به دست شما می‌رسد مفید است.

درک کانکتورهای دریافت پیش فرض در Exchange Server 2016
Exchange Server 2016 شامل دو Server Role به نامهای Mailbox Server Role و Edge Transport Server Role می باشد. Mailbox Server Role داری سه Transport Service (یا Sub Role) می باشد. این Transport Service ها Transport Pipeline نیز خوانده می شوند. ایمیل ها در بین این سه Pipeline حرکت می کند. سه Transport Service که به آن اشاره کردیم موارد زیر می باشند:
1- Front End Transport Service: این سرویس برای کلیه ایمیلهای ارسالی و دریافتی خارج از میل باکس های موجود در ایمیل سرور می باشد. این سرویس نقش صف دهی و بازرسی روی ایمیلها را ایفا نمی کند. وقتی ایمیلی از خارج سازمان می آید، اولین سرویسی که آن را دریافت می کند این سرویس می باشد. این سرویس ایمیل را به Transport Service منتقل می کند و به هیچ عنوان با Mailbox Transport به صورت مستقیم ارتباط برقرار نخواهد کرد.
2- (Transport Service (Hub Transport Service: این سرویس نقش گروه بندی و مدیریت صف ارسال و دریافت ایمیل را ایفا می کند. همچنین این سرویس بازرسی ایمیلها و بررسی آنها از لحاظ آنتی اسپم و anti-malware را انجام می دهد. این سرویس ایمیلها را از Front End Transport Service دریافت می کند و به Mailbox Transport Service منتقل می کند.
3- Mailbox Transport Service: این سرویس می باشد که در نهایت ایمیلها را دریافت و در میل باکس مرتبط قرار می دهد. این سرویس شامل دو زیر سرویس می باشد:
– Mailbox Transport Submission Service: این سرویس پیامها را از Mailbox Database دریافت می کند و آنها را به Transport Service منتقل می کند تا به مخاطب مورد نظر ارسال شود.
– Mailbox Transport Delivery Service: این سرویس ایمیل را از Transport Service دریافت می کند و از طریق (RPC (Remote Procedure Call به میل باکس مورد نظر منتقل و در آن ذخیره می کند.
برای دیدن لیست Receive Connector به کنسول (Exchange Admin Center (EAC لاگین کنید و از منوی mail flow وارد receive connector شوید:

همانطوری که در تصویر فوق مشاهده می کنید پنج Receive Connector در این لیست وجود دارد. تعداد سه کانکتور Frontend Transport Service و دو کانکتور Hub Transport Service وجود دارد. خب حال ببینیم که هر کدام از این کانکتورها چه کاری انجام می دهند.
1- Client Frontend HQ-MS1: این کانکتورها ایمیلهایی که به صورت امن شده از طریق TLS را دریافت می کند. پذیرش از طریق پورت 587 انجام می شود. این کانکتور توسط POP و IMAP استفاده می شود. این کانکتور کانکشنهای نرم افزاری IMAP و POP را به کانکتور Hub Transport Receive Connector بنام Client Proxy HQ-MS1 پروکسی می کند.
2- Default Frontend HQ-MS1: ایمیلهای ارسالی از طریق اینترنت توسط این کانکتور در پورت 25 پذیرفته می شوند. سپس این کانکتور ایمیلها را به Transport Service روی Hub Transport Service Receive Connector بنام Default HQ-MS1 روی پورت 2525 منتقل می کند.
3- Outbound Proxy Frontend HQ-MS1: اگر شما در Send Connector تیک مربوط به proxy through client access server option را زده باشید، سپس کلیه ایمیلهای خروجی توسط این کانکتور دریافت می شود. به زبان دیگر این کانکتور کلیه ایمیلهایی که توسط Transport Service ای که تیک proxy through client access server خورده باشد را دریافت می کند. اکنون ایمیلها توسط این کانکتور به اینترنت ارسال می شود. این کانکتور از طریق پورت 717 ایمیلها را دریافت می کند.

4- Client Proxy HQ-MS1: این یک سرویس Hub Transport می باشد. ایمیلها را از Frontend Service دریافت می کند وبه Mailbox Transport Service منتقل می کند. این کانکتور از پورت 465 دریافت می کند. این Receive Connector کانکشن های POP و IMAP پراکسی شده را که از Frontend Transport Service بنام Client Frontend HQ-MS1 ارسال شده دریافت می کند.
5- Default HQ-MS1: این یک Hub Transport Service می باشد. این کانکتورهای ایمیلهای دریافتی را از Frontend Transport Service دریافت می کند و به Mailbox Transport Service منتقل می کند. مشابه همین، ایمیلهای ارسالی را از Mailbox Service دریافت می کند و به Send Connector جهت ارسال ایمیل به اینترنت یا دریافت از طریق کانکتور Outbound Proxy Frontend HQ-MS1 (در صورتی که تیک proxy through client access server در Send Connector خورده باشد) منتقل می کند. این کانکتور ایمیلها را از طریق پورت 2525 دریافت می کند.

نحوه ی کانفیگ کردن دیتابیس در Exchange Server 2016

Posted on نوامبر 17, 2021نوامبر 17, 2021 by tilatel

در این مقاله قصد داریم تا شما را با نحوه ی ساخت و کانفیگ دیتابیس در Exchange Server 2016 آشنا کنیم با ما همراه باشید:

تصور اشتباهی که خیلی از افراد در مورد دیتابیس Exchange Server دارند، برابری این دیتابیس با دیتابیس های SQL Server می باشد. توجه داشته باشید که دیتابیس Exchange Server به هیچ عنوان همانند دیتابیس های SQL Server نمی باشد. در نتیجه قابلیت اتصال یک دیتابیس از یک Exchange Server به یک Exchange Server دیگر وجود ندارد. زمانی که Exchange Server را نصب می کنید، یک دیتابیس به صورت پیش فرض ایجاد می شود. هر چند که می توانید از همان دیتابیس برای ایجاد میل باکس ها استفاده کنید اما ما پیشنهاد می کنیم که از یک دیتابیس جدید برای این موضوع استفاده کنید.
برای ایجاد دیتابیس به صورت ذیل عمل می کنیم:

مطابق تصویر فوق وارد منوی Server و از آنجا وارد Databases می شویم و اقدام به ایجاد دیتابیس جدید می کنیم. مواردی که باید در حین ساخت دیتابیس جدید در Exchange Server 2016 انجام دهیم شامل:
– نام دیتابیس
– سروری که قصد ساختن دیتابیس برای آن دارید
– مسیر لاگهای مربوط به دیتابیس
– تعیین عملیات مانت شدن یا نشدن
نکته ای که در این قسمت وجود دارد این است که پیشنهاد می کنیم تیک مربوط به Mount this database را بردارید و پس از ذخیره کردن دیتابیس و ایجاد شدن آن، اقدام به مانت کردن کنید. علت این است که تاخیری که در ساخت دیتابیس و ارتباط با اکتیودایرکتوری وجود دارد باعث بروز خطائی می شود که این موضوع با به تاخیر انداختن عملیات مانت دیتابیس مرتفع می شود.
اگر از دیتابیسها Properties بگیرید مواردی به شما نمایش داده خواهد شد.

در منوی General اطلاعات عمومی از دیتابیس نمایش داده می شود. نظیر نام دیتابیس، مسیر دیتابیس، نام سرور میزبان، آخرین وضعیت بکاپ گیری و … .

در منوی Maintenance گزینه ای با نام Enable circular logging وجود دارد که به صورت پیش فرض به صورت غیر فعال می باشد. هر گونه عملیاتی که در دیتابیس ها انجام می شود منجر به تهیه لاگ می شود، نتیجه اینکه پس از مدت کوتاهی شاهد حجم زیادی لاگ هستید حتی پس از مدتی دیگر حجم لاگ ها از حجم خود دیتابیس نیز بیشتر می شود. برای مدیریت این لاگها می بایست از طریق بکاپ سرور نسبت تهیه بکاپ به صورت مستمر اقدام کنیم. پس از تهیه بکاپ لاگ ها به صورت اتومات حذف می شوند. اما اگر در سازمانی بکاپ سرور نداشته باشید ناگزیر به استفاده از این گزینه می باشید. پس از فعالسازی این گزینه سیستم پاکسازی لاگها به صورت اتومات انجام می شود. انجام این کار به هیچ وجه پیشنهاد نمی شود.
در تب Limit می توانید محدودیت فضا به ازای هر میل باکس را مشخص کنید. به صورت پیش فرض این مقدار حدود 2 گیگابایت می باشد. همچنین می توانید محدودیت را بردارید در این صورت محدودیت متناسب با فضای هارد دیسک شما می باشد.

نحوه ی کانفیگ کردن SPF Record در Exchange Server 2016

Posted on نوامبر 14, 2021نوامبر 14, 2021 by tilatel

در این مقاله قصد داریم تا شما را با نحوه ی کانفیگ کردن SPF Record در Exchange Server 2016 آشنا کنیم با ما همراه باشید:

SPF مخفف Sender Policy Framework به معنی چارچوب سیاست فرستنده می باشد. پس از ارسال ایمیل از یک ایمیل سرور و قبل از دریافت ایمیل توسط ایمیل سرور مقصد، سروری در اینترنت با نام Sender ID Framework مسئول بررسی اعتبار سرور ارسال کننده ایمیل می باشد.

یک SPF (Sender Policy Framework) Record لیست Mail Server هایی می باشد که مجاز هستند از طرف و به اسم دامنه سازمان شما به بقیه میل سرورها میل ارسال کنند.
این رکورد باعث کاهش فعالیت Spamming از طرف اسم دامنه سازمان شما می شود. یعنی هر میل سروری مجاز به استفاده از دامنه ما برای ارسال ایمیل نمی باشد.

SPF Record یکی از انواع رکوردهای DNS Server می باشد که معمولاً با پسوند txt در DNS Server ساخته می شود. اما ساخت SPF Record دارای اصولی می باشد که ما برای اطمینان از صحت ساخت آن می توانیم از طریق سایتهای معتبر در اینترنت نسبت یه ایجاد آن اقدام کنیم. یکی از معروف ترین سایتهای SPF Generator سایت www.spfwizard.net می باشد.

– برای ساخت SPF Record نام دامین مورد نظرمان را در قسمت Your Domain وارد می کنیم.
– فیلد بعدی (Allow servers listed as MX to send email for this domain) برای مشخص سازی این مطلب می باشد که آیا MX Record های ثبت شده در DNS Server اجازه ارسال ایمیل دارند یا خیر. در اکثر مواقع MX Record ها مسئول ارسال ایمیل نیز می باشند، اما شاید در شبکه ای IP مربوط به MX Record صرفاً برای دریافت ایمیل باشد و IP دیگری مسئول ارسال ایمیل باشد، پس بر اساس سیاست داخلی شبکه این گزینه را انتخاب می کنیم.
– فیلد بعدی : (Allow current IP address of the domain to send email for this domain) جهت مشخص کردن این مطلب می باشد که آیا A Record های تعریف شده در DNS Server دامین، مجاز به ارسال ایمیل می باشند یا خیر. این مورد نیز کاملاً وابسته به نوع شبکه می باشد، ولی معمولاً A Record ها مربوط به هاستینگ وب سایت ما می باشد و در صورتی که ما ایمیل سرور داخلی داشته باشیم، A Record ها مجاز به ارسال ایمیل نمی باشند.
– فیلد بعد: (Allow any hostname ending in yourdomain.com to send email for this domain) جهت مشخص سازی این مطلب می باشد که آیا هر رکوردی با پسوند yourdomain.com برای مثال ftp.yourdomain.com مجاز به ارسال ایمیل از طریق این دامین می باشد یا خیر، که در اکثر مواقع جواب این فیلد خیر می باشد.
– در فیلد بعدی : (IP addresses in CIDR format that deliver or relay mail for this domain) می توانیم IP آدرس هایی که مجاز به ارسال ایمیل با دامین مورد نظر ما می باشند را تعیین کنیم. این آدرس IP میتواند یک تک IP و یا یک رنج IP باشد.
– در فیلد : (Add any other server hostname that may deliver or relay mail for this domain) می توانیم سایر سرورهایی که مجاز به ارسال ایمیل از طرف دامین اصلی ما می باشند را تعریف کنیم. این قسمت برای زمانی می باشد که شما بخواهید به یک دامین اجازه ارسال از چند سرور مختلف که برای شما می باشد را بدهید. برای مثال شما مالک چهار دامین مختلف می باشید که هر کدام به صورت مستقل امکان ارسال ایمیل را با MX Record های خودشان دارند اما می خواهید اگر با MX Record یکی دیگر از دامین هایتان نیز ارسال شد مشکلی پیش نیاید. این موضوع معمولاً به ندرت پیش می آید. در صورت نیاز می توانید NS های سایر دامین هایتان را در این قسمت وارد نمایید.
– فیلد : (Any domains that may deliver or relay mail for this domain) کاملاً مشابه با فیلد بالا می باشد با این تفاوت که در فیلد بالا NS های مجاز را تعریف می کنیم و در این فیلد Domain Name های مجاز را تعریف می کنیم.
– فیلد : (How strict should be the servers treating the emails?) میزان شدت سخت گیری SIDF را تعیین می کند. به این صورت که می توان میزان سخت گیری را به حداکثر رساند (Fail (Not (compliant will be rejected) که در این صورت اگر شرایط تعیین شده شما در SPF رکود Pass نشود ایمیل به مقصد نخواهد رسید و برگشت می خورد، یا میزان سخت گیری را در حال متوسط (SoftFail (Not compliant will be accpted but marked) قرار می دهیم که در این صورت ایمیل به مقصد می رسد اما به صورت اسپم به آدرس مقصد می رسد و یا سخت گیری را در حالت حداقل (Neutral (Mails will be probably accepted)) قرار می دهیم که در این صورت، در هر حالت ایمیل به مقصد می رسد. این مورد نیز به سیاست ایمیل سرور شما مربوط می شود اما از لحاظ منطقی بهتر است شرایط را در حداکثر سخت گیری قرار می دهیم.
همانطور که در طی ساخت SPF Record مشاهده نمودید، خروجی نهایی یک خط متن می باشد. متن نهایی را به صورت یک TXT Record در DNS Server ایجاد کنید.
نحوه ساخت SPF Record در DNS مایکروسافتی:
در کنسول DNS، Zone مورد نظر خود را انتخاب کنید و در قسمت رکورد ها کلیک راست و بر روی Create another Recordکلیک نمایید و text را انتخاب و Create Record بزنید.

در پنجره جدید در قسمت Text متن رکورد SPF خود را وارد نمایید و بر روی Ok کلیک نمایید.

و در انتها مشاهده خواهید کرد رکورد SPF شما ایجاد شده است.

چگونگی اضافه کردن reCAPTCHA به Outlook Web App

Posted on نوامبر 13, 2021نوامبر 13, 2021 by tilatel

یکی از مسائل مهم این روزها در فناوری اطلاعات بحث امنیت می باشد که تمامی ادمین های شبکه را درگیر خود نموده است و همیشه باید حداکثر تدابیر امنیتی را برای شبکه های تحت پشتیبانی خود در نظر بگیرند تا از تهدیدهای اینترنتی در امان بمانند. در این مقاله قصد داریم تا شما را با یکی از راه های امن نمودن ایمیل سرور آشنا کنیم با ما همراه باشید:

در این مقاله می خواهیم در مورد نحوه اضافه کردن قابلیت امنیتی Google reCAPTCHA به صفحه OWA در Exchange Server صحبت کنیم.
قبل از شروع کار بهتر است اطلاعاتی در مورد این سرویس داشته باشید طبق اطلاعاتی که در سایت ویکی پدیا (https://fa.wikipedia.org/wiki/%D8%B1%DB%8C%E2%80%8C%DA%A9%D9%BE%DA%86%D8%A7) درج شده است در واقع reCAPTCHA نسخه جدید و بهینه CAPTCHA می باشد که این قابلیت جهت تفکیک ربات از انسان هنگام دسترسی به یک وب پیج کمک می‌کند. در نتیجه از طریق این قابلیت مطمئن می شوید که یک انسان قصد دسترسی به سایت مورد نظر را دارد. این قابلیت توسط لویز فن آخن، بن مائورر، کالین مک میلن، دیوید ابراهام و مانوئل بلوم در دانشگاه کارنگی ملون در محوطه دانشکده پیتسبرگ توسعه داده شد و سپس در سال 2009 به مالکیت گوگل در آمد.
همانطور که می‌دانید یکی از راههای اتصال کاربران به Exchange Server از طریق وب یا همان OWA می باشد که به صورت امن و از طریق پورت 443 انجام می شود اما ماهیت وب آسیب پذیر می‌باشد و نیاز است از طریق راهکاری جانبی نسبت به امن سازی بیشتر آن اقدامات لازم را انجام دهیم. یکی از این راهکارها اضافه کردن قابلیت Google reCAPTCHA می باشد. از طریق Google reCAPTCHA ابتدا مطمئن می‌شویم که کلاینتی که قصد لاگین به OWA دارید یک کاربر می‌باشد یا یک روبات. سپس از طریق نام کاربری و رمز عبور که برای کاربر نهایی در نظر گرفته شده است امکان لاگین و دسترسی به میل باکس فراهم می‌شود.
مراحل انجام کار به این صورت می‌باشد که ابتدا از طریق اکانت گوگل نسبت به ایجاد و رجیستر کردن یک سرویس reCAPTCHA برای دامین مورد نظر اقدام کنید و سپس از طریق کدهای اعلامی و تنظیمات لازم در Exchange Server امکان استفاده از این سرویس امنیتی در OWA فراهم شود.
مراحل انجام کار به صورت زیر می‌باشد:
1- ابتدا با سرچ کردن کلید واژه google recaptcha به صفحه https://www.google.com/recaptcha/intro/v3.html وارد شوید.
2- سپس با نام کاربری اکانت خود در Gmail لاگین کرده و نسبت به رجیستر دامین و اخذ کد برای reCAPTCHA اقدام کنید.

3- سپس با کلیک بر روی SUBMIT کد رجیستری مورد نیاز را دریافت کنید.

همانطور که مشاهده نمودید دریافت کد رجیستری reCAPTCHA به سادگی و در چند مرحله ساده انجام شد. مرحله بعدی مربوط به استفاده از این کدها در OWA می‌باشد.

در نظر داشته باشید که کل این فرآیند برنامه نویسی می‌باشد و برای متخصصین برنامه نویسی بسیار ساده می‌باشد اما شاید برای ادمینهای شبکه کاری سخت و پیچیده باشد. اگر مراحل این مقاله را به همین ترتیب و با دقت انجام دهید بدون نیاز به دانش برنامه نویسی به سادگی می‌توانید از قابلیت امنیتی Google reCAPTCHA در Exchange Server خود استفاده کنید.
4- به سروری که در آن Exchange Server را نصب نموده اید لاگین کنید و وارد مسیر زیر شوید:

C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth

از طریق notepad یک فایل با نام recaptcha.aspx ایجاد کنید و آن را باز کنید. محتویات زیر را عیناً در این فایل جایگذاری کنید.

<% @ Page AspCompat=True Language = “VB” %>
<%
‘ Put your own private key in the next line
Dim strPrivateKey As String = “SECRET KEY”
Dim strResponse = Request(“response”)
Dim objWinHTTP As Object
objWinHTTP = Server.CreateObject(“WinHTTP.WinHTTPRequest.5.1”)
objWinHTTP.Open(“POST”, “https://www.google.com/recaptcha/api/siteverify”, False)
objWinHTTP.SetRequestHeader(“Content-type”, “application/x-www-form-urlencoded”)
Dim strData As String = “secret=” & strPrivateKey & _
“&response=” & strResponse
objWinHTTP.Send(strData)
Dim strResponseText = objWinHTTP.ResponseText
Response.Write(strResponseText)
%>

Secret Key دریافت شده گوگل را به جای “SECRET KEY” جایگذاری کنید. فایل را ذخیره نموده و ببندید.
5- در همین مسیر فایلی به نام logon.aspx وجود دارد، ابتدا یک کپی از این فایل تهیه نمایید تا در صورت بروز مشکل امکان بازگشت به حالت فعلی را داشته باشید. سپس فایل را طریق نرم افزار notepad باز نموده و تغییرات زیر را در آن اعمال نمائید.
– از طریق میانبر CTRL-F نسبت به جستجوی پاراگراف زیر اقدام نمایید:

form action=”/owa/auth.owa” method=”POST” name=”logonForm”

سپس این محتوای داخل action را حذف نمایید، نتیجه نهایی می بایست به صورت زیر شود:

form action=” ” method=”POST” name=”logonForm”

– مجددا از طریق میانبر CTRL-F پاراگراف زیر را جستجو نمائید:

<div><input id=”passwordText”

– بلافاصله در خط بعدی محتوای زیر را اضافه نمائید:

<tr>
<td>
<script type=”text/j-avascript”>
function myClkLgn()
{
var oReq = new XMLHttpRequest();
var sResponse = document.getElementById(“g-recaptcha-response”).value;
var sData = “response=” + sResponse;
oReq.open(“GET”, “/owa/auth/recaptcha.aspx?” + sData, false);
oReq.send(sData);
if (oReq.responseText.indexOf(“true”) != -1)
{
document.forms[0].action = “/owa/auth.owa”;
clkLgn();
}
else
{
alert(“کد تأیید تکمیل نشده است” + “\n” +”reCAPTCHA is not valid”);
}
}
</script>
<script src=”https://www.google.com/recaptcha/api.js” async defer></script>
<div class=”g-recaptcha” data-sitekey=”SITE KEY”></div>
</td>
</tr>

– Site Key دریافت شده از گوگل را جایگزین SITE KEY کنید.
– مجدداً از طریق میانبر CTRL-F پاراگراف زیر را جستجو کنید:

به جای واژه clkLgn واژه myClkLgn را جایگزین کنید. نتیجه نهایی می بایست به صورت زیر شود:

اکنون بدون اینکه نیاز به ری استارت سرور یا سرویس IIS داشته باشید قسمت گرافیکی مربوط به سرویس Google reCAPTCHA را در OWA خود مشاهده می‌کنید.
در نظر داشته باشید برای اینکه این قابلیت به درستی انجام شود سرور ایمیل باید به URL زیر دسترسی داشته باشد:

https://www.google.com/recaptcha/api.js

اگر اینترنت ایمیل سرور را از طریق فایروال محدود نموده‌اید حتما دسترسی به این URL را برای سرور فراهم کنید.

چگونگی بکاپ گیری از Exchange Server 2016

Posted on نوامبر 11, 2021 by tilatel

در این مقاله قصد داریم روش گرفتن بکاپ از Exchange Server را برای شما توضیح دهیم با ما همراه باشید:

بکاپ گیری از سرورها امروزه یکی از الزامات هر شبکه ای به شمار می رود که در صورت هرگونه رخداد غیر مترقبه می تواند کمک شایانی به واحد IT نمایید.
نرم افزار Veeam Backup & Replication یکی از بهترین برنامه های بکاپ گیری از سرورهای مجازی می باشد.

در زیر برخی از امکانات Veeam در بکاپ گیری از Exchange لیست شده است:
• Restore کردن کل سرور Exchange
• جستجو و انتخاب Item های مختلف برای Restore شامل ایمیل ها، Mailbox ها، Contact ها و …)
• خروجی گرفتن از Mailbox و Public Folder به عنوان Personal Folder Files با فرمت PST
• بازگردانی Database پاک یا خراب شده.

از قبل فرض شده که شما روش نصب و کانفیگ اولیه نرم افزار Veeam را انجام داده اید (مانند معرفی Repository، سرورهای مجازی و …).
حال میرویم سراغ ایجاد یک Job جدید در Veeam برای Exchange؛ مطابق شکل زیر مراحل را طی نمایید و در صفحه بعد سرور Exchange خود را انتخاب کنید.

در مرحله زیر Repository و تعداد Restore Point ها را انتخاب و بر روی Next کلیک کنید.

در مرحله زیر هر دو گزینه را انتخاب و یک Geust OS credentials برای VM اضافه و بر روی Next کلیک کنید.

و در مرحله زیر روزها و ساعت هایی که قصد تهیه بکاپ را دارید مشخص کنید و بر روی Apply و سپس Finish کلیک کنید.

حال سر ساعت و روز های مشخص شده عملیات بکاپ انجام خواهد شد.
در زیر به بررسی چگونگی ریکاوری کردن سرور بر اساس Application Exchange خواهیم پرداخت.
مطابق شکل زیر مراحل را طی نمایید و Restore Point خود را انتخاب کنید.

اکنون به مرحله هیچان انگیز نرم افزار Veeam میرسیم ، همانطور که در شکل زیر مشاهده می کنید، در سمت چپ، دیتابیس های مربوط به سرور Exchange برای شما نمایش داده می شود و در صورتی که بر روی شاخه هر دیتابیس کلیک نمایید لیستی از تمامی Mailbox ها برای شما به نمایش در خواهد آمد و به همین صورت به شکل درختی می توانید به کوچکترین Item ها در Exchange دسترسی پیدا کنید، هر Item را که قصد Restore یا Export دارید را انتخاب و از منوی بالا گزینه Restore یا Export را انتخاب کنید.

آشنایی پیش نیازهای Exchange Server 2019

Posted on نوامبر 10, 2021 by tilatel

در این مقاله قصد داریم تا شما را با پیش نیازهای این نرم افزار آشنا کنیم با ما همراه باشید:

سازگاری با نسخه های پیشین:

سازگاری Exchange 2019 با نسخه های قدیمی در جدول زیر شرح داده شده است:

پیش نیاز های مورد نیاز در شبکه
پیش نیاز ها و الزامات شبکه برای نصب Exchange 2019 Organization در جدول زیر شرح داده شده است:

معماری Directory Server:

نصب Active Directory بر روی سخت افزار 64-bit با یک ویندوز سرور 64-bit باعث افزایش عملکرد directory Service ها در Exchange 2019 خواهد شد.

نصب Exchange بر روی Active Directory
به دلایل امنیتی و کارایی، توصیه نمی شود که Exchange 2019 را بر روی Active Directory نصب کنید، Exchange 2019 را تنها بر روی Member Servers ها نصب نمایید.

سیستم عامل:

سیستم عامل های پشتیبانی شده برای نصب Exchange 2019 در جدول زیر شرح داده شده است:

نکته:
• نصب Exchange 2019 بر روی Window Server Core به صورت کامل پشتیبانی و توصیه می شود و ویژگی Desktop Experience دیگر جزء الزامات نیست.
• نصب Exchange 2019 بر روی Nano Server پشتیبانی نمی شود.

نسخه های پشتیبانی شده PowerShell در Exchange 2019
سرورهای Exchange 2019 از نسخه ای که در زمان انتشار ویندوز سرور قرار دارد پشتیبانی می کند، به هیچ وجه نسخه های Stand-Alone WMF or PowerShell را بر روی سرور Exchange نصب نکنید.
.NET Framework
توصیه می شود آخرین نسخه.NET Framework که توسط Exchange پشتیبانی می شود را نصب کنید.
.NET Framework هایی که در جدول زیر لیست نشده اند در هیچ نسخه ای از Exchange 2019 پشتیبانی نمی شوند، این شامل نسخه های جزئی و پچ در .NET می باشد.

نسخه های Outlook پشتیبانی شده
• Outlook 2019
• Outlook 2016
• Outlook 2016 for Mac
• Outlook 2013
• Outlook for Mac for Office 365

پکپارچگی با Lync/Skype
برای ادغام Lync Presence و Lync Messaging با Exchange Server به Lync Server 2013 Cumulative Update 10 یا بالاتر و همچنین برای ادغام Skype for Business presence و Instant Messaging با Exchange Server به Skype for Business Server Cumulative Update 7 به بالا احتیاج است.

آشنایی با هارد SATA و ویژگی های آن

Posted on نوامبر 4, 2021می 26, 2022 by tilatel

نوعی رابط برای هارد دیسک است. در حالی که SATA نام رابط است، معمولا برای توصیف نوع هارد دیسک استفاده می شود، به عنوان مثال: SATA 7.2K

هزینه کم و ظرفیت بالا درایوهای SATA باعث کم هزینه بودن هر گیگابایت می شود که باعث می شود آنها را برای کاربران خانگی یا ذخیره سازی داده ها و سرویس های پشتیبان ایده آل کنند.

امروزه رایج ترین نوع درایو SATA نوع 7.2K است اما درایورهای قدیمی تر 5.4K هستند. K به سرعت چرخشی هارد دیسک اشاره دارد، یعنی 7200 دور در دقیقه.

سرعت SATA

از لحاظ سرعت، بهترین اندازه گیری IOPS (ورودی خروجی ها در هر ثانیه) است که میزان داده ها را اندازه گیری می کند که میزان داده ای را که می توان از آن خواند یا نوشته شده به هارد دیسک را تعیین کرد.

درایو معمولی SATA 7.2K در حدود 80 IOPS عمل می کند. این نسبت به 120 IOPS برای هارد دیسک SAS 10K و 180 IOPS برای یک هارد دیسک SAS 15K مقایسه می شود. درایوهای حالت جامد (SSD) می توانند در محدوده بین 4،600 تا 75،000 IOPS بسته به نوع SSD کار کنند.

ظرفیت هارد دیسک SATA

ظرفیت هارد دیسک های SATA می توانند بین 500GB تا 8TB باشد. به طور معمول هر چند یک گزینه خوب برای هزینه و ظرفیت بین 1TB تا 3TB است.

قابلیت اطمینان SATA

هارد دیسک های SATA برای استفاده در کاربردهای پر کاربرد در نظر گرفته نمی شوند، زیرا سرعت و دسترسی بالا نگرانی های اصلی هستند. درایوهای SATA کارهای بزرگی برای کاربردهای کمتری مانند خانه یا ذخیره داده و تهیه نسخه پشتیبان میتواند باشد.

درایوهای SATA متوسط زمان بین شکست (MTBF) که به طور کلی پذیرفته شده است در حدود 700،000 ساعت است. که نسبت به حدود 1.2 میلیون ساعت برای درایو SAS و بیش از 2 میلیون ساعت درایوهای SSD است.

مصرف برق SATA

درایوهای SATA معمولا بین 4 تا 6 وات در حالت خاموش و بین 10 تا 12 وات در شرایط عملیاتی معمول مصرف می کنند.

اصلاحات SATA

SATA در 3 تغییر اصلی در زیر توضیح داده شده است.

SATA I

SATA 1.5Gb/s قبلا به عنوان SATA 1.5Gb/s شناخته شده بود و با سرعت 1.5Gb/s عمل می کرد و توانست تا 150MB خروجی پهنای باند داشته باشد.

SATA II

SATA 3Gb/s قبلا به عنوان SATA 3Gb/s شناخته شده بود، SATA II در 3Gb/s کار می کرد و می تواند توان خروجی پهنای باند تا 300MB/s را داشته باشد.

SATA III

SATA 6Gb/s قبلا به عنوان SATA 6Gb/s شناخته می شود، SATA III با سرعت 6 گیگابایت بر ثانیه عمل می کند و می تواند ظرفیت پهنای باند تا 600MB/s را داشته باشد و با SATA II سازگار است.

کابل های SATA

کابل های SATA می توانند تا یک متر طول داشته باشند. در یک طرف یک اتصال دهنده داده ای است که دارای 7 پین (3 زمین، 4 خط داده فعال) و انتهای دیگر قدرت اتصال با 15 پین فراهم می کند برق، زمین و قابلیت رانندگی درایو.

خلاصه هارد دیسک SATA چیست؟

درایوهای SATA قابل اعتماد، تکنولوژیی اثبات شده اند. آنها برای استفاده های از جمله کاربرد خانگی یا ذخیره سازی داده ها یا پشتیبان گیری مفید هستند. آنها برای پشتیبانی از برنامه های پرکاربرد و یا شرایطی که سرعت و عملکرد معیار اصلی هستند، مناسب نیستند. برای این درایوهای SAS یا SSD بهترین گزینه هستند.

آشنایی با استوریج های NAS و DAS و تفاوت میان آن دو

Posted on اکتبر 31, 2021اکتبر 31, 2021 by tilatel

Direct Attached Storage (DAS) وسیله ای است که به همان روش هارد اکسترنال به رایانه متصل می شود – می تواند ATA ، SATA ، SAS ، USB ، FireWire یا Thunderbolt باشد. هر واحد DAS از یک سیستم فایل استفاده می کند که یک کامپیوتر میزبان می تواند درایورها را برای آن فراهم کند. سیستم فایل DAS توسط سیستم عامل رایانه شخصی که DAS به آن متصل است تعریف و کنترل می شود .

DAS دقیقاً مانند هارد دیسک داخلی ، دسترسی مستقیم به دیسک یا دیسک های خود را از نظر بخش ها فراهم می کند. اولین و رایج ترین نمونه یک هارد اکسترنال معمولی است. نمونه های پیچیده تر دستگاه های Drobo 5D و LaCie هستند.

تا آنجا که بازیابی داده ها می رود ، تکنیک های بکار رفته در بازیابی اطلاعات DAS همان روش هایی است که برای بازیابی دیسک سخت به طور منظم استفاده می شود به این معنی که تقریباً همه نرم افزارهای بازیابی اطلاعات می توانند داده ها را از یک واحد DAS بازیابی کنند تا اینکه به طور کلی کار کند.

شبکه متصل ذخیره سازی

Network Attached Storage (NAS) وسیله ای است که از طریق شبکه به رایانه شخصی متصل می شود. چنین دستگاههایی دسترسی به داده ها را در سطح پرونده و نه در سطح بخش فراهم می کنند. NAS درخواستهایی مانند “این قطعه از آن پرونده را به من بده” را اجرا می کند. NAS دارای سیستم پرونده ای خاص خود است که نوع آن پس از پیکربندی NAS تنظیم می شود و به رایانه ای که NAS با آن کار می کند بستگی ندارد.

از آنجا که یک NAS دسترسی مستقیمی به بخش های خود ندارد ، هیچ نرم افزاری برای بازیابی اطلاعات نمی تواند با آن کار کند. برای بازیابی اطلاعات از NAS ، باید NAS را جدا کنید ، دیسک ها را بیرون بکشید و مستقیماً آنها را به رایانه شخصی وصل کنید. شما باید این کار را انجام دهید حتی اگر لازم باشد فقط چند فایل را حذف کنید.

بعضی اوقات از NAS برای ذخیره سازی پرونده های iSCSI استفاده می شود. این امر به ظاهر این قانون را نقض می کند که دسترسی مستقیم به بخش ها غیرممکن است. در واقع ، اینگونه نیست. در واقع ، iSCSI نوع دیگری از دسترسی به یک پرونده خاص را که در یک سیستم پرونده NAS ذخیره شده است ، فراهم می کند.

بهین ارتباط هوشمند

برچسب: سايت خدمات پشتيباني