په UFW کې د VPN NAT د before.rules په کوم ځای کې ځای پرځای کېږي او څنګه یې ازموینه وکړو
په before.rules کې د NAT کرښه باید د COMMIT سره په سمه جدول برخه کې وي۔ د UFW له بیا بارولو مخکې نوماند د iptables-restore --test سره تحلیل کړئ۔
د NAT هغه قاعده چې په شیل کې د ټایپ کولو پر مهال کار کوي، په before.rules کې د پیسټ کولو پر مهال ناکامه شي، ځکه چې هغه فعال یو سکرپټ نه دی۔ دا د بیا رغولو په بڼه یو سند دی چې د جدولونو برخې، د زنځیرونو اعلانونه او د هر جدول لپاره د COMMIT نښه لري۔ په غلط ځای کې کرښه یا ټول بیا رغول بندوي یا هغه قواعد په خاموشۍ سره غورځوي چې تاسو یې شتون ته باور درلود۔ لاندې لارښود ټوټه هغه ځای کې ږدي چې چوکاټ یې تمه لري او پایله د بل بیا بارولو مخکې ثابتوي۔
د شیل فرمان د بیا رغولو فعال نه دی
هغه کرښه چې په iptables -t nat پیلېږي، د iptables بائنري لپاره لارښوونه ده، په داسې حال کې چې هغه فعال چې UFW یې لولي د بشپړ قواعدو ټولګې تشریح ده۔ توپیر ښکاري نه دی: د بیا رغولو بڼه باید پوه شي چې په کوم جدول کې ده، کوم زنځیرونه شته او جدول چېرې پای ته رسېږي۔ په هغه سند کې پیسټ شوې فرمان یا د نحو غلطي ده یا، له هغې هم بدتره، د غلط جدول سره تړل شوې قاعده۔ چوکاټ دا فعالونه د بیا رغولو د وسایلو له لارې باروي ځکه چې دوی اعلانیه دي نه پرلهپسې۔
سند په ټولیز ډول هم بارېږي، نو یوه خرابه برخه کولای شي د پاتې فعال تطبیق بند کړي۔ له همدې امله په NAT ټوټه کې یوه کوچنۍ غلطي د فلټر قواعد هم له ځانه سره راښکته کوي، او همدا راز د اورېدېوال بدلون یو خنډ ګرځي۔
ټوټه د موجودې جدول برخې دننه کېږدئ
د NAT ټوټه یوه بڼه لري، او بڼه له دننه د قاعدې له متن څخه مهمه ده۔ د جدول سرلیک برخه پرانیزي، د زنځیرونو اعلانونه شمارونکي ټاکي، قواعد وروسته راځي، او COMMIT برخه بندوي۔
*nat
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -s 10.55.0.0/24 -o ens3 -j MASQUERADE
COMMIT
پورته حوض او انټرفیس ستاسو د ارزښتونو لپاره ځای نیوونکي دي؛ د کاپي کولو وړ برخه جوړښت دی۔ که فعال لا دمخه *nat برخه لري، قاعده د هغې برخې دننه اضافه کړئ نه دا چې دوهمه پرانیزئ، ځکه چې بڼه د هر جدول لپاره یو COMMIT تمه لري او د یو جدول لپاره دوه برخې هغه ترمیم دی چې د پېښېدو په تمه دی۔ د وېش د زنځیرونو تعریفونه نه لمس شوي وساتئ، په شمول هغه چې پلورونکي د خپل ادغام لپاره اضافه کړي دي۔ د UFW چوکاټ لارښود before، user او after فعالونه او د سمونکي COMMIT اړتیا مستندوي۔
که فعال خالي وي، له یوه درس څخه یې مه ډکوئ۔ تایید کړئ چې کوم پیکج یې مالک دی او ژوندۍ تګلاره په حقیقت کې څه ده، ځکه چې خالي دوامداره فعال د دې ثبوت نه دی چې کرنل کوم قواعد نه لري، او بار شوې قواعدو ټولګه د دې ثبوت نه ده چې بل بیا بارول به د لوستلو لپاره بشپړ فعال ولري۔ لومړی ملاتړ شوې بنسټیزه کرښه بحال کړئ، بیا پر هغې د سایټ بدلونونه بیا تطبیق کړئ۔
نوماند پرته له تطبیق وازموئ
د بیا رغولو وسیله کولای شي یوه قواعدو ټولګه پرته له تطبیق تحلیل او جوړه کړي، او دا تر ټولو ارزانه ګڼه ازموینه ده۔ هغه په ژوندي فعال باندې نه، بلکې په ساتل شوې کاپي باندې وچلوئ، او یوازې د وتلو حالت نه بلکې د غلطۍ متن ولولئ۔ د تحلیل ناکامي یوه کرښه او معمولاً یو جدول نوموي، چې له هغه څخه ډېر دی چې ناکامه بیا بارول به یې ووایي۔
sudo cp /etc/ufw/before.rules /root/before.rules.bak
sudo iptables-restore --test < /root/before.rules.bak
echo "exit: 0"
د هغې ګڼې پاس کول ثابتوي چې سند تحلیلېږي او نور هېڅ نه۔ دا نه ثابتوي چې نوماند لا هم هرهغه زنځیر لري چې UFW پرې تکیه کوي، چې یوازې ستاسو د نیت شوو سرچینو اجازه ورکوي، یا چې لرې مدیریت د لاسرسي وړ پاتې کېږي۔ دا جلا کتنې دي، او وروستۍ یې د دوهمې ناستې وړ ده چې له پیل مخکې پرانیستل شي۔
هغه وسیله وټاکئ چې له نصب شوي بیکاینډ او د پتې کورنۍ سره سمون ولري۔ هغه کوربه چې nft بیکاینډ د مطابقت طبقې له لارې چلوي، اړوند فرمان ته اړتیا لري، او IPv6 قواعد په بشپړه توګه بل فعال کې ژوند کوي۔
لیږد، NAT او د لاسرسي تګلاره جلا وساتئ
د سرچینې ژباړه د پتې ستونزه حل کوي او هېڅ نه ورکوي۔ لیږد یوه جلا اجازه ده چې sysctl او د فلټر جدول یې کنټرولوي، او همدا هغه ده چې خلک یې هېروي کله چې تونل لارښوونه کوي خو تګ راتګ نه تېروي۔ د لاسرسي تګلاره درېیمه پرېکړه ده چې کومې سرچینې کومو خدمتونو ته رسېدلی شي، او هېڅ د NAT قاعده یې نه بیانوي۔ همدا درېیمې جلا ساتل دي چې ناکامي د یوې مبهمې نښې پر ځای د تشخیص وړ ګرځوي۔
sysctl net.ipv4.ip_forward
sudo iptables -t nat -S POSTROUTING
sudo iptables -S FORWARD
هغه درې پایلې یوځای ولولئ، نه یوه په یوه۔ د لیږد له غیرفعالېدو سره د masquerade قاعده هغه کلاینټ جوړوي چې نښلېږي خو چېرې هم نه رسېږي، چې د کلاینټ له اړخه په ټولیزه توګه د لارښوونې خرابۍ په څېر ښکاري او خلک غلط فعال ته لیږي۔ د فلټر جدول هم هغه ځای دی چې ډېر پراخ accept پکې پټېږي، نو هلته اوسئ چې د هغې تلواليزه تګلاره هم وګورئ۔
بیا بارول، رد او د VPN له لاسه ورکول تایید کړئ
درې کتنې یوه بشپړه د منلو ازموینه جوړوي: بیا بارول بریالي کېږي، اجازه شوې کلاینټ عملیات کار کوي، او هغه غوښتنه چې باید رد شي په رښتیا ردېږي۔ درېیمه هغه ده چې پرېښودل کېږي، او یوازینۍ شواهد دا دي چې تګلاره په ټولیزه توګه څه کوي۔
sudo ufw reload
sudo ufw status verbose
sudo iptables -t nat -L POSTROUTING -n -v
بیا هغه ناکامي وازموئ چې ستاسو لپاره ډیزاین شوې۔ تونل وغورځوئ او وګورئ چې کوربه څه کوي، ځکه چې هغه تګلاره چې یوازې تر هغه پورې کار کوي چې VPN فعال وي، د ناڅرګندې تکینې سره تګلاره ده۔ وروسته یو ځل بیا بار کړئ ترڅو ثابت شي چې کاري پایله فعال ورکوي، نه کوم پاتې چلېدونکی حالت۔
د IPv4 NAT د IPv6 په اړه هېڅ نه وایي، نو د قاعدې سره په همدې یادښت کې د دواړو کورنیو لپاره د نیت شوې پوښښ یادونه وکړئ۔ موخه یوه منسجمه مدیریت شوې تګلاره ده، او هغه ټوټه چې ناڅاپه تحلیل شوې د هغې ثبوت نه دی۔