راه‌اندازی IPv6 در شبکه محلی

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

  • پیش‌نیازها:
    شما نیاز به یک IP ثابت از نوع IPv4 دارید که دسترسی به آن از سرورهای HE مجاز باشد.
    تست مجاز بودن دسترسی را می‌توانید از داخل پنل کاربری Tunnle Broker انجام دهید.
  • درخواست IPv6 برای سرور Debian از HE
    به نشانی https://tunnelbroker.net بروید، ثبت نام کنید. تونل بروکر اجازه ایجاد ۵ تونل به صورت رایگان به شما می‌دهد.
    بعد از ثبت IP ثابت شما هنگام خارج شدن از فیلد نشانی IP آدرس شما چک می‌شود و در صورت عدم دسترسی اعلام می‌کند.
    در صورتی که دسترسی مشکلی نداشته باشد باید سروری که تونل از آن ساخته می‌شود را انتخاب کنید. توجه داشته باشید سرورهایی را انتخاب کنید که زبان آن‌ها انگلیسی باشد وگرنه در هنگام کار کردن با اینترنت نسخه ۶ ممکن است سایت‌ها به صورت پیش‌فرض سایت محلی با زبانی غیر از انگلیسی به شما نمایش دهند.

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

  • راه‌اندازی تونل
    تنظیم‌های مناسب را از صفحه Example پیدا کنید. و روی سیستم خود اعمال کنید.
    برای اینکه دسترسی به DNS سرور با پشتیبانی از IPv6 داشته باشید می‌توانید از Cache DNS Server پیشنهادی HE استفاده کنید.
    آدرس شما با ::۲ تمام می‌شود.

تست کارکردن IPv6 روی سرور
برای تست از دستور ping6 google.com -n استفاده کنید. باید بتوانید این آدرس را Resolve و پینگ کند.
IPv6 گوگل ۲a00:1450:4005:80a::200e است. در صورتی که آدرس پیدا نشد پینگ آدرس را امتحان کنید.
در صورت عدم پینگ بجای ::۲ انتهای آدرس نسخه ۶ خود ::۱ بگذارید و امتحان کنید. در صورت عدم کارکرد تنظیم‌ها را بررسی کنید و مطمئن شوید از/به IP نسخه ۴ سرور تونل دسترسی به IP ثابت شما وجود دارد. همچنین دقت کنید تنظیمات را اشتباه وارد نکرده باشید.

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

درخواست /۴۸ از تونل بروکر:
برای هر تونل می‌توانید یک محدوده /۴۸ برای شبکه داخلی خود درخواست کنید. این محدوده به صورت پیش‌فرض فعال نیست.

تتنظیم IP روتر /۴۸ روی کارت شبکه شبکه داخلی
با اینکه شما به کل محدوده /۴۸ دسترسی دارید اما هر شکبه نهایی فقط می‌تواند از /۶۸ استفاده کند.
ابتدا نشانی ::۱/۶۸ را روی کارت شبکه‌‌ای از سرور اینترنت که به شبکه محلی متصل است تنظیم کنید. باید بتوانید از خارج از شبکه خود (مثلا ابزارهای آنلاین یا یک شبکه دیگر که دارای دسترسی به IPv6 است) بتوانید این نشانی جدید را پینگ کنید.
یک سری ابزار عیب‌یابی IPv6 در نشانی http://lg.he.net در دسترس است.

نصب radvd با توجه به /۶۴ بودن ساب‌نت انتخابی
با دستور apt-get install radvd ابزار توزیع IPv6 در شبکه محلی را نصب کنید.
فایل تنظیم‌ در نشانی /etc/radvd.conf قرار دارد. کافی است که ساب‌نت /۶۸ انتخابی را داخل آن تعریف کنید و سرویس را restart کنید.

سرویس networking یکی از دستگاه‌های داخل شبکه محلی را ریست کنید. در زمانی کوتاه باید نشانی IP نسخه ۶ را در محدوده انحصاری شما ببینید.
از این ایستگاه باید بتوانید از ping6 نشانی‌های نسخه ۶ سایت‌ها را ببینیند. تنظیم DNS سرور را فراموش نکنید.

نکته بسیار مهم: فراموش نکنید با راه‌اندازی IPv6 روی شبکه محلی همه دستگاه‌ها از خارج از شبکه محلی شما قابل مشاهده هستند. تنظیم فایروال ( ip6table ) را فراموش نکنید.

اولین درخواست من برای انتشار آزاد اطلاعات

همونطور که خبر دارین مدتی پیش بعد از چند سال، آیین‌نامه «قانون انتشار و دسترسی آزاد به اطلاعات» تهیه، تایید و اجرایی شد.

