VPN সংযুক্ত থাকলেও Git 403: কে উত্তর দিচ্ছে তা খুঁজুন
403 একটি উত্তর, VPN সম্পর্কে রায় নয়। কোন উপাদান অনুরোধ প্রত্যাখ্যান করেছে তা চিহ্নিত করুন, তারপর নেটওয়ার্কগুলোর মধ্যে একবারে একটি চলক তুলনা করে কী বদলেছে তা লিখে রাখুন।
অফিসের Wi-Fi-তে কাজ করে, ফোনের হটস্পটে ব্যর্থ হয়, দুই ক্ষেত্রেই VPN সংযুক্ত। Git 403 ফেরত দেয় এবং ত্রুটিটি তিন লাইনের। প্রলোভন হলো হটস্পটকে কারণ ধরে নিয়ে কিছু বদলানো পর্যন্ত নেটওয়ার্ক সেটিংস বদলাতে থাকা। HTTP 403 মানে একটি সার্ভার অনুরোধ বুঝেছে এবং তা প্রত্যাখ্যান করেছে, তাই কাজের প্রশ্ন হলো কোন সার্ভার, আর কাজের পরবর্তী ধাপ হলো এমন তুলনা যা একবারে একটি জিনিস বদলায়।
নেটওয়ার্কের আগে স্ট্যাটাস পড়ুন
403 কোনো অনুসন্ধান ব্যর্থতা নয়, TCP টাইমআউট নয়, কিংবা অসম্পূর্ণ TLS হ্যান্ডশেকও নয়। এটি একটি সিদ্ধান্ত, যা নিয়েছে এমন কিছু যা আপনার অনুরোধ পার্স করেছে।
যে সেই সিদ্ধান্ত নিয়েছে তা না জানা পর্যন্ত, আপনার প্রতিটি নেটওয়ার্ক পরিবর্তন বিশ্বাসযোগ্য গল্পসহ একটি অনুমান।
কে 403 দিয়ে উত্তর দিতে পারে?
রিপোজিটরি অ্যাপ্লিকেশন কেবল একটি প্রার্থী। একটি প্রক্সি, একটি গেটওয়ে বা ফিল্টারিং পরিষেবা এর সামনে বসে আগে উত্তর দিতে পারে, আর ক্লায়েন্ট দুই ক্ষেত্রেই একই স্ট্যাটাস দেখে। স্ট্যাটাস, প্রাসঙ্গিক হেডার ও পরিশোধিত ত্রুটির বডি সংরক্ষণ করুন, তারপর সেগুলো অনুমোদিত পরিষেবার লগের সঙ্গে মিলিয়ে দেখুন। রিমোট URL এবং প্রকৃতপক্ষে পৌঁছানো এন্ডপয়েন্টও DNS বা প্রক্সি কনফিগারেশনের কারণে আলাদা হতে পারে, তাই কনফিগার করা ঠিকানা এবং অনুরোধ পাঠানো প্রসেস যাচাই করুন।
প্রত্যাখ্যান যদি রিপোজিটরিতে কখনো পৌঁছায়নি, তার লগ নীরব থাকবে, আর সেই নীরবতাই প্রমাণ।
একবারে একটি চলক তুলনা করুন
হটস্পট তুলনাটি কাজে লাগে কারণ এটি সমস্যা সংকুচিত করে, কারণ এটি কোনো কারণ প্রমাণ করে নয়। দুটি নেটওয়ার্ক একই সময়ে অ্যাড্রেসিং, IP পরিবার, প্রক্সি, TLS আলাপ এবং এগ্রেস নীতিতে আলাদা হতে পারে।
প্রতি প্রচেষ্টায় একটি জিনিস বদলান আর বাকিটা লিখে রাখুন। নিচের সারণিটিই সেই সর্বনিম্ন যা আমি এটি করার সময় নোটে রাখি:
| Keep constant | Record when it changes |
|---|---|
| Repository, operation and credentials | Resolved address and IP family |
| Git process and configuration | Proxy use and the responding component |
| Intended VPN profile | Actual route and exit seen by the service |
যে একক সারি কার্যকর ও ব্যর্থ রানের মধ্যে আলাদা, পরের ঘণ্টাটি সেখানেই যায়।
ওয়ার্কঅ্যারাউন্ড প্রমাণ, ব্যাখ্যা নয়
অন্য একটি ঠিকানা পরিবার জোর করে ব্যবহার করলে গন্তব্য, রুট বা যে মধ্যবর্তী উপাদান বেছে নেওয়া হয় তা বদলে যেতে পারে, তাই এটি ফলাফল বদলাতে পারে কিন্তু IPv6 রিপোজিটরির সঙ্গে অসামঞ্জস্যপূর্ণ তা প্রমাণ করে না। আলোচিত ভিন্ন একটি TLS সংস্করণ একই শ্রেণির পর্যবেক্ষণ। কোনোটিই সার্টিফিকেট যাচাই বন্ধ করা বা সংযোগ দুর্বল করা সমর্থন করে না। প্রথম যে পরিবর্তন কাজ করে সেখানেই থেমে না গিয়ে প্রত্যাখ্যানকারী উপাদানের নীতি ও লগ ধরে প্রকৃত সিদ্ধান্ত পর্যন্ত যান।
যে ওয়ার্কঅ্যারাউন্ড আপনি ব্যাখ্যা করতে পারেন না, তা অন্য কোথাও আবার ব্যর্থ হবে।
এমন প্রতিবেদন লিখুন যা ঠিক করা হবে
উত্তরদাতার মালিককে একই অপারেশন, দুটি পথ এবং যে উপাদান না বলেছে তা দিন। কিছু শেয়ার করার আগে অনুমোদন হেডার, এমবেড করা ক্রেডেনশিয়াল ও ব্যক্তিগত রিপোজিটরি বিবরণ সরিয়ে ফেলুন।
কাজের প্রতিবেদন সংক্ষিপ্ত, পুনরুৎপাদনযোগ্য এবং উপসর্গ নয়, স্তরটির নাম বলে।
যে পরীক্ষা আমি ক্রমে করি
রিমোট URL ও সমাধান করা এন্ডপয়েন্ট নিশ্চিত করুন, তারপর ব্যর্থ রান থেকে স্ট্যাটাস ও হেডার সংরক্ষণ করুন। দ্বিতীয় নেটওয়ার্কে একই অপারেশন পুনরাবৃত্তি করুন এবং দুটি রেকর্ড মিলিয়ে দেখুন।
তারপর সেই পার্থক্য যে উপাদান উত্তর দিয়েছে তার কাছে নিন:
- ক্লায়েন্টে ও নেটওয়ার্কে প্রক্সি কনফিগারেশন।
- রিপোজিটরির সামনে এগ্রেস নীতি বা ফিল্টারিং।
- টোকেন বা অ্যাকাউন্টের পরিসর, মেয়াদ শেষ ও SSO শর্তসহ।
- টোকেন যে পরিচয়ের প্রতিনিধিত্ব করে তার জন্য রিপোজিটরি অনুমতি।
স্ট্যাটাসের অর্থ নিজেই আছে RFC 9110-এ, এবং প্রতিবেদন লেখার সময় এটি উদ্ধৃত করার মতো।