Tailscale Serve თუ Funnel: ვის შეუძლია ბმულის რეალურად გახსნა?

ორივე ბრძანება ლოკალურ სერვისს Tailscale-ის HTTPS სახელის მეშვეობით აქვეყნებს და მათი გაშვების მანქანიდან ისინი თითქმის იდენტურად გამოიყურება. განსხვავება იმაშია, თუ ვის შეუძლია შემდეგ URL-მდე მისვლა და ეს განსხვავება განსაზღვრავს, რა კონტროლი სჭირდება თქვენს აპლიკაციას ჯერ კიდევ. Serve აუდიტორიას tailnet-ის შიგნით ინახავს, ხოლო Funnel მას ღია ინტერნეტში გადააქვს. ჯერ აუდიტორია აირჩიეთ, შემდეგ კი ბრძანება, რომელიც მას შეესაბამება.

Serve პასუხობს კითხვას თქვენი tailnet-ის შიგნით

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

Serve ასევე შეუძლია გადაგზავნილ მოთხოვნებს დაურთოს იდენტობის სათაურები, რომლებიც tailnet-ის მომხმარებელს აღწერს. თუ თქვენი აპლიკაცია ამ სათაურებს ავთენტიფიკაციად ენდობა, დაუკავშირეთ backend localhost-ს, რათა სხვა ვერაფერი მიაღწიოს მას პირდაპირ; მარშრუტიზებად მისამართზე მომსმენმა backend-მა შეიძლება მიიღოს მოთხოვნები, რომლებიც არასდროს გაუვლიათ პროქსის გავლით.

Funnel აუდიტორიას ღია ინტერნეტად აქცევს

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

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

რეჟიმი კლიენტიდან წაიკითხეთ, არა პორტიდან

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

tailscale serve status
tailscale funnel status
tailscale status --json | head -40

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

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

გამოსცადეთ იმ აუდიტორიით, რომელიც რეალურად გქონდათ განზრახული

გამოსცადეთ tailnet-ის გარედან და არა იმ მანქანიდან, რომელმაც სერვისი გამოაქვეყნა. მოთხოვნა tailnet-ის მოწყობილობიდან ამტკიცებს, რომ პროქსი მუშაობს, მაგრამ არ ამტკიცებს, რომ უცხო პირი გამორიცხულია. გამოიყენეთ ქსელი, რომელსაც არ აქვს Tailscale კლიენტი და არც მარშრუტი tailnet-ში.

curl -sI https://host.tailnet-name.ts.net
curl -sI https://host.tailnet-name.ts.net --resolve host.tailnet-name.ts.net:443:203.0.113.10

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

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