RRAS DHCP: alamat baru atau hanya opsi konfigurasi?
ACK di jejak VPN membuktikan adanya jawaban, bukan alokasi. RRAS bisa memiliki alamatnya sementara DHCP hanya mengirimkan opsi ke klien yang terhubung.
Membaca DHCPACK di rekaman sebagai bukti bahwa klien VPN memperoleh alamatnya dari DHCP adalah kesalahan. Biasanya itu hanya membuktikan bahwa suatu pesan DHCP telah dijawab. Windows RRAS dapat membagikan alamat sesi dari kumpulan statisnya sendiri sementara DHCP tetap memasok opsi kepada klien yang terhubung. Jenis permintaan memberi tahu Anda mana dari dua pekerjaan yang sedang berlangsung.
Dua pekerjaan yang berbagi satu jenis pesan
DHCP melakukan dua hal terpisah, dan keduanya berbagi jenis pesan. Yang satu mengalokasikan alamat dan sewa. Yang lain mengirimkan konfigurasi ke host yang sudah memiliki alamat, yang oleh RFC 2131 disebut DHCPINFORM. Balasan pada kasus kedua membawa opsi dan tidak membawa waktu sewa.
Jadi ACK adalah bukti adanya jawaban, bukan bukti alokasi. Pesan yang mendahuluinya menentukan pertanyaan mana yang diajukan. Bacalah baris permintaan lebih dulu dan sisa rekaman biasanya menjelaskan dirinya sendiri.
Dari mana RRAS memperoleh alamat
RRAS memiliki keputusan alamat VPN melalui metode penetapan IPv4 yang dikonfigurasi: server DHCP atau kumpulan alamat statis. Ketika kumpulannya statis, kumpulan itulah pengalokasinya, dan reservasi pada server DHCP terpisah tidak ikut menentukan dalam sesi itu. Kedua mekanisme dapat hidup berdampingan di jaringan yang sama tanpa salah satunya mengendalikan yang lain.
Get-Command -Module RemoteAccess *IPAddress*Temukan metode penetapan yang berlaku sebelum menelusuri masalah alamat. Jika kumpulannya statis, cakupan DHCP adalah tempat yang salah untuk dilihat. Perintah di atas mencantumkan cmdlet yang tersedia pada versi yang Anda jalankan, dan itu cukup untuk menemukan pengaturannya.
Apa yang bisa dan tidak bisa dibuktikan kelas pengguna
Kelas pengguna DHCP adalah string yang dikirim klien, bukan keanggotaan grup yang terautentikasi. Bahkan ketika klien mengirimkannya dan server mencocokkan kebijakan atasnya, label itu hanya membuktikan bahwa string tersebut sampai. RFC 3004 menyatakan terang-terangan bahwa opsi itu tidak mengautentikasi hak atas kelas tersebut.
Jangan berharap nama pengguna VPN, pengenal grup keamanan, atau alamat Ethernet laptop muncul di permintaan itu dalam bentuk yang dapat dipakai. Itu semua fakta autentikasi dan direktori, dan permintaan DHCP tidak membawa keduanya. Jika persyaratannya membedakan orang yang berwenang, terapkan di kebijakan VPN tempat identitas itu benar-benar ada. Pemisahan itulah alasan kedua sistem tetap independen.
Bandingkan buktinya, bukan ACK-nya
Bangun rantai bukti alih-alih membaca satu paket. Catat alamat yang diterima sesi, jenis dan bidang permintaan, opsi yang dikembalikan server, dan konfigurasi efektif klien sesudahnya. Setiap mata rantai menjawab pertanyaan berbeda, dan mata rantai yang hilang biasanya menjadi tempat gangguan sebenarnya.
Get-DhcpServerv4OptionValue -ScopeId 10.90.0.0Jika alamatnya berasal dari kumpulan RRAS, reservasi DHCP tidak menjelaskan apa pun. Jika opsinya sampai tetapi klien mengabaikannya, server sudah menjalankan tugasnya dan konfigurasi klien adalah perhentian berikutnya. Bandingkan kedua hasil itu secara eksplisit dan ACK tidak lagi ambigu. Dua rekaman, satu dari tiap metode penetapan, menyelesaikan perdebatan lebih cepat daripada dokumentasi mana pun.