იუზერმა შექმნა თიქეთი  “ვაზიარებ ინტერნეტს, VPN ვაკავშირებ, მაგრამ 1C-ში ვერ შევდივარ.”

 

კავშირის შემოწმება (Test-NetConnection)

იუზერი კი ამბობს, რომ ინტერნეტი არის, ვპნ-ს ვაკავშირებო მაგრამ ტრაბლშუტინგში IT-ს პირველი წესია: არასდროს ენდო მომხმარებლის სიტყვებს, გადაამოწმე თავად. მას შემდეგ, რაც ვიზუალურად შევაფასე ინტერნეტის არსებობა,  და VPN-ის კონექტი –  ვხსნი Powershell-ს და ვამოწმებ კავშირს სერვერთან. ბაზა გამოქვეყნებულია HTTP publication-ით (web-client), ამიტომ ვამოწმებ კავშირს პორტ 80-ზე

Test-NetConnection 192.168.99.10 -Port 80

შედეგი: **TcpTestSucceeded : True**.

ჰმ. იუზერი არ ცდებოდა. ვპნი დგას – კავშირი არის. მაშ რატომ შეიძლება 1C არ მუშაობდეს თუ კავშირი არის?

ვარაუდი: MTU Blackhole

როგორ მუშაობს ქსელი? სტანდარტულად, ერთი პაკეტის მაქსიმალური ზომა (MTU) არის 1500 ბაიტი.

L2TP და IPsec თავიანთ headers-ებს ამატებენ. შედეგად 1C-ის გენერირებული სტანდარტული პაკეტი, როგორც ჩანს, ზედმეტად „მსუქანი“ ხდება. ის მიდის პროვაიდერის ანძამდე, ვერ ეტევა მათ ლიმიტში და ქსელი მას უბრალოდ ანადგურებს. პაკეტი ქრება უგზო-უკვლოდ.

მაშ, რატომ აჩვენებს Test-NetConnection კავშირს? ეს ბრძანება ამოწმებს კავშირს ჰოსტთან, შეუძლია შეამოწმოს კავშირი კონკრეტულ პორტთან. მაგრამ აქვს ერთი სუსტი წერტილი.  ტესტი აგზავნის პაწაწინა TCP SYN პაკეტს (დაახლოებით 60 ბაიტი). ასეთი პატარა პაკეტი ნებისმიერ არხში გაძვრება.

1C კი, როცა ბაზას ტვირთავს, სავარაუდოდ უფრო დიდ პაკეტებს ისვრის + VPN overhead. როგორც ჩანს, ჩვენი პრობლემა არა კავშირში, არამედ პაკეტის ზომაშია! ვიწრო წრეებში ფართოდაა ცნობილი, რომ მობილური ოპერატორების ლიმიტები ხშირად უფრო მკაცრია, ვიდრე ჩვეულებრივი პროვაიდერის. როგორ შევამოწმოთ ეს ვარაუდი?

Windows-ის დაკითხვა

ვიძახებ netsh უტილიტას და პირდაპირ სისტემის ბირთვს ვეკითხები:

netsh interface ipv4 show subinterfaces

ვხედავ ჩვენს ინტერფეისს სახელით `1C` (ჩვენი ვპნის სახელი) და მის გვერდით წერია MTU – 1400

როგორც ჩანს ეს ზომაც კი დიდია.

ჩავატაროთ ექსპერიმენტი — გავაგზავნოთ პაკეტები და მკაცრად ავკრძალოთ მათი ფრაგმენტაცია გზაში (-f პარამეტრი).

ვხსნით კონსოლს და  ჩვენს სერვერს ვუგზავნით სხვადასხვა კალიბრის (ზომის) პინგებს:

ping 192.168.99.10 -f -l 1400

ვხედავ პასუხს

Packet needs to be fragmented but DF set

ვარაუდი გამართლდა. მოდი ეხლა ვცადოთ

ping 192.168.99.10 -f -l 1350

ისევ Packet needs to be fragmented but DF set

საბოლოოდ მსგავსი ცდებით  მხოლოდ 1300იანი პაკეტი გავიდა სამშვიდობოს. თუნდაც თეორიული 80 ბაიტიანი overhead-ითაც კი არ ვჯდებოდით ლიმიტში, პრაქტიკაში კი overhead ხშირად 100–140 ბაიტამდე ადის. მაგრამ მოდი პრაქტიკაში ვნახოთ როგორ იმუშავებს. ამ ოვერჰედების მათემატიკა პრაქტიკაში საკმაოდ ბუნდოვანია 😀

MTU-ს შემცირება

უნდა ვაიძულო Windows-ს, რომ მონაცემები უფრო მცირე ნაწილებად დაშალოს (TCP Segmentation),

კვლავ ვიყენებთ `netsh`-ს და MTU-ს 1300-მდე ვამცირებთ. პარამეტრით `store=persistent` კი ვეუბნებით სისტემას, რომ ეს სამუდამოდ დაიმახსოვროს (რეესტრში ჩაწეროს):

netsh interface ipv4 set subinterface “1C” mtu=1300 store=persistent

ბაზა იტვირთება, ყველაფერი მუშაობს!

მორალი

არასდროს ენდოთ მხოლოდ პინგს, როცა საქმე VPN-ს და მობილურ პროვაიდერებს ეხება. ყოველთვის შეამოწმეთ და დაარეგულირე MTU!