Kill switch აქტიურდება: რა ემართება ღია TCP სესიებს?

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

გადაგდება, უარყოფა და გადატვირთვა განსხვავებულია

Firewall-ის წესი, რომელიც ტრაფიკს გადააგდებს, პაკეტს აგდებს და არაფერს აბრუნებს, ამიტომ გამომგზავნი საკუთარი ტაიმერებით აგრძელებს ხელახლა გაგზავნას. წესი, რომელიც TCP reset-ით უარყოფს, კავშირს მაშინვე ხურავს და აპლიკაცია შეცდომას ხედავს. kill switch-ების უმეტესობა აგდებს, რადგან უარყოფა პოლიტიკას გაამჟღავნებდა და რადგან გადაგდება მკვდარი ქსელის ქცევას ჰგავს.

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

რას აკეთებს აპლიკაცია, სანამ შუალედი გრძელდება

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

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

გადაწყვიტეთ, საჭიროა თუ არა აღდგენა

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

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

შეამოწმეთ ბლოკირება და აღდგენა ცალ-ცალკე

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

ss -tnp state established '( dport = :443 )'
sudo conntrack -L -p tcp --dport 443
sudo tcpdump -ni any 'tcp port 443 and tcp[tcpflags] & tcp-syn != 0'

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

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