د LAN خدمت خپرول د VPN ګېټوې پر خپل پته

د ګېټوې د خپلو تونل پتو په یوه کې د LAN وسیلې وړاندې کول یوازې د NAT یوې کرښې ته اړتیا لري۔ بیا هم اړیکه ناکامه کیږي، ځکه چې ځواب ورکوونکې وسیله نه پوهیږي چې د کليانټ پته د همدې ګېټوې له لارې د لاسرسي وړ ده۔ پاکټ له کليانټ څخه دننه خواته تعقیب کړئ، بیا ځواب بیرته بهر خواته تعقیب کړئ، او ورکه نیمه برخه څرګنده شي۔

د کليانټ له نظره پیل وکړئ

په دې بېلګه کې کليانټ د VPN حوض 10.62.0.0/24 کې ناست دی او په 8080 پورټ کې له 10.62.0.1 سره نښلیږي۔ هغه پته د ګېټوې خپله ده، نو پاکټ د بل همکار پر ځای د ګېټوې کرنل ته رسېږي۔ د ګېټوې شاته LAN 172.21.4.0/24 ده۔ ګېټوې 172.21.4.10 لري او هغه وسیله چې واقعاً HTTP خدمت کوي 172.21.4.40 ده۔

د بل VPN همکار پته د ګېټوې د خدمت پتې سره د بدلولو وړ نه ده۔ که کليانټ د همکار پتې سره نښلیږي، د ګېټوې هېڅ قاعده په کې ښکېله نه ده، او دا ټول سفر غلط حالت دی۔

د منزل ژباړې حد په قصد محدود کړئ

تنګه نسخه یو پورټ وړاندې کوي او یوازې منزل بیا لیکي۔ پاکټ خپل پروتوکول او خپل سرچینه ساتي، او همدا د پاتې سفر لامل ګرځي۔

iptables -t nat -A PREROUTING -i tun0 -s 10.62.0.0/24 -d 10.62.0.1 -p tcp --dport 8080 -j DNAT --to-destination 172.21.4.40:80

هغه قاعده چې د پروتوکول او پورټ معیارونه نلري پراخه نسخه ده: هغه هر هغه پورټ ساتي چې کليانټ ټاکلی وي او یوازې پته بدلوي۔ دا هغه وخت سمه ده چې ټول هوسټ وړاندې شي، او هغه وخت غلطه چې یو خدمت مقصد وي۔ قاعده بیرته ولولئ او د انټرفېس نوم تایید کړئ۔ په غلط انټرفېس کې DNAT قاعده له هیچا سره نه ځي، چې د نیمه قاعدې په څېر ورته وخت پای تولیدوي او د وسیلې ته په کتلو کې یو ساعت ضایع کوي۔

پرېږدئ چې د فوروارډ پوله سره موافقه وکړي

ژباړه سرلیک بدلوي، اجازه نه ورکوي۔ د پیشفرض رد سیاست سره فوروارډ شوي جریان خپله اجازه ته اړتیا لري، او د بیرته ستنېدو لوري ته د ټینګ شوي اړیکې هغه قاعده چې ستاسو په سیاست کې به مخکې موجوده وي۔

iptables -A FORWARD -i tun0 -o lan0 -d 172.21.4.40 -p tcp --dport 80 -m conntrack --ctstate NEW -j ACCEPT
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

د هر DNAT جریان لپاره بې شرطه اجازه له دې طرحې پراخه ده او هغه نقشه کول به هم اجازه ورکړي چې وروسته بل څوک یې اضافه کوي۔ منزل او پورټ ونوموئ، او پاتې بند پریږدئ۔ که د فوروارډ قاعدې شمېرونکي صفر پاتې شي او د NAT شمېرونکي لوړ شي، پاکټ ستاسو له قاعدې مخکې غورځول کیږي۔ د دوهمې کاپي اضافه کولو پر ځای د ځنځیر ترتیب ولولئ۔

وسیله باید په یو ډول ځواب ووايي

له ژباړې وروسته وسیله په 10.62.0.0/24 کې سرچینه ویني۔ د هغې ځواب د هغې پیشفرض ګېټوې ته ځي، کوم چې LAN رائوټر دی، نه VPN ګېټوې، پرته له دې چې څه بل ډول ورته ووایي۔ دوه ترتیبات دا سمولای شي او دواړه سره برابر نه دي۔ په وسیله یا په LAN رائوټر کې مسیر 10.62.0.0/24 172.21.4.10 ته لیږي او د کليانټ سرچینه ساتي۔ محدوده سرچینه ژباړه پر ځای کليانټ د ګېټوې د LAN پتې شاته پټوي۔

ip route add 10.62.0.0/24 via 172.21.4.10 dev eth1
iptables -t nat -A POSTROUTING -s 10.62.0.0/24 -d 172.21.4.40 -o lan0 -p tcp --dport 80 -j SNAT --to-source 172.21.4.10

د خدمت د اړتیا له مخې وټاکئ۔ د هر کليانټ سیاست او معنی لرونکي لوګونه مسیر شوې بڼه غواړي؛ هغه وسیله چې مسیر نه شي ورکول کېدای، یا هغه خدمت چې ناگزیر باید LAN پته وویني، ژباړل شوې بڼې ته اشاره کوي۔ د یو ځواب د کار کولو لپاره نړیوال masquerade قاعده مه غوره کوئ۔ هغه هر کليانټ له هر منزل څخه پټوي او د سرچینې پتو پورې تړلي سیاستونه په خاموشۍ ماتوي۔

له ګېټوې خپله ازموینه مه کوئ

هغه غوښتنه چې په ګېټوې کې 10.62.0.1 ته جوړیږي د OUTPUT ځنځیر له لارې وځي، نه د راتلونکي PREROUTING له لارې۔ د هغې ناکامي یا بریالیتوب د کليانټ خواته قاعدې په اړه هېڅ نه وایي، او همداسې خلک دې پایلې ته رسیږي چې کار کوونکې قاعده ماتې ده۔

conntrack -L | grep 172.21.4.40
tcpdump -ni any 'port 8080 or port 80'

یوه ریښتینې کليانټ غوښتنه وچلوئ او دواړه ولولئ۔ د conntrack ننوتنه پلي شوې ژباړه ښیي، او نیول ښیي چې غوښتنه LAN ته تېره شوه که نه او ځواب د تونل خواته بیرته راغی که نه۔ له قاعدو د بدلون وروسته نوې اړیکه وکاروئ، ځکه چې موجوده حالت خپله پخوانۍ نقشه ساتي او په زاړه ډول به ناکامه وي۔ بیا ټوله خبرې اترې تایید کړئ: د وسیلې پته، د فوروارډ اجازه او د ځواب مسیر ټول یو جریان بیانوي۔