د VPN کلاینټ خدمت ته رسیدل: برعکس تونل یا DNAT
د پورټ فوروارډینګ پرته د OpenVPN کلاینټ خدمت ته رسیدل: برعکس SSH تونل د سرور اړخ DNAT او د انتخاب کولو درې شرطونو سره پرتله کړئ۔
حتی د کیریر NAT شاته لپ ټاپ هم کولی شي یو همکار ته خدمت وکړي، یوازې دا چې VPN سرور د لیدنې ځای وي۔ هلته دوه میکانیزمونه رسیږي: کلاینټ بهر ته ډایل کوي او له سرور څخه غواړي چې یو اوریدونکی پورټ وساتي، یا سرور یو پورټ خپروي او تونل ته یې ژباړي۔ دواړه ورته رسیدو ستونزه حل کوي او د ناکامۍ، څارنې او لاګ کولو پر مهال بېل چلند کوي۔ ستاسو په ترتیب کې کوم یو ځای لري، دا درې شرطونه فیصله کوي۔
دوه بڼې، یو د لیدنې ځای
په لومړۍ بڼه کلاینټ بهر ته SSH ناسته پرانیزي او له سرور څخه غواړي چې په ټاکل شوي پورټ اوریډي، او هر اړیکه د هماغه ناستې له لارې بېرته لیږي۔ په سرور کې هیڅ نه فوروارډ کیږي او د پاکیټ ژباړه نه کیږي، نو یوازینۍ اړتیاوې SSH حساب، اجازه شوې فوروارډینګ او د پورټ لپاره د اورېدې دېوال قاعده ده۔ خدمت په کلاینټ کې له loopback سره تړلی پاتې کیږي، چې معمولاً هماغه دی چې غواړئ۔
ssh -N -R 8081:127.0.0.1:8080 -o ExitOnForwardFailure=yes -o ServerAliveInterval=30 [email protected]
په دوهمه بڼه عام پورټ د سرور ملکیت دی او هره اړیکه د کلاینټ د تونل پتې په لور بیا لیکي۔ دغه کار د IP فوروارډینګ فعالول، د ننوتلو پر مهال د منزل ژباړه او د وتلو پر مهال د سرچینې ژباړه غواړي، او کله چې هیڅ SSH ناسته نه وي هم کار کوي۔ پورټ د ناستې نه، د سرور دی، او همدا ځانګړنه د ډیرو ریښتینو حالاتو فیصله کوي۔
دواړه بڼې په جوړښت کې خوندي نه دي۔ دواړه یو خدمت پورټ هغه هر چا ته ښکاره کوي چې د سرور عامې پتې ته رسیږي، او دواړه لا هم د خدمت په خپله تصدیق پورې تړلي دي۔
لومړی شرط: ایا پورټ باید له ناستې اوږد ژوند وکړي
برعکس فوروارډینګ هومره ژوند کوي څومره هغه SSH ناسته چې جوړ کړی یې دی۔ کله چې تړاو ولوېږي، اوریدونکی ورک شی او همکار د ورو لارې پر ځای رد شوې اړیکه ویني۔ د systemd واحد او د بیا پیل تګلارې سره د حکم څارنه دا حل کوي، او ExitOnForwardFailure=yes ناکام تړل سمدلاسه ښکاره کوي، د فوروارډینګ پرته روانه ناسته پرېښودلو پر ځای۔
ژباړل شوی پورټ که قواعد خوندي وي بیا پیلونه هم برداشت کوي، مګر دا په دې پورې تړلی دی چې کلاینټ هماغه د تونل پته وساتي۔ هغه متحرک حوض چې له بیا نښلیدو وروسته لپ ټاپ ته بله پته ورکوي، قاعده په چوپتیا سره هېڅ ته نه رسوي۔ لومړی د تونل پته خوندي کړئ، بیا قاعده ولیکئ، او دواړه د یو بدلون په توګه وګورئ۔
که خدمت باید د شپې درې بجې پرته له کوم څارونکي ځواب ورکړي، د سرور خپرې شوې پورټ لرونکې بڼه لږ خوځنده برخې لري، ځکه یوازینی پروسه چې باید روانه پاتې شي پخپله تونل دی۔
دوهم شرط: اورېدې دېوال او لاګونه د چا دي
برعکس بڼه ټوله تګلاره په دوو ځایونو کې ساتي۔ sshd د AllowTcpForwarding له لارې فیصله کوي چې لرې فوروارډینګ په ټولیز ډول اجازه لري که نه، او GatewayPorts فیصله کوي چې اوریدونکی له loopback یا له هرې پتې سره تړل کیږي۔ په اصلي ارزښت no سره د سرور بهر همکار د فوروارډینګ بریالي کیدو سره سره پورټ ته نه رسیږي، او دا مات شوی تونل ښکاري حال دا چې په رښتیا د تړلو پته ده۔
sudo ss -ltn '( sport = :8081 )'
sudo grep -E '^(GatewayPorts|AllowTcpForwarding)' /etc/ssh/sshd_config
ژباړل شوې بڼه فعال فوروارډینګ او دوه قواعد غواړي، او دوهم قاعده هغه ځای دی چې ډیری لارښوونې غلطیږي۔ د سرچینې ژباړه د conntrack د DNAT حالت پورې محدودول یعنې یوازې هغه اړیکې بیا لیکل کیږي چې د منزل قاعدې جوړې کړې دي، نه هره هغه پاکیټ چې سرور تونل ته لیږي۔
sudo sysctl -w net.ipv4.ip_forward=1
sudo iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 8081 -j DNAT --to-destination 10.88.0.6:8080
sudo iptables -t nat -A POSTROUTING -o tun0 -m conntrack --ctstate DNAT -j SNAT --to-source 10.88.0.1
هماغه بیا لیکنه د نسبت ورکولو هم ورانی کوي۔ له هغې وروسته کلاینټ هر زنګ وهونکی د سرور د تونل پتې په توګه ویني، چې د هرې پتې لپاره هر ډول د سرعت حد په یوه بالټي کې یوځای کوي او پټوي چې چا څه لیږلي۔ که نسبت ورکول مهم وي، اړیکه په سرور کې پای ته ورسوئ یا د اجازې پرېکړه هلته وساتئ او هویت په هغه سرلیک کې ولیږئ چې خدمت باور پرې لري۔ د دغو دوو سمونو ترمنځ انتخاب په دې پورې تړلی دی چې خدمت اصلاً د پروکسي سرلیک لولي که نه۔
دریم شرط: یو پورټ یا ډیر، او نوم د چا دی
په یوه پورټ یو خدمت هغه حالت دی چې هڅې کې برعکس فوروارډینګ ګټي۔ یو حکم، یو حساب او یوه اورېدې دېوال قاعده ته اړتیا لرئ، او پاکول یعنې ناسته وژل۔ په ورته عامه پته ډیر خدمتونه تاسو د سرور خپرې شوې بڼې په لور ټېل وهي، ځکه هر برعکس فوروارډینګ خپل سرور پورټ ته اړتیا لري او ټولګه له هر خدمت سره لوېږي۔
نومونه دا نور هم پېچلي کوي۔ برعکس فوروارډینګ کولی شي د TCP پروکسي شاته وي چې د SNI له مخې لارښونه کوي، حال دا چې ژباړل شوی پورټ معمولاً د هر خدمت لپاره یو پورټ دی۔ که خدمت پخپله TLS پای ته ورسوي او اصلي کوربه نوم ته اړتیا ولري، پروکسي طریقه هغه ساتي، او DNAT طریقه یې یوازې هغه وخت ساتي چې خدمت هغه نوم په هغه پورټ کې ومني۔
ولیکئ چې درې شرطونو کوم یو بڼه فیصله کړه۔ که نه، د دوهم خدمت اضافه کوونکی بل کس به هماغه پرتله له لږ زمینه سره بیا پرانیزي۔
پریکړه وکړئ، بیا له بهر څخه ازموینه وکړئ
لاره له هغه شبکه څخه ازموئ چې لپ ټاپ ته هیڅ لاره نه لري، او د غوښتنې د اجرا پر مهال په سرور کې کاونټرونه وګورئ۔ له سرور څخه د هغه خپلې عامې پتې په لور ازموینه دلته هیڅ ثابتوي نه، ځکه پاکیټ په ځایي ډول جوړیږي او هیڅکله د ننوتلو د ژباړې هنګ ته نه رسیږي، نو ازموینه کولی شي بریالۍ شي حال دا چې ریښتینې لاره ماته ده۔
sudo iptables -t nat -L PREROUTING -n -v
sudo tcpdump -ni any 'tcp port 8081' -c 20
هغه کاونټرونه چې ثابت پاتې کیږي یعنې پاکیټ هیڅکله قاعدې ته نه دی رسیدلی، چې د برابرونکي یا د کوربه اورېدې دېوال په لور اشاره کوي۔ هغه کاونټرونه چې د خدمت د انکار پر مهال خوځیږي، د کلاینټ خپل اورېدې دېوال یا هغې پتې په لور اشاره کوي چې خدمت پرې اوري۔ هغه تونل چې پاکیټ وړي خو هیڅ نه بېرته ورکوي، د لارې یا برعکس لارې ستونزه ده، او د دغو درېو پایلو هیڅ یوه هم د کلاینټ اډاپټر په سمون سره نه باید اصلاح شي۔ دمخه له هر بدلون څخه ولیکئ چې کوم کاونټر وخوځېد، ځکه بلې ازموینې ته هماغه بنسټ کرښه اړینه ده۔
کله چې بڼه کار وکړ، پورټ، مالک او د څارنې طریقه د تونل ترتیب ته څنګه ثبت کړئ۔ هغه رسیدو سمون چې یوازې د چا په شیل تاریخ کې وي، یو بیا پیل د تکراري پېښې څخه لرې دی۔