მშობლიური TLS, SSH გადაცემა ან VPN ერთი ღრუბლოვანი სერვისისთვის

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

დაიწყეთ სერვისით, არა ქსელით

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

აიღეთ პატარა შიდა API, რომელიც უკვე HTTPS-ს ემსახურება 8443 პორტზე api.internal.example-ის სერტიფიკატით. ჰოსტზე ss -ltnp გვიჩვენებს, რასთან არის მიბმული, ხოლო openssl s_client -connect 127.0.0.1:8443 -verify_hostname api.internal.example გვიჩვენებს, მოქმედია თუ არა სერტიფიკატი იმ სახელისთვის, რომელსაც კლიენტი რეალურად გამოიყენებს. თუ ორივე ჯანსაღია, სერვისს შეუძლია დაიცვას საკუთარი ნაკადი და მხოლოდ ხელმისაწვდომობა რჩება. ეს გაცილებით პატარა პრობლემაა, ვიდრე ქსელის აშენება.

ნაბიჯი 1: იცავს თუ არა სერვისი თავს?

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

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

ნაბიჯი 2: არის თუ არა ერთი TCP პორტი მთელი მოთხოვნა?

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

ფორმაა ssh -N -L 8443:127.0.0.1:8443 [email protected], და მთავარი დეტალი სამიზნე მისამართია: 127.0.0.1 შორეულ მხარეს წყდება, ამიტომ სერვისთან კავშირი ბასტიონიდან იხსნება და არა თქვენი ლეპტოპიდან. მიაბით ლოკალური მსმენელი ვიწროდ როგორც -L 127.0.0.1:8443:..., რომ შემთხვევით არ გამოაქვეყნოთ სერვისი საკუთარ ლოკალურ ქსელში. სერვერის მხარეს შეზღუდეთ, რისი გადაცემაც ანგარიშს შეუძლია, ნაცვლად იმისა, რომ კლიენტის კარგ ქცევას მიენდოთ. PermitOpen, AllowTcpForwarding local და ნაგულისხმევი GatewayPorts no სამი პარამეტრია, რომლებიც ზოგად რელეს კონკრეტულ არხად აქცევს.

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

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

ნაბიჯი 3: არის თუ არა მარშრუტიზაცია რეალური მოთხოვნა?

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

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

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

რაც შემდეგ გაქვთ

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

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