در این پست نحوه پیکربندی و ایجاد اتصال SSH بدون Password  یا اصطلاحا Password-Less Login را بین دو سرور مرور خواهیم کرد.  در این روش اتصال از طریق SSH Key انجام خواهد گرفت. از مزیت های این روش که اغلب بین سرور های Trust  ایجاد می شود، می توان به راحتی تبادل فایل، پشتیبان گیری به صورت ریموت،  مدیریت سرور مقصد به صورت ریموت و …  اشاره کرد.

در محیطی این آموزش سرور مبدا و مقصد با مشخصات زیر می باشند.

سرور مبدا یا سروری که قرار است اتصال بدون Password  از طریق آن انجام شود با آدرس 172.17.105.29

سرور مقصد که قرار است اتصال بدون Password  به آن انجام پذیرد با آدرس 172.17.105.28

قدم اول :

 

اتصال به سرور مبدا و ایجاد یک جفت کلید عمومی از طریق دستور زیر، در اینجا من از نام کاربری root  بین دو سرور استفاده میکنم و در صورت تمایل میتوانید از نام های کاربری دیگری غیر از root  هم استفاده کنید.

[root@hamed-lab ~]# ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa): 
Created directory '/root/.ssh'.
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
0e:74:10:1c:b5:08:59:fb:e0:eb:7b:8a:d6:dd:34:6b root@hamed-lab
The key's randomart image is:
+--[ RSA 2048]----+
|    .+=+.        |
|    ...+ .       |
|      = o        |
|     o +         |
|      o S        |
|       +  o      |
|     ....o o     |
|    .o. o E      |
|   .. ++ .       |
+-----------------+

قدم دوم:

ایجاد دایکتوری ای با نام .ssh در Home Directory  کاربر، در سرور مقصد که در اینجا ما این عمل را از طریق SSH و از سرور مبدا انجام می دهیم.

[root@hamed-lab ~]# ssh root@172.17.105.28 mkdir -p .ssh
root@172.17.105.28's password: 

 

قدم سوم

محتویات فایل id_rsa.pub که در مرحله اول ایجاد شده است باید در سرور مقصد ودر فایل authorized_keys و در  مسیر ایجاد شده در مرحله قبل وارد شود.

[root@hamed-lab ~]# cat .ssh/id_rsa.pub | ssh root@172.17.105.28 'cat >> .ssh/authorized_keys'
root@172.17.105.28's password: 

قدم چهارم

بر اساس ورژن های مختلف SSH باید برای دایرکتوری و فایل ایجاد شده در سرور مقصد Permission  های لازم را ایجاد کرد.

[root@hamed-lab ~]# ssh root@172.17.105.28 "chmod 700 .ssh ; chmod 640 .ssh/authorized_keys"
root@172.17.105.28's password: 

مرحله پنجم

اتصال بدون Password

اگر مراحل بالا به درستی انجام شده، از این به بعد اتصال به سرور مقصد از طریق کاربر root  بدون Password  انجام خواهد شد.

