Kāpēc DHCP rezervācija nav statiska IP jūsu VPN serverim

Rezervācija atbilst klienta identifikatoram, nevis mašīnai, un tā nekad nepadara jūsu publisko IP statisku. Kas patiešām pārvieto mājas VPN servera adresi.

Pārvietoju mājas VPN kārbu no Wi-Fi uz Ethernet, un tās „pastāvīgā“ adrese mainījās tajā pašā vakarā. Maršrutētājā nekas nebija salūzis. Rezervācija bija atbilsusi bezvadu adapterim, un šis adapters vairs nebija ceļā.

Šim pašam pārpratumam ir otra puse. LAN adreses sakārtošana neko nedara adresei, uz kuru pieslēdzas jūsu draugi, un tai nav nekāda sakara ar privāto kopu, ko VPN dod klientiem. Trīs adreses, trīs atsevišķi kļūmes režīmi, un tikai viens no tiem ir rezervācijas darbs.

Rezervācija atbilst klientam, nevis ierīcei

DHCPv4 rezervācija ir piesaistīta klienta aparatūras adresei; DHCPv6 tā ir piesaistīta DUID, kuru klientam paredzēts saglabāt. hostname lauks ir cilvēkiem domāts apzīmējums. Maršrutētājs patiešām salīdzina identifikatoru, kas atnāk pieprasījumā.

Lasiet ierakstu kā nosacījumu: kad šis identifikators prasa, dodiet tam šo adresi. Atjauninājumi saglabā to pašu nomu, kamēr atbilstība pastāv, un pārstartēšana vienkārši prasa vēlreiz. Kad identifikators mainās, pieprasījums palaiž garām rezervāciju un klients paņem to, ko piedāvā dinamiskā kopa. Nekādas kļūdas, nekāda brīdinājuma, tikai cita adrese.

OpenWrt skaidri parāda formu. Viens config host bloks failā /etc/config/dhcp saista vārdu, MAC un adresi kopā, un statisko nomu dokumentācija paskaidro, kā šis ieraksts sadarbojas ar kopu. Citi maršrutētāji tos pašus trīs laukus slēpj aiz citiem apzīmējumiem.

Kur atbilstība klusi iztrūkst

Aparatūras maiņa ir parastais gadījums. Nomainiet tīkla karti vai pārvietojiet mašīnu starp Ethernet un Wi-Fi, un adrese, ko redz maršrutētājs, mainās līdzi. Vecā rezervācija paliek sarakstā un joprojām izskatās pareiza.

Pārinstalēšana ir otrais gadījums, un tā vispārīgāk iekodas IPv6. Svaiga instalācija var radīt jaunu DUID, kamēr vecā IPv4 noma vēl ir spēkā, tāpēc v4 adrese kādu laiku izdzīvo un v6 ieraksts pārstāj darboties bez redzamas rediģēšanas.

Trešais ir piesprausts klienta identifikators. Vairāki DHCP klienti ļauj MAC vietā iestatīt identifikatora virkni. Ja atjauninājums vai konfigurācijas pārrakstīšana šo iestatījumu izmet, atbilstība pazūd, kaut arī mašīna nav pārvietota.

Ceturtais ir dublēšanās: vecs bloks un jauns bloks vienam un tam pašam hostam. Serveris atbild ar to noteikumu, kas atbilst, bieži vien ar kopas adresi, no kuras gribējāt izvairīties. Dzēsiet veco ierakstu, nevis pievienojiet otru.

Konfigurācija hosta pusē un cik tā maksā

Adreses iestatīšana hostā pilnībā novērš atbilstības jautājumu. Saskarne ceļas ar šo adresi neatkarīgi no tā, vai DHCP atbild, un to jūs gribat no mašīnas, kurai jābūt sasniedzamai pēc maršrutētāja pārstartēšanas.

Cena ir īpašumtiesības. Tagad prefiksu, vārteju un atrisinātājus nodrošināt jums, un adrese pašiem jātur ārpus dinamiskās kopas. Ubuntu ar netplan to nes /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 lietotāji nonāk tajā pašā stāvoklī ar nmcli con mod "Wired connection 1" ipv4.method manual ipv4.addresses 192.168.50.10/24 ipv4.gateway 192.168.50.1, pēc tam ar nmcli con up "Wired connection 1". Pirmajā mēģinājumā lietojiet netplan ar netplan try, nevis ar netplan apply; nepareizi ievadīta vārteja izrauj kārbu no tīkla un atstāj jūs meklējam konsoli.

Tomēr paturiet atbilstošu rezervāciju. Tā nav lieka. Ieraksts fiksē adresi maršrutētāja pusē un neļauj DHCP serverim dot šo adresi viesu ierīcei, ja kāds vēlāk paplašina kopu.

Stabila LAN adrese nav publisks galapunkts

Novirziet porta pāradresāciju uz 192.168.50.10, un noteikums pārdzīvos jebkuru LAN puses izmaiņu. Stabilu interneta adresi tas gan nedod. Jūsu publiskā IP pieder ISP un var pārvietoties atkārtotas pieslēgšanās vai modema maiņas laikā, un dinamiskais DNS ir domāts tieši tam.

Aiz operatora līmeņa NAT publiskas IPv4 pāradresēšanai vispār nav, un neviena rezervācija to nerada. Vispirms pārbaudiet maršrutētāja WAN lapu: ja adrese ir koplietotā diapazonā, ienākošā pāradresācija nevar darboties, lai cik tīra būtu rezervācija.

Trešā adrese ir tuneļa kopa, bieži kaut kas līdzīgs 10.8.0.0/24. Šīs adreses pastāv tikai tuneļa iekšpusē un nekad neparādās LAN. Sajaukt tās ar servera LAN adresi ir tas ceļš, kā ports galu galā tiek pāradresēts uz klientu, kas ir tiešsaistē tikai tik ilgi, kamēr ir pieslēgts.

Pārbaudiet ceļu tādā secībā, kādā tas lūzt

Sāciet ar maršrutētāju. Salīdziniet nomu tabulas ierakstu ar rezervācijas mērķi; ja serveris paņēma kopas adresi, identifikators ir nepareizs, un ip link show hostā dod salīdzināmo vērtību.

Tad hosts. ip -4 addr show eth0 jārāda gaidītā adrese un prefikss. Otra adrese tajā pašā saskarnē parasti nozīmē, ka DHCP joprojām darbojas līdzās jūsu statiskajai konfigurācijai.

Tad pāradresācija. Pārliecinieties, ka galamērķis joprojām ir vienāds ar adresi, kuru tikko pārbaudījāt, un ka kaut kas klausās ar ss -lntp. Pāradresācija uz slēgtu portu no ārpuses izskatās tieši kā salūzusi pāradresācija.

Pabeidziet no ārpuses, tālrunī ar izslēgtu Wi-Fi. Šis viens tests atdala „vietējā adrese ir nepareiza“ no „publiskā sasniedzamība ir salūzusi“, abas problēmas, ko šī iekārta nemitīgi sajauc.

Pierakstiet trīs adreses, LAN, publisko un tuneļa kopu, un atzīmējiet, kura sistēma kuru pārvalda. Kad nākamajā mēnesī savienojums neizdosies, jūs zināsiet, kuru pārbaudīt, nevis mainīsiet visas trīs uzreiz.

Saistītie raksti