Alamat VPN lawan pajakan DHCP LAN: siapa yang memberikan IP terowong?
Klien VPN anda menunjukkan alamat yang tidak pernah muncul dalam fail pajakan LAN. Baca klien, muatan IKEv2 dan kumpulan gateway untuk mencari pemberi sebenar.
Sambungkan klien dan lihat penyesuai dan bukan ikon Wi-Fi. Alamat seperti 10.80.0.14 mungkin berada pada terowong walaupun tiada pelayan DHCP di LAN pejabat pernah merekodkan pajakan itu. Proses yang memilih nombor itulah yang menentukan di mana penyelesaian masalah bermula.
Pada klien semuanya kelihatan sama: satu alamat IPv4, satu topeng, kadangkala gateway lalai. Perbezaannya hanya muncul apabila anda bertanya siapa yang menjawab alamat itu dan siapa yang menyimpan rekodnya.
Baca alamat terowong dari sisi klien
Windows menunjukkan perbezaan jika anda membaca seluruh blok dan bukan baris pertama. ipconfig /all mencetak keterangan penyesuai, alamat fizikal dan baris DHCP. Penyesuai dail PPP atau IKEv2 biasanya melaporkan DHCP sebagai dimatikan, kerana sambungan telah merundingkan alamatnya semasa dail dan bukannya menyewa daripada pelayan LAN. Penyesuai terowong dengan DHCP dihidupkan adalah luar biasa dan wajar disiasat secara berasingan.
Linux membahagikan maklumat yang sama kepada dua alat. ip -4 addr show dev tun0 memberikan alamat dan panjang awalan. nmcli -f IP4 connection show work mendedahkan sama ada nilai itu datang daripada profil sambungan, pertukaran DHCP pada pautan atau konfigurasi yang ditolak. WireGuard ialah kes paling jelas, kerana wg-quick menggunakan baris Address daripada fail konfigurasi apabila antara muka muncul dan tiada rakan sebaya memperuntukkan apa-apa semasa menyambung.
Awalan juga memberitahu sesuatu. /32, atau topeng 255.255.255.255, bermaksud gateway menjangka untuk menghalakan ke satu alamat hos, manakala topeng yang lebih luas mencadangkan subrangkaian pada pautan di suatu tempat di belakang terowong.
Apa yang dibawa oleh muatan konfigurasi IKEv2
IKEv2 mempunyai mekanisme khusus untuk tugas ini. Muatan konfigurasi yang diterangkan dalam RFC 7296, seksyen 3.15.1 membawa atribut seperti INTERNAL_IP4_ADDRESS, INTERNAL_IP4_NETMASK, INTERNAL_IP4_DNS dan pasangan IPv6 mereka. Klien menghantar atribut dengan nilai panjang sifar apabila tiada keutamaan, dan penjawab memulangkan nilai yang mahu digunakan. Pertukaran itu berjalan di dalam IKE_AUTH, sudah disulitkan, jadi tiada siaran DHCP pernah melintasi terowong.
Dua kesan menyusul. Pertama, alamat dipilih oleh penjawab atau mana-mana bahagian belakang kebenaran yang dirujuknya, sebab itu kumpulan boleh berada pada gateway, dalam balasan RADIUS atau dalam pemetaan penyedia identiti. Kedua, atribut DNS berasingan daripada atribut alamat. Menerima 10.80.0.14 tidak mengatakan apa-apa tentang penyelesai mana yang kembali, atau sama ada ada yang kembali.
Atribut topeng rangkaian adalah pilihan dalam amalan. Banyak penggunaan hanya memulangkan alamat dan membiarkan klien memasang laluan hos, sebab itu kumpulan yang sama boleh kelihatan seperti /32 pada satu klien dan /24 pada klien lain.
Di mana skop DHCP LAN dan kumpulan VPN bertembung
Masalah bermula apabila kedua-dua pemberi menunjuk julat yang sama. Pelayan DHCP untuk 10.20.30.0/24 tidak tahu apa-apa tentang kumpulan VPN yang dikonfigurasikan untuk 10.20.30.128/25, jadi tiada apa yang menghalangnya daripada memajakkan 10.20.30.140 kepada pencetak sementara gateway memberikan alamat yang sama kepada klien jauh. Pertembungan itu kekal senyap berhari-hari dan kemudian muncul sebagai pendua sekali-sekala.
Reka bentuk tapak-ke-tapak yang dihalakan mengelakkan pertembungan secara pembinaan. Hos di cawangan menyimpan alamat yang diberikan oleh pelayan DHCP tempatannya. Antara muka terowong pada kedua-dua gateway membawa alamat pautan mereka sendiri, dan jadual penghalaan menentukan bagaimana paket bergerak. Alamat klien akses jauh ialah kategori ketiga dan tidak patut dicampur dengan alamat pautan gateway.
Menjambatani terowong ke LAN menghapuskan pemisahan itu. Jika reka bentuk benar-benar memerlukan satu domain siaran, titik akhir VPN mesti menyertai keputusan peruntukan yang sama seperti pelayan DHCP, melalui geganti atau sumber berautoriti bersama, dan bukannya mengeluarkan alamat sendiri.
Sahkan proses mana yang memiliki alamat
Buktikan pemilikan sebelum menukar skop. Pada klien, catat alamat dan awalan. Pada LAN, cari dalam pangkalan data pajakan. Pada gateway, senaraikan kumpulan yang dikonfigurasikan untuk diagihkannya. Alamat yang ditemui dalam fail pajakan milik pelayan DHCP, bermakna terowong dijambatani atau digeganti; alamat yang hanya ditemui dalam kumpulan gateway milik titik akhir terowong.
# client: address and prefix on the tunnel interface
ip -4 addr show dev tun0
# LAN DHCP server: is this address leased to anyone?
grep -c '10.80.0.14' /var/lib/dhcp/dhcpd.leases
# gateway: pools that remote-access clients draw from
sudo swanctl --list-pools
Catat empat perkara apabila jawapannya jelas: komponen mana yang memperuntukkan alamat klien, julat mana yang ditempah untuknya, bagaimana trafik balik sampai ke julat itu dan sumber mana yang menerimanya. Empat entri itu menjadikan satu baris penyesuai maya sebagai fakta operasi.
Ulangi pemeriksaan atribut DNS semasa anda di sana. Kumpulan yang mengagihkan alamat tetapi tiada penyelesai membiarkan klien pada DNS tempatannya, yang merupakan kegagalan berbeza daripada kumpulan yang mengagihkan alamat yang sudah digunakan oleh LAN.