[root@hamed-lab ~]# ssh root@172.17.105.28 
Last login: Mon Sep 18 21:57:13 2017 from 172.17.105.29
[root@localhost ~]# ifconfig 
eno16780032: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 172.17.105.28  netmask 255.255.255.128  broadcast 172.17.105.127
        inet6 fe80::250:56ff:feba:16f2  prefixlen 64  scopeid 0x20<link>
        ether 00:50:56:ba:16:f2  txqueuelen 1000  (Ethernet)
        RX packets 734175  bytes 42688092 (40.7 MiB)
        RX errors 0  dropped 245  overruns 0  frame 0
        TX packets 4779  bytes 790935 (772.3 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 0  (Local Loopback)
        RX packets 10  bytes 964 (964.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 10  bytes 964 (964.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

امیدوارم مفید واقع شده باشد.

آموزش نصب و راه اندازی سرویس VSFTP در CentOS

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

FTP چیست:

FTP پروتکلی است که با هدف انتقال فایل در بستر شبکه ایجاد شده است و برای کاربران امکان اتصال و انتقال فایل از کلاینت به سرور را فراهم می نماید.

این پروتکل یکی از رایج ترین و ساده ترین پروتکل های مورد استفاده در شیکه برای انتقال فایل می باشد ولی به دلیل اینکه در تبادل اطلاعات از رمزنگاری استفاده نمیکند دارای امینت بسیار پائین است در نتیجه مورد هدف Exploit های بسیاری است.

vsftp چیست؟:

vsftp یکی از سرویس های ارائه FTP است که مخفف کلمات Very Secure File Transfer Protocol  میباشد. این سرویس به علت امنیتی که در عین سادگی پیکربندی فراهم میکند بسیار مورد توجه قرار گرفته است و به صورت گسترده نیز در حال استفاده است. برخی از امکانات این سرویس به شرح زیر است:

• • امکان استفاده از virtual IP
  • پشتیبانی از virtual user
  • قابلیت کار به صورت Standalone یا تحت نظر inetd
  • فراهم بودن ایجاد محدودیت در پهنای باند
  • پشتیبانی از IPv6
  • رمز نگاری اطلاعات از طریق ssl

نصب و راه اندازی vsftp:

در این آموزش از سیستم عامل CentOS به عنوان سرور استفاده شده است. پکیج مربوط به این سرویس vsftpd نام دارد و در repository های پیش فرض این سیستم عامل قرار دارد.

با استفاده از yum پیکیج vsftpd  را نصب می نماییم.

yum –y install vsftpd

بعد دانلود و نصب پیکیج های مورد نیاز، می بایست سرویس را start  و  enable  کرده تا سرویس در هر بار بوت به صورت اتوماتیک اجرا گردد.

systemctl enable vsftpd 
systemctl start vsftpd

حال برای این که امکان سرویس دهی از طریق پروتکل ftp  به سیستم های داخل شبکه فراهم شود، نیاز است رول های مربوطه در firewalld  به صورت دائمی اضافه گردند.  در غیر این صورت فایروال اتصال کاربران از طریق این پروتکل را به صورت پیش فرض نمی دهد.

firewall-cmd --zone=public --permanent --add-port=21/tcp
firewall-cmd  --zone=public --permanent --add-service=ftp
firewall-cmd –reload

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

پارامترهای فایل پیکربندی:

سرویس vsftp نیز همانند اکثر سرویس های لینوکسی پارامتر های پیکربندی را از قایل پیکربندی آن و  درمسیر    /etc/vsftpd/vsftpd.conf مقدار دهی خواهد کرد. برخی از پارامتر های مورد استفاده در این سرویس به همراه توضیحی مختصر از آنها به شرح جدول زیر می باشد.

 

نکته: در خصوص گزینه message_file باید توجه داشت که این فایل باید hidden  باشد و در دایرکتوری ای که قصد نمایش آن را به کاربر داریم وجود داشته باشد. به عنوان نمونه با قرار دادن مقدار این پارامتر به صورت زیر  و قرار دادن فایل warning در home  کاربر می بایست پیغام داخل این فایل در هنگام ورود  به کاربر نمایش داده شود.

message_file=.warning

در نهایت با توجه به این که در این آموزش قصد داریم تا امکان استفاده از ftp را برای کاربران local فراهم کنیم و هر کاربر نیز در home  خود  jail شود،  فایل config نهایی به صورت زیر خواهد بود.

پس از ذخیره کردن تنظیمات، سرویس را مجددا راه اندازی میکنیم.

با توجه به این که ما در این آموزش از chroot استفاده کرده ایم نیاز است تا selinux  نیز در این خصوص پیکربندی شود. در غیر این صورت در هنگام وررود با پیغام زیر مواجه خواهید شد.

setsebool -P ftpd_full_access on

تست عملکرد:

پس از انجام تنظیمات، اتصال از طرق ftp به سرور را تست و بررسی میکنیم.

همانطور که مشاهده می شود، اتصال به سرور موفق بود. حال با توجه به این که tcp_wrapper  نیز در تنظیمات vsftp فعال شده بود، تست دیگر را با معرفی هاست و سرویس در فایل های /etc/hosts.allow و /etc/hosts.deny انجام می دهیم.

ابتدای به امر در فایل /etc/hosts.allow امکان استفاده از سرویس vsftpd را تنها برای Localhost فراهم کرده و سپس در /etc/hosts.deny سایر هاست ها را از استفاده از این سرویس منع میکنیم. محتویات فایل های اشاره شده به صورت زیر خواهد بود.

ابتدا به صورت local  اتصال را بررسی می نمائیم. همانطور که در تصویر زیر مشاهده مینمائید این اتصال با موفقیت انجام شد.

حال از کلاینت خود و از طریق شبکه اتصال را بررسی میکنم. با توجه به توضیحات بالا و پیکربندی انجام شده کاربر امکان اتصال به سرویس را نخواهد داشت.

توضیح نهایی این که تا این جای کار کاربران local امکان اتصال حواهند داشت، در صورتی  قصد داشته باشیم تا تعداد محدودی از کاربران مجاز به ورود و استفاده از سرویس باشند، می بایست  از userlist  استفاده کنیم و  تنها نام کاربری کاربران مجاز را در آن معرفی نماییم.

نتیجه گیری:

همانطور که اشاره شد، پروتکل های مختلفی برای به اشتراک گزاری فایل و انتقال فایل وجود دارد که FTP یکی از قدیمی ترین، ساده ترین آن ها است که گستردگی استفاده زیادی نیز دارد.

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

 

 

systemd

systemd یک System Manager  می باشد که در ابتدای بوت شدن سیستم پردازش آن شروع می شود و به عنوان parent  سایر process ها شناخته می شود و به عنوان جایگزینی برای init معرفی شده است.

init چیست؟

init  یا SysVinit در اصل یک daemon process یا پکیج مدیریت سرویس است  که به محض روشن شدن کامپیوتر تا زمان خاموش شدن آن فعالیت می کند. در واقع init اولین پردازشی است که پس از بوت شدن  سیستم شروع به فعالیت می کند و به عنوان والد (parent) تمام پردازش ها محسوب می شود و همیشه دارای PID برابر با ۱ می باشد.

اگر به هر دلیلی daemon مربوط به init  نتواند شروع به کار کند, هیچ پردازش یا پروسس دیگری نمی تواند شروع به کار نماید. در این صورت سیستم وارد شرایطی شده است که به آن kernel panic می گویند.

با توجه به نیاز های مختلف جایگزین هایی برای هدف  ایجاد شد که برخی از آنها به daemon process  اصلی برخی از توزیع ها در آمد. مانند ‌Upstart  که در Ubuntu پیاده سازی گردید (تا نسخه ۱۶.۰۴)  یا systemd  که در برخی از توزیع ها مانند Fedora, Open SuSE, CentOS و … پیاده سازی گردیده اند.

systemd چیست؟

systemd همانند init  یک System Manager  یا پکیج مدیریت سرویس  می باشد که در ابتدای بوت شدم سیستم پردازش آن شروع می شود و به عنوان parent  سایر process  ها با PID=1  فعالیت خواهد کرد. systemd برای رفع برخی نواقص init  طراحی و پیاده سازی شده است به عنوان نمونه شروع process  ها به صورت همزمان و موازی در زمان بوت شدن سیستم که علاوه بر کاهش زمان بوت شدن سیستم عامل, استفاده از منابع پردازشی را نیز کاهش می دهد.

به عنوان نمونه init  به صورت سریالی عمل میکند. به این معنی که یک وظیفه تنها در زمانی شروع میشود که وظیفه قبلی با موفقیت انجام شده و در Memory نیز load  شده باشد که در زمان بوت شدن سیستم عامل باعث افزایش زمان بوت شدن می گردید. لازم به ذکراست که systemd  با هدف افزایش سرعت بوت شدن ایجاد نشده است اما برای این که کارها به صورت منظم انجام شود, نیاز بود تا هر گونه delay یا تاخیر غیر ضروری حذف گردد. که اجرای موازی process  ها و رعایت dependency  از مواردی بود که به کاهش این تاخیر ها کمک کردند.

نمونه ای از رعایت dependency این است که به صورت مثال سرویس هایی که در ابتدای شروع به پردازش نیاز به running بودن سرویس network دارند میتوانند پس از شروع به کار سرویس network به صورت همزمان و موازی شروع به کار نمایند. که این کار در init همانطور که گفته شد به صورت سریالی انجام می پذیرد.

 

ویژگی های systemd

برخی از ویژگی هامانند کارآمی بیشتر نسبت به init  و یا ساده تر شدن پروسه بوت و بهبود API  و… باعث شد تا systemd  محبوبیت بیشتری پیدا کند و رفته رفته جای خود را در توزیع های مختلف باز بکند. در زیر شرح کامل ویژگی های systemd  آورده شده است.

1. طراحی بهتر و کارآمد
2. ساده شدن پروسه بوت شدن
3. اجرای پروسس ها به صورت همزمان و موازی در هنگام بوت
4. بهتر شدن API
5. امکان حذف Component های اختیاری
6. راه اندازی سرویس ها بر اساس تنظیمات نوشته شده در فایل کانفیگ (راه اندازی سرویس ها در init  به وسیله سلسله دستوراتی از طریق شل اسکریپت انجام میگیرد.)
7. زمان بندی کارها
8. لاگ ها توسط  journald ذخیره سازی می شوند.
9. امکان انتخاب systemd برای ثبت وقایع سیستمی همانند sysog
10. ذخیره سازی لاگ ها به صورت باینری
11. کنترل ورود و خروج کاربران به وسیله systemd-logind

نطقه ضعف systemd عدم تطابق با  POSIX است.

systemd در برخی از توزیع های لینوکس:

مقایسه systemd و init

Systemd برای فعالیت از مجموعه ای از پکیج ها استفاده می کند برخی از این پکیج ها و وظایف آنها به شرح زیر است.

journald

daemon است که وظیفه جمع آوری لاگ اتفاقات سیستمی و ذخیره سازی آنها به صورت باینری را بر عهده دارد. البته ادمین سیستم این امکان را دارد که مشخص کند لاگ ها توسط این daemon انجام شود یا توسط syslog-ng یا rsyslog

logind

وظیفه مدیریت ورود و  خروج واتصالات کاربران را بر عهده دارد و امکان multi session  را برای کاربران را فراهم می آورد و در واقع جایگزینی است برای Consolekit که توسعه آن متوقف شده است.

networkd

وظیفه handle  کردن پیکربندی کارت های شبکه را بر عهده دارد.در اوایل این daemon  تنها می توانست به صورت استاتیک به کارت های شبکه IP دهد و برخی از پیکربندی های اولیه ‌Bridging  را انجام دهد که از سال ۲۰۱۴ امکان DHCP سرور برای IPv4 و پشتیبانی از VXLAN به آن اضافه شده است.

tmpfiles

ابزاری است که وظیفه ایجاد و حذف فایل ها و دایرکتوری های موقت (Temp) را بر عهده دارد و به صورت معمول در شروع به کار سیستم عامل فعال شده و در بازه های مشخص شده نیز عمل می کند.

timedated

وظیفه کنترل تنظیمات مربوط به زمان را بر عهده دارد. تنظیماتی مانند زمان سیستم, time zone و انتخاب زمان به UTC و زمان محلی (Local Time Zone) را بر عهده این daemon  است.

udevd

udev  نقش یک device manager  را برای کرنل ایفا میکند و وظیفه آن handle کردن دایرکتوری /dev و تمام فعالیت های مرتبط با user space را در هنگام حذف یا اضافه device  جدید را بر عهده دارد.

libudev

یک استاندارد library برای استفاده از udev است که به برنامه های third-party اجازه میدهد تا منابع udev را query  کنند.

Systemd-boot

boot Manager است که در systemd تعبیه شده است که سابقا با نام gummiboot شناخته می شده است.

تفاوت init و Systemd در یک نگاه

برای آشنایی با نحوه ایجاد سرویس در systemd میتوانید با ما در این وبسایت همراه باشید.

 

NFS چیست:

NFS مخفف کلمات Network File System  و معرفی پروتکلی برای به اشتراک گزاری دایرکتوری بین سرور های لینوکسی است. از طریق این پروتکل میتوان یک دایرکتوری را در بستر شبکه با سرور یا کلاینتی دیگر به اشتراک گذاشت به شکلی که گویی از دیسک لوکال خود در حال استفاده است. از این پروتکل تاکنون چهار نسخته ارائه شده است که آخرین آن NFSv4 می باشد. خصوصیات و معرفی ورژن های مختلف این پروتکل رو میتوانید از اینجا مطالعه کنید.

این سرویس به صورت سرور / کلانت فعالیت می کند و از طریق آن میتواند Storage مرکزی ای ایجاد کرد. همچنین میتوان آن را از طریق acl در ورژن جدید آن نیز ایمن تر کرد.

 

راه اندازی NFS server:

در این مستند راه اندازی سرویس NFS روی centos 7  و با هدف اشتراک گزاری یک دایرکتوری بین دو سرور با قابلیت read/write  همزمان بر روی آنها توضیح داده خواهد شد

در این آموزش از دو سیستم در محیطی تستی و با مشخصات زیر استفاده شده است.

Server1:

CentOS Linux release 7.4.1708 (Core)

IP: 192.168.200.200

Server2:

CentOS Linux release 7.4.1708 (Core)

IP: 192.168.200.201

ماشین Server1 در این مستند به عنوان NFS Server  و server  دوم به عنوان NFS Client  فعالیت خواهند کرد.

برای نصب NFS در هر دو ماشین از دستور زیر استفاده میکنیم تا پکیج مربوطه به همراه Dependency  های آن نصب گردد.

Server1~]#  yum –y install nfs-utils

بعد از نصب،  در سرور اول،  دایرکتوری ای که قصد Share کردن آن را داریم را ایجاد میکنیم  و owner  دایرکتوری را به همراه پرمیژن ها آن مشخص میکنیم .

Server1~]#  mkdir -p /share/nfs

Server1~]#  chmod –R 755 /share/nfs

Server1~]#  chown nfsnobody:nfsnobody /share/nfs

سپس سرویس های مربوطه  را از طریق دستور زیر فعال می کنیم تا در هر بار  بوت شدن سیستم عامل، سرویس به صورت اتوماتیک شروع به کار نماید.

Server1~]#  systemctl enable rpcbind

Server1~]#  systemctl enable nfs-server

Server1~]# systemctl enable nfs-lock

Server1~]# systemctl enable nfs-idmap

یا به صورت کلی در یک دستور به صورت زیر

Server1~]# systemctl enable rpcbind nfs-server nfs-lock nfs-idmap

حال سرویس های مربوطه را به صورت زیر start  میکنیم.

Server1~]#  systemctl enable rpcbind

Server1~]#  systemctl enable nfs-server

Server1~]# systemctl enable nfs-lock

Server1~]# systemctl enable nfs-idmap

یا مانند بالا به صورت کلی و با یک دستور:

Server1~]# systemctl start  rpcbind  nfs-server nfs-lock nfs-idmap

معرفی سرویس ها:

 

