د VPN کانټینر دننه ویب انټرفیس ته رسېدل: د پورټ مالک وټاکئ

په اپلیکیشن کې هېڅ ستونزه نشته او په تونل کې هېڅ ستونزه نشته، خو ډشبورډ بیا هم نه پورته کېږي۔ کله چې یوه خدمت د network_mode: service:vpn سره چلېږي، نو د VPN کانټینر د شبکې نوم‌ځای شریکوي، یعنې د هغه اورېدونکی او خپاره شوي پورټونه د خدمت نه، بلکې د هماغه نوم‌ځای دي۔ له دې درې پرېکړې راوځي: اپلیکیشن چېرته تړل کېږي، کوم کانټینر پورټ خپروي، او د مدیریت لاره څومره تنګه ده۔ که دا په غلط ترتیب ترسره کړئ، هر یوازینی تنظیم سم ښکاري، خو یوځای کېدل نشي کار کولی۔

د پورټ نوم‌ځای څوک لري

په شریک نوم‌ځای کې، تړلي خدمت ته د ports: ننوتلو زیاتول هېڅ ګټوره کار نه کوي، او څو شبکې انتخابونه د طراحۍ له مخې د هغه لپاره نه ملاتړ کېږي۔ پرځای یې هغه کانټینر ته خپور کړئ چې نوم‌ځای لري۔ هماغه کانټینر هغه هم دی چې پته یې په هوسټ کې ښکاري، نو نقشه د یوې ننوتنې په توګه لوستل کېږي، نه د هر خدمت لپاره یوه۔

services:
  vpn:
    image: vpn-client-image
    cap_add: [NET_ADMIN]
    ports:
      - "127.0.0.1:8080:8080"
  app:
    network_mode: "service:vpn"

د نقشې کیڼ اړخ پتې ته پام وکړئ۔ له 127.0.0.1 سره تړل خپرې شوې پورټ د هوسټ په لوپ‌بیک کې پاتې کوي، چې معمولاً د مدیریت انټرفیس غواړي۔ له 0.0.0.0 سره تړل یې په هوسټ د هر انټرفیس باندې ښکاره کوي، او دا اسانتیا نه، بل امنیتي پرېکړه ده۔

اپلیکیشن دې هغه ځای واوري چې نوم‌ځای یې تمه لري

د نوم‌ځای دننه له 127.0.0.1 سره تړل شوی اورېدونکی یوازې د هماغه نوم‌ځای له داخله رسېدلای شي۔ خپاره شوي هوسټ پورټونه له باندې راځي، نو د نقشې د کار کولو لپاره اپلیکیشن باید پراخه پته وتړي۔ دا په ډېرو سرورونو کې د یوې کرښې بدلون دی، او همدا هغه ګام دی چې خلک یې له کانټینر پرته د ځای پرځای کولو لپاره لیکل شوي کلکتیا لارښود له کاپي کولو وروسته پرېږدي۔

docker compose exec app ss -lntp
docker port vpn
curl -sS -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8080/

د اپلیکیشن دننه د اورېدونکو لیست د تړلو پتې په اړه رښتیا وایي، او docker port ښیي چې مالک په رښتیا څه خپاره کړل۔ که لومړی 127.0.0.1 وښیي او دویم د هوسټ نقشه وښیي، نو تاسو بې‌تمه‌توب د VPN ترتیباتو ته له لاس ورکولو پرته وموندل۔

وټاکئ چې د مدیریت لاره څنګه دننه شي

درې سمې ترتیبات شته۔ پر VPN کانټینر یې خپور کړئ او له هوسټ یا محلي شبکې ورته ورسیږئ۔ د نوم‌ځای مخې ته یو معکوس پروکسي کېږدئ او پروکسي ته یوازینی خلاص پورټ ورکړئ۔ یا ډشبورډ یوازې د نوم‌ځای له داخله د exec ناستې یا SSH تونل له لارې د رسېدو وړ وساتئ، چې تر ټولو کم ښکارېدل او تر ټولو کمه اسانتیا ده۔

کوم څه سم دي دا په دې پورې اړه لري چې انټرفیس چاته او له کومه ځایه ورته اړتیا ده۔ په هماغه هوسټ یوازینی مدیر د لوپ‌بیک تړلو سره بسنه کوي۔ هغه ټیم چې د VPN له لارې ورته رسېږي، سوچ شوې لاره او نومول شوی مالک ته اړتیا لري۔ د پروکسي انتخاب کول تاسو ته TLS او د لاسرسي ثبتونه درکوي، خو په بدل کې یو بل برخه هم په تازه حالت ساتل غواړي۔

د مدیریت پورټ پرانیزئ پرته له دې چې هر څه پرانیزئ

د VPN کلاینټ خپله د سیمه‌ایز لاسرسي یا قفل پالیسي کولای شي راغونډه مدیریتي غوښتنه وغورځوي، حتی کله چې وتونکی تونل په بشپړه توګه کار کوي۔ د پام‌شوي سرچینې او پورټ لپاره یوه مستنده استثنا اجازه کړئ، بیا تایید کړئ چې د تونل نورمال ساتنه نه ده بدله شوې۔ د ډشبورډ د پورته کېدو لپاره د بېړني بټن بندول د براوزر ټب په بدل کې ریښتینی کنټرول له لاسه ورکول دي۔

د اپلیکیشن خپله تصدیق فعال پرېږدئ۔ د VPN سره تړلي سټیک دننه اوسېدل هر ځایي کاروونکي یا هغه هر وسیلې ته اجازه نه ورکوي چې هوسټ ته رسېدلای شي، او د تونل شاته بې‌تصدیقه مدیریت پینل بیا هم بې‌تصدیقه مدیریت پینل دی۔

د مدیریت وسیلې څخه یې وګورئ، بیا وروسته یې بیا وګورئ

له هغه ماشین څخه یې وازموئ چې په رښتیا به خدمت مدیریت کوي، نه له هوسټ څخه، بیا اپلیکیشن ته اړین انټرنیټ لاره جلا وګورئ۔ په مدیریت کې بریا یو لوری ثابتوي او د وتلو په اړه هېڅ نه وایي۔

له بیا جوړېدو وروسته یې بیا وازموئ۔ بدل شوی شبکه‌ایز مالک هغه نوم‌ځای بدلوي چې اپلیکیشن ورته نښلېږي، او هغه URL چې له تازه‌والي مخکې کار کاوه ممکن وروسته هېڅ ته اشاره ونه کړي۔ خپره شوې نقشه او د تړلو پته ولیکئ ترڅو بله بیا جوړونه بیا څېړنه نه، بلکې د دوو دقیقو کتنه وي۔