گردش کار و اطلاعات مربوط به فیلترینگ از جمله چیزهایی هستند که تابحال در موردش هیچ اطلاع واضحی منتشر نشده است.
به نظرم میشه از همین قانون استفاده کرد و درخواست انتشار اطلاعات مربوط به گردش کار سیستم فیلترینگ و لیست سایت‌های filterشده و دلیل فیلتر هر کدوم را درخواست کرد و بعد به صورت آزاد منتشر کرد.

کسی اطلاعی داره که دقیقا به کجا می‌شه این درخواست را داد؟ کارگروه تعیین مصادیق مجرمانه؟ شرکت ارتباطات زیرساخت؟ وزارت ارتباطات و فناوری اطلاعات؟ شورای عالی فضای مجازی؟

آیا وکیلی هست که تمایل داشته باشه برای آماده‌کردن متن این درخواست همکاری کنه؟

باگ امنیتی SSLv3

Poodle

این روزها مرتب داره باگ‌های امنیتی خفن با سابقه‌های طولانی در حد بیش از ۱۰ سال پیدا و اعلام می‌شه.

اگه حضور ذهن داشته باشید باگ‌های Heartblead یا همون خون‌ریزی قلبی در OpenSSL، باگ بزرگ Shellshock خیلی وقت نیست که اعلام شدند.

اما آخرین باگ امنیتی که همین دیروز سر و صداش بلند شد، مشکل امنیتی است در SSL نسخه ۳. اسم این باگ که از طرف Google اعلام شده Poodle است.

Mozilla اعلام کرده که از نسخه بعدیش (نسخه ۳۴) پشتیبانی از SSLv3 که ۱۵ ساله بازنشسته شده را قطع می‌کنه. Chrome هم همین سیاست را در پیش گرفته است.

اگه کاربر عادی هستید در Firefox با نصب افزونه SSL Version Control از نشانی  https://addons.mozilla.org/en-US/firefox/addon/ssl-version-control می‌تونید قبل از اینکه نسخه جدید فایرفاکس بیاد از اتصال مشکل‌دار SSLv3 جلوگیری کنید. همینطور می‌تونید Google Chrome را با گزینه  –ssl-version-min=tls1 اجرا کنید تا گوگل کروم هم از این پروتکل مشکل‌دار استفاده نکنه.

اگه سرور وب Apache دارید و SSL روش فعال است در اولین فرصت با تنظیم خط زیر در etc/apache2/mods-enabled/ssl.conf/ از کاربرای سایتتون محافظت کنید:

اطلاعات بیشتر در مورد این مشکل امنیتی در http://googleonlinesecurity.blogspot.com/2014/10/this-poodle-bites-exploiting-ssl-30.html در دسترس است.
مثل همیشه بلاگ بیان ( blog.bayan.ir ) هم اطلاعات خوبی منتشر کرده است.

+آپدیت: اطلاعات بیشتر و راهنمای رفع خطر در وبلاگ بیان منتشر شده است. همینطور یک ابزار برای بررسی آنلاین اینکه شما در خطرید یا نه هم منتشر کرده است. همینطور یک پست در مورد چه شرایطی ممکن است شما را دچار خطر کند در این بلاگ منتشر شده است.

افغان‌تلکام در ایران

این اطلاعات شبکه‌ای است که پکت ما توش گیر می‌کنه!

نشانی ساختمان اداره زیرساخت، شبکه AfghanTelecom:

حل مشکل ارتباط با اینترنت!

مدتی قبل یه مطلب گذاشته بودم در مورد اینکه با eeepcـم توی خونه مشکل دارم و اگه اندازه درخواست‌ها زیاد بشه اینترنتم کار نمی‌کنه.
نتیجه این مشکل این بود که مثلا بعد از وارد کردن رمز gmail وارد مرحله بعدی نمی‌شد یا اگه توی بلاگ می‌خواستم مطلب بزارم نمی‌شد و …
این مشکل باقی بود تا هفته پیش که رفتم تهران‌لاگ. اونجا این موضوع را با یکی از دوستان در میون گذاشتم و اون هم گفت یکی دیگه از دوستاش هم مشابه این مشکل را داشته و حلش کرده. قرار شد که برام بپرسه و خبر بده.
یکی دو روز بعد ایمیل زد و گفت مشکل از تنظیم mtu است.
اتفاقا همون روز یکی از دوستان همکار هم سر یه صحبتی گفت که POL اینطور مشکلی داره و باید تنظیم‌ mtu را عوض کنی. خودش عدد ۱۲۸۰ را پیشنهاد کرد (چیزی بود که خودش استفاده می‌کرد) و البته گفت با ping -s SIZE می‌شه این عدد را دقیق پیدا کرد.
شب که رفتم خونه اول با دستور ifconfig wlan0 mtu 1280 سعی کردم مشکل حل بشه. با اینکه mtu عوض شده بود اما به نظر می‌رسید مشکل باقیه. بنابراین رفتم داخل پنل کنترل مودم و از اونجا این مقدار که روی auto بود را آوردمش روی حالت دستی و عدد mtu را از 1490 که مقدار پیش‌فرض برای ارتباط‌های pppoe است را تغییرش دادم به 1280 و مشکل حل شد!
البته هنوز نفهمیدم این مشکل چطور بود که فقط توی linux دیده می‌شد اما توی ویندوز مشکل وجود نداشت! و چرا با تغییر mtu توی لینوکس حل نشد! احتمالا این مطلب مینونه کمک کنه. در این مطلب با استفاده از iptable مقدار mtu را در هنگام ایجاد ارتباط (بسته sync) به مقدار دلخواه کم یا زیاد می‌کند.