• rpcbind:وظیفه mapping سرویس  را به پورت آن بر عهده دارد. سرویس RPC به هر برنامه یک آیدی اختصاص میدهد  که به آن program ID گفته می شود این اطلاعات در فایل /etc/rpc نگه داری میشود. این سرویس مشخص می کند که هر program id از چه پورتی برای برقراری ارتباط میتواند استفاده کند. هنگامی که کلاینتی درخواستی مبنی بر اتصال ایجاد می نماید، این سرویس پورت مربوطه را مشخص کرده، سپس کاربر را به سمت آن هدایت میکند در نتیجه امکان ارتباط و communicate بین سرویس و کلاینت مستلزم فعال بودن این سرویس می باشد که می بایست قبل از باقی سرویس ها شروع به کار نماید.

همانطور که در شکل زیر مشاهده می کنیم، به سرویس NFS آیدی ای برابر با 100003 اختصاص داده شده است.

حال با دستور rpcinfo –p میتوانیم ببینیم که این program id به چه پورتی map شده است.

همانطور که در شکل بالا مشخص است، nfs در ورژه های 3 و 4  بر روی پورت 2049 udp و tcp فعالیت میکند.

• nfs-idmap: وظیفه mapping بین username و Group  به  UID و GID را بر عهده دارد.
• nfs-lock: عملیات locking بر روی فایل های NFS را بر عهده دارد. در صورتی که کلانتی درخواست locking  برای فایلی را به سرور ارسال نماید، این سرویس وظیفه مدیریت این در خواست را بر عهده دارد. به عنوان مثال در صورت درخواست کلاینت به صورت پیشفرض به مدت 15 ثانیه بر روی فایل عملیات locking  را انجام میدهد.

بعد از شروع به کار سرویس ها،  دایکتوری ای را که ایجاد کرده ایم را به صورت زیر در فایل /etc/export معرفی میکنیم.

/share/nfs      192.168.200.201(rw,sync,no_root_squash,no_all_squash)

پارامتر های پیکربندی:

برخی از پارامتر های مورد استفاده در فایل /etc/export به شرح زیر است:

• rw: مجوز هر دو عملیات خواندن و نوشتن بر روی فایل سیستم را فراهم میکند.به صورت پیشفرض هر عملیاتی که منجر به تغییر بر روی فایل سیستم شود، نادیده گرفته میشود، همانند رفتاری که در تنظیم ro در پیش گرفته میشود.
• async: این گزینه این امکان را فراهم میکند تا به درخواست های تغییر بر روی دیسک قبل از این که واقعا تغییری اعمال شود، پاسخ داده شود. در واقع به کلاینت گفته می شود تغییرات مورد نظر بر روی دیسک اعمال شده است ولی در عمل اینطور نیست. این گزینه میتواند کارایی سیستم را بهبود ببخشد اما در کنار این بهبود ریسک از دست رفتن اطلاعات در صورت ری استارت شدن ناگهانی سرور یا به اصطلاح unclean restart ( مانند شرایط کرش کردن کرنل و قطع برق سرور و …) نیز وجود دارد.

• sync: درخواست تغییر روی دیسک تنها و تنها زمانی به کلاینت ارسال می شود که تغییرات بر روی دیسک اعمال یا commit  شده باشد. از ورژن ۱ به بعد این گزینه به عنوان تنظیمات پیش فرض مورد استفاده قرار میگیرد.
• wdelay:  در صورتی که سرور تشخیص دهد ممکن است عملیات نوشتن دیگری مرتبط با عملیات فعلی بر روی دیسک انجام شود، عملیات نوشتن بر روی دیسک را با تاخیر انجام خواهد داد. این کار باعث میشود تا در یک عملیات نوشتن چندین درخواست را در دیسک نوشت. در نتیجه تعداد دفعات رجوع به دیسک جهت نوشتن داده بر روی آن کمتر میشود که در نتیجه آن کارایی سرور نیز بهبود می یابد. اما در مواقعی که درخواست های زیاد و نامرتبطی به سرور ارسال شود فعال بودن این گزینه عملا میتواند باعث کاهش کارایی و عملکرد سرور شود. این گزینه از تنظیمات پیش فرض است که جهت غیر فعال سازی آن میتوان از no_wdelay استفاده کرد.
• root_squash: در صورتی که کاربر root قصد دسترسی به فایلی را در nfs ‌ سرور داشته باشد. رفتار سرور با این کاربر هماهنند کاربر root در سرور اصلی خواهد بود. با فعال بودن این گزینه. uid کاربر root در سرور به  uid دیگری که متعلق به کاربر nobody است map میشود. در نتیجه سطح دسترسی کاربر در سرور به حداقل دسترسی ممکن کاهش می باید. برای غیر فعال سازی این گزینه از گزینه no_root_squash استفاده میشود.
• all_squash : عملکردی همانند عملکرد  root_squash‌دارد با این تفاوت که این عملکرد برروی تمامی کاربرای تاثیر گزار خواهد بود. غیر فعال سازی عملکرد این گزینه با no_all_squash امکان پذیر است. فعال کردن این گزینه برای فایل سیستم هایی که در دسترس عموم قرار میگیرند مناسب است.
• anonuid and anongid: با استفاده از این دو گزینه میتوان درخواست های یک فایل سیستم یا دایرکتوری را که از سمت کاربر anonymous  وارد می شود را به یک uid و  gid به خصوص map کرد. به عنوان مثال تصور کنید نام کاریری ای به نام javad با uid ‌ برابر با ۵۰۵  داریم. با انتخاب گزینه anouid=505 تمامی درخواست ها بر روی فایل ها با uid  کاربر javad ثبت و انجام می شوند.

لازم به ذکر است در صورتی که بخواهیم اشتراک گزاری را به آدرس خاصی محدود نکنیم میتوانیم جای آدرس IP از “*” استفاده کنیم.

در نهایت تنظیمات مربوط به فایروال را برای باز کردن NFS و سرویس ها مورد استفاده آن را به صورت زیر انجام میدهیم.

firewall-cmd --permanent --zone=public --add-service=nfs

firewall-cmd --permanent --zone=public --add-service=mountd

firewall-cmd --permanent --zone=public --add-service=rpc-bind

firewall-cmd –reload

تنظیمات سمت کلایت ( Server2)

پس از نصب پکیج nfs-utils  بر روی سرور دوم، می بایست دایرکتوری را که قصد داریم جهت sharing  از آن استفاده کنیم را ایجاد کرده، سپس مسیر share  شده در سرور اول را با تایپ NFS   به آن  mount کنیم.

Server2~]#  mkdir /share

mount -t nfs 192.168.200.200:share/nfs /share

برای این که عملیات mount  کردن به صورت اتوماتیک در هر بار بوت شدن سیستم عامل انجام شود، خط زیر را در فایل /etc/fstab اضافه میکنیم.

192.168.200.200:share/nfs           /share   nfs defaults 0 0

و با دستور mount –a  سیستم را force میکنیم تا بر اساس فایل fstab  عملیات mount  کردن را مجددا انجام دهد.

حال با دستور df  یا mount  میتوان مطمئن شد که عملیات طبق انتظار انجام شده باشد.

در نهایت با mount شدن دایرکتوری nfs به دایرکتوری  share در سرور دوم،  جهت تست نیز فایلی در مسیر /share  ایجاد مینماییم.

همانطور که مشاهده میشود، به علت استفاده از no_root_squash فایل ایجاد شده با ownership کاربر root ایجاد شده است.

تست عملکرد:

حال جهت تستی دیگر این گزینه را به root_squash تغییر می دهیم و مجددا فایلی را ایجاد می نمائیم.

طبق توضیحات بالا همانطور که انتظار میرفت فایل جدید با ownership  کاربر nobody  ایجاد گردید.

به عنوان آخرین تست نیز میخواهیم تمامی فایل های ایجاد شده در مسیر /share با ownership کاربر hamed و گروه  nfsnobody ایجاد گردند. برای این کار فایل exports را به شکل زیر تغییر میدهیم.

در server1 کاربر hamed دارای uid  برابر با 1002  می باشد.

از آنجا که کاربری به نام hamed در سرور دوم وجود ندارد، در نتیجه امکان map کردن این uid  به نام کاربری برای سرور دوم مقدور نمی باشد و صرفا uid را نمایش میدهد. در صورتی که در server1  این نام کاربری وجود دارد لذا وضعیت فایل در سرور اول به صورت زیر می باشد.

نتیجه گیری:

در این مستند نحوه پیکربندی و پیاده سازی سرویس NFS مورد بررسی قرار گرفت. این سرویس از آن نظر که محدودیتی در توزیع سیستم عامل های لینوکسی در آن وجود ندارد میتواند  در شبکه به عنوان Central Storage  مورد استفاده و بهره برداری قرار گیرد.

استفاده از DVD  به عنوان Local Repository

 

نصب package  ها بر روی سرور هایی که فاقد اینترنت هستند و به Repository  های پیش فرض متصل نمی شوند و یا پکیج های خاص و یا حجم بالا یکی از معضلات  کاربران لینوکسی است. در این آموزش قصد داریم به صورت مرحله به مرحله نحوه استفاده از DVD به عنوان Local Repository  را بررسی کنیم.

 

• ابتدا ISO مورد نظر (Installation ISO) را به یک دایرکتوری Mount  میکنیم.

# mount -o loop /home/hamed/RHEL7.1.iso /mnt

 

در صورتی که از DVD استفاده میکنیم باید به شکل زیر مسیر DVD Rom  را وارد نمائیم.

# mount -o loop /dev/sr0  /mnt

 

در مسیر  /etc/repos.d  ایجاد میکنیم که باید با .repo  خاتمه یابد به عنوان مثال localrepo.repo و مقادیر زیر را در آن وارد خواهیم کرد.

