Git WSL2-ში VPN-ის დროს იჭედება: ინტერფეისის MTU თუ გზა?

კლონი ავთენტიფიკაციას გადის, ობიექტების რაოდენობა ჩნდება და შემდეგ წუთების განმავლობაში არაფერი მოძრაობს. Windows აცნობებს, რომ VPN დაკავშირებულია, ჰოსტის სახელი წყდება და იმავე მანქანაზე ბრაუზერი იმავე რეპოზიტორიის გვერდს უპრობლემოდ იღებს. ეს კომბინაცია პაკეტის ზომაზე მიუთითებს და არა სერთიფიკატებზე, და ზომის კითხვა ორ ადგილას უნდა დაისვას, რადგან WSL2-ს აქვს საკუთარი Linux ინტერფეისი საკუთარი MTU-ით. ერთი რიცხვი გზის Windows მხარეს ეკუთვნის, მეორე დისტრიბუტივს, და მხოლოდ VPN ადაპტერის კითხვა გზის ნახევარს გამოუკვლეველს ტოვებს.

სამი ნიშანი ზომის პრობლემას სხვისგან გამოჰყოფს

პირველი ნიშანი ფორმაა: კავშირის დამყარება და მცირე გაცვლა წარმატებით მთავრდება, შემდეგ მასიური გადაცემა წინსვლას წყვეტს. მეორე სიმეტრიაა: იგივე რეპოზიტორია და იგივე ტრანსპორტი ვარდება, მაშინ როცა იმავე გზაზე სხვა ჰოსტი მუშაობს, ან ჩავარდნა იცვლება დატვირთვის ზომით და არა დღის დროით. მესამე სიჩუმეა: არავითარი ავთენტიფიკაციის შეცდომა, არავითარი პროქსის უარი, არავითარი სახელის გადაწყვეტის ჩავარდნა, მხოლოდ გადაცემა, რომელიც არასდროს სრულდება.

ეს სამი ერთად ამართლებს პაკეტის ზომის ჰიპოთეზას. DNS-ის ჩავარდნა, ვადაგასული ტოკენი, უარყოფილი SSH გასაღები და პროქსი, რომელიც CONNECT-ს უარყოფს, თითოეული თავის შეცდომას წარმოქმნის და არცერთი მათგანი წარმატების შემდეგ გაჩერებას არ ჰგავს. იმავე რეპოზიტორიის, ტრანსპორტისა და დროის ფანჯრის შენარჩუნება ტესტირებისას არის ის, რაც შედარებას პატიოსანს ხდის.

გადაწყვეტამდე შეადარეთ ორივე ინტერფეისი

შეაგროვეთ Windows-ის ხედი და Linux-ის ხედი იმავე სესიაში და დაიჭირეთ რეპოზიტორიის მისამართი, ნაცვლად იმისა, რომ გამოიცნოთ, რომელი ინტერფეისი ატარებს მას. ქვემოთ მოცემული ბრძანება ჯერ დანიშნულებას წყვეტს, რათა მარშრუტის ძებნამ აღწეროს ის რეალური სერვერი, რომელსაც კლონი უკავშირდება, და ის შეიძლება განსხვავდებოდეს ბრაუზერის მიერ ნაჩვენები სახელისგან. გაუშვით ორივე ნახევარი ერთმანეთთან ახლოს, რადგან VPN-მა შეიძლება შეცვალოს ინტერფეისის მეტრიკები ცდებს შორის.

netsh interface ipv4 show subinterfaces
wsl -d Ubuntu -- bash -lc 'dest=$(getent ahostsv4 github.com | awk \'NR==1{print $1}\'); ip -br link show; ip route get "$dest"'

Linux-ის ნახევარი გაუშვით დისტრიბუტივის შიგნით, ნაცვლად გამომავალი მონაცემების Windows-ის გარსში ჩასმისა, რადგან ინტერფეისების სახელებს და მარშრუტის არჩევას მხოლოდ იქ აქვს აზრი. Windows-ის გარსიდან ჩასმული შედეგი არასწორ რიცხვებს დიდი თავდაჯერებით აცნობებს. ჩაწერეთ მოწყობილობა, არჩეული მარშრუტი და MTU თითოეული მხრიდან, სანამ რამეს შეცვლით.

გადაწყვიტეთ, უნდა იყოს თუ არა რიცხვი უფრო პატარა

