لیرې کاروونکي د VPN هب له لارې دویم سایټ ته نه رسېږي

یو لیرې کاروونکی له هب سره نښلوي، د هب په خپله LAN کې د فایل سرور ته رسېږي، او هر څه سم ښکاري۔ بیا په مرکزي دفتر کې 10.20.0.50 کې یو شریک پرانیزي، چې هب ورته د جلا سایټ-تر-سایټ ټونل له لارې رسېږي، او وخت ختمېږي۔ دواړه ټونلونه پورته دي او دواړه کاونټرونه لوړېږي، نو هېڅ ټونل خراب نه دی۔ د هب له لارې تګ په درې وسیلو کې درې رټینګ پریکړې دي، او ټونل یوازې هغه مخکښې لېږدوي چې د هغو لپاره جوړ شوی وي۔ دا هغه ترتیب دی چې زه یې ګورم، او هغه کمانډ چې ښیي هر ګام سم دی که نه۔

تګ درې لټونونه غواړي، نه یو ټونل

هر وسیله خپله تر ټولو اوږده مخکښه سمون کوي او هېروي یې۔ لپ ټاپ باید 10.20.0.50 ټونل ته ولېږي، نه خپل ځایي رټر ته۔ هب باید هغه پاکټ واخلي چې د لیرې لاسرسي انټرفیس ته راغلی او سایټ-تر-سایټ انټرفیس ته یې وسپاري۔ مرکزي دفتر باید د کاروونکي پتې لپاره ځواب د ټونل له لارې بیرته ولېږي۔ د درېیو له ډلې هر یو که ناکام شي په براوزر کې ورته ښکاري: چوپتیا۔

له همدې امله د هر ټونل جلا ازموینه دومره لږ ثابتوي۔ د هب د LAN پتې ته پنګ کول لومړۍ پریکړه ازموي، او له مرکزي دفتر څخه هب ته پنګ کول درېیمه۔ هغه پاکټ چې ناکامېږي سرچینه یې د کاروونکو پول او منزل یې دویم سایټ دی، نو لومړی هغه مخکښې ولیکئ۔ دلته پول 10.80.0.0/24 دی، د هب LAN 10.10.0.0/24 دی او مرکزي دفتر 10.20.0.0/24 دی۔

لیرې مخکښه لیرې کلینټ ته ټېله کړئ

په یو OpenVPN لیرې لاسرسي سرور کې کلینټ د نښلېدو پر مهال لارې زده کوي۔ پرته له push، د ووېشل شوي ټونل کلینټ 10.20.0.50 خپل ګېټوې ته لېږي او پاکټ هېڅکله ټونل ته نه ننوځي۔

push "route 10.20.0.0 255.255.255.0"

ټېل شوې لار هغه وخت پلي کېږي چې کلینټ نښلوي، نو هغه کاروونکی چې آنلاین پاتې کېږي تر څو چې بیا ونښلي هېڅ نه ویني۔ په کلینټ کې وګورئ: په Linux کې ip route get 10.20.0.50، په Windows کې route print۔ پایله باید د ټونل انټرفیس نوم واخلي۔

push له هب سره مرسته نه کوي۔ دا کلینټ ته یو پیغام دی، نه په سرور کې لار او نه د لېږد اجازه، نو هب چې بشپړ push کرښه لري هم یو هپ وروسته بهیر غورځوي۔ دا هغه عادي لامل دی چې خلک پرې پایله کوي چې push ناکام شو۔

هب ته ریښتینې د وتلو لار ورکړئ

هب ته د مرکزي دفتر د مخکښې لپاره خپله بله هپ غواړي۔ په رټ شوي ټونل کې دا د سایټ-تر-سایټ انټرفیس له لارې عادي لار ده، او یو کمانډ هم ټاکل شوې لار او هم ټاکل شوې سرچینه ښیي:

ip route get 10.20.0.50 from 10.80.0.25
sudo ip route add 10.20.0.0/24 via 172.30.0.2 dev s2s0

چېرې چې د سایټ-تر-سایټ پښه پخپله OpenVPN ده، لار کولای شي په همغه ترتیب کې د سیال د ټونل پتې په ګېټوې توګه واوسي: route 10.20.0.0 255.255.255.0 172.30.0.2۔ ګېټوې اختیاري نه دی۔ که يې پرېږدئ، بله هپ د تطبیق ډیفالټ ته لوېږي، چې د یو لیرې کلینټ او څو سیالونو لرونکي هب ترمنځ توپیر لري۔

د پالیسۍ پر بنسټ IPsec توپیر لري: د هب کرنل پاکټ خپل عادي LAN ګېټوې ته لېږي او پالیسي یې د وتلو پر لار نیسي، نو د ټونل لار یا هېڅ نه کوي یا ترافیک د پالیسۍ ترڅنګ وړي۔ په پورته کمانډ کې سرچینه وګورئ، ځکه چې د پول د پتې پر ځای 10.10.0.1 مانا دا ده چې کرنل هغه پته غوره کړې چې لیرې خوا به یې رد کړي۔ iroute هم ځواب نه دی؛ دا سرور ته وایي چې کوم کلینټ د خپل ټونل شاته سبنیټ لري، نه دا چې د درېیم سایټ لپاره ترافیک چېرته ولېږي۔