Cat /etc/repos.d/localrepo.repo

 

[LocalRepo]

name=Local Repository
baseurl=file:///mnt
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7

 

حال نوبت پاک کردن کش yum  است که این کار نیز با دستور زیر انجام میگیرد.

# yum clean all

در نهایت با دستور yum install Package-name پکیج مورد نظر را نصب میکنیم. در اینجا به عنوان نمونه پکیج vsftpd  را نصب خواهیم کرد.

# yum install vsftpd

 

Loaded plugins: fastestmirror

LocalRepo                                                | 3.6 kB     00:00
(1/2): LocalRepo/group_gz                                  | 157 kB   00:00
(2/2): LocalRepo/primary_db                                | 2.7 MB   00:00
Determining fastest mirrors
Resolving Dependencies
--> Running transaction check
---> Package vsftpd.x86_64 0:3.0.2-9.el7 will be installed
--> Finished Dependency Resolution
 
Dependencies Resolved
 
================================================================================
Package         Arch            Version               Repository          Size
================================================================================
Installing:
vsftpd          x86_64          3.0.2-9.el7           LocalRepo          165 k
 
Transaction Summary
================================================================================
Install  1 Package
 
Total download size: 165 k
Installed size: 343 k
Is this ok [y/d/N]: y
Downloading packages:
warning: /cdrom/Packages/vsftpd-3.0.2-9.el7.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID f4a80eb5: NOKEY
Public key for vsftpd-3.0.2-9.el7.x86_64.rpm is not installed
Retrieving key from file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7
Importing GPG key 0xF4A80EB5:
Userid     : "CentOS-7 Key (CentOS 7 Official Signing Key) <security@centos.org>"
Fingerprint: 6341 ab27 53d7 8a78 a7c2 7bb1 24c6 a8a7 f4a8 0eb5
Package    : centos-release-7-0.1406.el7.centos.2.3.x86_64 (@anaconda)
From       : /etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7
Is this ok [y/N]: y
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
Installing : vsftpd-3.0.2-9.el7.x86_64                                    1/1
Verifying  : vsftpd-3.0.2-9.el7.x86_64                                    1/1
 
Installed:
vsftpd.x86_64 0:3.0.2-9.el7
 
Complete!

 

به یاد داشته باشید این روش فقط محدود به ماشینی خواهد بود که DVD  بر روی آن Mount  شده است.

در صورت مواجه با پیغام خطای “The remote session was disconnected because there are no Remote Desktop License Server available to provide a license Please Contact the server administrator” جهت رفع مشکل مراحل زیر را دنبال کنید.

یک روش ورود به سرور با استفاده از Admin Mode  می باشد یعنی
mstsc /admin

اما برای رفع کامل مشکل :

• با دستور regedit وارد محیط  Registry Editor  شوید و وارد مسیر زیر شوید.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\RCM\GracePeriod

• در قسمت Permissions مالکیت دایرکتوری GracePeriod  را به کاربر admin تغییر می دهید.

• به کاربر admin دسترسی کامل می دهیم تا امکان پاک کردن کلید L$RTMTIMEBOMB برایتان فراهم شود.

• در نهایت کلید L$RTMTIMEBOMB را پاک کرده و سیستم را مجددا راه اندازی می کنید.

با بوت مجدد، سیستم اقدام به ساخت دوباره این کلید با مقادیر جدید خواهد کرد و در نهایت مشکل حل خواهد شد.

معرفی iptables و firewalld:

سرویس های firewalld  و  iptables  هر دو فایروال های پیش فرض سیستم عامل ها و توزیع های مبتنی بر RedHat  میباشند و هر دو از بستر netfilter  استفاده میکنند. iptables نسخه ای سنتی و قدیمی تر از firewalld می باشد که در نسخه RHEL7 یا firewalld  جایگزین گردید. اما هر دو همچنان گستردگی استفاده خود را در دنیای لینوکس حفظ کرده اند.

هر دو ابزار با پشتیبانی IPv4 و IPv6  و پروتکل های TCP و UDP این امکان را فراهم میکنند تا امنیت سرور ها را در شبکه تا حد ممکن افزایش داده و از دسترسی های ناخواسته به سرور از طریق شبکه جلوگیری نمود.

نکته: در RHEL8 که اخیرا عرضه شده است، firewalld از بستر nftables به جای netfilter  استفاده میکند.

در ادامه مستند به نصب هر دو سرویس ، معرفی و پیکربندی هرکدام خواهیم پرداخت.

iptables:

همانطور که پیش تر اشاره شد، iptables بر اساس netfilter  پیاده سازی شده است و تا قبل از  RHEL7 به عنوان فایروال پیش فرض استفاده می شده است. ساختار iptables  بر اساس سه قسمت زیر است:

• Tables
• Chains
• Rules

Tables:

جداول iptables برای برای دسته بندی گروهی از chain ها که هر کدامل شامل یک یا چند rule  میباشند مورد استفاده قرار میگیرند.جداول پیش فرض شامل 5 جدول به شرح زیر هستند:

• filter: جدول پیشرفض مورد استفاده iptables است که برای فیلتر کردن پکت های ورودی و خروجی مورد استفاده قرار میگیرد.
• nat: جدولی است که به منظور اعمال تنظیمات NAT مورد استفاده قرار میگیرد.
• raw: در حالت عادی کرنل پکت ها را بر اساس State آنها ( یا جزئی از یک کانشن جدید هستند یا جزئی از یک کانکشن جاری و باز) بررسی میکند. این جدول این امکان را فراهم میکند تا با پکت ها قبل از این که کرنل بر اساس state  آنها اقدامی انجام دهد کارکرد.
• mangle: از طریق این جدول میتوان تغییراتی را در header پکت ها ایجاد نمود. به عنوان مثال تغییر مقدار TTL در پکت های دریافتی. این عمل تحت عنوان packet mark نیز شناخته می شود.
• security: برای مدیریت دسترسی از طریق متد MAC یا mandatory access control  می باشد.

Chains:

هر جدول شامل تعدادی chain هستند که هر کدام گروهی از rule  ها را در خود نگه میدارند. که میتوانند سیستمی باشند یا توسط کاربر ساخته شود.

سه chain  اصلی عبارتند از :

• INPUT: برای مدیریت rule های مربوط به پکت های ورودی به سیستم به کار میرود.
• OUTPUT: برای مدیریت rule های مربوط به پکت های خروجی از سیستم به کار میرود.
• FORWARD: برای مدیریت پکت هایی که از طریق route در سیستم forward می شوند به کار میرود.

Rules:

مجموعه ای از قوانین هستند که درون chain  ها نگه داری می شوند و شامل matches و targets است. بدین معنی که بخشی از rule  ها بیانگر شروطی  و بخشی دیگر بیانگر عملی است که در صورت صادق شدن آن شروط باید انجام شود.

هنگامی که پکتی بررسی می شود، از ابتدای این لیست به ترتیب rule  ها بررسی می شوند تاmatch  اتفاق افتد. در صورتی که پکتی با قوانین موجود در لیست همخوانی داشته باشد، بر اساس قواعد target با آن برخورد می شود.

به عنوان مثال:

اگر پکتی از آدرس 192.168.200.150 و از طریق پورت 5050 پروتکل TCP وارد شد آنگاه آن را drop  کن.

در مثال بالا بخش اگر همان match و بخش آنگاه همان target  خواهد بود.

Matches:

شرایطی است که برای پکت ها در نظر گرفته می شود. در صورتی که این شرایط برای پکت همخوانی داشته باشد، iptables پکت را بررسی و قواعد target را بر آن اعمال میکند.

برخی از match ها به شرح زیر می باشند.

• Source (-s): بیان گر مبدا پکت است که میتواند IP، رنج IP یا hostname باشد.
• destination (-d): بیانگر مقصد پکت است می تواند ، رنج IP یا hostname باشد.
• protocol (-p): بیانگر پروتکل پکت ورودی می باشد. مانند TCP یا UDP در صورتی که پروتکلی مشخص نشود، به صورت پیش فرض کلیه پروتکل های یا all در نظر گرفته می شود.
• –in-interface (-i): بیانگر اینترفیسی است که پکت از آن دریافت می شود.
• –out-interface (-o): بیانگر اینترفیسی است که پکت از آن خارج می شود.

Targets:

بیانگر اقدامی است که برای پکت در نظر گرفته می شود. target  با –j یا  –jump در انتهای دستور مشخص می شود. و چهار نوع دارد:

• :Accept اجازه دسترسی یا عبور پکت را میدهد.
• Drop: اجازه دسترسی به پکت یا عبور آن را نمیدهد و جوابی نیز به درخواست کننده نمی دهد.
• Queue: پکت های دریافتی را صف بندی میکند.
• Return: اگر rule دارای target برابر با return باشد، بررسی rule  های آن chain برای پکت متوقف می شود و پکت بر اساس رول های chain بالا دستی بررسی می شود ولی در صورتی که این rule در یکی از chain های اصلی وجود داشته باشد، پالیسی پیشرفض برای آن اعمال خواهد شد.

در صورتی که قصد اضافه کردن rule به chain  خاصی را داشته باشیم، از option با مقدار A- یا  append– و در صورتی که قصد حذف آن را داشته باشیم از option با مقدار D- یا delete– استفاده میکنیم.

دستورات iptables:

حال بعد از آشنایی با iptables، به بررسی چند دستور جهت آشنایی بیشتر با نحوه حذف و اضافه نمودن rule ها می پردازیم.

جهت بررسی و مشاهده لیست rule  های موجود از دستور زیر استفاده می کنیم.

