VPN ছাড়া Git আটকে যায়? OpenSSH IPQoS দিয়ে প্যাকেট চিহ্নিত করে
OpenSSH ডিফল্টভাবে তার প্যাকেটগুলো QoS মান দিয়ে চিহ্নিত করে। যেখানে পথ সেই চিহ্ন ফেলে দেয়, সেখানে পুশ আটকে থাকে যতক্ষণ না টানেল প্যাকেটগুলোর পথ বদলায়।
অফিস থেকে ক্লোন করা কাজ করে, ফোনের হটস্পট দিয়ে একই ক্লোন কাজ করে, আর হোটেল নেটওয়ার্ক থেকে একই ক্লোন VPN চালু না করা পর্যন্ত ঝুলে থাকে। SSH হ্যান্ডশেক শেষ হয় এবং প্রথম সত্যিকারের ট্রান্সফারেই সেশন চুপ হয়ে যায়। ক্লায়েন্ট কনফিগারেশনে যোগ করা এক লাইন git ও ssh দুটোকেই সারিয়ে তোলে। যখন একটি ক্লায়েন্ট সেটিং একসাথে কয়েকটি টুল সারায়, তখন ত্রুটি ক্লায়েন্ট যা পাঠায় তাতে, যে লিংক দিয়ে পাঠায় তাতে নয়।
উপসর্গটি পথের পার্থক্য হিসেবে পড়ুন
যে টানেল সমস্যা সারায় তা বিরল ক্ষেত্রেই মেরামত। এটি পথ, ক্যারিয়ার ও মধ্যবর্তী ডিভাইস বদলে দেয়, অথচ ল্যাপটপ ঠিক একই প্যাকেট তৈরি করে চলে। যদি একটি পথ হেডার ভুলভাবে সামলায় আর অন্যটি তা অপরিবর্তিত রাখে, তবে পার্থক্যটি ক্লায়েন্টে নয়, মধ্যবর্তী ডিভাইসের নীতিতে। এখানে টানেল সাক্ষী, সমাধান নয়।
সেশনটি যেখানে মরে, সেটি আরও সংকুচিত করে। নাম খোঁজা বা কী বিনিময়ে যা ব্যর্থ হয়, তেমন দেখায় না। যে সেশন প্রমাণীকরণ করে, ব্যানার ছাপে এবং তারপর প্রথম বড় লেখায় জমে যায়, সে ইতিমধ্যেই প্রমাণ করেছে যে রাউটিং, নামকরণ ও শংসাপত্র সবই কাজ করছে।
ক্লায়েন্ট প্রতিটি SSH সকেটে একটি QoS বাইট বসায়
7.8 থেকে প্রতিটি OpenSSH সংযোগ IP হেডারে একটি মান বহন করে যা রাউটার ট্রাফিককে অগ্রাধিকার দিতে ব্যবহার করতে পারে। টার্মিনাল সেশন একটি মান পায় আর বাল্ক কপি পায় অন্য মান, এই ধারণায় যে টাইপ করা মানুষ ফাইল স্থানান্তরের চেয়ে ভালো ব্যবহার পাওয়ার যোগ্য। অধিকাংশ নেটওয়ার্ক এই ইঙ্গিত সম্পূর্ণ উপেক্ষা করে, তাই এটি বছরের পর বছর খেয়াল হয় না। অল্প কিছু Wi-Fi ড্রাইভার, মোবাইল অপারেটর ও VPN কনসেনট্রেটর এর উপর কাজ করে, আর তাদের কয়েকটি খারাপভাবে কাজ করে।
যখন এই মানটি স্ট্রিমের মাঝখানে পুনরায় লেখা বা ফেলে দেওয়া হয়, সংযোগটি ব্যর্থ হয় না, এটি এগোনো থামিয়ে দেয়। পুনঃপ্রেরণ বাড়ে, উইন্ডো ভেঙে পড়ে, আর অ্যাপ্লিকেশন কিছুই জানায় না কারণ কোনো ত্রুটি ঘটেনি। এই নীরবতার জন্যই মানুষ উপসর্গটিকে ব্যর্থতা নয়, ঝুলে যাওয়া বলে বর্ণনা করে।
প্রথমে ssh -V দিয়ে ক্লায়েন্ট বিল্ড নিশ্চিত করুন। 7.8 বা তার উপরে যেকোনো কিছু এই আচরণ ডিফল্টভাবে বহন করে।
তিনটি কমান্ড যা এটিকে MTU ও DNS থেকে আলাদা করে
কোনো কনফিগারেশন ফাইল সম্পাদনার আগে দুটি সদৃশ সমস্যা বাদ দেওয়া দরকার। MTU ত্রুটি ছোট বিনিময় চালিয়ে দেয় এবং প্রথম বড় প্যাকেটে জমে যায়, অথচ নামসংক্রান্ত ত্রুটি কখনোই সেশন তৈরি করে না।
ssh -o IPQoS=none -v [email protected]
ssh -G [email protected] | grep -i ipqos
sudo tcpdump -ni any -vv "tcp port 22"
প্রথম কমান্ডটি মার্কিং বন্ধ রেখে ব্যর্থ কাজটি পুনরাবৃত্তি করে, আর তার সফল সম্পাদনই সবচেয়ে শক্তিশালী একক প্রমাণ। দ্বিতীয়টি সেই কনফিগারেশন ছাপে যা ক্লায়েন্ট ওই গন্তব্যে সত্যিই প্রয়োগ করবে, ফলে ভুলে যাওয়া কোনো ফাইলের পুরোনো এন্ট্রি ধরা পড়ে। তৃতীয়টি স্থানান্তর আটকে থাকা অবস্থায় উভয় দিকে TOS বাইট দেখায়, আর আকর্ষণীয় নমুনা হলো ভাঙা পথে মান থাকা কিন্তু কাজ করা পথে না থাকা।
ক্যাপচারটি সার্ভারে নয়, ল্যাপটপে চালান, কারণ প্রেরক মানটি বসায় এবং যেকোনো দিক তা বদলাতে পারে। একই ক্যাপচার দিয়ে কাজ করা ও ব্যর্থ পথের তুলনা করুন, অনুমান ছাড়াই পার্থক্য দেখা যাবে।
ব্যতিক্রমটি একটি ফাইলে রাখুন, একবারে একটি হোস্ট
ব্যতিক্রমটি যে হোস্টে প্রযোজ্য তার পাশে থাকা উচিত, সঙ্গে একটি মন্তব্য যা বলে কেন এটি আছে।
Host gitlab.example.internal
IPQoS none
# direct route rewrites the marking; the tunnel route passes it
মানের চেয়ে পরিধি বেশি জরুরি। ওয়াইল্ডকার্ড এন্ট্রি সর্বত্র আচরণটি বন্ধ করে, ভালো আচরণ করা নেটওয়ার্কে কাজে লাগা একটি ইঙ্গিত নষ্ট করে, আর কেউ বলতে পারে না এটি কখন এসেছে। প্রতি-হোস্ট এন্ট্রি পড়ার যোগ্য, ফিরিয়ে আনা যায় এবং নেটওয়ার্ক সারানোর পর মুছে ফেলা খুব সহজ। ব্যক্তিগত সাময়িক সমাধানের জন্য ব্যবহারকারীর ফাইল, আর পুরো ফ্লিটের একই ব্যতিক্রম দরকার হলে ব্যবস্থাপিত ফাইল ব্যবহার করুন।
ব্যতিক্রমটি কী ঢাকছে না সে বিষয়ে স্পষ্ট থাকুন। এটি SSH-এ প্রযোজ্য, তাই HTTPS রিমোট, প্যাকেজ মিরর ও ব্রাউজার সবই এর বাইরে, আর তাদের যেকোনোটির ব্যর্থতার নিজস্ব প্রমাণ দরকার। বাস্তিয়ন হয়ে যাওয়া চেইনে প্রতিটি হপ ক্লায়েন্ট কনফিগারেশন ব্যবহার করে, আর যে হপ আটকে যায় সেটিই পরিধি নির্ধারণের যোগ্য।
নেটওয়ার্ক মালিকের সঙ্গে চক্রটি বন্ধ করুন
সন্ধানটি চারটি তথ্য হিসেবে হস্তান্তর করুন: ক্লায়েন্ট সংস্করণ, পরীক্ষিত পথ, ব্যবহৃত VPN ক্লায়েন্ট এবং কোন দিক মার্কিং বহন করেছে। এই চারটিই নেটওয়ার্ক মালিকের পক্ষে আচরণটি পুনরুৎপাদন করা এবং তা ইচ্ছাকৃত কি না ঠিক করার জন্য যথেষ্ট।
ব্যতিক্রমটি ঝুলে যাওয়া সারালে না, তবে তা সরিয়ে ফেলুন। ব্যর্থ পরীক্ষা থেকে টিকে যাওয়া সাময়িক সমাধান কিংবদন্তি হয়ে যায়, আর পরের ব্যক্তি এক ঘণ্টা ব্যয় করে প্রমাণ করে যে এটি কিছুই করে না। যদি এটি ঝুলে যাওয়া সারায়, পথটি এখনও তার ওপর দিয়ে যাওয়া প্রতিটি অন্য টুলের জন্য ভুল, আর মেরামত সেই ব্যক্তির কাজ যে মধ্যবর্তী ডিভাইস চালায়।
ক্লায়েন্টের পরিবর্তনটি মেয়াদসহ একটি সাময়িক ব্যবস্থা। সেই মেয়াদটি মন্তব্যে লিখুন।