له OpenVPN سره وصل یاست خو هېڅ نه بارېږي: له کلاینټ څخه بهر ته یوه مزل

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

له کلاینټ پیل کړئ او بهر ته لاړ شئ

په دې ترتیب درې ازموینې وکړئ او ولیکئ چې لومړی چېرته ناکامېږي. د سرور د ټانل پتې ته ping وکړئ، چې دا ثابتوي ټانل پخپله ټرافیک وړي. د یوې عامه پتې ته په شمېره ping وکړئ، چې د نوم حل پرته لېږد او ژباړه ثابتوي. بیا هڅه وکړئ یو کوربه نوم حل کړئ، چې یوازینۍ ازموینه ده چې DNS کاروي. هر نتیجه له شک څخه یوه بشپړه طبقه لرې کوي.

دریمې ازموینې ته مه ورځئ ځکه براوزر ګړندی ښکاري. ناکامه پاڼه لوډول درې واړه طبقې یوځای پټوي، او له همدې ځایه خلک پیل کوي او بیا یو کارکوونکی ټانل له سره جوړوي. ناکامه پاڼه نه وایي چې له درېیو کومه ماتې شوې.

دوه نیول ښیي چې پیکټونه چېرته درېږي

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

sudo tcpdump -ni tun0 -c 20 icmp
sudo tcpdump -ni enp1s0 -c 20 icmp

که غوښتنې په ټانل کې ښکاره شي او په پورتنۍ لینک کې هېڅکله نه، نو سرور هغه د ټانل او تار ترمنځ غورځولي، او لامل لېږد یا د لېږد د اوروال ننوتل دي، نه NAT. که په دواړو کې ښکاره شي، سرور خپله برخه کړې او ځواب نور بهر ورک شوی، چې ژباړې، پورتنۍ فلټر یا د برابرونکي اړخ ته محدودیت ته اشاره کوي.

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

ip -4 route get 9.9.9.9

په هغه وتنه کې د dev ډګر هغه نوم دی چې NAT قاعده به یې وروسته اړتیا ولري، نو ساتل یې کړئ.

لېږد په کرنل کې یو سویچ او د اوروال یوه تګلاره ده

کرنل باید په لومړي سر کې د لېږد سره موافقه وکړي. اوسنی ارزښت ولولئ، بیا ترتیبات تلپاتې کړئ پر ځای چې یوازې په چلېدونکي کرنل کې یې ولیکئ:

sysctl net.ipv4.ip_forward
printf 'net.ipv4.ip_forward=1\n' > /etc/sysctl.d/70-vpn-forward.conf
sysctl --system

لېږد یوازې نیمې برخې دي. په UFW لرونکي کوربه کې د لېږد تګلاره په /etc/default/ufw کې ټاکل کیږي او باید ACCEPT وي تر څو بیا لوستل اغیزه وکړي. د لېږد په لاره کې تلواله غورځول لاس ورکول په بشپړ ډول روغ ساتي خو هره هغه پیکټ چې د ټانل څخه د وتلو هڅه کوي په چوپتیا غورځوي، او دا هغه نښه ده چې تاسو پیل کړې وه.

هغه کوربه چې nftables مستقیم مدیریتوي همدا پوښتنه په بله نحوه لري. د کلاینټ د ازموینې په مهال د لېږد د زنځیر شمېرونکي وګورئ، ځکه هغه زنځیر چې پوښتل کیږي او هغه چې غورځوي په کنفیګریشن فایل کې ورته ښکاري.

په NAT قاعده کې ریښتینی وتونکی انټرفیس ونوموئ

د سرچینې ژباړه هغه انټرفیس ته اړه لري چې واقعاً کوربه پرېږدي، د هغه پول سره چې سرور یې ویشي. د دې قاعدې دواړه نیمې باید واقعیت بیان کړي، او هېڅ یوه یې اختیاري نه ده.

iptables -t nat -A POSTROUTING -s 10.44.0.0/24 -o enp1s0 -j MASQUERADE

کلاسیکه ناکامي هغه قاعده ده چې له لارښود څخه کاپي شوې او -o eth0 وایي په هغه ماشین چې اډاپټر یې بل نوم لري. قاعده پرته له خبرداري نصبېږي، له هېڅ سره سمون نه خوري، او کلاینټ لا هم انټرنېټ نه لري. پول د همدې تېروتنې بله نیمه ده: که سرور 10.44.0.0/24 وویشي او قاعده 10.8.0.0/24 پوښي، نو هېڅکله به هېڅ سمون ونه خوري.

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

iptables -t nat -L POSTROUTING -v -n

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

که سرور د ورېځې NAT نمونه هم وي، پلیټفارم هم خبره لري. هغه نمونه چې پتې ژباړي معمولاً اړتیا لري چې د سرچینې او منزل کتنه غیر فعاله وي چېرته چې برابرونکی هغه ترتیب وړاندې کوي، او د VPN پورټ پخپله باید له بهره ورسیږي.

DNS د لومړي تر شا دوهمه ناکامي ده

په پتې ping کول چې کار کوي خو نومونه ناکامېږي د حل کوونکي ستونزه ده، او خپل لامل لري. هغه کلاینټ چې خپل سیمه‌ییز حل کوونکی ساتي هغه پوښتنې په بشپړ ټانل کې لېږي او د هغه ځواب انتظار کوي چې هېڅکله نه راځي، ځکه سیمه‌ییز حل کوونکی اوس د لارې په غلط اړخ کې دی.

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

push "dhcp-option DNS 9.9.9.9"
push "dhcp-option DNS 149.112.112.112"

Windows کلاینټونه بیا هم کېدای شي سیمه‌ییز حل کوونکي ته ورستانه شي، او block-outside-dns همدې ته د مخنیوي لپاره دی، خو په دې بیه چې هغه نومونه ورک شي چې یوازې سیمه‌ییز شبکه یې حل کولی شي. systemd-resolved لرونکي Linux کلاینټونه ډېری وخت لېږل شوی حل کوونکی له پامه غورځوي پرته له دې چې سکریپټ یې نصب کړي، نو د دې پایلې دمخه چې لېږل له پامه وغورځېدل، د ټانل وسیلې لپاره resolvectl status وګورئ.

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