iptables -L

در صورتی که صرفا لیست rule  های یک chain  به خصوص مد نظر باشد نیز در انتهای دستور اسم chain را به صورت زیر وارد میکنیم.

iptables –L INPUT

ایجاد Default policy:

در صورتی که پکتی با rule  های هیچ یک از chain  ها همخوانی نداشته باشد، نیاز است تا اقدامی به صورت پیش فرض برای آن در نظر گرفته شود. به عنوان نمونه اگر پکتی با هیچ rule خاصی همخوانی نداشت، آن را drop کنیم.دستور زیر سیاست پیش فرض را  قبول یا accept قرار خواهد داد.

iptables -t filter -P INPUT ACCEPT

و دستور زیر سیاست پیش فرض را بر رد درخواست با drop  قرار خواهد داد.

iptables -t filter -P INPUT DROP

ایجاد و حذف و جایگزین کردن  فیلتر:

در مثال های زیر با اضافه نمودن چند فیلتر به ساختار دستوری iptables  در حذف و اضافه کردن rule  ها خواهیم پرداخت.

 

• مثال1: تمامی ترافیک های ورودی از یک ادرس را به سرور مسدود نمائیم. از آنجا که پروتکلی در دستور زیر مشخص نشده است، کل ترافیک ورودی از 192.168.200.200 به مقصد 192.168.200.201 مسدود خواهد شد.

 

 

iptables -A INPUT -s 192.168.200.200 -d 192.168.200.201 -j DROP

• مثال2:  ترافیک SSH با دستور زیر فیلتر خواهد شد

iptables -A INPUT -s 192.168.200.200 -d 192.168.200.201 -p tcp --dport 22 -j DROP

• مثال3: ترافیک ورودی و خروجی TCP بر روی پورت 22 برای اینترفیس en33  مورد قبول واقع می شود

iptables -A INPUT -p tcp -i ens33 --dport 22 -j ACCEPT
iptables -A OUTPUT -p tcp -o ens33 --sport 22 -j ACCEPT

• مثال4: همانند مثال بالا با این تفاوت که چند پورت به صورت رنج معرفی گردیده است.

iptables -A INPUT -p tcp -i ens33 --dport 22:26  -j ACCEPT

در تمامی مثال های بالا rule هایی به chain های جدول filter  اضافه گردید. حال اگر قصد حذف rule وارد شده را داشته باشیم از همان دستور اما با option  برابر با D- استفاده می نمائیم.

iptables -D INPUT -s 192.168.200.200 -d 192.168.200.201 -j DROP

در صورتی که قصد داشته باشیم تمامی rule  های یک chain را حذف نمائیم از دستور زیر استفاه میکنیم.  در مثال زیر forward chain ازجدول filter تخلیه خواهد شد.

iptables  -F FORWARD

در صورتی که قصد داشته باشیم تمامی rule  های یک table  را پاک نمائیم از دستور زیر استفاده خواهد شد.

iptables  -t filter -F

نکته:

باید توجه داشت که ترتیب rule  های هر chain  مهم است. به عنوان نمونه در صورتی که خط اول INPUT برای پذیرش تمامی ترافیک ها و خط آخر برای عدم قبول ترافیک ICMP تنظیم شده باشد، ترافیک ورودی فقط با rule  اول match خواهد شد. لذا این ترتیب بندی ها میبایست در نظر گرفته شود.

برای مشاهده شماره و ترتیب rule  ها میتوان از دستور زیر استفاده کرد.

iptables -L --line-numbers

تا به اینجای کارrule اضافه شده در انتهای chain اضافه یا append  می شدند. در صورتی که قصد داشته باشیم rule در جای خاصی از جدول اضافه شود به جای –A از –I یا –insert استفاده مینمائیم. مانند دستور زیر

iptables -I INPUT 2 -s 192.168..199 -d 192.168.200.201 -p tcp --dport 22 -j DROP

تفاوت این دستور با دستورات بالا در این است که علاوه بر استفاده از option   -I مبنی بر insert در جدول، بعد از اسم chain نیز با مشخص کردن شماره خط،  همانند شکل بالاrule  اضافه شده را در خط دوم  اضافه نمودیم.

حال که شماره rule ها در chain را در اختیار داریم، میتوانیم همانند دستور زیر، rule  های مورد نظر را به id یا شماره آنها حذف نمود.

iptables -D INPUT 2

در نهایت اگر قصد داشته باشیم rule خاصی را replace  نماییم میتوانیم از option –R یا –replace استفاده وکنیم.

با دستور زیر rule  دوم از تصویر بالا را با rule  مورد نظر جایگزین می نمائیم.

iptables -R INPUT 2 -s 192.168.200.199 -d 192.168.200.201 -p tcp --dport 22 -j DROP

firewalld:

سرویس firewalld همانطور که پیشتر اشاره شد از نسخه RHEL7 جایگزین iptables   شد اما تا قبل از نسخه 8 از یک بستر استفاده میکردند. در firewalld از ابزاری به نام firewall-cmd برای ایجاد، جایگزینی و حذف rule  ها استفاده می شود. قبل از معرفی این ابزار برخی از مفاهیم firewalld را مورد بررسی قرار میدهیم.

Zones:

firewalld rule  ها را در مجموعه هایی به نام zone  مدیریت میکند. در واقع Zone  ها لیستی از rule  ها هستند که رفتار firewalld با ترافیک دریافتی اینترفیس ها از طریق آنها مشخص می شود.

Zone  های پیش فرض در firewalld به شرح زیر می باشند:

• drop: کمترین میزان اعتماد در این zone وجود دارد. در این zone تمامی ترافیک های دریافتی بدون ارسال هیچ پاسخی drop خواهند شد و فقط ترافیک های خروجی مجاز خواهند بود.
• block: همانند drop می باشد اما با خشونتی کمتر از آن. در این zone نیز تمامی ترافیک های ورودی drop می شوند اما در پاسخ به درخواست های ورودی، پیغامی مانند icmp-host-prohibited و یا icmp6-adm-prohibited  نیز ارسال می شود.
• public: به نوعی بیانگر شبکه های عمومی و سطح امنیت و اعتماد کم در آن هاست. ترافیک های ورودی در این zone تماما بسه نمی شوند می میتوان بر اساس نیاز به آنها اجازه دسترسی داد.
• external: در صورتی که قصد NAT کردن Private IP خود را داشته باشیم از این zone استفاده می نمائیم.
• internal:  ترافیک های دریافتی در این zone قابل اعتماد تر هستند و برخی سرویس ها در این zone نیز ممکن است در دسترس باشند.
• dmz: برای ایزوله کردن ترافیک از سایر آدرس هاش شبکه مورد استفاده قرار میگیرد و فقط ترافیک های خاصی امکان اتصال خواهند اشت.
• work: بیشتر ترافیک های ورودی در این zone قابل اعتماد هستند و تعدادی کمی از سرویس ها نیز در آن فعال و در دسترس هستند.
• home: برای محیط خانگی کاربرد دارد و تضور بر این است که تمام سیستم های شبکه اعتماد وجود دارد. سطح دسترسی از طریق سرویس های مختلف کمی بیشتر از home می باشد.
• trusted: به تمام ماشین های داخل شبکه اعتماد کامل وجود دارد و کمترین محدودیت در ترافیک ها را اعمال میکند.

دریافت اطلاعات Zone ها:

هر کارت شبکه به یک zone متصل خواهد شد و قوانین آن zone بر ترافیک های ورودی و خروجی آن اینترفیس حاکم خواهد بود. این امکان وجود دارد که در صورت نیاز zone  مورد نظر خود را ایجاد و خصوصیات آن را ویرایش کرده و سپس اینترفیسی را به آن متصل نمائیم.

Rule ها در firewalld یا به صورت آنی (immediate) و یا به صورت دائمی (permanent ) خواهند بود. در صورتی که تغییری در rule خاصی ایجاد شود یا rule جدیدی اضافه شود مادامی که به صورت دائمی ثبت نشوند موقت خواهند بود ودر بوت بعدی وجود نخواهند داشت.

اضافه کردن دائمی rule  و یا ایجاد تغییرات در آن ها با option –permanent صورت میپذیرد.

برای مشاهده لیست zone  ها و zone  پیش فرض از دو دستور زیر استفاده مینمائیم.

firewall-cmd get-zones
firewall-cmd --get-default-zone

در صورتی که قصد داشت هباشیم rule های هر zone  را مشاهده کنیم، میتوانیم از دستور زیر استفاده کنیم.

firewall-cmd --list-all  --zone=block

دستور بالا rule  های block zone  را به صورت زیر نمایش می دهد. در صورتی که اسم zone  مشخص نشود، rule های zone  پیشفرض نمایش داده می شود.

در صورتی که قصد داشته باشیم اینترفیسی را به zone خاصی متصل کنیم، از دستور زیر استفاد می نماییم.

firewall-cmd  --zone=trusted --change-interface=ens33

همانطور که در تصویر قابل مشاهده است، اینترفیس ens33 به trusted zone متصل گردید.

نکته مهم:

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

در صورتی که مدیریت تمامی اینترفیس ها از طریق یک zone فراهم باشد، میتوان zone پیش فرض را به zone مورد نظر و با دستور زیر تغییر داد.

firewall-cmd --set-default-zone=home

اضافه کردن rule برای سرویس ها:

در firewalld برخی از سرویس ها مهم و پر کاربرد به همراه اطلاعات آنها مانند پروتکل و پورت مورد استفاده آن ها به صورت از پیش تعریف شده وجود دارند. این امکان برای ما فراهم است تا تنظیمات و اضافه کردن سرویس ها را بر اساس این اطلاعات انجام دهیم.

