ერთი URL ოფისისა და VPN-ისთვის? რატომ იშლება დაშვებული სიის მითი
VPN კავშირი არ ცვლის იმ მისამართს, რომელსაც დაშვებული საიტი ხედავს. URL-ის დამატებამდე შეამოწმეთ რეალური გასასვლელი, სანდო პროქსის ნახტომი და IPv6 გზა.
შეაერთეთ გვირაბი, გახსენით იგივე სანიშნე და დაშვებული საიტი პასუხობს ზუსტად ისე, როგორც ოფისიდან. ეს არის ის ვარაუდი, რომელზეც დისტანციური წვდომის გეგმების უმეტესობა ჩუმად ეყრდნობა, და ის მოქმედებს მხოლოდ მანამ, სანამ სამი ცალკეული რამ ერთდროულად ჭეშმარიტი რჩება. არც ერთი მათგანი არ არის VPN კლიენტის თვისება და ვერც ერთი DNS ჩანაწერი ვერ უზრუნველყოფს არც ერთ მათგანს. როცა სანიშნე სახლში ვერ მუშაობს, ბრაუზერი გაძლევთ ერთ საერთო შეცდომას, მიუხედავად იმისა, მიზეზია დაკარგული მარშრუტი, დაუმტკიცებელი გასასვლელი მისამართი თუ პროქსი, რომელმაც შეცვალა ის წყარო, რომელზეც იუწყება. ამ სამის ერთ პრობლემად მიჩნევა სწორედ ის გზაა, რომლითაც პოლიტიკის პატარა შესწორება დაშვებული სიების გაფართოების ერთ კვირად იქცევა.
დიზაინი, რომელიც უძლებს რეალურ ოფისურ ქსელთან შეხებას, ვარაუდზე ვიწროა: სამსტრიქონიანი მკაფიო გადაწყვეტილების ცხრილი, ერთი აღსრულების წერტილი, რომლის გვერდის ავლა შეუძლებელია, და უარის ტესტი, რომელიც რაღაცას ამტკიცებს. ვარაუდის დაშლა პირველი მოდის, რადგან მის შემდეგ ყველაფერი დამოკიდებულია იმის ცოდნაზე, რომელი ფენა წარმოადგენს წყაროს არასწორად.
მითი: დაკავშირება მარშრუტიზაცია არ არის
გვირაბი მყარდება და კლიენტი აყენებს მარშრუტებს პრეფიქსების გარკვეული ნაკრებისთვის. ეს არის ყველაფერი, რასაც დაკავშირება აკეთებს. გაივლის თუ არა ურთიერთდაუკავშირებელი HTTPS მოთხოვნა გვირაბში და რომელი საჯარო მისამართიდან ჩანს, რომ მოდის, როცა ჩამოვა, ეს გადაწყვეტილებებია, რომლებსაც მოგვიანებით სხვა კომპონენტები იღებენ: მარშრუტების ცხრილი ირჩევს გზას, ხოლო გასასვლელი ირჩევს წყაროს.
ამიტომ ოფისი და სამზარეულოს მაგიდა განსხვავდებიან იმავე ლეპტოპით, იმავე ბრაუზერის პროფილითა და იმავე სანიშნით. ოფისში მოთხოვნა გადის შენარჩუნებული საჯარო მისამართიდან, რომელზეც საიტის ოპერატორი დათანხმდა. სრული გვირაბით ის შეიძლება გავიდეს VPN გასასვლელიდან, რაც სხვა მისამართია და, სანამ ვინმე დაამატებს, დაუმტკიცებელი. გაყოფილი გვირაბით ის შეიძლება საერთოდ არ შევიდეს გვირაბში. ამ სამი გზიდან მხოლოდ ორი იყო ოდესმე საიტის მფლობელთან შეთანხმების ნაწილი, ხოლო მესამე არ არის ხარვეზი, რომელიც დამატებითი allow სტრიქონით უნდა დაიფაროს.
მოთხოვნის სამი მდგომარეობა, ორი დამტკიცებული გასასვლელი
ჩამოწერეთ მატრიცა firewall-ზე შეხებამდე, რადგან ცხრილი დიზაინია და წესი მხოლოდ მისი ერთი განხორციელება. ქვემოთ მოცემული მისამართები დოკუმენტაციის დიაპაზონებია; შეცვალეთ ისინი თქვენი შენარჩუნებული მნიშვნელობებით და შეინახეთ იქ, სადაც საიტის მფლობელს შეეძლება მათი შემოწმება.
| Request path | Source the site sees | Intended decision |
|---|---|---|
| Office, no tunnel | Office public exit | Admit to the application login |
| Remote, approved full tunnel | Approved VPN egress | Admit to the same login |
| Remote, ordinary connection | Neither approved address | Deny at the network boundary |
შუა სტრიქონი არის ის ადგილი, სადაც ამ გეგმების უმეტესობა იმტვრევა. მნიშვნელოვანია ის მისამართი, რომელსაც აღმასრულებელი მოწყობილობა ხედავს, და არა ის კერძო მისამართი, რომელსაც ლეპტოპი გვირაბის შიგნით ინახავს და არც მისი LAN მისამართი. 10.8.0.6-ის მსგავსი მნიშვნელობა არაფერს ნიშნავს საჯარო საიტისთვის, 192.168.1.44-იც ასე. გვირაბის მისამართი გვირაბის მისამართების დეტალია, და არა მოწმობა, რომლის შემოწმებაც საიტს შეუძლია.
თუ თქვენი VPN ვერ უზრუნველყოფს სტაბილურ, დოკუმენტირებულ გასასვლელს, მატრიცას არ აქვს სწორი შუა სტრიქონი და დაშვებული სიების არც ერთი რაოდენობა არ გამოიგონებს მას. ამ მომენტში პატიოსანი არჩევანია კერძო საიტი, რომელსაც აღწევენ მკაფიო კერძო მარშრუტებით, ან იდენტობის გაცნობიერებული წვდომის კარიბჭე აპლიკაციის წინ. ორივეს აქვს სხვა ხელშეკრულება, ვიდრე საჯარო დაშვებულ სიას, და ორივე უფრო ადვილი ასახსნელია აუდიტორისთვის, ვიდრე სია, რომელიც გაიზარდა მანამ, სანამ შემთხვევით არ იმუშავა.
წაიკითხეთ წყარო იქ, სადაც გადაწყვეტილება მიიღება
დააყენეთ შეზღუდვა მოწყობილობაზე, რომელიც ამთავრებს მოთხოვნას, და დაადასტურეთ, რომ არც ერთი ალტერნატიული წარმოშობის გზა არ გვერდს უვლის მას. Nginx-ის წვდომის მოდული აფასებს allow და deny დირექტივებს თანმიმდევრობით, იმარჯვებს პირველი დამთხვევა, და გარემომცველი ბლოკიდან მიღებული წესები კვლავ მოქმედებს location-ის შიგნით. ვიწრო allow ფართო allow-ის გვერდით იმავე ადგილას ჩვეულებრივ ნიშნავს, რომ ფართო წყვეტს. წაიკითხეთ ამ location-ის მთელი მოქმედი კონფიგურაცია, სანამ მის ერთ სტრიქონსაც შეცვლით.
server {
listen 443 ssl;
server_name intranet.example.com;
set_real_ip_from 10.20.0.10;
real_ip_header X-Forwarded-For;
real_ip_recursive on;
location /app/ {
allow 203.0.113.24; # office public exit
allow 198.51.100.77; # approved VPN egress
deny all;
proxy_pass http://app_backend;
}
}დატვირთვის ბალანსერის ან საპირისპირო პროქსის უკან ეს წესი ხედავს პროქსის, თუ სხვას არ ეტყვით. აღადგინეთ გამომძახებლის მისამართი მხოლოდ მხარდაჭერილი სანდო პროქსის მექანიზმით, პროქსის მისამართების მკაფიო სიით. მოთხოვნის თავსართი, რომელიც ამტკიცებს დამტკიცებულ მისამართს, არ არის მტკიცებულება, რომ გამომძახებელი მას ფლობს, და საჯარო მსმენელზე შეუმოწმებელი გადაცემული თავსართი დაშვებულ სიას დეკორაციად აქცევს.
შემდეგ შეამოწმეთ მისამართების მეორე ოჯახი. წესების ნაკრები, რომელიც მხოლოდ IPv4-ს მოიცავს, არასრული გადაწყვეტილებაა ჰოსტის სახელისთვის, რომელიც AAAA-ზეც პასუხობს, და მოქმედი IPv6-ის მქონე კლიენტი იმავე აპლიკაციას მიაღწევს გზით, რომელიც არასოდეს გადაგიხილავთ.
გაყოფილი გვირაბი: მოთხოვნა, რომელიც არასოდეს შემოდის
გაყოფილი გვირაბი ატარებს მხოლოდ თავის სიაში არსებულ პრეფიქსებს. ოფისის შიდა ქვექსელები ჩვეულებრივ ამ სიაში ხვდება; საჯარო ვებსაიტი არა. ბრაუზერი წყვეტს სახელს, ადარებს არჩეულ მისამართს მარშრუტების ცხრილს და მაინც პოულობს ლოკალურ ნაგულისხმევ კარიბჭეს თავის წინ.
ასე მოდის მოთხოვნა მომხმარებლის სახლის კავშირიდან, უარყოფილია, და ანგარიში ამბობს, რომ VPN გატეხილია, მაშინ როცა გვირაბი აკეთებს ზუსტად იმას, რისთვისაც იყო კონფიგურირებული. ორი შესწორება ლეგიტიმურია: გაატარეთ ის დანიშნულება გვირაბში და მიეცით დამტკიცებულ გასასვლელს მისი ტარების უფლება, ან აღიარეთ, რომ საიტს პირდაპირ აღწევენ, და მიეცით დისტანციურ მომხმარებლებს სხვა დამტკიცებული გზა, მაგალითად წვდომის კარიბჭე. საიტის საჯარო დაშვებული სიის გაფართოება მანამ, სანამ სახლის მისამართი შემთხვევით მოხვდება, არც ერთია მათგანი და ის ხსნის იმ საზღვარს, რომელიც დიზაინს უნდა აღესრულებინა. პირველი ორი მატრიცას პატიოსნად ინახავს; მესამე ჩუმად შლის მისგან ერთ სტრიქონს.
დაამტკიცეთ უარი, შემდეგ აღდგენა
შეამოწმეთ მოთხოვნით, რომელიც რეალურ გადაწყვეტილებას ამუშავებს, ცხრილის ყოველ სტრიქონზე მდგარი კლიენტიდან. მისაწვდომობის შემოწმება რომელიმე ურთიერთდაუკავშირებელ მისამართის გვერდთან არაფერს ამტკიცებს, რადგან იმ დანიშნულებას შეიძლება აპლიკაციისგან განსხვავებული გზა ჰქონდეს.
curl -sS -o /dev/null -w 'status=%{http_code}
' https://intranet.example.com/app/login
# repeat with the tunnel up, then with it down
tail -f /var/log/nginx/access.log | grep ' /app/'შეადარეთ საზღვარზე არსებული წვდომის ჩანაწერი იმას, რაც ცხრილმა იწინასწარმეტყველა. შემდეგ ჩამოწიეთ გვირაბი და გააკეთეთ ახალი მოთხოვნა, რომელიც უნდა უარყოფილ იქნას; უკვე ჩატვირთული გვერდი ან უკვე ღია კავშირი საერთოდ არაფერს ამოწმებს. თუ უარი არ გამოჩნდა, აღსრულების წერტილი იქ არ არის, სადაც ფიქრობთ.
შეინახეთ აპლიკაციის ავთენტიფიკაცია ქსელში დაშვების შემდეგ, რადგან ოფისის გასასვლელი და VPN გასასვლელი თითოეული ბევრ ადამიანს წარმოადგენს და არც ერთი არ იდენტიფიცირებს ინდივიდს. მომხმარებლებისთვის ინსტრუქცია მოკლე რჩება: ასწიეთ დამტკიცებული გვირაბი, შემდეგ სცადეთ ხელახლა. ეს ინახავს ერთ URL-ს მოხერხებულად, მაშინ როცა წყაროს წესი გადაწყვეტილებად რჩება და არა ვარაუდად.