هغه پوښتنه چې د TCP handshake وروسته ځړېږي د لارې موندنې ستونزه نه ده. د لارې تېروتنې handshake ناکاموي، نو هغه ناسته چې جوړېږي او بیا چوپه پاتې کېږي د لارې دننه ته اشاره کوي: پلټنه، MTU، یا هغه ډول چې د تونل UDP پاکټونه رارسېږي. ستاسو مخې ته پرېکړه دا ده چې هغه لاره سمه کړئ که تونل TCP ته انتقال کړئ. درې شرطونه دا فیصله کوي، او هیڅ یو یې د ډیټابیس په اړه نه دی.

له دې مخکې چې تونل ملامت کړئ، بندښت طبقه بندي کړئ

څلور پایلې کاروونکي ته یو شان ښکاري او انجنیر لپاره بشپړ توپیر لري.

What the client seesWhat it rules out
Connection refusedNothing is listening on the address and port the client reached
Timeout before the handshakeA filter, a missing route, or the wrong address
Handshake completes, query hangsThe session exists, so look at inspection, MTU and packet order
Stalls that recover on retryOften reordering, or a state table entry expiring

یوازې وروستي دوه کرښې د تونل په سر وخت تېرولو ته جواز ورکوي. د VPN له لارې رد شوی اړیکه معمولاً دا ده چې ډیټابیس یوازې په loopback اورېدل کېږي، چې دا د اورېدونکي ستونزه ده، او له handshake مخکې د وخت پای فیلټر یا لاره ده. د دواړو هیڅ یو د انکپسولیشن په بدلولو نه ښه کېږي.

لومړی طبقه بندي په ټکټ کې ولیکئ. دا ترټولو ارزانه ګام دی او د لټون ډېره برخه لره غورځوي.

درې شرطونه چې د UDP او TCP ترمنځ فیصله کوي

انکپسول شوی IPsec ټرافیک پر UDP ځي، او UDP لارې ته آزادي ورکوي چې پرته له دې چې چا ته ووایي بیا ترتیب او غورځول وکړي. کله چې بیا ترتیب پاکټونه د تونل د تکرار ضد کړکۍ څخه بهر کړي، هغه په چوپتیا غورځول کېږي او دننه TCP ناسته یوازې انتظار کوي. د بریالي handshake او هغه پوښتنې شاته میکانېزم دا دی چې هېڅکله نه راګرځي.

د لارې سمول یا TCP ته بیرته تګ درې شیانو ته اړه لري. لومړی، ایا پر لاره ریښتینی پاکټ زیان شته، که یوازې بیا ترتیب؟ دویم، ایا تاسو کولی شئ هغه ځای بدل کړئ چې پلټنه پکې کېږي، یا دا تونل له هغه برخې وویستل شي چې بیا ترتیب کوي؟ دریم، ایا کاري بار د بندښت بڼې ته حساس دی، لکه ډېرې ملټي پلکس ناستې چې یوه لینک شریکوي؟

که لومړی ځواب زیان وي او دویم نه،نو 443 کې TCP هغه عملي بدیل دی. که دویم ځواب هو وي، لاره سمه کړئ او UDP وساتئ.

د اپلیکیشن تېروتنه نه، د فایر وال ریکارډ ولولئ

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

کلستر هم وګورئ. ناسم تنظیم شوی کلستر کولی شي ناسته د یو غړي په حالت جدول کې وساتي پداسې حال کې چې پاکټونه د بل غړي لارې ځي، نو ځوابونه هغه ځای ته رسېږي چې هیڅ حالت نه وي. دا ډول بندښتونه ناڅاپي ښکاري او له بار سره اړه نه لري.

له هر بدلون مخکې دواړه سرونه پرتله کړئ، او د پاکټونو شمېر نه، د راتګ ترتیب پرتله کړئ:

tcpdump -ni any udp port 4500 -w /tmp/encap.pcap
tcpdump -ni any tcp port 5432 -w /tmp/inner.pcap

443 کې TCP په رښتیا ستاسو لپاره څه لګښت لري

تونل TCP ته انتقالول د بیا ترتیب نښه لره غورځوي، ځکه چې منځنی بکس اوس منظم جریان ویني. دا TCP-over-TCP هم جوړوي. بهرنۍ اړیکه هغه څه بیا لیږي چې دنننۍ اړیکه دمخه بیا لیږلي، او یو زیان کولی شي ټولې ملټي پلکس ناستې یوځای ودروي. پر پاکه لاره دا نه ښکاري. پر زیان لرونکې لاره درمل له نښې څخه بدتر دي.

دا تبادله هغه وخت منل کېدونکې ده چې بدیل یې بشپړه بې اړیکۍ وي، او باید د مالک سره د استثنا په توګه ثبت شي نه دا چې د عادي شي په توګه ومنل شي.

ټرانسپورټ، پورټ، یوه نمونه پوښتنه او اندازه شوې پایله، او همدارنګه نېټه ثبت کړئ. پرته له دې ریکارډ بل انجنیر تجربه تکراروي، او استثنا په چوپتیا کې معماري کېږي.

پرېکړه د بیا کتنې وړ وساتئ

د لارې تشخیص ژر زوړ کېږي. منځنی بکس بدلېږي، د بلیډ تنظیم بدلېږي، لینک لوړېږي، او 443 کې د TCP دلیل ورکېږي پداسې حال کې چې تنظیم پاتې کېږي. پر استثنا د بیا کتنې نېټه کېږدئ او هغه شرط ونوموئ چې UDP ته د بیرته تګ اجازه درکوي.

دواړه ټرانسپورټونه په کوچنۍ پوښتنه او په لویه پایلو ټولګه وآزموئ. بیا ترتیب د اندازې پورې تړلي بندښتونه ښکاره کوي، پداسې حال کې چې د اورېدونکي خرابي دواړه اندازې یو شان دروي.

اړوندې مقالې