اطلاعات مرتبط با سرویس ها با نام همان سرویس در مسیر /usr/lib/firewalld/services و در فرمت xml قابل مشاهده هستند. برای دریافت لیستی از سرویس ها میتوان از دستور زیر استفاده کرد.

firewall-cmd --get-services

به عنوان نمونه درصورتی که بخواهیم سرویس ssh  را به public zone اضافه نمیایم به صورت زیر عمل خواهیم کرد.

firewall-cmd --zone=public --add-service=ssh

و برای حذف سرویس نیز از remove-service– به صورت زیر استفاده خواهیم کرد.

firewall-cmd --zone=public  --remove-service=ssh

در صورتی که بخواهیم تغییرات به صورت دائمی ثبت شوند نیز میتوان مانند دستور زیر از –permanent  استفاه نمائیم.

firewall-cmd --zone=work --add-service=ssh  --permanent

در صورتی که سرویس مورد نظر در لیست سرویس های firewalld قرار نداشت میتوانیم با استفاده از فرمت xml یکی از سرویس ها سرویس مورد نظر خود را ایجاد نمائیم یا این که پورت مورد استفاده در سرویس مورد نظر را در firewalld و با دستور زیر اضافه نماییم.

با دستور زیر پورت 3550 بر روی پروتکل tcp به public zone  اضافه میگردد.

firewall-cmd --zone=public --add-port=3550/tcp

همچنین در صورتی که بخواهیم رنجی از پورت ها را در این zone  اضافه کنیم نیز میتوانیم به صورت زیر این کار را انجام دهیم.

firewall-cmd --zone=public --add-port=3720-3725/tcp

در firewalld ویژگی دیگری به نام rich rule  وجود دارد که از طریق آن میتوان با جزئیات بیشتر اقدام به محدود کردن ترافیک ها نمود. به عنوان نمونه، هدایت کردن ترافیک یک پورت بر روی پورتی دیگر، ایجاد Whitelist، محدود کردن تعداد درخواست های ورودی و…

نمونه ای از rich rule به صورت زیر می باشد که در آن rule مورد نظر بر روی IPv4 و از مبدا 192.168.200.199 و برای سرویس http  فعال خواهد شد و تعداد درخواست ها در ساعت را برابر با 100  درخواست در ساعت قرار داده و در صورتی که شرایط مطرح شده در rule برقرار شود، آن را در فایل messages ثبت می نماید. در آموزشی مجزا به تشریح rich rule ها خواهم پرداخت.

firewall-cmd --permanent --zone=public --add-rich-rule='rule family=ipv4 source address=192.168.200.199/32 service name=http log level=notice prefix="firewalld rich rule INFO: " limit value="100/h" accept'

نتیجه گیری:

در این مستند، به بررسی مفاهیم و ساختار دو فایروال مطرح و محبوب لینوکسی firewalld و iptables  پرداخته شد و سعی شد پس ایجاد آشنایی با دستورات هر دو سرویس، نحوه ایجاد، حذف و اضافه کردن rule ها و ایجاد یا رفع محدودیت در ترافیک های ورودی و خروجی را به صورت ابتدایی مورد بررسی قرار دهیم. حفظ امنیت سرور و جلوگیری از دسترسی ها و ایجاد ترافیک های ناخواسته در محیط های عملیاتی بسیار مهم و حیاتی می باشند در نتیجه آشنایی با این سرویس ها برای ایجاد امنیت هر چه بیشتربرای system administrator ها امری ضروری خواهد بود.

معرفی Syslog:

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

با اطلاعات کسب شده از این طریقمی توان  بررسی روند عملکرد یک نرم افزار ، عیب یابی سیستم (troubleshot)، ثبت وقایع امنیتی، مدیریت سیستم و تحلیل و آنالیز آن ها پرداخت.

Syslog دارای پیام هایی به شرح زیر می باشد.

• Facility
• Severity
• message

Facility:

کدی است که بیانگر نوع برنامه ای که در حال لاگ کردن پیام ها است. رفتار با facility  ها می تواند متفاوت نیز باشد.

لیستی از facility ها به شرح زیر می باشد:

 

Severity:

هر پیام ثبت شده در syslog  باید دارای یک severity level یا اولویت (priority) باشد تا درجه اهمیت پیام را مشخص نماید، serenity های موجود به شرح جدول زیر می باشند:

 

در syslog  هر چقدر که مثدار عددی severity بالاتر رود، درجه اهمیت و اولویت آن نیز بالاتر میرود.

Message:

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

خط زیر یک نمونه از پیام های ایجاد شده توسط kernel  می باشد.

Jan  5 08:55:20 server1 kernel: e1000: ens37 NIC Link is Down

Syslog میتواند به صورت لوکال یا به صورت متمرکز و مرکزی عمل کند. در حالتت لوکال، برنامه ها پیام های خود را به سرویس لوکال syslog  ارسال میکنند و این سرویس بر اساس تنظیماتی که برای آن در فایل /etc/syslog.conf  انجام شده است با پیام ها بر خورد میکند.

در روش متمرکز، سروری به عنوان سرور مرکزی لاگ وظیفه دریاف لاگ از سایر سرور ها و ذخیره سازی آنها را بر اساس تنظیمات انجام شده در /etc/syslog.conf  ذخیره می نماید. در سایر سرور ها که می بایست اگ خود را به سرور مرکزی ارسال نمایند، هر برنامه پیام خود را به syslog  لوکال خود ارسال میکند و پیام درفایت شده بر اساس تنظیمات انجام شده برای سرویس لوکال، به سمت سرور مرکزی هدایت خواهد شد.

تنظیمات syslog:

در فایل پیکربندی syslog  در هر دو مدل پیاده سازی، هر خط بیانگر یک یا چند selector وaction  می باشد. قسمت selector  بیانگر facility وpriority می باشد.

به عنوان مثال در خط زیر mail.info به عنوان selector و /var/log/mail.log بیانگر Action  مربوطه می باشد و بدین معنی میباشد که لاگ های دیافت شده از سرویس mail ( یا همان facility2)  و با severity برابر با 6 را در فایل /var/log/mail.log ذخیره نماید.

mail.info /var/log/mail.log

استفاده از “*” در Selector  به معنی any می باشد.  به عنوان نمونه در مثال های زیر نمونه اول بیانگر این است که لاگ های دریافت شده از mail با هر اولویتی که دریافت شد در مسیر اشاره شده ذحیره گردد. و یا در در مثال دوم عنوان میشود که از هر سرویسی اگر پیامی با درجه اولیت warning دریافت شد در فایل /var/log/warning.log ذخیر گردند.

mail.* /var/log/mail.log
*.warning /var/log/warning.log

نکته مهم:

در تعریف selector نقشی به نام modifier  نیز وجود دارد که با علامت “=”  یا “!” استفاده میشود. در صورتی که در تعریف selector و در قسمت severity از modifier استفاده نشود، به آن  priority  و priority های مهم تر از آن اشاره میکند، در واقع mail.warning  یعنی هر پیامی با اولویت warning و بالاتر از آن (err، crit، alert و emergency). در صورتی که بخواهیم صرفا یک severity خاص را معرفی کنیم میبایست از modifier  “=” را به صورت زیر استفاده کنیم.

mail.=notice /var/log/messages

در صورتی که بخواهیم پیام هایی با اولویت کمتر لاگ شوند از فرمت زیر استفاده میشود که به معنی هر لاگی غیر از لاگ هایی با اولیوت notice و بالاتر خواهد بود.

mail.!notice /var/log/messages

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

mail.!=debug /var/log/service.log

که بیان گر این است که هر پیامی با هر اولویتی به جز debug در مسیر اشاره شده لاگ شود.

در صورتی که قصد داشته باشیم تا پیام را به remote server  یا log server ارسال کنیم میتوانیم به صورت زیر Action را تعریف نمائیم.

*.emerg @logserver.testdomain.ir
*.emerg @172.16.15.14

در خط بالا علامت @ بیانگر ارسال بر روی پروتکل  UDP و @@  بیانگر ارسال از طریق پروتکل  TCP خواهد بود.

در centos  به صورت پیش فرض از rsyslog  جهت ثبت وقایع استفاده میشود. این سرویس به صورت modular  طراحی شده است و برخی از علکرد های آن را میتوان از طریق فراخوانی این ماژول ها استفاده کرد. برخی از این ماژول ها به صورت یش فرض در سرویس  شروع به کار سرویس load  می شوند و نیازی به فراخوانی آنها به صورت مستقل نیست. برخی از تنظیمات این سرویس به شرح زیر می باشند:

• Imuxsock: ماژولی است امکان لاگ کردن پیام ها به صورت لوکال را از طریق ابزاری مانند logger فراهم می سازد.
• Imjournal: ماژولی است که در سیستم عامل های مبتنی بر system امکان دسترسی سرویس به imjournal را فراهم میکند.
• ActionFileDefaultTemplate: مشخص کننده این است که به صورت پیشفرض از کدام template برای فرمت دهی لاگ ها استفاده کند. به صورت پیشفرض این سرویس از فرمت استاندارد استفاده میکند و در صورتی که قصد داشته باشیم از فرمت دلخواه استفاده کنیم می بایست ابتدا template متناسب را ایجاد کرده و به این پارامتر معرفی نمائیم.
• ActionFileEnableSync: دارای مقادیر on یا off می باشد و به این معنی می باشد که هر بار write های انجام شده را با فایل مربوطه در دیسک sync نماید. این عمل در تعداد عملیات های زیاد نوشتن میتواند کارایی سیستم را کاهش دهد.

