OpenVPN სახლში მუშაობს, მაგრამ ერთ ქსელში არა: UDP თუ TCP?

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

რომელი საფეხური ჩავარდა — ის განსაზღვრავს, რომელი შედარებაა მნიშვნელოვანი

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

გადაღება გააკეთეთ ხელახალი ცდის დროს და არა შემდეგ. კლიენტზე tcpdump -ni any udp port 1194 გვიჩვენებს, საერთოდ ბრუნდება თუ არა რაიმე პასუხი. გაიმეორეთ იმ სერვერის WAN ინტერფეისზე, რომელსაც თქვენ აკონტროლებთ — ეს გამოავლენს, აღწევს თუ არა ეს პაკეტები საერთოდ შორეულ ბოლომდე.

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

UDP ფილტრაცია დახურული პორტის წინააღმდეგ

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

TCP პროფილი 443 პორტზე ჩვეულებრივი გადაწყვეტაა, რადგან ჩვეულებრივ HTTPS ნაკადს ჰგავს და გადის კაპტიურ პორტალებსა და გასასვლელ ფილტრებზე. ორი პირობა უნდა დაკმაყოფილდეს. სერვერმა უნდა მოუსმინოს proto tcp-server -ით, კლიენტმა უნდა შეესაბამებოდეს proto tcp-client -ს, და ოპერატორმა უნდა გამოაქვეყნოს ის ალტერნატიული ენდპოინტი. სამუშაო UDP პროფილის გადაწერა TCP 443-ის მტკიცებით უშედეგოა, როცა მეორე მხარეს არაფერი უსმენს.

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

ძველი პროტოკოლები ამ ღერძზე ცუდად გამოიყურებიან. PPTP-ს სჭირდება TCP 1723 პლუს GRE, და GRE არის IP პროტოკოლი 47 და არა პორტი, ამიტომ ჩვეულებრივი პორტის გადამისამართება ვერ გამოხატავს მას.

როცა სწორედ კომუტატორი აგდებს პაკეტებს

მართვად კომუტატორს შეუძლია განზრახ ჩააგდოს ტუნელი. HPE-ის და Aruba-ს ზოგიერთ მოდელს აქვს UDP flood დაცვის კონტროლი, ზოგჯერ წარწერით Prevent UDP Blat Attack, გაფართოებული უსაფრთხოების განყოფილებაში. როცა ეს კონტროლი აქტიურია, კომუტატორის უკან მდგარი სერვერი არაფერზე პასუხობს და ყველა კლიენტი ერთნაირად იწურება დროში. მისი გამორთვა და გაშვებული კონფიგურაციის შენახვა მთელი შეკეთებაა, მაგრამ მხოლოდ მას შემდეგ, რაც დაადგენთ, რომ კომუტატორი ნამდვილად გზაზეა.

საწინააღმდეგო მტკიცებულება განასხვავებს კომუტატორის ჩაგდებას პროვაიდერის ბლოკისგან. წაიკითხეთ ინტერფეისის მრიცხველები და flood დაცვის ჟურნალი ISP-სთან ბილეთის გახსნამდე. DoS ან flood დაცვის მქონე სამომხმარებლო როუტერები იმავე ფორმით ვარდებიან, და ასევე ნებისმიერი შუალედური მოწყობილობა მოკლე UDP უმოქმედობის ლიმიტით. ხელის ჩამორთმევა, რომელიც არასოდეს სრულდება, ჩაგდებაზე მიუთითებს, ხოლო ტუნელი, რომელიც რამდენიმე წუთი სიჩუმის შემდეგ კვდება, ლიმიტზე მიუთითებს.

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

მისამართების გადაფარვა, რომელიც DNS ჩავარდნას ჰგავს

10.0.0.0/8-ის შიგნით დანომრილი წვდომის ქსელი შეიძლება გადაფაროს ტუნელის პულს და resolver ჩვეულებრივ სწორედ ამ პულში ცხოვრობს. როცა ლეპტოპი Wi-Fi-ზე იღებს მისამართს, როგორიცაა 10.184.178.50 , /8 ნიღბით, ყოველი 10.x დანიშნულება განმარტებით ლოკალურია. 10.4.0.1 -ისთვის განკუთვნილი პაკეტები მერე LAN-ზე მიდის, ტუნელი აქტიური რჩება და სახელების გარჩევა ვარდება.

ip addr გადაფარვას ერთი შეხედვით ამჟღავნებს, ხოლო ip route get 10.4.0.1 გვიჩვენებს, სად მიეწოდება პაკეტი სინამდვილეში. ვინაიდან თვალსაჩინო სიმპტომი resolver-ის ჩავარდნაა, ეს ხშირად რამდენიმე რაუნდ DNS ცვლილებას გადაურჩება.

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

არჩევანი TCP სარეზერვო გზასა და ბილიკის შესწორებას შორის

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

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