UFW د VPN د DNS سرور له منځه وړي کله چې تونل پورته شي
د UFW ډیفالټ انکار تګلاره د تونل انټرفیس هم پوښي. ترافیک د لوري له مخې ترتیب کړه، فشار شوی resolver ته په tun0 اجازه ورکړه، بیا بهرنۍ لاره پرانیزه.
نومونه هغه شېبه چې VPN وصل شي حل کېدل بندوي، په داسې حال کې چې عامه پتې ته ping لا هم ځواب ورکوي او د فایر وال حالت کې هغه څه نه ښکاري چې غلط ښکاره شي. په تګلاره کې هېڅ نه دی بدل شوی؛ بدل شوی دا دی چې نوی انټرفیس راغی، او ډیفالټ انکار له لومړي پاکټ څخه ورته رسېږي. UFW د لوري او انټرفیس له مخې پرېکړه کوي، نو د بې سیمې اړیکې لپاره لیکل شوې قاعده د تونل څخه وتونکي ترافیک په اړه هېڅ نه وایي. سمون څو تنګ قواعد دي چې په ټاکلې ترتیب پلي کېږي.
نښه یوازې د تونل له پورته کېدو وروسته ښکاري
د ډیفالټ انکار تګلاره هغه څه کوي چې ورته ویل شوي: هر هغه څه چې سمونکی قاعده نه لري رد کېږي، په هر هغه انټرفیس چې شتون لري. کله چې قواعد لیکل کېدل تونل نه و، نو هېڅ یو یې نشي کولی هغه ونیسي، او هغه انکار چې تل هلته و اوس د نومونو حل ته تطبیق کېږي. یوازې پتې ته مستقیم ترافیک بیا هم کار کولی شي کله چې پراخه اجازه یې پوښښ کوي، او له همدې امله عامه resolver ته ping بریالی کېږي خو د نوم لټون ناکامېږي. تشه د هغه انټرفیس لپاره قاعده ده چې تګلارې هېڅکله نه دی لیدلی.
دا هم تشریح کوي چې ولې ناکامي پاکه بېرته ګرځي: تونل ښکته کړه او نومونه بیا حل کېږي، ځکه چې پوښتنه هغه انټرفیس ته بېرته ځي چې قواعد لري. هغه تګلاره چې یوازې د تونل پورته والي پر مهال ناکامېږي DNS ستونزه نه ده، او resolver پخپله تنظیمول دلته تر ټولو ډېر وخت ضایع کوي. د resolver ترتیب لوستلو دمخه د انټرفیسونو لیست ولوله.
درې لوري، درې بېلابېلې قاعدې
یوه ناسته په یو څخه زیاتو لورو کې قاعدو ته لاس ورکوي، او تونل نږدې هر یو ته دویم انټرفیس ورزیاتوي. که ترافیک لومړی د لوري او انټرفیس له مخې ترتیب کړې، پاتې برخه میخانیکي کېږي، ځکه هر لاندې کرښې ته خپله قاعده په خپل ځای کې اړینه ده. بېلګې tun0 او د 10.8.0.0/24 حوض کاروي، نو نومونه او سیمې د کلاینټ خپل تولید څخه بدل کړه.
| Direction | Example packet | Rule that admits it | Written on |
|---|---|---|---|
| Client to the pushed resolver | A DNS query to 10.8.0.1 | Destination port 53 over the tunnel | The client's tun0 |
| Client to the VPN server | A handshake to the server's public address | Server address and port on the physical link | The client's physical interface |
| Server to a service | SSH from the pool to port 22 | Source pool, destination port, tunnel interface | The server's tun0 |
| Anyone to the listener | The VPN listener itself | 1194/udp on the public side | The server's public interface |
دوه کرښې ډېری وختونه ګډېږي ځکه چې دواړه تونل یادوي. د resolver قاعده هغه ترافیک اجازه کوي چې کلاینټ تونل ته لیږي، خو د SSH قاعده هغه ترافیک اجازه کوي چې سرور له هغه ځایه ترلاسه کوي؛ دوی په بېلابېلو ماشینونو کې ژوند کوي او په خپلواکه توګه ناکامېږي. هغه کرښه چې تر ټولو ډېره هېرېږي دویمه ده، ځکه کلاینټ نشي کولی تونل جوړ کړي تر څو چې د سرور عامې پتې ته د هغه ترافیک اجازه ورکړل شي. له پورته څخه ښکته کار وکړه او هر ناکامي یو احتمالي لامل لري.
د فشار شوی resolver خپله قاعده غواړي
دا چې تونل DNS وړي که نه، په دې پورې اړه لري چې سرور څه لیږي. هغه سرور چې د resolver اختیار فشاروي، په کلاینټ ترتیب کې شخصي پته نصبوي، او هغه پته یوازې د تونل له لارې لارښود کېدای شي. که سرور هېڅ فشار نه کوي، کلاینټ هغه resolver ساتي چې مخکې یې درلود او لاندې قاعدو ته د اجازې ورکولو څه نه وي. د یو څه لیکلو دمخه فشار شوې حالت او اوسنی پوښتنې پایله وګوره:
dig +short @10.8.0.1 example.com
resolvectl status tun0
sudo ufw status numberedد حالت تولید کارېدونکی resolver او هغه لینک چې تړلی یې دی نوموي، او د هغه شاته د لارې لټون ښیي چې کوم انټرفیس به هغې پتې ته پوښتنه وړي. کله چې resolver په بل لینک وي، ستونزه د فایر وال څخه مخکې ده او هېڅ قاعده به مرسته ونه کړي. کله چې دواړه د تونل په اړه سره یو ځای شي، دوې قاعدې ته اړتیا ده، ځکه UDP ډېری پوښتنې وړي او TCP کله چې ځواب پرې شي مسؤلیت اخلي. دواړه ارزښتونه ولیکه، ځکه قاعدې به همدغو ته نوم ورکړي:
sudo ufw allow out on tun0 to 10.8.0.1 port 53 proto udp comment 'pushed resolver'
sudo ufw allow out on tun0 to 10.8.0.1 port 53 proto tcp comment 'truncated answers'تر کورني لارې دمخه بهرنۍ لاره پرانیزه
کلاینټ باید د سرور عامې پتې ته ورسیږي تر څو چې تونل شتون ولري، نو د هغې قاعده په فزیکي لینک کې کېني او باید لومړی په خپل ځای کې وي. هغه تګلاره چې resolver ته اجازه ورکوي خو سرور هېروي، کلاینټ په بشپړه توګه د تونل د جوړولو څخه بې وسه پرېږدي، او دا نښه معمولا kill switch ته منسوبېږي. بیا هغو خدمتونو ته اجازه ورکړه چې واقعا یې د تونل له لارې غوښتل، په یو وخت کې یوه تنګه قاعده، د انټرفیس په بشپړه خلاصولو پرځای. تنګې قاعدې هغه لامل دي چې انکار یې په خپل ځای کې پاتې کېدای شي.
sudo ufw allow out to 198.51.100.10 port 1194 proto udp comment 'vpn server'
sudo ufw allow out on tun0 to any port 443 proto tcp comment 'web through tunnel'په ازموینه کې ترتیب مهم دی، ځکه لومړنۍ قاعده هغه ده چې تونل ته د پورته کېدو اجازه ورکوي. هغه اضافه کړه، وصل شه، او د خدمت قاعدې له اضافه کولو دمخه ډاډ ترلاسه کړه چې تونل پورته دی، ځکه دواړه یو ځای کول دا معنا لري چې ناکامي هېڅ نه وایي چې کومه نیمه غلطه ده. پورتنۍ اسنادي پته هغه پای ټکي ته بدله کړه چې کلاینټ ورته ترتیب شوی.
د کلاینټ خوا په قصدې توګه د اړیکې پرې کولو سره بشپړه کړه. انکار باید لا هم هغه ترافیک رد کړي چې قصداً مو ایستلی، ځکه هغه resolver چې د تونل پورته والي پر مهال ځواب ورکوي یوازې د هغې تګلارې نیمه برخه پوښي چې په شک کې انکار کوي.
هغه کلاینټ چې وصل شي لا نه دی منل شوی
سرور خپل لوری لري چې باید په پام کې ونیول شي، او هغه کلاینټ چې لاس ورکول بشپړوي لا هم نشي کولی په سرور کې چلېدونکي هېڅ شي ته ورسیږي تر څو چې سرور هغه ومني. د عام اورېدونکي قاعده یوازې تونل ته د شتون اجازه ورکوي؛ دا د تونل ترافیک نه پرېږدي چې دننه شي. په سرور کې دا دوه قاعدې او یوه ازموینه چې خدمت واقعا اورېدل کوي:
sudo ufw allow 1194/udp comment 'openvpn listener'
sudo ufw limit in on tun0 from 10.8.0.0/24 to any port 22 proto tcp comment 'admin over tunnel'
ss -ltn | grep ':22'په قاعده کې حوض باید هغې سیمې سره برابر وي چې سرور یې ځانګړې کوي، او د تونل شمېره باید د سرور جوړې شوې سره سمه وي، ځکه د بل انټرفیس لپاره قاعده د قاعدې له نه شتون څخه نه بېلېدای شي. limit د اداري پورټ لپاره قصداً دی، ځکه تکراري اړیکې پرته له حد منلو محدودوي. د اورېدونکي ازموینه تړلی پورټ له غورځول شوي پاکټ څخه بېلوي، چې له کلاینټ څخه یو شان ښکاري. شمېرل شوې قاعدې هم بشپړه انځور نه ده: د UFW before قاعدې او هر لاسليک شوی nftables کرښه مخکې سمونږي او لا هم کولای شي هغه پاکټ رد کړي چې لیست یې د اجازې ورکوونکي په څېر ښکاري.