নেস্টেড VPN টানেল: বড় প্যাকেটে ভেতরেরটি কেন আটকে যায়
প্রতিটি টানেল পরেরটি শুরুর আগেই পাথের প্যাকেট বাজেটের একটি অংশ খরচ করে। হেডারগুলো যোগ করুন আর বড় প্যাকেটে ভেতরের সেশন ব্যর্থ হয়।
DNS সমাধান হয়, SSH সেশন চালু থাকে, তারপর একটি বড় আপলোড আটকে যায়, অথচ একই হোস্টে ping এখনও উত্তর দেয়। এই বিভাজন ভাঙা টানেলের দিকে নয়, বরং প্যাকেটের আকারের দিকে ইঙ্গিত করে। নেস্টেড টানেল এমন আকারে পৌঁছায় যা কোনো একটি টানেল একা পৌঁছাত না। ভেতরের সেশন ঠিকই আছে; তাকে এমন প্যাকেট দেওয়া হচ্ছে যা আর ফিট করে না।
পাথ MTU আসলে কোথায় যায়
প্রতিটি এনক্যাপসুলেশন পরের স্তর পালা পাওয়ার আগেই বাইট খরচ করে। একটি Ethernet পাথ বাইরের প্যাকেটকে 1500 বাইট দেয়, আর বাইরের টানেল তার ভেতরের কিছু ঠিকানা পাওয়ার আগেই নিজের অংশ নিয়ে নেয়। একটি অনুমিত ওভারহেড মান ঠিক যতটা গুরুত্বপূর্ণ ঠিক ততটাই ভুল হবে।
স্তরগুলো ক্রমে তালিকাভুক্ত করুন: অ্যাক্সেস পাথ, বাইরের ট্রান্সপোর্ট, বাইরের টানেল, ভেতরের ট্রান্সপোর্ট, ভেতরের টানেল, অ্যাপ্লিকেশন। প্রতিটি হেডার একবার গণনা করুন, এবং UDP-কে টানেলের নিজস্ব হেডার ও ট্যাগ থেকে আলাদা রাখুন।
দুটি WireGuard স্তর, একবারই গণনা
একটি IPv4 অ্যাক্সেস পাথ নিন, তার ভেতরে আরেকটি WireGuard টানেল। বাইরের স্তরে লাগে 20 বাইট IPv4, 8 বাইট UDP এবং WireGuard ডেটা হেডার ও তার প্রমাণীকরণ ট্যাগের জন্য 32 বাইট। তার ভেতরে ভেতরের টানেলের দরকার তার নিজের 20 বাইটের IPv4 হেডার ও 8 বাইটের UDP হেডার, তারপর দ্বিতীয় 32 বাইট WireGuard ওভারহেড। যা বাকি থাকে তাতে IPv4 হেডার, TCP হেডার আর ডেটা ধরে। IPv6 বাইরের পাথে 20-এর বদলে 40 লাগে এবং 1320 বাকি থাকে।
| Layer | Bytes |
|---|---|
| Path MTU | 1500 |
| Outer IPv4 header | 20 |
| Outer UDP header | 8 |
| Outer WireGuard header and tag | 32 |
| Inner transport IPv4 header | 20 |
| Inner UDP header | 8 |
| Inner WireGuard header and tag | 32 |
| Innermost IPv4 header | 20 |
| TCP header | 20 |
| Payload that fits | 1340 |
হিসাব 1340 বাইটে ঠেকে। একই নিয়মে একটি স্তর TCP পেলোডের জন্য 1400 রাখে, অর্থাৎ 1500 বিয়োগ 20, 8, 32, 20 ও 20, আর 60 বাইটের পার্থক্যটাই ঠিক দ্বিতীয় টানেলের যোগ করা ভেতরের এনক্যাপসুলেশন।
1400 নেস্টেড পাথে প্রয়োগ করুন, আর ভেতরের টানেল 60 বাইট কম পড়ে, যা প্যাকেট যথেষ্ট বড় না হওয়া পর্যন্ত অদৃশ্য থাকে। প্যাডিং আর প্রোটোকলের নিজস্ব ফ্র্যাগমেন্টেশন অপশন সংখ্যাগুলো আবার নাড়ায়, তাই টেবিলটিকেই বিশ্বাস করুন।
MTU, MSS ও ফ্র্যাগমেন্টেশন আলাদা আলাদা জায়গায় কাজ করে
ইন্টারফেস MTU ইন্টারফেস যা পাঠাবে তা সীমিত করে, আর TCP MSS ক্ল্যাম্পিং পরিবর্তন করে TCP প্রতিপক্ষ কী পাঠাতে রাজি। ক্ল্যাম্পিং TCP সেশন ঠিক করে এবং বড় UDP ডেটাগ্রামের জন্য কিছুই করে না, এভাবেই একটি সমাধান এক অ্যাপ্লিকেশনে সফল দেখায় আর পরেরটিতে নীরবে ব্যর্থ হয়। প্রোটোকলের নিজস্ব ফ্র্যাগমেন্টেশন অপশন নিজের ব্যর্থতাসহ তৃতীয় লিভার। ইন্টারফেস MTU হলো প্রচলিত প্রথম পদক্ষেপ এবং সবচেয়ে ভোঁতা।
ব্রিজড ও রাউটেড টানেল ভিন্ন ফ্রেম বহন করে, তাই অন্য ডিপ্লয়মেন্টের সংখ্যা খুব কমই প্রযোজ্য হয়। পাথ MTU ডিসকভারি, যা বর্ণিত আছে RFC 8201-এ, কেবল তখনই সাহায্য করে যখন নির্ভরশীল ICMP বার্তাগুলো যেতে দেওয়া হয়।
যে স্তরটি কম পড়েছে তা খুঁজে বের করা
চাহিদা তুলনার সুযোগ দিলে নেস্ট করার আগে প্রতিটি টানেল আলাদাভাবে যাচাই করুন। নির্দিষ্ট আকারের প্রোব এটি নিষ্পত্তি করে: ping -M do -s 1472 -c 3 10.8.0.1 ওই স্তরের ভেতরে পূর্ণ 1500 বাইটের একটি IPv4 প্যাকেট পাঠায়। দ্বিতীয় স্তর যোগ করুন এবং একই প্রোব পুনরাবৃত্তি করুন, যাতে কোনো ব্যর্থতা একটি জানা পরিবর্তনের অন্তর্গত হয়।
কোনো ট্রান্সফার আটকে গেলে একবারে একটি নথিভুক্ত প্যারামিটার বদলান এবং ব্যর্থ আকারটি লিখে রাখুন। ফেরার পথও দেখুন, কারণ নেস্টেড রুট রিকার্শন প্যাকেট-আকারের সমস্যাকে এতটাই নিখুঁতভাবে নকল করতে পারে যে এক দুপুর খরচ হয়ে যায়। ফিল্টার করা ICMP উত্তর আসল সীমা লুকাতে পারে, তাই প্রোব যুক্তির চেয়ে বেশি জরুরি।
বাজেটটি লিখে রাখুন যেখানে পরের মানুষটি তা পাবেন
প্রতি স্তরে একটি সারির টেবিল একটা মুখের নিয়মের চেয়ে বেশি দিন টেকে। টানেল ডায়াগ্রামের পাশে এটি রাখুন যাতে চাপের মুখে কেউ হিসাবটা আবার না করে।
বেশি টানেল মানে বেশি নির্ভরতা, তাই রোলব্যাক পরিকল্পনা বাজেটের পাশে জায়গা পাওয়ার যোগ্য। সংখ্যাগুলো এখনও মিলে না গেলে আবার অনুমান না করে পথটি মাপুন। লক্ষ্য হলো এমন সংখ্যা যা আপনি যুক্তি দিয়ে রক্ষা করতে পারেন, মুখস্থ করতে পারেন না।