https://virgool.io/feed/@mahdibahramih دوآپسی خرد و ریز، علاقه مند به یادگیری هر چی که هست و نیست. fa 2026-06-10 13:08:49 https://files.virgool.io/upload/users/37994/avatar/PPhcJH.jpeg?height=120&width=120 https://virgool.io/@mahdibahramih https://virgool.io/@mahdibahramih/%D8%B3%D8%B1%D9%88%DB%8C%D8%B3-%D9%87%D8%A7-%D8%AA%D9%88-%DA%A9%D9%88%D8%A8%D8%B1%D9%86%D8%AA%DB%8C%D8%B2-%DB%B2-k5i1gpq06lp6 خب مثل بقیه پست هایی که تو ویرگول(یا هر جایی دیگه) مینویسم همین اول اعلام کنم که این نوشته ممکنه کلی کم و کاستی داشته باشه (نگارشی٬فنی ...) بابتش عذر میخوام ولی امیدوارم که قابل استفاده باشه.قبل از خوندن این نوشته لازمه که نوشته قبلی من رو با عنوان سرویس ها تو کوبرنتیز ۱ رو بخونید.تو نوشته قبلی سعی کردم به طور خلاصه مفهوم کلی سرویس ها و موارد استفاده شون رو براتون شرح بدم. حالا تو این نوشته قصد دارم انواع سرویس هارو معرفی کنمانواع سرویس ها سرویس ها تو کوبرنتیز سه نوع هستن Cluster ip , Node Port , Load Balancer حالا به طور خلاصه درباره هر کدوم یکم توضیح میدم 1- Cluster ip: ما از این نوع سرویس تو نوشته قبل استفاده کردیم. از این نوع سرویس برای دسترسی به پاد ها داخل کلاستر استفاده میشه. به طور ساده تر ما اگه pod داشته باشیم که بخواییم داخل کلاستر قابل دسترسی باشه از این نوع استفاده میکنیم که هم با ip و هم با name قابل دسترسیه.2- Node port:میشه گفت پر استفاده ترین نوع سرویس برای قابل دسترسی کردن سرویس در خارج از کلاستر برای ماست. در حالت کلی با ساخت سرویس با type Node port یه پورت رندوم ( یا تعیین شده ) بالای 30000 روی همه نود ها به صورت listen در میاد و ترافیک رسیده به این پورت ها به سرویس ما هدایت میشه. مثل شکل زیر خب تصور کنید که ما یه کلاستر کوبر داریم با یک مستر و دو ورکر که ip های این ماشین ها به این صورته :‌master ip : 10.10.10.1worker 1 ip : 10.10.10.2 worker 2 ip : 10.10.10.3خب حالا ما یک سرویس از نوع node port با کانفیگ زیر میسازیم که مثل قبل به پاد nginx ما وصله apiVersion: v1kind: Servicemetadata: name: nginx-nodeportspec: type: NodePort ports: - port: 3036 nodePort: 30036 selector: app: nginxخب حالا ما یه سرویس از نوع node port داریم و این جوری کار میکنه که پورت ۳۰۰۳۶ همه نود های ما به صورت listen در میان و ترافیکی که بیاد به این پورت هدایت میشه به pod nginx ما و ما میتونیم nginx مون رو ببینیم . یکم ساده ترش میشه اینکه اگه ما تو browser مون هر کدوم از ip های نود هامون رو بزنیم با پورت ۳۰۰۳۶ (مثال 10.10.10.2:30036 ) صفحه nginx مون رو میبینیم.خب اینم از این :) . سرویس nodeport ساده ترین روش واسه expose کردن app مون به دنیای واقعی بیرونه اما خب یه سری مشکلات هم داره. بزرگترین مشکلش هم اینه که حالا ما اومدیم یه وب سایتی ساختیم میخواییم بدیم دست ملت برن ببیننش. خب دامین مستقیم که نمیتونیم ست کنیم چون دامین مستقیم به ip و پورت ۸۰ مپ میشه ولی تو این جریان پورت ما فرق داره . باید به مشتری (‌کاربر) بگیم بی زحمت این پورت و حفظ کن هر وقت خواستی بیای وب سایت ما این پورت رو هم ته ادرس ما بزن :) که خوب خیلی ضایع است ....3- Load Balancerمعمولا این نوع سرویس واسه ما که تو ایران کار و زندگی میکنیم یکم غریبه . حالا چرا ؟ چون ما به خاطر شرایطی که تو کشورمون داریم دسترسی به cloud provider های بزرگ دنیا خیلی سخته ( شاید غیر ممکن با این شرایط جدید که گوگل ایجادش کرده). و معمولا این نوع سرویس نیازمند یه سری ملزوماته که هر cloud provider اومده اونو واسه زیر ساخت خودش ایجاد کرده حالا این وسط یه سری ابزار های open source ای هم ایجاد شدن که میشه با پیاده سازیشون با یکم دردسر یه این نوع سرویس روی bare metal ( یا vm ) دسترسی داشت که تو پست های اینده دربارشون میگم براتون. زیاد حاشیه رفتیم برگردم سر اصل داستان. این سرویس چیه ؟ سرویس load balancer ( تو cloud provider )‌ این جوریه که شما میای یه سرویس از این نوع میسازی مثل این:apiVersion: v1kind: Servicemetadata: name: loadbalancer-nginxspec: selector: app: nginx ports: - port: 80 type: LoadBalancerنتیجه اینه که به این سرویس یه ip public معتبر اختصاص داده میشه و شما با زدن اون ip از کل دنیا میتونید nginx خودتون و ببینید. واقعا زیبا و کاربردیه ولی حیف که دستمون بهش نمیرسه :( تو این نوشته سعی کردم یه دید کلی از سرویس ها بهتون بدم . امیدوارم که مفید بوده باشه. مثل قبل اگه جایی واستون نا مفهوم بود اصلا نگران نباشید٬ به گیرنده هاتون دست نزنید مشکل از فرستنده است:)‌سوال ها و نظراتتون رو کامنت کنید من حتما جواب میدم:) mahdibahramih mahdibahramih Mon, 05 Apr 2021 14:01:57 +0430 https://virgool.io/@mahdibahramih/%D8%B3%D8%B1%D9%88%DB%8C%D8%B3-%D9%87%D8%A7-%D8%AA%D9%88-%DA%A9%D9%88%D8%A8%D8%B1%D9%86%D8%AA%DB%8C%D8%B2-%DB%B1-fh6ljd37mnfo خب مثل بقیه پست هایی که تو ویرگول(یا هر جایی دیگه) مینویسم همین اول اعلام کنم که این نوشته ممکنه کلی کم و کاستی داشته باشه (نگارشی٬فنی ...) بابتش عذر میخوام ولی امیدوارم که قابل استفاده باشه.خب بریم سر اصلا داستان:نمیخوام از صفر صفر شروع کنم پس واسه فهمیدن این نوشته لازمه که از قبل اطلاعات کوچیکی درباره K8S داشته باشین.سرویس چیست؟خب تصور کنید که ما یه کلاستر اماده داریم که داره کار میکنه٬ حالا ما اومدیم app خودمون رو توی این کلاستر deploy کردیم ( واسه سادگی app رو یه nginx ساده ببینید ) این pod یه ip گرفته و شما اگه از داخل کلاستر requests بزنید به اون پاد میتونید صفحه اصلی nginx تون رو ببینید. ولی یه مرحله که جلو تر بریم به یه مشکل بر میخوریم! مشکل چیه؟ مشکل اینه که حالا من چجوری این app رو واسه بقیه مردم تو کل جهان قابل نمایش کنم؟ این جاست که سرویس ها میان تو بازی.خب تا این جا فهمیدیم که service ها نقششون چیه حالا بیایید نقشی رو که واسش گفتیم مرور کنیم و یه نقش دیگه هم اضافه کنیم بهش.نقش اول: قابل دسترس کردن pod ای که داخل کلاستر بالا اوردین واسه کاربرایی که خارج از کلاسترننقش دوم: گفتیم که وقتی یه pod بالا میاریم یه ip بهش assign میشه و ما از این ip واسه دسترسی بهش استفاده میکنیم. حالا تصور کنید به هر دلیلی‌( اپدیت٬ خارج شدن یه نود از کلاستر و ....) pod شما از بین رفته و یه pod جدید بالا اوردین ( یا خود کلاستر این کارو کرده). حالا چی پیش میاد ؟‌ یه pod جدید یه ip جدید داره و از طریق ip که شما قبلا از app تون داشتید قابل دسترسی نیست! ای بابا داستان شد که :( این جاست که service ها مثل یه قهرمان ظاهر میشن.خب ما تا این جا فهمیدیم که سرویس ها به چه دردی میخورن و اصلا چرا به وجود اومدن. حالا بریم ببینیم چجوری کار میکنن.سرویس ها چجوری کار میکنن ؟اول بریم سراغ اینکه ببینیم سرویس ها تو k8s چجوری مشکل دوم مارو حل میکنن ( نقش دوم سرویس ها):خب الان سیستم فرضی ما بدین صورته:‌ یک پاد با قالب زیرapiVersion: v1kind: Podmetadata: name: nginx labels: app: nginxspec: containers: - name: nginx image: nginxخب به همین راحتی میشه یه پاد nginx تو کوبرنتیز بالا اورد.پاد ما بالا اومده و ما به این شکل داریمشتو تصویر اطلاعات کلی پاد رو میبینید حالا بیایید واس پادمون سرویس ایجاد کنیم.apiVersion: v1kind: Servicemetadata: name: my-servicespec: selector: app: nginx ports: - protocol: TCP port: 80 targetPort: 80 خب با توجه به کانفیگ بالا ما یه سرویس ساختیم به اسم my-service و تو قسمت selector گفتیم که وصل شو به pod ای که lable ش با این قانون match بشه : app:nginx . تو ادامه هم گفتیم که port 80 این سرویس رو به port 80 پادمون روی پروتوکل tcp وصل کنه.خب حالا این سرویس چطور مشکل مارو حل میکنه ؟ یه چیز جالب سرویس ها با اسمشون به جای ip قابل دسترسی هستن.حالا متوجه شدین که مشکل ما چطور حل شد ؟ اجازه بدین یه شکل واستون بیارم این شکل کاملا گویای service هست. چون سرویس به وسیله match شدن قانونی که واسش تو قسمت selector فایل کانفیگش نوشتیم میاد به پاد ها وصل میشه عوض شدن ip پاد هاتون تو مسیر دسترسی شما به پاد ها خللی وارد نمیکنه از سمت دیگه اس چون شما با name به سرویستون وصل میشید عوض شدن ip سرویس هم مشکلی نیست.به همین راحتی مشکل ما حل شد :)حالا شما اگه تو کلاسترتون دستور curl my-service رو بزنید صفحه nginx تون رو میبینید حتی اگه هزار بار ip پادتون عوض شه.البته سرویس کار های دیگه ای رو هم برای ما انجام میده ولی چون دوست دارم که نوشته هام واسه کسایی که تازه کوبرنتیز رو شروع کردن مناسب باشه فعلا در ساده ترین و مینیموم ترین حالت پیش میریم. خب به نظر میاد بهتره بیش تر از این طولانیش نکینم واسه پست اول کافیه.اگه سوالی داشتین یا جایی نا مفهوم بود اصلا نگران نباشید٬ به گیرنده هاتون دست نزنید مشکل از فرستنده است:)‌سوال ها و نظراتتون رو کامنت کنید من حتما جواب میدم:)تو ادامه بقیه ماجرا رو هم میگم. mahdibahramih mahdibahramih Wed, 17 Mar 2021 13:23:48 +0330 https://virgool.io/@mahdibahramih/%D8%AA%D8%AC%D8%B1%D8%A8%D9%87-%D9%85%D8%A7-%D8%AF%D8%B1-%D8%A8%D8%B1%DA%AF%D8%B2%D8%A7%D8%B1%DB%8C-uutctf2020-wfojz3lguce3 خب، بعد از گذشت یه مدت زمان نسبتا طولانی از پایان رقابت UUTCTF۲۰۲۰ تصمیم گرفتم که یه نوشته کوتاه دربارش بنویسم. قبل از شروع لازمه بگم که این نوشته ممکنه کلی ایرادات نگارشی و دستوری داشته باشه. همین اول از همه دوستانی که متن و میخونن معذرت میخوام بابت اشکالات احتمالی متن.حالا چرا اینقدر فاصله افتاد بین این نوشته و پایان خود مسابقه؟‌ چون منتطر بودم یکم زمان بگذره به نوعی بتونم دید بهتری از اون چه که اتفاق افتاد داشته باشم بعد شروع به نوشتن بکنم. معرفی۱− ببینیم اصلا CTF چی هست؟! مخفف عبارت Capture The Flag میباشد، مسابقاتی در زمینه هک و امنیت کامپیوترها هستند و مابین هکرها رواج دارند و عموما شامل شرکت کنندگانی در زمینه های متخصصان امنیت شبکه، تحقیق و پژوهش، مهندسی معکوس و دیگر کارهای مربوطه هستند که می توانند با هم به رقابت بپردازند. “پرچم” در حقیقت پاسخ نهایی چالش ها است که در آخر امکان دارد به صورت یک متن ساده به دست آید.۲− حالا بریم سراغ UUTCTF کلا UUTCTF تشکیل شده از دو بخش CTF , UUT. بخش اول رو که بالا واستون معرفی کردم. حالا UUT چیه ( یا بهتره بگیم کجاست)‌ UUT مخفف عبارت Urmia University of Technology یا به عبارت بهتر " دانشگاه صنعتی ارومیه" است. مسابقه UUTCTF هم از دل انجمن علمی مهندسی کامپیوتر این دانشگاه بیرون اومده و یه مسابقه CTF دانشجویی به حساب میاد که هر ساله انجمن علمی مهندسی کامپیوتر دانشگاه صنعتی ارومیه و صد البته دکتر تاجبخش مسولیت برگزاریش رو بر عهده دارن.تیر ماه سال ۹۹ سومین دوره این مسابقه موسوم به UUTCTF2020 برگزار شد. دو دوره قبلی به ترتیب UUTCTF2019 به صورت آنلاین و UUTCTF2018 به صورت لوکال برگزار شده بود. تو این دوره کار ما به مراتب سخت تر بود.( خودمون بعد شروع مسابقه متوجه شدیم چه بلایی داره سرمون میاد ?) حالا چرا و چجوری و بقیه داستان هاشو پایین تر واستون میگم.یه کوچولو هم درباره خودم بگم من مهدی بهرامی هستم در زمان برگزاری این مسابقه دانشجوی دانشگاه صنعتی ارومیه و syatem admin مسابقه بودم و حالا تو حوزه DevOps و sysadmin مشغول فعالیتم?.همکاری با آروانبه طور خلاصه ما واسه برگزاری این مسابقه زیر ساخت نیاز داشتیم . واسه استفاده از زیر ساخت خود دانشگاه کلی دردسر و محدودیت واسمون وجود داشت به همین دلیل تصمیم گرفتیم که از آروان کمک بگیریم . با یه ایمیل همه چی حل شد! و تیم آروان خیلی سریع و با اغوش باز استقبال کردن از ایده ما و به نوعی اسپانسر ما شدن. راستش من خودم فکر نمیکردم اینقدر سریع و بدون دردسر پیش بره این پروسه ولی واقعا رفتارشون با ما فوق العاده بود کلی هم کمکون کردن که تو ادامه توضیح میدم واستون.آمار و نتایجدر کل این مسابقه با حضور ۷۳۰ تیم از کشورهای مختلف دنیا و شرکت ۱۰۶۹ شرکت کننده برگزار شد. تو این دوره ۲۱ سوال مطرح بود که در حوزه‌های رمزنگاری، جرم یابی، مهندسی معکوس و وب تعریف شده بود.در نتیجه این مسابقات سه تیم bootplug, flagbot and DarkArmy به ترتیب اول تا سوم شده و برای شرکت در دور بعدی P0SCon دعوت شدند.در مسابقه امسال، افزایش چشم گیر شرکت کنندگان محسوس بود. همچنین افزایش بسیار زیاد حملات بر روی سرور مسابقات نیز به شدت قابل مشاهده بود. این نشان از مورد توجه قرار گرفتن مسابقات UUTCTF و طبعا دانشگاه صنعتی ارومیه در عرصه‌های بین المللی است.داستان ترسناک DOWNTIME:بالاخره روز ۳۱ خرداد (روز برگزاری مسابیقه) رسید. من به شخصه فکر میکردم قراره بعد چند ماه کار روی این مسابقه بالاخره به اخرش رسیدیم و قراره یه نفس راحت بکشیم ‌ چون دوبرابر سال قبل زیرساخت اماده کرده بودیم( که البته چه خوش خیال بودم!). ما دسترسی هارو باز کردیم و شرکت کننده ها مسابقه رو شروع کردن یک ساعت اول همه چی خوب بود. بعدش کابوس شروع شد! سرور مسابقه مون از دسترس خارج شد. چشمام سیاهی میرفت وقتی داشتم لاگ های nginx و میخوندم ? یه جوری زیر حمله DDos بودیم که سرور های دانشگاه به خواب عمیقی فرو رفتن به سرعت تصمیم گرفتیم که سرور مسابقه رو انتقال بدیم روی سرور های اروان (‌ قبل این فقط سرور سوال هامون روی زیرساخت اروان بود )‌ ولی کماکان مشکل وجود داشت. دامنه مون و انتقال دادیم روی CDN اروان. مشکل کمتر شد ولی همچنان ادامه داشت. بالاخره با بدبختی فراوان تونستیم مسابقه رو ادامه بدیم و تمومش کنیم. توی این بین تیم فنی آروان خیلی کمکمون کردن با اینکه روز تعطیل بود باز هم اومدن و کمکون کردن که لازمه بازم ازشون تشکر کنم.یه توضیح کوچیکم این اخر بدم: امتیازی که مرجع رسمی رقابت های ctf موسوم به ctftime به uutctf2019 داد 20 بود. uutctf2020 نسبت به uutctf2019 پیشرفت قابل توجهی تو بالا بردن سطح سوالات داشت ولی از شانس بد ما بخاطر مشکلات زیرساختی که این مسابقه داشت تونست 19.7 امتیاز کسب کنه (که خب قطعا مقصر اصلی این اتفاق بنده یعنی sysadmin تیم بودم). البته uutctf2021 ای در راهه که قراره ...... حالا ادامش بماند خودتون خواهید دید ((:و اینکه جا داره بازم از آروان تشکر کنم که قطعا اگه همراهی و کمک اونا قبل و حین مسابقه نبود برگزاری این مسابقه سخت و چه بسا غیر ممکن می‌بود mahdibahramih mahdibahramih Sat, 16 Jan 2021 13:04:16 +0330