Anwani ya VPN dhidi ya ukodishaji wa DHCP kwenye LAN: nani hutoa IP ya handaki?

Unganisha mteja na uangalie adapta badala ya aikoni ya Wi-Fi. Anwani kama 10.80.0.14 inaweza kukaa kwenye handaki ilhali hakuna seva ya DHCP kwenye LAN ya ofisi iliyowahi kurekodi ukodishaji huo. Mchakato uliochagua namba ndio huamua utatuzi wa tatizo unaanzia wapi.

Kwa upande wa mteja kila kitu kinaonekana sawa: anwani moja ya IPv4, kifuniko kimoja, wakati mwingine lango chaguo-msingi. Tofauti huonekana tu unapouliza nani hujibu anwani hiyo na nani huweka kumbukumbu yake.

Soma anwani ya handaki kutoka upande wa mteja

Windows huonyesha tofauti ikiwa utasoma kizuizi kizima badala ya mstari wa kwanza. ipconfig /all huchapisha maelezo ya adapta, anwani halisi na mstari wa DHCP. Adapta ya kupiga simu ya PPP au IKEv2 kwa kawaida huripoti DHCP kama imezimwa, kwa sababu muunganisho ulijadili anwani yake wakati wa kupiga simu badala ya kuikodisha kutoka seva ya LAN. Adapta ya handaki yenye DHCP imewashwa si ya kawaida na inafaa uchunguzi wa peke yake.

Linux hugawanya taarifa hiyo hiyo kwa zana mbili. ip -4 addr show dev tun0 hutoa anwani na urefu wa kiambishi awali. nmcli -f IP4 connection show work hufichua kama thamani ilitoka kwenye wasifu wa muunganisho, mabadilishano ya DHCP kwenye kiungo au usanidi uliosukumwa. WireGuard ndilo wazo lililo wazi zaidi, kwa sababu wg-quick hutumia mstari wa Address kutoka faili ya usanidi wakati kiolesura kinaonekana na hakuna mwenzake anayegawa chochote wakati wa kuunganisha.

Kiambishi awali pia husema kitu. /32, au kifuniko cha 255.255.255.255, humaanisha lango linatarajia kuelekeza kwenye anwani moja ya mwenyeji, ilhali kifuniko kipana zaidi hudokeza subnet ya kwenye kiungo mahali pengine nyuma ya handaki.

Mzigo wa usanidi wa IKEv2 hubeba nini

IKEv2 ina utaratibu maalum wa kazi hii. Mzigo wa usanidi ulioelezwa katika RFC 7296, sehemu ya 3.15.1 hubeba sifa kama INTERNAL_IP4_ADDRESS, INTERNAL_IP4_NETMASK, INTERNAL_IP4_DNS na zinazolingana nazo za IPv6. Mteja hutuma sifa yenye thamani ya urefu sifuri wakati hana upendeleo, na anayejibu hurudisha thamani anayotaka itumike. Mabadilishano hayo huenda ndani ya IKE_AUTH, yakiwa yamesimbwa tayari, kwa hivyo hakuna matangazo ya DHCP yanayovuka handaki.

Hufuata matokeo mawili. Kwanza, anwani huchaguliwa na anayejibu au sehemu yoyote ya nyuma ya uidhinishaji anayoitafuta, ndiyo sababu bwawa linaweza kukaa kwenye lango, katika jibu la RADIUS au katika ramani ya mtoa utambulisho. Pili, sifa ya DNS imetenganishwa na sifa ya anwani. Kupokea 10.80.0.14 hakusemi chochote kuhusu ni kisuluhishi kipi kilichorudi, au kama kimerudi chochote.

Sifa ya kifuniko cha mtandao ni ya hiari kivitendo. Usambazaji mwingi hurudisha anwani pekee na kumruhusu mteja kufunga njia ya mwenyeji, ndiyo sababu bwawa lilelile linaweza kuonekana kama /32 kwa mteja mmoja na /24 kwa mwingine.

Mahali ambapo wigo wa DHCP wa LAN na bwawa la VPN hugongana

Tatizo huanza wakati wagawaji wote wawili wanaelekeza kwenye masafa yale yale. Seva ya DHCP ya 10.20.30.0/24 haijui chochote kuhusu bwawa la VPN lililowekwa kwa 10.20.30.128/25, kwa hivyo hakuna kinachomzuia kukodisha 10.20.30.140 kwa kichapishi ilhali lango linatoa anwani hiyo hiyo kwa mteja wa mbali. Mgongano hukaa kimya kwa siku kadhaa kisha hujitokeza kama nakala ya mara kwa mara.

Muundo wa tovuti-hadi-tovuti ulioelekezwa huepuka mgongano kwa muundo wake wenyewe. Mwenyeji katika tawi huhifadhi anwani aliyopewa na seva yake ya DHCP ya ndani. Violesura vya handaki kwenye lango zote mbili hubeba anwani zao za kiungo, na jedwali la uelekezaji huamua jinsi pakiti zinasafiri. Anwani za wateja wa ufikiaji wa mbali ni aina ya tatu na hazipaswi kuchanganywa na anwani za kiungo za lango.

Kuunganisha handaki kwenye LAN kwa daraja huondoa utenganishaji huo. Ikiwa muundo unahitaji kwa kweli kikoa kimoja cha matangazo, kituo cha mwisho cha VPN lazima kishiriki katika maamuzi yale yale ya ugawaji kama seva ya DHCP, kupitia relay au chanzo cha pamoja cha mamlaka, badala ya kutoa anwani yenyewe.

Thibitisha ni mchakato upi unaomiliki anwani

Thibitisha umiliki kabla ya kubadilisha wigo. Kwa upande wa mteja andika anwani na kiambishi awali. Kwenye LAN tafuta katika hifadhidata ya ukodishaji. Kwenye lango orodhesha mabwawa ambayo imewekwa kugawa. Anwani inayopatikana katika faili ya ukodishaji ni ya seva ya DHCP, kumaanisha handaki limeunganishwa kwa daraja au kupitishwa kwa relay; anwani inayopatikana tu katika bwawa la lango ni ya kituo cha mwisho cha handaki.

# 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

Andika mambo manne wakati jibu liko wazi: sehemu ipi hugawa anwani ya mteja, masafa gani yamehifadhiwa kwa ajili yake, trafiki inayorudi inafikaje masafa hayo na rasilimali zipi huikubali. Maandishi hayo manne hubadilisha mstari wa adapta pepe kuwa ukweli wa kiutendaji.

Rudia ukaguzi wa sifa ya DNS wakati ukiwa hapo. Bwawa linalogawa anwani lakini bila kisuluhishi humwacha mteja kwenye DNS yake ya ndani, ambayo ni hitilafu tofauti na bwawa linalogawa anwani ambayo LAN tayari inaitumia.