Forwarding rules:

همانطور که پیش تر اشاره شد، میتوان لاگ ها را در سروری مرکزی نیز ذخیره نمود. برای این کار علاوه بر این که سرور مبدا می بایست پیام ها را به سرور مقصد ارسال کند، می بایست سرور مقصد برای پذیرش لاگ از سایر سرویس ها پیکربندی شده باشد. در سمت ارسال کننده یا مبدا، برای ارسال  پیام ها به سروری دیگر، یابد از forwarding rule  ها استفاده نمود. میتوان برای پیام های مختلف، Severity های مختف rule  های متنوعی ایجاد نمود.

در زیر یک نمونه از forwarding rule ها آورده شده است. باید توجه داشت که کل مجموعه زیر به عنوان یک rule  درنظر گرفته می شود. در صورتی که قصد داشته باشیم rule  های بیشتری ایجاد نمائیم باید کل بلاک زیر مجددا در فایل کانفیگ تکرار شوند.

$ActionQueueFileName fwhamed1 
$ActionQueueMaxDiskSpace 1g   
$ActionQueueSaveOnShutdown on 
$ActionQueueType LinkedList   
$ActionResumeRetryCount -1    
*.* @@remote-host:514

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

• ActionQueueFileName: نامی یکتا برای فایل spool متعلق به این rule می باشد.
• ActionQueueMaxDiskSpace: جداکثر فضایی که فایل spool میتواند در دیسک اشغال کند را مشخص می نماید.
• ActionQueueSaveOnShutdown: در هنگام shutdown پیام ها را جهت ارسال در آینده در دیسک ذخیره کند.
• ActionQueueType: متد و الگورتیم مدیریت صف پیام ها را مشخص میکند.
• ActionResumeRetryCount: بیانگر این است که در صورتی که سرور مقصد از دسترس خارج شد، چه میزان تلاش برای اتصال به آن صورت پذیرد. مقدار -1 به معنی بی نهایت می باشد.

سخن آخر:

در سیستم های کامپیوتری فعالیت ها و اتفاقات زیادی در حال رخ دادن هستند. اطلاعات گرد آوری شده از عملکرد سیستم عامل، عملکرد کاربران، عملکرد سرویس ها، اتصالات برقرار شده از طریق شبکه و … همه و همه میتوانندبیانگر وضعیتی از سیستم باشند. با استفاده از اطلاعاتی که از این طریق syslog جمع آوری می شود می توان علاوه بر آگاهی از وضعیت سرورها و سرویس ها در صورت مشاهده وضعیت نامتعارف براساس اطلاعات دریافتی اقدام متناسب را لحاظ کرد. همچنین میتوان برای ذخیره سازی سوابق، آنالیز و تحلیل و مهمتر از همه troubleshooting  سرویس ها نیز از داده های جمع آوری شده استفاده نمود.

 

معرفی Multipath و آموزش راه اندازی آن

Path چیست؟

path مسیر ارتباطی بین سرور و Storage  است که میتواند از طریق HBA یا کابل سرور را به storage متصل کند. در صورتی که به هر دلیلی مانند مشکل در San Switch، مشکل در کابل، مشکل شبکه ای و … مشکلی در عملکرد ارتباط برقرار شود، قطع شدن مسیر ارتباطی میتواند مشکلاتی را برای سرور و سریس دهی آن ایجاد کرده و یا کل عملکرد آن را مختل نماید.

در واقع ارتباط بین سرور و Storage آن هم از یک مسیر میتواند  گلوگاهی پر خطر در سرویس دهی و معماری سرویس باشد.  تصور کنید سرور دیتابیسی که دیسک آن بر روی SAN یا SDN قرار دارد. قطع شدن تنها راه ارتباطی آن به دیسک خود و عدم توانایی آن در خواندن و نوشتن داده ها میتواند سرویس دهی تمامی سرویس های وابسته به آن مجموعه را مختل کند.

 

Multipath چیست؟

با توجه به توضیحات بالا، جهت رفع این دست مشکلات معمولا بیش از یک مسیر ارتباطی بین سرور و Storage فراهم میگردد تا علاوه بر ایجاد redundancy  و بالا بردن throughput  در صورتی که یکی از مسیر ها به هر دلیلی دچار مشکل شد، عملکرد سیستم از طریق مسیر فرعی و بدون مشکل ادامه داشته باشد.

در لینوکس ابزاری بومی به نام DM- multipathing  وجود دارد که امکان معرفی چند مسیر برای ارتباط با Storage را فراهم  می سازد. به این ترتیب که مسیر های معرفی شده را با هم تجمیع کرده و هر LUN  متصل به سرور را به عنوان block device جدیدی در مسیر /dev/mapper  ایجاد می نماید.

اجزا multipath:

Multipath دارای چهار جز اصلی و به شرح زیر می باشد.

مشخصات سرور های مورد استفاده:

برای پیاده سازی multipath از دو سرو با مشخصات زیر استفاده شده است که در آن سرور یک به عنوان storage server و  server دوم نقش کلاینت را در این سناریو ایفا می کنند.

Server1: 	
CentOS Linux release 7.4.1708 (Core) 
IP: 192.168.200.200
Server2: 	
CentOS Linux release 7.4.1708 (Core) 
IP: 192.168.200.201

نیازمندی های انجام پروژه:

در این پروژه جهت شبیه سازی شرایط مورد نظر نیاز به وجود حداقل یک LUN متصل به سرور است. با توجه محیط آزمایشگاهی و نبود SAN، از طریق Server1  نسبت به ایجاد یک iSCSI Target  و ایجاد LUN و معرفی ان به Server2 اقدام میکنیم و در نهایت با افزودن دو کارت شبکه دیگر به Server1 پیکربندی Multipath و تست شرایط قطعی را بررسی خواهیم کرد.

پیاده سازی iSCSI:

تنظیمات سمت سرور (iSCSI target):

 

برای ییاده سازی ISCSI در لینوکس از ابزاری به نام target  استفاده می کنیم که این امکان را برای ما فراهم میکند تا یک یا چند دیسک از سرور را از طریق پروتکل iSCSI در شبکه به صورت block device  به  اشتراک گذاشته و یک Storage متمرکز ایجاد نمائیم. به سروری که  iSCSI در آن اجرا می شود و دیسک ها آن به شاتراک گذاشته می شود، iSCSI target  و به کلاینت هایی که به سرور متصل می شوند و از دیسک ها استفاده میکنند، iSCSI initiator  گفته می شود.  در مستند با توجه به موضوع اصلی آن توضیحات ارائه شده در خصوص پیکربندی iSCSI به صورت خلاصه بیان خواهد شد.

مرحل پیاده سازی iSCSI target  در لینوکس به شرح زیر می باشد.

در ابتدا با دستور زیر targetcli را در Server1 نصب مینمائیم.

Server1~]#  yum install targetcli

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

Server1~]#  systemctl enable target
Server1~]#  systemctl start target

بعد از شروع به کار سرویس با دستور targetcli وارد محیط prompt این سرویس میشویم.

Server1~]# targetcli

در محیط prompt با دستور ls لیستی از اطلاعات موجود و پیکربندی های فعلی را میتوانیم ببینیم.  که در آن تمامی دیوایس ها در قسمت backstore نمایش داده خواهند شد که میتواند یکی از تایپ های block،  fileio، pscsi و ramdisk باشد. در قسمت target  لیستی از iSCSI target  های ایجاد شده داده خواهد شد.

در اینجا از پیش دو دیسک sdb و  sdc یک physical volume ایجاد کرده و در نهایت یک lvm با حجمی برابر با حجم هر دو دیسک ایجاد کرده ایم را  به عنوان iSCSI target  معرفی نمائیم. اما ابتدا لازم است وارد قسمت block  شویم لذا مراحل ما به صورت زیر خواهد بود.

/> cd backstores/block 
/backstores/block> create LUN00 /dev/isc-co-vg/isc-co-lv

با دستور ls میتواینم ببینیم که block device ما ایجاد شده است.

حال برای ایجاد target مورد نظر ابتدا با دستور cd /iscsi وارد مسیر iscsi  میشویم سپس با دستور زیر iSCSI target مورد نظر را ایجاد میکنیم.

cd /iscsi
/iscsi> create iqn.2020-01.com.test:server

بعد از ایجاد iSCSI target برای آن port group با نام tpg1 ایجاد می شود که داخل آن میتوانیم به صورت زیر دسترسی به Target را فقط برای کلاینت های مجاز فراهم کنیم.

cd /iscsi/iqn.2020-01.com.test:server/tpg1/acls
create iqn.2020-01.com.test:clients

در انتها نیاز است که LUN مورد نظر را به target  ایجاد شده اختصاص دهیم. برای این کار وارد مسیر lun در target  رفته و دستور زیر را وارد می نمائیم.

cd /iscsi/iqn.2020-01.com.test:server/tpg1/luns 
create /backstores/block/LUN00

در نهایت با بازگشت به صفحه اصلی و زدن دستور ls پیکربندی نهایی را خواهیم دید. همانطور که در شکل زیر قابل مشاهده است، LUN ایجاد شده در مرال قبل به acl  مرتبط به clients به درستی map  شده است.

در نهایت با استفاده از دستور saveconfig تنظمیات انجام شده را ذخیره میکنیم. البته در صورت استفاده از دستور exit  به صورت اتوماتیک آخرین اغییرات اعمال شده ذخیره خواهد شد اما همچنان می توان با استفاده از دستور saveconfig  از ذخیره شدن تنظیمات مطمئن شد.  پیکربندی های انجام شده در فایل /etc/target/saveconfig.json ذخیره خواهد شد.

