რატომ არ არის DHCP რეზერვაცია სტატიკური IP თქვენი VPN სერვერისთვის

სახლის VPN ყუთი Wi-Fi-დან Ethernet-ზე გადავიტანე და მისი „მუდმივი“ მისამართი იმავე საღამოს შეიცვალა. როუტერზე არაფერი იყო გატეხილი. რეზერვაცია უსადენო ადაპტერს ემთხვეოდა და ეს ადაპტერი უკვე აღარ იყო გზაზე.

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

რეზერვაცია ემთხვევა კლიენტს და არა მოწყობილობას

DHCPv4-ში რეზერვაცია კლიენტის ტექნიკურ მისამართზეა მიბმული; DHCPv6-ში — DUID-ზე, რომლის შენარჩუნებაც კლიენტს მოეთხოვება. hostname ველი ადამიანებისთვის არსებული იარლიყია. რაც როუტერი რეალურად ადარებს, არის იდენტიფიკატორი, რომელიც მოთხოვნაში მოდის.

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

OpenWrt ფორმას ნათლად აჩვენებს. ერთი config host ბლოკი /etc/config/dhcp-ში აერთიანებს სახელს, MAC-ს და მისამართს, და სტატიკური იჯარების დოკუმენტაცია ხსნის, როგორ ურთიერთქმედებს ეს ჩანაწერი აუზთან. სხვა როუტერები იმავე სამ ველს სხვადასხვა იარლიყის მიღმა მალავენ.

სად იშლება დამთხვევა ჩუმად

ტექნიკის შეცვლა ჩვეულებრივი შემთხვევაა. შეცვალეთ ქსელის ბარათი, ან გადაიტანეთ მანქანა Ethernet-სა და Wi-Fi-ს შორის, და მისამართი, რომელსაც როუტერი ხედავს, მასთან ერთად იცვლება. ძველი რეზერვაცია სიაში რჩება და კვლავ სწორად გამოიყურება.

გადაყენება მეორე შემთხვევაა და IPv6-ზე ყველაზე მტკივნეულად კბენს. ახალი ინსტალაცია შეიძლება ახალი DUID შექმნას, სანამ ძველი IPv4 იჯარა ჯერ კიდევ მოქმედებს, ამიტომ v4 მისამართი გარკვეულ დროს ცოცხლობს და v6 ჩანაწერი ჩერდება მოქმედებას ყოველგვარი ხილული რედაქტირების გარეშე.

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

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

კონფიგურაცია ჰოსტის მხრიდან და რა ღირს

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

ფასი საკუთრებაა. ახლა პრეფიქსს, კარიბჭეს და გადამწყვეტებს თქვენ აწვდით და მისამართი დინამიური აუზის გარეთ თავად უნდა შეინარჩუნოთ. netplan-იან Ubuntu-ში მას /etc/netplan/01-vpn.yaml ატარებს:

network:
  version: 2
  ethernets:
    eth0:
      dhcp4: false
      addresses: [192.168.50.10/24]
      routes:
        - to: default
          via: 192.168.50.1
      nameservers:
        addresses: [192.168.50.1]

NetworkManager-ის მომხმარებლები იმავე მდგომარეობას აღწევენ nmcli con mod "Wired connection 1" ipv4.method manual ipv4.addresses 192.168.50.10/24 ipv4.gateway 192.168.50.1-ით, შემდეგ nmcli con up "Wired connection 1"-ით. netplan გამოიყენეთ პირველივე ცდაზე netplan apply-ის ნაცვლად netplan try-ით; არასწორად აკრეფილი კარიბჭე ყუთს ქსელიდან ამოიღებს და კონსოლის ძებნაში დაგტოვებთ.

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

სტაბილური LAN მისამართი საჯარო ბოლო წერტილი არ არის

მიმართეთ პორტის გადამისამართება 192.168.50.10-ზე და წესი გაუძლებს LAN მხარეს ყველა ცვლილებას. ის სტაბილურ ინტერნეტ მისამართს არ გაძლევთ. თქვენი საჯარო IP პროვაიდერს ეკუთვნის და შეიძლება გადაადგილდეს ხელახალი დაკავშირებისას ან მოდემის შეცვლისას, დინამიური DNS სწორედ ამისთვისაა.

ოპერატორის დონის NAT-ის უკან საერთოდ არ არსებობს საჯარო IPv4 გადასამისამართებლად და არც ერთი რეზერვაცია არ ქმნის მას. ყველაფერზე ადრე შეამოწმეთ როუტერის WAN გვერდი: თუ მისამართი საერთო დიაპაზონშია, შემომავალი გადამისამართება ვერ იმუშავებს, რაც არ უნდა სუფთა იყოს რეზერვაცია.

მესამე მისამართი გვირაბის აუზია, ხშირად რაღაც 10.8.0.0/24-ის მსგავსი. ეს მისამართები მხოლოდ გვირაბის შიგნით არსებობს და LAN-ზე არასოდეს ჩნდება. მათი სერვერის LAN მისამართთან არევა არის გზა, რომლითაც პორტი საბოლოოდ გადამისამართდება კლიენტზე, რომელიც ონლაინშია მხოლოდ მაშინ, სანამ დაკავშირებულია.

შეამოწმეთ გზა იმ თანმიმდევრობით, რომლითაც წყდება

დაიწყეთ როუტერიდან. შეადარეთ იჯარების ცხრილის ჩანაწერი რეზერვაციის სამიზნეს; თუ სერვერმა აუზის მისამართი აიღო, იდენტიფიკატორი არასწორია და ჰოსტზე ip link show გაძლევთ შედარების მნიშვნელობას.

შემდეგ ჰოსტი. ip -4 addr show eth0 უნდა აჩვენოს მოსალოდნელი მისამართი და პრეფიქსი. მეორე მისამართი იმავე ინტერფეისზე, როგორც წესი, ნიშნავს, რომ DHCP ჯერ კიდევ მუშაობს თქვენი სტატიკური კონფიგურაციის გვერდით.

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

დაასრულეთ გარედან, ტელეფონზე გამორთული Wi-Fi-ით. სწორედ ეს ერთი ტესტი ჰყოფს „ლოკალური მისამართი არასწორია“ და „საჯარო ხელმისაწვდომობა გატეხილია“, ის ორი პრობლემა, რომლებსაც ეს კონფიგურაცია გამუდმებით ურევს.

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