لیرې خوا د کاروونکو پول ته وغځوئ

مرکزي دفتر لا دمخه د هب LAN، 10.10.0.0/24 پوښي۔ د کاروونکو پول دویمه مخکښه ده او باید په ټاکونکو کې هم وي، که نه هېڅ پالیسي 10.80.0.25 ته لېږل شوی ځواب نه پوښي۔ هر سیال له خپلې خوا څخه د مخکښو ټولګو همغه جوړه نوموي:

# strongSwan swanctl.conf, on the hub
local_ts  = 10.10.0.0/24, 10.80.0.0/24
remote_ts = 10.20.0.0/24

# on the headquarters peer
local_ts  = 10.20.0.0/24
remote_ts = 10.10.0.0/24, 10.80.0.0/24

د یوې وسیلې local_ts د بل remote_ts دی۔ د هب بلاک مرکزي دفتر ته کاپي کړئ او جوړه برعکسېږي، نو ماشوم SA هېڅکله پورته نه راځي۔

زوړ ipsec.conf سینټکس د کامې سره جلا شوې leftsubnet کاروي۔ روان امنیتي ټولنه هغه ټاکونکي ساتي چې پرې خبرې شوې، نو له سمون وروسته ټونل بیا جوړ کړئ۔ هغه ټاکونکی چې په 10:00 بدل شو او په 09:40 پورته شوي SA پروړاندې ازمویل شو، لا هم ناکامېږي، په داسې حال کې چې د ترتیب فایل په ټول وخت سم ښکاري۔

بیا وروستۍ هپ وګورئ۔ په لیرې پای کې ip route get 10.80.0.25 باید ټونل ته اشاره وکړي۔ که خدمت LAN رټر د خپل ډیفالټ ګېټوې په توګه کاروي، هغه رټر هم بیرته راستنیدو لار ته اړ دی، که نه ځواب هماغه ځای مري۔ په هغه برخه کې tcpdump -ni eth1 host 10.80.0.25 چلول ښیي چې ځواب له پای څخه بهر وتلی که نه۔

په هب کې بهیر ته اجازه ورکړئ

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

sysctl -w net.ipv4.ip_forward=1
iptables -I FORWARD -i tun0 -o s2s0 -s 10.80.0.0/24 -d 10.20.0.0/24 -j ACCEPT
iptables -I FORWARD -i s2s0 -o tun0 -s 10.20.0.0/24 -d 10.80.0.0/24 -j ACCEPT

د بیرته لار فلټر کول د هغې ترڅنګ غلی ناکامي ده: کله چې دواړه پښې په جلا انټرفیسونو وي، rp_filter=1 کولای شي ځواب وغورځوي، په داسې حال کې چې د منلو قاعدې کاونټر هېڅ نه خوځېږي۔ iptables -vnL FORWARD د یوې هڅې مخکې او وروسته پرتله کړئ۔ هغه قاعده چې هېڅکله نه زیاتېږي هغې ته نه رسېدل کېږي، نو د بیا لیکلو پر ځای یوه طبقه ښکته وګورئ۔

که یوازې یوې ډلې تګ ته اړتیا وي، لار د client-config-dir لاندې د هر کلینټ په فایل کې کېږدئ، نه دا چې نړیوال push پراخ کړئ۔ په هب کې Source NAT هم د لیرې خوا د بیرته لار اړتیا لره کوي، مګر د کاروونکي پته پټوي، نو د لیرې سایټ لاګونه او د پتې پر بنسټ قاعدې کاروونکي نه شي توپیرولای۔

له کلینټ څخه وګورئ، بیا په برعکس ترتیب بیرته راوګرځوئ

یوازې ICMP نه، TCP پورټ وازموئ، ځکه پنګ تېرېدلی شي په داسې حال کې چې خدمت بند وي۔ له کلینټ څخه nc -vz 10.20.0.50 445 او traceroute -n 10.20.0.50 ښیي چې دویمه هپ د هب د ټونل پته ده که نه۔ په هب کې، tcpdump -ni tun0 host 10.20.0.50 او په سایټ-تر-سایټ انټرفیس کې همغه فلټر: په دواړو غوښتنه مګر په هېڅ کې ځواب نه وي، ستونزه لیرې خوا ته ځي۔

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

د بیرته ګرځولو لیست وساتئ، ځکه څلور شیان بدل شول او درې یې هېرول اسانه دي: ټېل شوې لار، د هب لار، ټاکونکي او د اور وژنې دیوال قاعدې۔ دوی په برعکس ترتیب بیرته واخلئ، SA بیا جوړ کړئ، او یو کاروونکی بیا ونښلي۔ جزوي بیرته ګرځول هغه لار پرېږدي چې ټونل ته اشاره کوي چې نور سمون نه خوري، او لوستل یې له اصلي چوپتیا ستونزمن دي۔ د OpenVPN 2.6 لارښود ستاسو نسخې لپاره push، route او iroute مستند کوي۔