سرویس target  را با استفاده از دستور زیر restart  میکنیم.

Systemctl restart target

به عنوان آخرین قدم پورت 3260 را در فایروایل نیز باز میکنیم.

firewall-cmd --permanent --add-port=3260/tcp
firewall-cmd --reload

تنظیمات سمت کلاینت (iSCSI initiator):

در سمت کلاینت ابتدا با دستور زیر iscsi-initiator-utils را نصب میکنیم.

yum install iscsi-initiator-utils

بعد از نصب، وارد مسیر /etc/iscsi/initiatorname.iscsi شده و iqn ایجاد شده برای clients را در آن به صورت زیر وارد میکنیم.

InitiatorName=iqn.2020-01.com.test:clients

سپس سرویس های iscsi  و iscsid را Enable و start میکنیم.

systemctl enable iscsi iscsid
systemctl start iscsi iscsid

سپس با دستور زیر از صحت ارتباط اطمینان برقرار میکنیم.

iscsiadm --mode discovery --type sendtargets --portal 192.168.200.200:3260

در صورتی که مشکلی در ارتباط و پیکربندی وجود نداشت، با دستور زیر به iSCSI target معرفی شده login میکنیم.

iscsiadm -m node -T iqn.2020-01.com.test:server -p 192.168.200.200 –l

در نهایت با زدن دستور  های زیر میبینیم که دیسک جدید به ماشین اضافه شده است و میتوان از آن استفاده کرد.

fdisk –l
pvs –a –o +dev_size

در صورتی که قصد داشته باشیم ارتباط را قطع نمایئم میتوانیم از درستور قبل با option –u استفاده نمائیم.

iscsiadm -m node -T iqn.2020-01.com.test:server -p 192.168.200.200 –u

در نهایت با معرفی LUN مورد نظر به Server2 به نحوه پیکربندی multipath میپردازیم.

پیکربندی multipath:

قبل از راه اندازی multipath، یک نیازمندی دیگر باقی است، اضافه کردن دو اینترفیس جدید به Server1. با توجه به عدم وجود پیچیدگی در نحوه اضافه کردن اینترفیس جدید، از ارائه توضیحات مربوطه صرف نظر می کنیم. در نهایت وضعیت سرور ما بعد از اضافه کردن سا اینترفیس به صورت زیر خواهد شد.

بعد از اضافه شدن اینترفیس ها از این که امکان دسترسی به LUN ایجاد شده در مرحله قبل از طریق هر سه اینترفیس Servcer1 فراهم است، اطمینان حاصل میکنیم.

سپس دستور iscsiadm را برای سایر اینترفیس های اضافه شده نیز اجرا میکنیم تا از طریق دو IP جدید نیز به LUN مورد نظر login کنیم.

[root@server2 ~]# iscsiadm -m node -T iqn.2020-01.com.test:server -p 192.168.200.199 -l
[root@server2 ~]# iscsiadm -m node -T iqn.2020-01.com.test:server -p 192.168.200.198 -l

بعد از انجام عملیات فوق در صورتی که وضعیت دیسک های متصل به سرور را بررسی کنیم، خواهیم دید که LUN معرفی شده به Server2 با توجه به این که از سه مسیر مخلف به آن معرفی شده است، به عنوان سه دیسک شناخته شده است.

حال که دیسک از سه مسیر قابل مشاهده و دسترسی است، به سراغ پیکربندی multipath خواهیم رفت. Multipath  در لینوکس با استفاده از device-mapper-mulitpath یا dm-multipath انجام می شود و همانطور که گفته شد به صورت بومی بر روی سرور های لینوکسی وجود دارد. با این حال ّرای اطمینان از وجود این package میتوانیم از دستور زیر استفاده کنیم.

rpm -qa |grep multipath

در صورتی که این package نصب نبود، با دستور زیر نسبت به نصب آن اقدام میکنیم.

yum install device-mapper-multipath

سپس سرویس را برای راه اندازی خودکار در هر بار بوت سیستم عامل فعال و راه اندازی میکنیم.

systemctl enable multipathd
systemctl start multipathd

بعد از شروع سرویس، فایل پیکربندی را با دستور زیر ایجاد میکنیم.

mpathconf --enable --user_friendly_names n

درصورتی که user_freindly_names برابر با y قرار داده شود، در هنگام نمایش مشخصات دیسک ها و مسیر های آنها از alias آن ها برای نمایش به جای WWID  استفاده خواهد شد. علت استفاده از WWID این است که این ID برای هر دیسک منحصر به فرد بوده و قابل تغییر نیست در صورتی که نام میتواند به هر دلیلی دچار تغییر شود. در این صورت ممکن است این تغییر نام مشکلاتی درعملکرد و شناسایی تنظیمات مبتنی بر نام ایجاد کند.  در شکل زیر، در دستور اول این گزینه برابر با no و در دستور دوم مقدار آن برابر با yse  می باشد.  تفاوت نمایش با رنگ زرد مشخص شده است.

لازم به ذکر است درصورتی که WWID ای به نامی map شود، اطلاعات آن در مسیر /etc/multipath/bindings ذخیره خواهد ش

فایل پیکربندی ایجاد شده دارای چند بخش می باشد که در ادامه به معرفی بخش ها آن خواهیم پرداخت:

• defaults
• blacklist
• multipath
• devices

defaults: 

تنظیماتی است که به صورت پیش فرض برروی تمامی Device ها اعمال می شود. به عنوان نمونه در تنظیمات زیر، از round-robin  برای انتخاب مسیر استفاده خواهد شد، friendly name  برای همه yes خواهد بود مگر این که در قیمت devices و  multipath برای Device مشخصی مقدار جداگانه ای برای آن تغریف شود.

defaults {
        path_selector           "round-robin 0"
        user_friendly_names     yes
}

برخی از پارامتر های قابل استفاده در این قسمت به قرار زیر است:

blacklist:

در این قسمت میتوان Device ها را از فرایند multipath خارج یا black list کرد. برای black list  کردن Device ها میتوان از WWID، devnode (device name)، vendor، product، property های device و همچنین بر اساس device type  استفاده کرد.

به عنوان نمونه:

Black list  با استفاده از WWID

lacklist {
       wwid 26353900f0264456456
}

Black list  با استفاده ازdevnode

lacklist {
  devnode "^sd[a-z]"
}

Black list  با استفاده از vendor  و product

blacklist {
       device {
               vendor  "HP"
               product "*"
      }
}

Multipaths:

در این قسمت میتوانیم به تفکیک برای هر Device   تنظیمات بخصوص آن را جداگانه معرفی نمایئم. تنظیماتی که در این قسمت معرفی می شوند، بر تنظیماتی که در قسمت Devices و defaults مشخص شده اند overwrite خواهند شد. پارامتر هایی که میتوان در این قسمت استفاده کرد همانند پارامتر های دو قسمت قبل است. یک نمونه از این تنظیمات به صورت زیر است.

multipaths {
       multipath {
              wwid                  3600508b40000775650000000b0000
              alias                 server1
              path_selector         "round-robin 0"
              no_path_retry         5
		}
	}

devices:

درصورتی که Storage controller ی در لیست تجهیزات شناخته شده multipath نباشد یا بخواهیم Attribute خاصی از آن را با مقدار مشخصی مقدار دهی کنیم، میتوانیم از طریق این قسمت آن را به سیستم معرفی کنیم. برای مشاهده vendor های پشتیبانی شده از دستور زیر استفاده میکنیم.

multipath –t

در ادامه بعد از آشنایی اولیه با پارامتر ها و اجزاری فایل پیکربندی این سرویس، فایل پیکربندی را با تنظیماتی ساده و به شکل زیر تغییر می دهیم و سرویس را مجددا راه اندازی میکنیم.

بعد از راه اندازی سرویس با زدن دستور multipath –ll وضعیت دسترسی به دیسک را مشاهده خواهیم کرد. در تصویر مشخصات دیسک به همراه نام انتخاب شده برای آن و وضعیت مسیر ها  نمایش داده شده است. همانطور که مشاهده میشود وضعیت دیسک ها Active  و آماده فعالیت نمایش داده می شود.

حال برای تست عملکرد یکی از اینترفیس های Server1 را قطع کرده سپس مجددا وضعیت را در server2 بررسی میکنیم.

همانطور که در شکل مشاهده می شود، یکی از مسیر ها به وضعیت failed و  faulty تغییر وضعیت داده شده است.

وضعیت مسیر بر اساس مقدار polling interval  چک و بررسی خواهد شد و در صورت فعال شدن مجددا به صورت Active و ready تغییر وضعیت داده شده و مجددا مورد استفاده قرار میگیرد.

نتیجه گیری:

در محیط های عملیاتی می بایست برای حفظ دوام سرویس دهی و کیفیت آن، تلاش کرد مواردی که به هر دلیلی میتواند گلوکاهی برای سرویس دهی باشد حذف شده و یا ریسک آنها به حداقل ممکن رسانده شود. بروز مشکلاتی مانند قطعی ارتاط یک سرور به دلیل عدم وجود fault tolerance میتواند ضرر های هنگفت مالی و غیر مالی برای کسب و کارهای حساس ایجاد کند. در این مستند سعی شد تا معرفی multipath مکانیزمی برای تحمل خطا در سرور هایی که از دیسک های شبکه ای مانند SAN استفاده میکنند را مورد بررسی قرار گیرد. باید توجه داشت که پیکربندی این سرویس با در نظر گرفتن محیط آزمایشگاهی و سادگی آنها انجام شده است و در محیط ها عملیاتی میبایست پارامتر های مختلفی را جهت پیکربندی مناسب سرویس در نظر گرفت.