Tatlong kondisyon ang nagtatakda kung aling identifier ang dapat gamitin ng isang reservation: aling sistema ang nagbabahagi ng address, nakakakita ba ang sistemang iyon ng layer-2 frame, at ano ang ginagamit nitong client key. Ang home router na may DHCP, bridged VPN at routed tunnel ay iba-iba ang sagot sa mga tanong na iyon. Mas matibay ang pagpili ng identifier kaysa sa pagsubok na i-freeze ang bawat MAC address na iniuulat ng adapter, dahil ang identifier ang aktwal na binabasa ng allocator.

Magsimula sa allocator at magtrabaho pabalik; ang identifier sa panig ng client ay ang anumang tinatanggap ng sistemang iyon.

Tanungin muna ang allocator

Ang DHCP server ay naglalaan mula sa pool at itinatapat ang mga reservation sa identifier na kinikilala nito, na maaaring hardware address, client identifier string o DUID depende sa bersyon ng protocol. Ang VPN server ay naglalaan mula sa sarili nitong pool at itinatapat sa kung ano ang inilalantad ng modelo ng configuration nito, kadalasan ang authenticated na Common Name. Ang bridged network ay maaaring magbigay ng parehong problema sa DHCP server na naglilingkod na sa LAN. Bawat isa ay ibang paghahanap, at ang reservation na wasto sa isa ay hindi nakikita ng iba.

Kumpirmahin kung ano talaga ang nakikita ng server bago mag-configure ng anuman. Ang reservation na nagpangalan ng maling identifier ay tahimik na nabibigo: ang client ay tumatanggap lamang ng address mula sa pool, at ang pagkakamali ay mukhang problema ng client.

Kung saan may kahulugan pa ang MAC address

Sa pisikal na Ethernet o Wi-Fi link, tinutukoy ng hardware address ang isang interface sa segment na iyon. Pinapaikot ito ng mga feature ng privacy, gumagawa ng bago ang mga virtual adapter, at ang laptop ay maaaring magpakita ng iba't ibang halaga sa Wi-Fi at sa dock. Ang routed TUN tunnel ay nagdadala ng IP packet at hindi ipinapadala ang orihinal na wireless identity sa malayong DHCP server, kaya ang MAC-based na reservation sa landas na iyon ay walang maipantapat. Naiiba ang TAP: nagdadala ito ng Ethernet frame at maaaring sumali sa bridged domain kung saan mahalaga pa rin ang layer-2 identifier.

Kahit doon, ang kaugnay na address ay ang ginagamit sa domain na iyon, hindi awtomatikong ang sa pisikal na uplink.

May sariling espasyo ang tunnel address at peer key

Ang routed OpenVPN deployment ay naglalaan ng address sa pamamagitan ng sarili nitong modelo: per-client configuration na naka-key sa authenticated na pangalan, o tahasang pool. Ang pagbabago ng DHCP reservation ng LAN router ay hindi lumilikha ng allocation na iyon, at ang pagdaragdag ng tunnel reservation ay hindi nakakaapekto sa LAN. Mas malayo ang WireGuard, dahil ang peer ay kinikilala sa pamamagitan ng pampublikong key at mga pinapayagang address, hindi sa anumang hardware identifier. Walang generic na Ethernet reservation ang pumapalit sa peer configuration doon.

Magtago ng imbentaryo na naghihiwalay sa apat na bagay: ang credential ng device, ang virtual adapter, ang identifier ng allocator at ang inilaan na address. Ang isang pisikal na makina ay maaaring may maraming adapter, address at session.

Ang matatag na address ay hindi pagkakakilanlan

Ang mahuhulaan na address ay maginhawa sa operasyon at hindi ito credential ng authentication. Ang mga patakaran sa pag-access na umaasa sa address ay tumitigil na maging pagsusuri ng pagkakakilanlan sa sandaling ito ay muling ilaan, ibahagi o pekein. Kung ang isang patakaran ay nakadepende sa address, i-coordinate ang muling paglalaan at pagbawi sa nagmamay-ari ng pagkakakilanlan, at itago ang tunay na desisyon sa authentication sa ibang lugar. Sa ganoon ang kaginhawahan ay hindi nagiging tanging ebidensya kung aling device ang kumonekta.

Itala nang sama-sama ang allocator, identifier at inilaan na address. Kapag nagbago ang isa, ang dalawa pa ang iyong sinusuri.

Kung ang dalawang sistema ay parehong nagsasabing naglalaan para sa parehong subnet, magpasya kung alin ang nagmamay-ari nito bago magdagdag ng reservation sa alinman sa kanila.

Kaugnay na mga artikulo