ყველა პორტის გადამისამართების წესმა შეიძლება გადაყლაპოს თქვენი WireGuard-ის მსმენელი
ფართო გადამისამართების წესმა შეიძლება გადაყლაპოს კარიბჭის საკუთარი WireGuard და SSH მსმენელები. აირჩიეთ ვიწრო წესები ან ცალკე საჯარო მისამართი და შემდეგ შეამოწმეთ მართვის გზა.
საჯარო კარიბჭე უკვე ატარებს WireGuard-ს UDP 51820-ზე, SSH-ს 22-ზე და ერთ აპლიკაციას, რომელიც ინტერნეტიდან უნდა იყოს ხელმისაწვდომი. მაცდური წესი გადაამისამართებს ყველა პორტს პირთან და საქმეს დასრულებულად აცხადებს. WireGuard-ის კარიბჭეზე ასეთმა წესმა შეიძლება დაიპყროს გვირაბის საკუთარი ტრანსპორტი და ჩაკეტოს თქვენ იმ მანქანიდან, რომელიც მას ამთავრებს. გამოქვეყნება მარშრუტიზაციის გადაწყვეტილებაა მართვის სიბრტყის გამონაკლისით და არა ერთი DNAT ხაზი.
საჯარო შესასვლელი თუ გვირაბის შესასვლელი: აირჩიეთ ერთი
სერვისის გამოქვეყნება ქმნის ინტერნეტში შესვლის ახალ წერტილს. ეს არ არის იგივე, რაც პირისთვის VPN-ის წევრობის მიცემა, რადგან ვიზიტორი არასდროს შედის გვირაბში და კარიბჭე ხდება ბექენდის საჯარო სახე. ეს განსხვავება განსაზღვრავს წესის აუდიტორიას და მის სერტიფიკატს.
ადმინისტრაციული ინტერფეისები იშვიათად ხვდება ამ პოზიციაზე. ავტორიზებული VPN კლიენტებისთვის ხელმისაწვდომი ადმინის გვერდი თავდასხმის ზედაპირს გვირაბის შიგნით ინახავს და თავს არიდებს შესვლის ფორმის თვითნებური სკანირებისთვის გამოფენას. საჯარო აპლიკაციის ბოლო წერტილებს კვლავ სჭირდებათ საკუთარი TLS სერტიფიკატი, აუთენტიფიკაცია და სიჩქარის შეზღუდვა; დაშიფრული WireGuard ნაბიჯი არ იცავს ვიზიტორის მონაკვეთს კარიბჭემდე.
თუ სერვისი ნამდვილად საჯარო უნდა იყოს, ჩამოწერეთ ჰოსტის სახელი, სერტიფიკატი, რომელიც მას ფარავს, და ვიზიტორთა ის დიაპაზონები, რომლებმაც უნდა მიაღწიონ მას. ეს სამი ფაქტი შემდგომში განსაზღვრავს წესის ფორმას და ფილტრის პოლიტიკას. ამის გარეთ ყველაფერი მოცულობის ზრდაა საჯარო მსმენელზე.
ერთი პორტი შიგნით, ერთი ბექენდი გარეთ
გამოიყენეთ ერთი საჯარო პორტი და ერთი ბექენდ სერვისი. ამ მაგალითში eth0 ატარებს საჯარო მისამართს 198.51.100.20, კარიბჭის გვირაბის მისამართია 10.200.0.1, ხოლო პირი აპლიკაციას 10.200.0.7-ზე ატარებს. საჯარო TCP 9443 აისახება პირის TCP 8443-ზე:
iptables -t nat -A PREROUTING -i eth0 -d 198.51.100.20 -p tcp --dport 9443 -j DNAT --to-destination 10.200.0.7:8443
iptables -t nat -A POSTROUTING -o wg0 -d 10.200.0.7 -p tcp --dport 8443 -m conntrack --ctorigdst 198.51.100.20 --ctorigdstport 9443 -j SNAT --to-source 10.200.0.1SNAT წესი ემთხვევა თარგმნილ ბექენდს და თავდაპირველ საჯარო დანიშნულებას, ამიტომ იმავე ბექენდ სერვისზე სხვა კავშირი ამ გამოსახულების გარეთ რჩება. ის ასევე მალავს ვიზიტორის მისამართს პირისგან და ეს არის ის გაცვლა, რომელიც წყაროს შემნახველ მარშრუტულ დაბრუნებას ცალკე დიზაინად აქცევს. iptables გაფართოებების ცნობარი აღწერს ორივე სამიზნეს და მათ შესაბამისობის ვარიანტებს.
გადამისამართება კვლავ უნდა ჩაირთოს და ფილტრის ჯაჭვს სჭირდება ნებართვა თარგმნილი დანიშნულებისა და პორტისთვის, ასევე დადგენილი პასუხებისთვის. FORWARD ჯაჭვი DNAT-ის შემდეგ ხედავს თარგმნილ დანიშნულებას, ამიტომ საჯარო მისამართზე დაწერილი წესი არ ემთხვევა გადამისამართებულ პაკეტს. ნებართვა დაწერეთ ბექენდის კორტეჟზე და არა საჯაროზე.
პირმა უნდა მიიღოს სერვისის კავშირი კარიბჭის გვირაბის მისამართიდან და პასუხი უკან გვირაბით გაგზავნოს. მისი AllowedIPs უნდა აძლევდეს ნებართვას იმ წყაროს, რომელსაც ის რეალურად იღებს, და წყაროს თარგმნისას ეს არის კარიბჭის გვირაბის მისამართი, ხოლო ფართო 0.0.0.0/0 ჩანაწერი ყველა პირზე ამ დიზაინისთვის საჭირო არ არის. დაბრუნების ტრაფიკს წყვეტს პირი, რომლის სიაშიც ეს მისამართი აკლია, ან წყაროს შემნახველი დიზაინი, რომელიც თავად ვიზიტორის მისამართს გადასცემს, ამიტომ შეამოწმეთ ის წყარო, რომელსაც პირი რეალურად ხედავს და არა ის, რაც თქვენს წესშია.
კარიბჭის საკუთარი მსმენელები წესის გარეთ შეინახეთ
დანიშნულების თარგმნა ხდება მანამ, სანამ მანქანა გადაწყვეტს, რომ პაკეტი ლოკალურია, ამიტომ UDP 51820 შეიძლება აღმოჩნდეს პირთან და არა იმ პროცესთან, რომელიც ყველა პირის კავშირს ინახავს. წესი წარმატებით იტვირთება და გვირაბი კვდება, რაც ძნელად წასაკითხი მარცხია პირის მხრიდან.
SSH-ს, მონიტორინგის აგენტებს და კარიბჭეზე განთავსებულ ნებისმიერ სხვა სერვისს იგივე ექსპოზიცია აქვს. წესი, რომელიც ყველაფერს გადასცემს, არ განასხვავებს მართვის სიბრტყეს გამოქვეყნებული აპლიკაციისგან და ცვლილების შემდეგ პირველი გადატვირთვა არის ის მომენტი, როცა ჩაკეტვა აშკარა ხდება. ყველაფრის მომცველი წესი არ აფრთხილებს იმ სერვისზე, რომელსაც ჩუმად ითვისებს. თქვენ ამას აღმოაჩენთ, როცა შემდეგი კავშირი ვერ მოხდება.
თუ ფართო გადამისამართება ნამდვილად საჭიროა, მართვის პორტები დაიტოვეთ ყველაფრის მომცველ წესამდე ან გამოიყენეთ ცალკე საჯარო მისამართი გამოქვეყნებისთვის. მეორე ვარიანტი უფრო სუფთაა, რადგან მართვის მისამართი საკუთარ პოლიტიკას ინახავს, მაგრამ პროვაიდერმა ეს მისამართი უნდა მოგცეს; DNS ჩანაწერის დამატება მას არ ანაწილებს.
ფართო TCP და UDP გადამისამართება ასევე არ არის ყველა პროტოკოლი. ICMP-ს, IPv6-ს, ბილიკის MTU უკუკავშირს და VPN-ის გარე ტრანსპორტს საკუთარი პოლიტიკა სჭირდება და TCP-ისა და UDP-ის მომცველი წესი ამ შემთხვევებს ნაგულისხმევ ჯაჭვს უტოვებს.
მოდელი აირჩიეთ წესების დაწერამდე
ოთხი ფორმა ფარავს კარიბჭის გამოქვეყნებების უმეტესობას და არჩევანი დამოკიდებულია იმაზე, რამდენ სერვისს მართავთ და რამდენ მართვის სიბრტყის რისკს იტანთ. ქვემოთ მოცემული ცხრილი ალაგებს მათ ყველაზე ვიწროდან ყველაზე ფართომდე.
| Model | What it protects | Cost | Use when |
|---|---|---|---|
| Narrow port forward | Every other listener, including the VPN | One rule per service | Few services, stable ports |
| Catch-all with reserved ports | Ports named in the exception list | Rule order becomes critical | Many services and disciplined review |
| Separate public address | Control address fully isolated | Provider must supply the address | High-value publication |
| VPN-only access | No public entry at all | Visitors need the tunnel | Admin interfaces and internal tools |
დაიწყეთ ვიწრო მოდელით, თუნდაც მოგვიანებით მეტ სერვისს ელოდებოდეთ. ის ყველაზე ადვილად აუდიტირებადია და ვიწრო წესების ნაკრების გადაქცევა გადამოწმებულ ყველაფრის მომცველ წესად უფრო მარტივია, ვიდრე იმის გარკვევა, რომელი მსმენელი დაიპყრო ფართო წესმა. რომელი მოდელიც არ უნდა აირჩიოთ, წესები ფაირვოლის მფლობელთან შეინახეთ. iptables ხაზების UFW-ის ან nftables-ის კონფიგურაციის გვერდით გამოყენება, რომელიც იმავე ჯაჭვებს მართავს, ქმნის პოლიტიკას, რომელიც ჩატვირთვის რიგის მიხედვით იცვლება.
დაამტკიცეთ გამოქვეყნებაც და მართვის გზაც
შეამოწმეთ ავტორიზებული გარე კლიენტიდან დამტკიცებული ჰოსტის სახელით და მისთვის ვალიდური სერტიფიკატით. დაადასტურეთ, რომელი ბექენდი უპასუხა, შემდეგ შეამოწმეთ, რომ დაუკავშირებელი საჯარო პორტები კვლავ აკრძალულია. გამორთული სერტიფიკატის შემოწმება არ არის წარმატებული HTTPS ტესტი და არასწორ ბექენდზე მიღწეული კავშირი უარესია, ვიდრე წარუმატებელი.
ამის შემდეგ შეამოწმეთ თავად კარიბჭე: დააკავშირეთ WireGuard პირი, გახსენით SSH სესია და დაადასტურეთ, რომ მონიტორინგი კვლავ იუწყება. გამოქვეყნებულ სერვისს შეუძლია იმუშაოს, სანამ მართვის სიბრტყე გატეხილია, ამიტომ ორივე შემოწმება ერთსა და იმავე ცვლილების ფანჯარაში უნდა იყოს. გადატვირთეთ ერთხელ, რომ დაამტკიცოთ წესების მოსალოდნელი რიგით ხელახლა გამოყენება, შემდეგ მოხსენით გამოქვეყნება და დაადასტურეთ, რომ მოხსნა ნამდვილად შეესაბამება დამატებას. გაშვებისას ბევრი დამატება არასრული გაწმენდით არის ის, რაც დროებით ტესტს მუდმივ გახსნილობად აქცევს.