Mengapa tempahan DHCP bukan IP statik untuk pelayan VPN anda

Saya memindahkan kotak VPN rumah dari Wi-Fi ke Ethernet dan alamat “kekal”nya berubah pada malam yang sama. Tiada apa pun pada penghala yang rosak. Tempahan itu sepadan dengan penyesuai wayarles, dan penyesuai itu tidak lagi berada di laluan.

Salah faham yang sama mempunyai separuh kedua. Membetulkan alamat LAN tidak melakukan apa-apa untuk alamat yang dihubungi rakan anda, dan ia tidak ada kaitan dengan kolam peribadi yang VPN berikan kepada klien. Tiga alamat, tiga mod kegagalan berasingan, dan hanya satu daripadanya ialah tugas sesuatu tempahan.

Tempahan sepadan dengan klien, bukan peranti

Dalam DHCPv4 tempahan berkunci pada alamat perkakasan klien; dalam DHCPv6 ia berkunci pada DUID yang dijangka dikekalkan oleh klien. Medan hostname ialah label untuk manusia. Apa yang penghala benar-benar bandingkan ialah pengecam yang tiba dalam permintaan.

Baca entri itu sebagai syarat: apabila pengecam ini meminta, berikan alamat ini. Pembaharuan mengekalkan pajakan yang sama selagi padanan kekal, dan but semula hanya meminta lagi. Apabila pengecam berubah, permintaan terlepas tempahan dan klien mengambil apa sahaja yang ditawarkan kolam dinamik. Tiada ralat, tiada amaran, hanya alamat yang berbeza.

OpenWrt menunjukkan bentuknya dengan jelas. Satu blok config host dalam /etc/config/dhcp mengikat nama, MAC dan alamat bersama-sama, dan dokumentasi pajakan statik menerangkan bagaimana entri itu berinteraksi dengan kolam. Penghala lain menyembunyikan tiga medan yang sama di sebalik label berbeza.

Di mana padanan itu gugur secara senyap

Menukar perkakasan ialah kes biasa. Tukar NIC, atau pindahkan mesin antara Ethernet dan Wi-Fi, dan alamat yang dilihat penghala berubah bersamanya. Tempahan lama kekal dalam senarai, masih kelihatan betul.

Pemasangan semula ialah kes kedua, dan ia paling kuat menggigit pada IPv6. Pemasangan baru boleh menjana DUID baru sementara pajakan IPv4 lama masih sah, jadi alamat v4 bertahan seketika dan entri v6 berhenti terpakai tanpa sebarang suntingan yang kelihatan.

Yang ketiga ialah pengecam klien yang dipin. Beberapa klien DHCP membenarkan anda menetapkan rentetan pengecam dan bukannya menggunakan MAC. Jika peningkatan atau penulisan semula konfigurasi menggugurkan tetapan itu, padanan hilang walaupun mesin tidak berpindah.

Yang keempat ialah pertindihan: blok lama dan blok baru untuk hos yang sama. Pelayan menjawab dengan peraturan yang sepadan, selalunya alamat kolam yang anda mahu elakkan. Padam entri lama dan bukannya menambah yang kedua.

Konfigurasi di sisi hos dan kosnya

Menetapkan alamat pada hos menghapuskan persoalan padanan sepenuhnya. Antara muka naik dengan alamat itu sama ada DHCP menjawab atau tidak, dan itulah yang anda mahu daripada mesin yang mesti boleh dicapai selepas penghala but semula.

Kosnya ialah pemilikan. Anda kini membekalkan awalan, get laluan dan penyelesai, dan anda sendiri mesti menyimpan alamat itu di luar kolam dinamik. Pada Ubuntu dengan netplan, /etc/netplan/01-vpn.yaml membawanya:

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]

Pengguna NetworkManager mencapai keadaan yang sama dengan nmcli con mod "Wired connection 1" ipv4.method manual ipv4.addresses 192.168.50.10/24 ipv4.gateway 192.168.50.1, kemudian nmcli con up "Wired connection 1". Gunakan netplan dengan netplan try pada percubaan pertama dan bukannya netplan apply; get laluan yang tersalah taip mengeluarkan kotak itu daripada rangkaian dan membiarkan anda mencari konsol.

Namun simpan tempahan yang sepadan. Ia bukan berlebihan. Entri itu merekodkan alamat di sisi penghala dan menghalang pelayan DHCP daripada memberikan alamat itu kepada peranti tetamu jika seseorang meluaskan kolam kemudian.

Alamat LAN yang stabil bukan titik akhir awam

Halakan port forward ke 192.168.50.10 dan peraturan itu bertahan setiap perubahan di sisi LAN. Ia tidak memberikan anda alamat internet yang stabil. IP awam anda milik ISP dan boleh bergerak semasa sambung semula atau pertukaran modem, itulah gunanya DNS dinamik.

Di sebalik NAT peringkat pembawa, tiada IPv4 awam untuk dipos ke hadapan sama sekali, dan tiada tempahan menciptanya. Periksa halaman WAN penghala sebelum apa-apa lagi: jika alamatnya berada dalam julat dikongsi, pemajuan masuk tidak mungkin berfungsi, sebersih mana pun tempahannya.

Alamat ketiga ialah kolam terowong, selalunya sesuatu seperti 10.8.0.0/24. Alamat itu hanya wujud di dalam terowong dan tidak pernah muncul pada LAN. Mengelirukannya dengan alamat LAN pelayan ialah cara sesuatu port akhirnya dimajukan kepada klien yang hanya dalam talian semasa ia bersambung.

Periksa laluan itu mengikut susunan ia rosak

Mulakan pada penghala. Bandingkan entri jadual pajakan dengan sasaran tempahan; jika pelayan mengambil alamat kolam, pengecamnya salah, dan ip link show pada hos memberikan nilai untuk dibandingkan.

Kemudian hos. ip -4 addr show eth0 sepatutnya melaporkan alamat dan awalan yang dijangka. Alamat kedua pada antara muka yang sama biasanya bermaksud DHCP masih berjalan di samping konfigurasi statik anda.

Kemudian pemajuan. Sahkan destinasi masih sama dengan alamat yang anda baru sahkan, dan sahkan sesuatu sedang mendengar dengan ss -lntp. Pemajuan ke port tertutup kelihatan sama seperti pemajuan rosak dari luar.

Akhiri dari luar, pada telefon dengan Wi-Fi dimatikan. Ujian yang satu itu memisahkan “alamat tempatan salah” daripada “kebolehsampaian awam rosak”, dua masalah yang sering dicampurkan oleh persediaan ini.

Catatkan ketiga-tiga alamat, LAN, awam dan kolam terowong, dan tandakan sistem mana yang memiliki setiap satu. Apabila sambungan gagal bulan depan anda akan tahu yang mana hendak diperiksa dan bukannya menukar ketiga-tiganya sekali gus.