ინტერფეისის MTU, რომელიც აღემატება გზის ტევადობას, ავტომატურად ნაკლი არ არის, რადგან გზის MTU-ის აღმოჩენა სწორედ ამისთვის არსებობს. ჩავარდნის რეჟიმი ჩნდება მაშინ, როცა აღმოჩენა ითრგუნება: ICMP შეტყობინებები სადღაც გზაზე იფილტრება, გამგზავნი ზღვარს ვერასდროს იგებს და დიდი პაკეტები ქრება, სანამ პატარები გადიან. ეს გზის თვისებაა, არა Git-ის. ეს იმის მიზეზიცაა, რომ პატარა ფაილმა შეიძლება წარმატებით დასრულდეს კავშირზე, სადაც დიდი ვერასდროს სრულდება.

თუ მტკიცებულებები ამას ემხრობა, Linux-ის ინტერფეისზე დროებითი ცვლილება ყველაზე იაფი ტესტია. აირჩიეთ მნიშვნელობა გამოსაყენებელი გზის ზომაზე ნაკლები, ჩაწერეთ წინა და დატოვეთ ყველა სხვა უცვლელი, რათა შედარებას აზრი ჰქონდეს. თუ გადაცემა პატარა მნიშვნელობით სრულდება, თქვენ გაქვთ დიაგნოზი და არა დამთხვევა.

ip -br link show dev eth0
sudo ip link set dev eth0 mtu 1380
ip -br link show dev eth0

გადაწყვიტეთ, სად უნდა იცხოვროს პარამეტრმა

ტესტიდან სამი ვარიანტი გამომდინარეობს და ჩვეულებრივ მხოლოდ ერთი მათგანია შესაფერისი. თუ პატარა მნიშვნელობა ასწორებს გადაცემას და მნიშვნელობა ნამდვილად საჭიროა ამ ქსელისთვის, პარამეტრს სჭირდება სასიცოცხლო ციკლის მფლობელი: გაშვების კაუჭი დისტრიბუტივში, პლატფორმის მიერ მართული ქსელის კონფიგურაცია ან დოკუმენტირებული პროცედურა. თუ მნიშვნელობა არაფერს ასწორებს, დააბრუნეთ და დაუბრუნდით ტრანსპორტის, პროქსისა და ავთენტიფიკაციის კითხვებს.

გაშვების კაუჭის არსებობა დამოკიდებულია გამოყენებულ Windows-ისა და WSL-ის ვერსიებზე და კონფიგურირებულ ქსელურ რეჟიმზე. Windows-ის ქსელის სარკეში ასახვა შეიძლება შეცვალოს, როგორ ურთიერთქმედებს VPN დისტრიბუტივთან, ისე, რაც MTU-ის კორექციაზე მეტად მნიშვნელოვანია, ამიტომ დაადგინეთ რეჟიმი, სანამ მისთვის შემოვლით გზას შეიმუშავებთ. ერთ ოპერატორს ან ერთ VPN პროფილს შესაფერისი მნიშვნელობა შემდეგისთვის ნაგულისხმევი არ არის.

რასაც უნდა მოერიდოთ, ეს არის მაცდური განლაგება: პრივილეგირებული ქსელური ბრძანება ყოველი ინტერაქტიული გარსის გაშვების ფაილში, ან პაროლის გარეშე sudo მთელი ip ბინარული ფაილისთვის, რათა სკრიპტმა ერთი ხაზი გაუშვას. ორივე დიაგნოზს მუდმივ ზემოქმედებად აქცევს და საწყისი პრობლემის დანახვას შემდეგ უფრო ართულებს.

გადაამოწმეთ სუფთა გაშვების შემდეგ, შემდეგ დააბრუნეთ

ცვლილება, რომელიც მხოლოდ დისტრიბუტივის გადატვირთვამდე ძლებს, გამოსწორება არ არის. გადატვირთეთ დისტრიბუტივი, ხელახლა დაუკავშირდით VPN-ს და გაიმეორეთ საწყისი Git ოპერაცია, და არა შემცვლელი, როგორიცაა ping ან მცირე HTTP მოთხოვნა. შემდეგ დაადასტურეთ, რომ ახალ სესიაში ინტერფეისი სასურველ მნიშვნელობას ატარებს.

ip -br link show dev eth0
ip route get "$(getent ahostsv4 github.com | awk 'NR==1{print $1}')"

ჩაწერილი საწყისი მნიშვნელობა ცვლილების გვერდით შეინახეთ, რათა ექსპერიმენტი სუფთად გაუქმდეს, და აღნიშნეთ, რომელი მისამართების ოჯახი გამოიცადა, რადგან IPv4-ის შედეგი არაფერს ამბობს იმავე ჰოსტზე IPv6 კავშირზე. WSL-ის ქსელების დოკუმენტაცია აღწერს რეჟიმებს, რომლებიც განსაზღვრავენ, როგორი უნდა იყოს გამოსწორება; თავად MTU რიცხვი ლოკალური გაზომვაა და არა რეკომენდაცია.