له بریج شويو OpenVPN کلاینټونو سره انټرنیټ نشته؟ د NAT قاعده وګورئ

بریج شوی سرور فعال دی، masquerade قاعده شته، او بیا هم په کلاینټ کې براوزر څرخي. هر څه داسې ښکاري چې باید کار وکړي، ځکه لومړی ساعت د تونل او اعتبارنامې په کتلو تېرېږي. بیا د NAT قاعدې شمارونکی لولئ او یو صفر وینئ چې نه دی خوځېدلی. هغه قاعده چې هېڅکله یې یو پیکټ هم نه دی شمېرلی، هېڅکله له یوه سره نه ده ګډه شوې، او په بریج شوي سرور کې لامل جوړښتي دی: د کلاینټ ترافیک د مجازي tap وسیلې له لارې وځي، خو قاعده هغه فزیکي کارت نوموي چې تاسو له زاړه لارښود څخه کاپي کړی و.

شواهد شمارونکی دی، نه د جدول ثبت

شته قواعد او ګډېدونکې قواعد بېلې خبرې دي، او شمارونکی هغه څه دی چې بېلوي یې. د NAT جدول په تفصیلي شمارونکو سره ولیکئ او د هرې قاعدې ترڅنګ شمېرې ولولئ، مخکې له دې چې څه بدل کړئ. شمارونکی چې ترافیک روان وي او په صفر ولاړ وي، مانا دا ده چې قاعده پرېښودل شوې، هر څومره چې پته یې سمې ښکاره شي. شمارونکی چې پورته ځي خو اړیکه بیا هم ناکامېږي، تاسو بل ځای ته استوي: فوروارډینګ، د بېرته راتلو لار، یا لرې سر.

iptables -t nat -L POSTROUTING -v -n

لومړی د انټرفیس ګډېدو ترڅنګ شمارونکی ولولئ. که د سرچینې ساحه سمه او د وتلو اړخ غلط وي، سمون په قاعده کې یوه کلمه ده، نه بشپړه نوې قاعده.

هغه نوم ومومئ چې کرنل یې په رښتیا ثبتوي

مخکې له دې چې قاعده ولیکئ، د تونل وسیلې نوم د انټرفیسونو له لیست څخه وټاکئ، نه له حافظې. په بریج شوي OpenVPN ترتیبدا کې وسیله معمولاً هغه tap انټرفیس دی چې سرور جوړ کړی، او نوم یې ستاسو د سیمه ایز ترتیب برخه ده، نه یو نړیوال ثابت. ډاډ ترلاسه کړئ چې تونل فعال وي او وسیله شته، ځکه هغه وسیله چې یوازې د کلاینټ له نښلېدو وروسته ښکاري، پخوانۍ ازموینه به د قاعدې ستونزه ښکاره کړي.

ip -brief link

نوم ولیکئ. په دې تشخیص کې هر وروستی حکم هماغه ته اشاره کوي، او دلته د ټایپ غلطي بېخي هغه صفر شمارونکی جوړوي چې اصلي غلطۍ جوړ کړی و.

قاعده د تونل وسیلې لپاره بیا ولیکئ

قاعده تونل وسیلې ته وګرځوئ او د کلاینټ ساحه د ګډېدو شرط په توګه وساتئ، تر څو تونل ترافیک پوښي او د هوسټ خپلې اړیکې پرې نه ږدي. خپله ساحه او د وسیلې نوم ورکړئ، ځکه دواړه لاندې بېلګې دي او هېڅ یو هم د نصبونو ترمنځ نه لېږدېږي.

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o tap0 -j MASQUERADE

بیا هغه دوه نور شرایط وګورئ چې همدا نښه یې پټوي. وګورئ چې فوروارډینګ فعال دی که نه، او که نه، نو د وېش د خپل ترتیب په داخل کې یې فعال کړئ، نه د echo له لارې چې د بیا پیلېدو وروسته ورکېږي. د forward ځنځیر شمارونکې هم ولولئ، او که هغه تونل ترافیک وغورځوي، هماغه انټرفیس په ځانګړي ډول اجازه ورکړئ او د ځنځیر تګلاره پرېنږدئ.

د forward ځنځیر له شمارونکو سره لوستل یو حکم غواړي او د بلې قاعدې له لمس مخکې نیمې پاتې امکانونه ردوي.

ولې فزیکي کارت هېڅکله نه ګډېږي

بریج یو سافټویر سویچ دی چې له tap وسیلې او یوه فزیکي انټرفیس څخه جوړ شوی. د کلاینټ فریم هغه سویچ ته ننوځي او د کارت پیکټ په توګه نه، بلکې د بریج غړي په توګه فزیکي شبکې ته وځي. نو کرنل پیکټ بریج او د هغې پورټ ته منسوبوي، ځکه هغه کارت چې تاسو یې فکر کاوه هېڅکله په ګډېدو کې نه ښکاري. په فزیکي انټرفیس کې هېڅ خراب نه دی؛ هغه یوازې هغه وسیله نه ده چې کرنل پیکټ ورته منسوبوي.

هغه ستونزه چې خلک وروسته ورسره مخامخ کېږي له همدې جوړښت څخه راځي: په بریج باندې د فریم فلټرول له IP فلټرولو څخه بېله اسانتیا ده. که اړتیا د فریم کچې محدودیت وي، هغه د بریج فلټرولو پورې اړه لري، نه د IP جدول قاعدې ته.

له پیل څخه تر پایه یې ثابت کړئ، بیا یې تلپاتې کړئ

یو کلاینټ پورته کړئ او د سرور په LAN کې څه پنګ کړئ؛ هغه لار فوروارډینګ پرته له کوم ژباړې ازموي. وروسته له هغه یو عام څه وغواړئ تر څو masquerade قاعده باید وکارول شي، او شمارونکی یو ځل بیا ولولئ: باید د دې ازموینې لپاره وخوځېږي، نه د پخوانۍ. په تونل وسیله اخیستل شوی کپچر ښيي چې فریم چېرته ښکاري او کومه پته لېږدوي.

وروستی ګام: کاروونکي قواعد په هغه ترتیب کې کېږدئ چې بیا پیلېدل یې لولي، او هغه د وسیلې نوم ولیکئ چې د دې هوسټ بریج یې په رښتیا کاروي. هر څه چې په لاس ولیکل شي د بیا پیلېدو وروسته ورکېږي، او هماغه خرابي بېرته راځي پرته له دې چې څه یې تشریح کړي.

که د بیا لیکلو وروسته هم شمارونکی نه خوځېږي، په قاعده کې د سرچینې ساحه له هغې پتې سره پرتله کړئ چې کلاینټ په رښتیا ترلاسه کړې، ځکه بریج شوی سرور کولای شي له هغې ساحې څخه پتې ورکړي چې تاسو یې اراده نه لرله.