ნამდვილად ეხმარება TCP 443? მხოლოდ მაშინ, თუ სერვერი იქ უსმენს
TCP პროფილი სარეზერვო გზაა და არა ნიღაბი. შეამოწმეთ, უსმენს თუ არა სერვერი ამ პორტზე, შემდეგ აწონეთ ორმაგი TCP-ის ფასი მიუწვდომლობის წინააღმდეგ.
TCP 443 წინაპირობის მქონე სარეზერვო გზაა და არა ნიღაბი, რომელიც გვირაბს ნებისმიერ ფილტრს გვერდით გაატარებს. ის ეხმარება მაშინ, როცა ოპერატორი უკვე აქვეყნებს TCP-ის მსმენელს ამ პორტზე და გზა იტანს საათობით ღია კავშირს. ის მარცხდება, ჩვეულებრივ როგორც დროის ამოწურვა, როცა ამ ორიდან ერთი აკლია, და დროის ამოწურვა იშვიათად ამბობს, რომელი. გადართვის გადაწყვეტილებას სამი კითხვა სჭირდება, და მათგან მხოლოდ ერთი ეხება პორტის ნომერს.
პორტის ნომერი ტრანსპორტის დაპირება არ არის
პორტი ასახელებს ბოლო წერტილს; TCP მას დალაგებულ ბაიტთა ნაკადად აქცევს; OpenVPN წყვეტს, რა მოძრაობს ამ ნაკადის შიგნით. იმავე ნომერზე მდგარი ვებ სერვერი სულ სხვა აპლიკაციურ განლაგებას იყენებს, ამიტომ 443 პორტის გაზიარება მათ ფილტრისთვის მსგავსს ხდის და მეტს არაფერს. ნომერი ფილტრის წაკითხული მინიშნებაა და არა თვისება, რომელიც პაკეტების შიგთავსს ცვლის. მათი ერთად მიჩნევა იმიტომ, რომ პორტს იზიარებენ, ის შეცდომაა, რომელიც აქაური დაბნეულობის უმეტესობის უკან დგას.
შუამავალი მოწყობილობები იშვიათად იღებენ პორტზე მარტივ დაშვება-ან-აკრძალვის გადაწყვეტილებას. ბევრი პირველ ბაიტებს ამოწმებს, ზოგი დანიშნულებას ამაგრებს, ზოგი კი ზედმეტად ხანგრძლივად ღია კავშირებს ახალდებს. ამიტომ შეიძლება ერთი და იგივე პროფილი ერთი ქსელიდან იმუშაოს და მეორიდან დროის ამოწურვამდე მივიდეს, და ამიტომ ღირს სარეზერვო გზის გამოცდა როგორც მხარდაჭერილი არჩევანისა და არა როგორც დაპირებისა. როცა ფილტრი ტრაფიკს ამოწმებს, პორტის ნომერი მხოლოდ პირველია, რასაც უყურებს.
დაადასტურეთ მსმენელი, სანამ პროფილს შეეხებით
სერვერი უნდა იყოს კონფიგურირებული TCP-ზე ამ პორტზე, და კლიენტის პროფილმა უნდა მოითხოვოს იგივე ტრანსპორტი. UDP პროფილის გადაწერა TCP-ის მოთხოვნით მსმენელს არ ქმნის, და მიღებული დროის ამოწურვა არ განსხვავდება პორტის ჩამოგდებული ფაიერვოლისგან. ჩამოტვირთეთ ოპერატორის საკუთარი TCP პროფილი, როცა არსებობს, რადგან ზოგი სერვისი თითოეული ტრანსპორტისთვის ცალკე ბოლო წერტილს და ცალკე იდენტობის პარამეტრებს აქვეყნებს. ხელით რედაქტირება კარგია კონტროლირებული ტესტისთვის და ცუდი გზაა პროვაიდერის განზრახული კონფიგურაციის გამოსაცნობად.
ამ შესაბამისობის ორივე მხარე კონფიგურაციაში ჩანს, და OpenVPN პროექტის კავშირის პარამეტრები ორივე ფორმას აღწერს. მინიმალური წყვილი ასე გამოიყურება:
# server: accept TCP on this port
proto tcp-server
port 443
# client: request the same transport
proto tcp
remote vpn.example.com 443სამი პირობა წყვეტს, ღირს თუ არა სარეზერვო გზა თავის ფასს
პირველი პირობაა, რომ ოპერატორი საერთოდ სთავაზობს ამ ტრანსპორტს; მის გარეშე დანარჩენს მნიშვნელობა არ აქვს. მეორეა, რომ გზა ცოცხლად ინახავს ხანგრძლივ სესიას, რადგან ზოგი ქსელი ღია დარჩენილ კავშირებს ახალდებს და არა პორტს სრულად ბლოკავს. მესამეა, არის თუ არა სარეზერვო გზა განზრახ გამონაკლისი თუ დროებითი ხერხი, რომელიც მალავს თქვენ მიერ გაუსწორებელ ხარვეზს.
ყოველ პირობას იაფი შემოწმება აქვს. რომელიმეზე მარცხი კლიენტის მხრიდან ერთნაირად გამოიყურება:
| Condition | How to check it | What a failure decides |
|---|---|---|
| The server offers TCP | The operator's profile list, or a listening-socket check on the server | No client-side edit can help |
| The path keeps long sessions | A test connection left open for an hour | Reconnects will look like server faults |
| The fallback is deliberate | A change record naming the UDP fault | The underlying fault stays invisible |
სანამ ტრანსპორტებს შეადარებთ, დაასრულეთ ნებისმიერი შესვლა დამჭერ პორტალზე. ქსელი, რომელსაც თქვენი მოწყობილობა არ დაუშვია, ორივე ტრანსპორტს ბლოკავს, და მაშინ შედარება პორტალს ზომავს და არა გვირაბს. შედით, დაადასტურეთ, რომ ჩვეულებრივი დათვალიერება მუშაობს, და მხოლოდ ამის შემდეგ დაიწყეთ ტესტი.
ფასი, რომელსაც იღებთ: TCP TCP-ის შიგნით
TCP ხელახლა აგზავნის დაკარგულ სეგმენტებს და ინახავს მათ რიგს. როცა აპლიკაცია, რომელიც თავადაც იყენებს TCP-ს, მუშაობს TCP გვირაბის შიგნით, აღდგენის ორი ფენა ერთსა და იმავე დანაკარგზე რეაგირებს, და სწორედ ეს ურთიერთქმედება ხდის გვირაბს ნელი შეგრძნობისას დანაკარგებიან გზაზე. სიმპტომია დაყოვნება და კანკალი და არა სუფთა მარცხი, რაც აადვილებს შორეული მხარის დადანაშაულებას. გაზომეთ კლიენტის მხრიდან ორივე ტრანსპორტში, სანამ დასკვნას გამოიტანთ.
UDP თავს არიდებს ამ ჩადგმას და სწორედ ეს არის მთავარი მიზეზი, რის გამოც ოპერატორები მას ამჯობინებენ და TCP-ს მხოლოდ ალტერნატივად სთავაზობენ. სტაბილური TCP კავშირი მაინც უფრო სასარგებლოა, ვიდრე მიუწვდომელი UDP კავშირი, ამიტომ შედარება ორ რეალურ ფასს შორისაა და არა კარგ და ცუდ არჩევანს შორის. შედარებისას მოწყობილობა და წვდომის ქსელი უცვლელად დაიტოვეთ, თორემ შედეგი არასწორ ცვლადს აღწერს.
კლიენტის ზოგი ფუნქცია მხოლოდ ერთი ტრანსპორტისთვისაა დოკუმენტირებული, ამიტომ სარეზერვო პროფილმა შეიძლება ჩუმად დაკარგოს ის ქცევა, რომელსაც ეყრდნობოდით. წაიკითხეთ პარამეტრის ტრანსპორტული მოთხოვნა, სანამ TCP პროფილს უბრალო ჩანაცვლებად მიიჩნევთ.
ხარვეზები, რომლებსაც სხვა ტრანსპორტი არ ეხება
ვადაგასული სერტიფიკატი მაინც საჭიროებს საათის შემოწმებას ან განახლებას, და უარყოფილი ანგარიში მაინც საჭიროებს სწორ რწმუნებებს. შეინახეთ ოპერატორის მიერ მოწოდებული სერვერის იდენტობის შემოწმებები, რადგან ნაცნობი პორტის ნომერი არავის ამოწმებს. პასუხისმგებელი პორტი მხოლოდ ამბობს, რომ რაღაც უსმენს.
თუ გვირაბი ამოქმედდა და დანიშნულებები მაინც ვერ მუშაობს, დარჩენილი პრობლემა კავშირის შემდგომი მარშრუტიზაცია ან სახელების გადაწყვეტაა და არა ტრანსპორტი. მიჰყევით ამ გზას პორტებში ტრიალის ნაცვლად, რადგან სწორედ ასე ქრება შუადღე. პროფილი გეუბნებათ, რომელი ტრანსპორტი სცადოთ; ის არასდროს გეუბნებათ, რატომ ჩავარდა UDP გზა.