asus eee pc دیوانه

مدتی است که مشکلی بس عجیب با asus eee pc پیدا کردم.

وقتی توی خونه می‌خوام باهاش برم توی اینترنت گشت و گذار ییهویی کارت شبکه از کار میافته. مهمتر از همه این که وقتی که از کار میافته به نظر می‌رسه از خط فرمان می‌شه درخواست‌های GET را ارسال کرد و جوابش را دید (و الیته از توی مرورگر هم) اما درخواست‌های POST بخصوص اون‌هایی که یه ذره مقدار دیتا شون بزرگ باشه، مثلا وقتی می‌خوای یه مقاله‌ای که نوشتی را بزاری توی بلاگت گویا همه چی از کار میافته. اصلا ترافیک قطع میشه و نمی‌شه هیچ کاری کرد.

یا درخواست‌های tor همینطور، یه ذره کار می‌کنه و بعد از کار میافته.

درخواست‌های https پروکسی هم.

جالب اینه که بدون اینکه در تنظیمات تغییری بدی، توی شرکت همه چی درست و حسابی داره کار می‌کنه!
توی خونه از سرویس POL استفاده می‌کنم و توی شرکت اغلب از Irancell. هر چند توی شرکت با POL هم مشکلی ندارم!

خیلی توی اینترنت سرچ کردم اما هیچ سر نخی به دست نیاوردم. تنها چیزی که پیدا کردم این بود که گویا بعضی از کارت شبکه‌های وایرلس با مود N مشکل دارند که برای رفع این مشکل توی خونه مودم را بردم روی مود G (نتونستم کارت شبکه را روی مود G قفل کنم پس صورت مساله را پاک کردم!). یه مدت بهتر بود و باز دوباره چند وقتیه همون آش و همون کاسه!

چند وقت پیش حتی زدم سیستمم را از اول نصب کردم اما افاقه نکرد! (home را البته نگه داشتم. شاید دفعه بعدی اون‌ها را هم پاک کردم)

حتما براتون جالبه که در همین زمان «مریم» می‌تونه به اینترنت وصل بشه و هر نوع استفاده‌ای داشته باشه بدون مشکل!

مشکل شناخت نام هاست در آپاچی

کسایی که وب‌کارند و کد وب می‌زننند زیاد پیش میاد که روی سیستم لوکال‌شون آپاچی، این وب سرویس محبوب را نصب کنند تا کارهاشون را بتونند تست کنند. خیلی وقت‌ها میشه که بعد از نصب آپاچی و موقع شروع به کار اون این پیام را می‌بینیم:apache2: Could not reliably determine the server’s fully qualified domain name, using 127.0.1.1 for ServerName.
دلیلش چیه؟ دلیلش اینه که تنظیمات FDQN سیستم‌تون درست نیست و سیستم نمی‌تونه FDQN سیستم را اتوماتیک شناسایی کنه.

راه حلش چیه؟
۱. توی تنظیمات آپاچی بگین اسم کامل سرور Default چیه.
۲. تنظیمات FDQNت را درست کنید. در ساده‌ترین حالت برین توی فایل etc/hosts/ و جلوی 127.0.0.1 اسم کامل هاست‌تون (شامل اسم هاست و نام دامنه مثلا sadeq.localdomain) را اضافه کنید. دقت کنید که اسم کامل هاست حتما باید اولین اسم بعد از IP باشه!

مشکل‌های مشابه برای چه ابزارهای دیگه‌ای ممکنه رخ بده؟ Exim که به عنوان MTA پیشفرض در Debian استفاده می‌شه هم ممکنه همین مشکل را داشته باشه و موقع شروع به کار پیام بده که نمی‌تونه FDQN سیستم را شناسایی کنه. روش ۲م این مشکل را هم حل می‌کنه.

پی‌نوشت: FDQN چیه؟ FDQN مخفف Fully Qualified Domain Name است و بعضی وقت‌ها به عنوان نام مطلق هم بهش گفته می‌شه. این اسم نام هاست را به صورت یکتا در سلسه مراتب DNS سرورها مشخص می‌کنه (در اینترنت یا اینترانت). این نام از یه اسم هاست و یه دامنه تشکیل شده. (اسم دامنه می‌تونه تک بخشی مثلا localdomain یا چند بخشی مثلا sadeq.ir باشه)