Azure P2S VPN-ൽ സ്ഥിര IP: ക്ലയന്റ് വിലാസം എന്തുകൊണ്ട് മാറുന്നു
Azure point-to-site ഓരോ കണക്ഷനിലും പൂളിൽ നിന്ന് അടുത്ത ലഭ്യമായ വിലാസം നൽകുന്നു, അതിനാൽ സ്ഥിരമായ ക്ലയന്റ് IP നിലവിലില്ല. പകരം ശ്രേണികളിലോ ഐഡന്റിറ്റിയിലോ ആക്സസ് അടിസ്ഥാനമാക്കുക.
ഓരോ Azure point-to-site ക്ലയന്റും പ്രാമാണീകരണ സമയത്ത് പൂളിൽ നിന്ന് ഒരു വിലാസം സ്വീകരിക്കുന്നു, ആ കണക്ഷൻ നിലനിൽക്കുന്നിടത്തോളം മാത്രം അത് സൂക്ഷിക്കുന്നു. റിസർവേഷൻ പട്ടികയില്ല, ഉപയോക്താവിന് അനുസരിച്ചുള്ള മാപ്പിംഗില്ല, “ഈ വ്യക്തിക്ക് എപ്പോഴും 172.16.0.10 നൽകുക” എന്നർത്ഥമുള്ള ഗേറ്റ്‌വേ ക്രമീകരണവുമില്ല. ഈ ഒരു സംവിധാനം തന്നെയാണ് പിന്നീട് ആളുകൾ നേരിടുന്ന രണ്ട് ലക്ഷണങ്ങളും വിശദീകരിക്കുന്നത്: മുമ്പ് ഒത്തുപോയ ഉപയോക്താവുമായി ഇനി ഒത്തുപോകാത്ത NSG നിയമം, ആരും ഉദ്ദേശ്യപൂർവ്വം ചേർക്കാത്ത ഒരു യന്ത്രത്തെ നിശ്ശബ്ദമായി കടത്തിവിടുന്ന അനുമതിപ്പട്ടിക. നിയമത്തെ കൂടുതൽ മികച്ച IP നിയമം കൊണ്ട് മാറ്റുന്നത് രണ്ടിനെയും ശരിയാക്കുന്നില്ല, കാരണം നിയമം പേരെടുത്തു പറയുന്ന കാര്യം നിങ്ങൾ നിയന്ത്രിക്കാത്ത ഒരു സമയക്രമം അനുസരിച്ച് വീണ്ടും അനുവദിക്കപ്പെടുന്നു.
പൂൾ ശേഷിയാണ്, ഐഡന്റിറ്റിയല്ല. ഒരേസമയത്തുള്ള ടണലുകൾക്ക് അദ്വിതീയ വിലാസങ്ങൾ ലഭിക്കാൻ അത് നിലനിൽക്കുന്നു, ലീസ് അവസാനിക്കുന്ന നിമിഷം അവ പുനരുപയോഗിക്കുന്നു. അത് വ്യക്തമായാൽ, ഉപയോഗപ്രദമായ ചോദ്യം “ഈ ക്ലയന്റിനെ എങ്ങനെ പിന്ന് ചെയ്യാം” എന്നതിൽ നിന്ന് “ഗേറ്റ്‌വേ പുനരുപയോഗിക്കാത്ത എന്തിനെതിരെ എനിക്ക് നിയമം എഴുതാം” എന്നതിലേക്ക് മാറുന്നു.
ക്ലയന്റ് കണക്റ്റ് ചെയ്യുമ്പോൾ ഗേറ്റ്‌വേ യഥാർത്ഥത്തിൽ എന്ത് ചെയ്യുന്നു
ഗേറ്റ്‌വേ ക്രമീകരിച്ച ക്ലയന്റ് വിലാസ പൂൾ സൂക്ഷിക്കുന്നു, അതിനെ ലീസ് പട്ടികയായി കണക്കാക്കുന്നു. കണക്ഷനിൽ അത് അടുത്ത ലഭ്യമായ വിലാസം, പ്രായോഗികമായി ഏറ്റവും താഴ്ന്ന ലഭ്യമായത് എടുത്ത്, ക്ലയന്റ് വിച്ഛേദിക്കുന്നതോ ലീസ് അവസാനിക്കുന്നതോ വരെ ടണൽ അഡാപ്റ്ററിന് നൽകുന്നു. തീരുമാനിക്കുന്നത് ക്രമമാണ്, ഐഡന്റിറ്റിയല്ല: ശാന്തമായ കാലയളവിന് ശേഷം ആദ്യം വീണ്ടും കണക്റ്റ് ചെയ്യുന്നയാൾക്ക് അപ്പോൾ യാദൃശ്ചികമായി ഒഴിഞ്ഞുകിടക്കുന്ന ഏറ്റവും താഴ്ന്ന വിലാസം ലഭിക്കുന്നു.
പൂളിന്റെ വലിപ്പം പെരുമാറ്റം മറയ്ക്കുന്നു. പരീക്ഷകരുടെ എണ്ണത്തേക്കാൾ ഒന്നോ രണ്ടോ വിലാസം കൂടിയ ലാബ് പൂൾ നിർണ്ണായകമായി തോന്നുന്നു, കാരണം അതേ ലാപ്‌ടോപ്പ് എല്ലാ രാവിലെയും അതേ ക്രമത്തിൽ വീണ്ടും കണക്റ്റ് ചെയ്യാൻ സാധ്യതയുണ്ട്. മൂന്നാമതൊരു യന്ത്രം ചേർക്കുകയോ, പൂളിന്റെ വലിപ്പം മാറ്റുകയോ, ഉച്ചഭക്ഷണത്തിനിടയിൽ സെഷൻ കണക്റ്റ് ചെയ്ത് വെക്കുകയോ ചെയ്താൽ മാതൃക തകരുന്നു. വിലാസം ഒരിക്കലും സ്ഥിരമായിരുന്നില്ല; ക്യൂ ആയിരുന്നു സ്ഥിരം.
point-to-site കോൺഫിഗറേഷനിലെ ഏത് മാറ്റവും ലീസ് ഇടവും പുനഃസജ്ജീകരിക്കുന്നു. മറ്റൊരു പ്രാമാണീകരണ തരം, വലിപ്പം മാറ്റിയ പൂൾ, പുതിയ പൂൾ ശ്രേണി, അല്ലെങ്കിൽ പൊളിച്ച് വീണ്ടും നിർമ്മിച്ച ഗേറ്റ്‌വേ — എല്ലാം ക്ലയന്റുകളെ അവരുടെ പഴയ വിലാസങ്ങളുമായി ഇനി ഒത്തുപോകാത്ത പൂളിലേക്ക് തിരികെ അയക്കുന്നു. ആ മാറ്റത്തിൽ ഒന്നും നിങ്ങളുടെ NSG-യെ തൊടുന്നില്ല, അതുകൊണ്ടാണ് തകരാർ സ്വയംഭൂവായി തോന്നുന്നത്.
ഏകദേശം ഒരു മിനിറ്റിനുള്ളിൽ ഇത് കാണാം. കണക്റ്റ് ചെയ്യുക, ക്ലയന്റിന്റെ കണക്ഷൻ വിശദാംശങ്ങളിൽ ടണൽ വിലാസം കുറിക്കുക, വിച്ഛേദിക്കുക, രണ്ടാമത്തെ യന്ത്രം കണക്റ്റ് ചെയ്യുക, പിന്നീട് ആദ്യത്തേത് വീണ്ടും കണക്റ്റ് ചെയ്യുക. തിരികെ ലഭിക്കുന്ന വിലാസം രണ്ടാമത്തെ യന്ത്രം എന്ത് പിടിച്ചിരിക്കുന്നു എന്നതിനെ ആശ്രയിച്ചിരിക്കുന്നു, ആവശ്യപ്പെട്ടാൽ മുൻപത്തേത് പുനഃസ്ഥാപിക്കാൻ ഒരു പോർട്ടൽ ക്രമീകരണവുമില്ല.
ക്ലയന്റ് IP അടിസ്ഥാനമാക്കിയ NSG യഥാർത്ഥത്തിൽ കണക്ഷൻ ക്രമത്തെക്കുറിച്ചുള്ള ഒരു നിയമമാണ്
ആളുകൾ ആദ്യം എഴുതുന്ന നിയമം വ്യക്തമാണ്: മാനേജ്‌മെന്റ് VM-ന്റെ NIC-ലോ അതിന്റെ സബ്‌നെറ്റിലോ ഉള്ള ഇൻബൗണ്ട് നിയമം, ഉറവിടമായി VPN ക്ലയന്റിന്റെ ആന്തരിക വിലാസം. ചെറുതാണ്, എഴുതിയ ദിവസം തന്നെ പരീക്ഷണം പാസാകുന്നു, പൂളിൽ ഒന്നിൽ കൂടുതൽ ഒഴിഞ്ഞ വിലാസം ഉണ്ടായാൽ ഉടൻ പരാജയപ്പെടുന്നു.
ഇതിൽ നിന്ന് രണ്ട് പരാജയ രീതികൾ ഉണ്ടാകുന്നു, അവയിൽ ഒന്ന് മാത്രമാണ് ബഗ് പോലെ തോന്നുന്നത്. നിയമം പേരെടുത്തു പറയുന്ന വിലാസം അപ്പോൾ മറ്റൊരാൾ പിടിച്ചിരിക്കുന്നതിനാൽ നിയമാനുസൃത ഉപയോക്താവിനെ നിരസിക്കുന്നു, അത് ശല്യപ്പെടുത്തുന്ന സപ്പോർട്ട് ടിക്കറ്റായി വരുന്നു. അല്ലെങ്കിൽ നിയമം ഇപ്പോഴും വിശ്വസിക്കുന്ന ഒരു വിലാസം പാരമ്പര്യമായി ലഭിച്ചതിനാൽ അനുദ്ദേശ്യ ഉപയോക്താവിനെ അനുവദിക്കുന്നു, ആരെങ്കിലും ആക്സസ് ഓഡിറ്റ് ചെയ്യുന്നത് വരെ അത് ഒന്നുമായി വരുന്നില്ല.
നിയമം ലീസിനെ പിന്തുടരുന്നതിനാൽ, ഫലപ്രദമായ നയം “ആദ്യം കണക്റ്റ് ചെയ്യുന്നയാൾക്ക് മാനേജ്‌മെന്റ് ആക്സസ് ലഭിക്കുന്നു” എന്ന് വായിക്കുന്നു. ഇത് ഉദ്ദേശ്യത്തിന്റെ വസ്ത്രം ധരിച്ച കണക്ഷൻ ക്രമത്തിന്റെ വിവരണമാണ്, ഏത് നിയമ ശുചിത്വവും അതിനെ ഉദ്ദേശ്യ പ്രകടനമാക്കുന്നില്ല.
ക്ലയന്റ് ലീസും ഗേറ്റ്‌വേ വിലാസവും വ്യത്യസ്ത വസ്തുക്കളാണ്
ആശയക്കുഴപ്പത്തിന്റെ ഭൂരിഭാഗവും ഒരു വാക്കിൽ നിന്ന് വരുന്നു. ഗേറ്റ്‌വേയ്ക്ക് താരതമ്യേന സ്ഥിരമായ പൊതു IP ഉണ്ട്; ക്ലയന്റുകൾക്ക് പൂളിൽ നിന്നുള്ള സ്വകാര്യ വിലാസങ്ങളുണ്ട്, അവ സ്ഥിരമല്ല. സോൺ-റിഡണ്ടന്റ് അല്ലാത്ത VPN ഗേറ്റ്‌വേയ്ക്ക് പൊതു IP ചലനാത്മകമായി അനുവദിക്കപ്പെടുന്നു, പക്ഷേ അത് വലിപ്പമാറ്റം, റീസെറ്റ്, സാധാരണ അറ്റകുറ്റപ്പണി എന്നിവയെ അതിജീവിക്കുന്നു — ഗേറ്റ്‌വേ തന്നെ ഇല്ലാതാക്കി വീണ്ടും സൃഷ്ടിക്കുമ്പോൾ അത് മാറുന്നു. സോൺ-റിഡണ്ടന്റ്, സോണൽ ഗേറ്റ്‌വേ SKU-കൾ Standard SKU പൊതു IP ഉപയോഗിക്കുന്നു, ആ അനുവദനം സ്ഥിരമായിരിക്കണം.
ആ സ്ഥിരതയാണ് ഓൺ-പ്രെമൈസസ് പീയറിന് അതിന്റെ കോൺഫിഗറേഷനിൽ വേണ്ടത്, അത് ഒരു വ്യക്തിഗത ക്ലയന്റിനെ തിരിച്ചറിയുന്നതിനെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല. പങ്കാളി ഏത് വിലാസം കാണും എന്ന് ചോദിച്ചാൽ, ഉത്തരം site-to-site-ൽ ഗേറ്റ്‌വേയുടെ പൊതു IP അല്ലെങ്കിൽ പങ്കിട്ട NAT ശ്രേണി — ഒരിക്കലും ലാപ്‌ടോപ്പിന്റെ ടണൽ ലീസ് അല്ല.
ഗ്രൂപ്പ് പൂളുകൾ നിയമം എഴുതാൻ മൂല്യമുള്ള ഒരു ശ്രേണി നൽകുന്നു
Virtual WAN point-to-site ഉപയോക്തൃ ഗ്രൂപ്പുകളെ പിന്തുണയ്ക്കുന്നു, ഓരോ ഗ്രൂപ്പിനും സ്വന്തം ക്ലയന്റ് വിലാസ പൂൾ നൽകാം. അംഗത്വം ഐഡന്റിറ്റി കൊണ്ട് തീരുമാനിക്കുന്നു, അതിനാൽ ക്ലയന്റ് വീഴുന്ന ശ്രേണി പ്രവചനീയമാകുന്നു: പ്രവർത്തനങ്ങൾ ഒരു ശ്രേണിയിൽ, കരാറുകാർ മറ്റൊന്നിൽ, ശ്രേണി എന്നത് ഫയർവാൾ അല്ലെങ്കിൽ NSG നിയമത്തിന് ഊഹിക്കാതെ പേരെടുത്തു പറയാവുന്ന ഒന്നാണ്.
ഫലമായുണ്ടാകുന്ന നിയമ കൂട്ടത്തിന് അവലോകനം ചെയ്യാവുന്ന ഒരു രൂപമുണ്ട്:
- ഓരോ പ്രേക്ഷകർക്കും ഒരു പൂൾ, തലകളുടെ എണ്ണത്തേക്കാൾ ഏറ്റവും കൂടിയ ഒരേസമയ സെഷനുകൾക്കായി അളന്നത്;
- ഗ്രൂപ്പ് അംഗത്വം ഐഡന്റിറ്റി വഴി കൈകാര്യം ചെയ്യുന്നു, ആരെങ്കിലും ചേരുമ്പോഴെല്ലാം നിയമങ്ങൾ തിരുത്തിയല്ല;
- NSG അല്ലെങ്കിൽ Azure Firewall നിയമങ്ങൾ പൂൾ ശ്രേണികൾക്കെതിരെ എഴുതുന്നു, ഒരിക്കലും വ്യക്തിഗത ലീസുകൾക്കെതിരെ അല്ല;
- ഒരിക്കലും ഒരു ശ്രേണി പങ്കിടാൻ പാടില്ലാത്ത പ്രേക്ഷകർക്ക് വേറിട്ട ഹബ് അല്ലെങ്കിൽ ഗേറ്റ്‌വേ.
| Rule target | Survives a reconnect | What it still cannot express |
|---|---|---|
| Client tunnel address | No | Follows connection order and admits whoever holds the address next |
| Whole client pool | Yes | Grants every connected client identical access |
| Virtual WAN group pool | Yes | Only as reliable as group membership |
| Gateway public IP | Until the gateway is recreated | Identifies the site, not the person |
മുഴുവൻ പൂളും അനുമതിപ്പട്ടികയിൽ ചേർക്കുന്നത് സത്യസന്ധമാണ് പക്ഷേ പരുക്കനാണ്: ആ ശ്രേണിയിലെ ഓരോ കണക്റ്റ് ചെയ്ത ക്ലയന്റും ഒരേ ആക്സസ് നേടുന്നു. അത് അവലോകനത്തിനിടയിൽ കണ്ടെത്തുന്നതിന് പകരം ഉറക്കെ പറയാൻ മൂല്യമുള്ള നയ തീരുമാനമാണ്. ഇപ്പോഴും ഓരോ വ്യക്തിക്കും ഉത്തരം ആവശ്യമുള്ളത് റോൾ അസൈൻമെന്റുകൾ വഴി വിഭവത്തിനാണ്, പാക്കറ്റ് ഫിൽട്ടറിനല്ല.
വിന്യാസത്തിന് Virtual WAN-ലേക്ക് പോകാൻ കഴിയാത്തപ്പോൾ
പല ഗേറ്റ്‌വേകളും സാധാരണ VPN ഗേറ്റ്‌വേകളായി തുടരുന്നു, Virtual WAN-ലേക്ക് പോകുന്നത് നിസ്സാരമായ മാറ്റമല്ല. പ്രായോഗിക ഉത്തരം, ഉപയോക്താവിനനുസരിച്ചുള്ള തീരുമാനം പാക്കറ്റ് ഫിൽട്ടറിൽ നിന്ന് ഉപയോക്താവ് ആരെന്ന് ഇതിനകം അറിയുന്ന ഒന്നിലേക്ക് മാറ്റുക എന്നതാണ്.
വിഭവ തലത്തിലുള്ള ഐഡന്റിറ്റിയാണ് ഏറ്റവും വിലകുറഞ്ഞ പതിപ്പ്. Storage, SQL, Key Vault എല്ലാം ഉപയോക്താവ് അല്ലെങ്കിൽ ഗ്രൂപ്പ് അനുസരിച്ചുള്ള റോൾ അസൈൻമെന്റുകളോടെ Entra ID പ്രാമാണീകരണം പിന്തുണയ്ക്കുന്നു, അതിനാൽ VPN നെറ്റ്‌വർക്ക് എത്തിച്ചേരൽ മാത്രം തെളിയിച്ചാൽ മതി. പേരുള്ള അക്കൗണ്ടുകളുള്ള ജംപ് ഹോസ്റ്റ് ഭരണപരമായ ജോലിക്ക് അതേ ജോലി ചെയ്യുന്നു, കാരണം ഹോസ്റ്റ് വ്യക്തിയെ രേഖപ്പെടുത്തുന്നു, ടണൽ പാക്കറ്റുകൾ മാത്രം കൊണ്ടുപോകുന്നു. ക്ലയന്റുകളെ DNS-ൽ രജിസ്റ്റർ ചെയ്ത് സംഖ്യയ്ക്ക് പകരം പേര് അനുവദിക്കുന്നത് നിയമത്തെ ഒരു തലം ഉയർത്തുന്നു. ആപ്ലിക്കേഷൻ തലത്തിലുള്ള ഐഡന്റിറ്റി — സർട്ടിഫിക്കറ്റ് വിഷയം, ടോക്കൺ ക്ലെയിം, ഗ്രൂപ്പ് അംഗത്വം — തീരുമാനിക്കാൻ ആവശ്യപ്പെടുന്നത് നെറ്റ്‌വർക്കിനെയല്ല, ആപ്ലിക്കേഷനെയാകുമ്പോൾ പ്രവർത്തിക്കുന്നു.
സ്ഥിരമായ ഉറവിട വിലാസം നിർബന്ധിക്കുന്ന പങ്കാളിക്ക്, നിർവചിച്ച പിയർ പ്രിഫിക്സുള്ള site-to-site അല്ലെങ്കിൽ ExpressRoute ആണ് ഉത്തരം. അവർ പിയർ പ്രിഫിക്സ് അനുവദിക്കുന്നു, അവരുടെ ഭാഗത്ത് പ്രത്യക്ഷപ്പെടുന്ന വിലാസം ഗേറ്റ്‌വേയുടേതാണ്, ആരെങ്കിലും ലാപ്‌ടോപ്പ് റീബൂട്ട് ചെയ്യുമ്പോൾ അത് മാറുന്നില്ല.
മറ്റൊരു അനുമതിപ്പട്ടിക തിരുത്തുന്നതിന് മുമ്പ് പൂൾ പരിശോധിക്കുക
പൂളിന്റെ രണ്ട് സവിശേഷതകളാണ് ആളുകൾ ക്ലയന്റിന് ആരോപിക്കുന്ന പെരുമാറ്റത്തിന്റെ ഭൂരിഭാഗത്തിനും കാരണം. വളരെ ചെറിയ പൂൾ ലീസുകൾ വേഗത്തിൽ പുനരുപയോഗിക്കുന്നു, അതിനാൽ വിലാസങ്ങൾ നിരന്തരം നീങ്ങുന്നതായി തോന്നുന്നു, വിലാസ അടിസ്ഥാനമാക്കിയ ഏത് നിയമവും രൂപകൽപ്പനയാൽ അസ്ഥിരമായി തോന്നുന്നു. ഓൺ-പ്രെമൈസസ് ശ്രേണികളുമായോ വെർച്വൽ നെറ്റ്‌വർക്ക് വിലാസ സ്ഥലവുമായോ ഓവർലാപ്പ് ചെയ്യുന്ന പൂൾ ഒരു ഫയർവാൾ നിയമവും പരിഹരിക്കാത്ത റൂട്ടിംഗ് അവ്യക്തത സൃഷ്ടിക്കുന്നു.
ഒരു നിയമം തൊടുന്നതിന് മുമ്പ് മൂന്ന് കാര്യങ്ങൾ ഒരു പേജിൽ ഇടുക: point-to-site പൂൾ, വെർച്വൽ നെറ്റ്‌വർക്ക് വിലാസ സ്ഥലം, ഓൺ-പ്രെമൈസസ് ശ്രേണികൾ. അവ ഓവർലാപ്പ് ചെയ്യാൻ പാടില്ല, പൂളിന് ഓരോ ഒരേസമയ ക്ലയന്റിനും സ്ഥലവും വീണ്ടും കണക്റ്റ് ചെയ്യാനുള്ള മാർജിനും വേണം.
പിന്നീട് ഈ ക്രമത്തിൽ ചക്രം അടയ്ക്കുക:
- രണ്ട് യന്ത്രങ്ങളിൽ നിന്ന് രണ്ട് ക്രമങ്ങളിലും കണക്റ്റ് ചെയ്ത് വിലാസങ്ങൾ താരതമ്യം ചെയ്യുക; അവ പരസ്പരം മാറാൻ കഴിയുമെങ്കിൽ, വിലാസ അടിസ്ഥാനമാക്കിയ ഒരു നിയമവും സുരക്ഷിതമല്ല.
- ഗേറ്റ്‌വേ Virtual WAN ആണോ എന്ന് പരിശോധിക്കുക; ആണെങ്കിൽ, വിലാസം തോറുമുള്ള നിയമങ്ങൾക്ക് പകരം ഗ്രൂപ്പ് പൂളുകൾ ഉപയോഗിക്കുക.
- നിയമം തെറ്റായ വ്യക്തിയുമായി ഒത്തുപോയാൽ എന്ത് സംഭവിക്കുമെന്ന് ചോദിക്കുക; ഉത്തരം ആക്സസ് സംഭവമാണെങ്കിൽ, നിയന്ത്രണം ഐഡന്റിറ്റിയിലേക്ക് മാറ്റുക.
- ഏത് ശ്രേണി ഏത് ഗ്രൂപ്പിന്റേതാണെന്ന് NSG നിർവചനങ്ങളുള്ള അതേ സംഭരണിയിൽ രേഖപ്പെടുത്തുക.
- പൂൾ, പ്രാമാണീകരണം അല്ലെങ്കിൽ ഗേറ്റ്‌വേ മാറ്റത്തിന് ശേഷം വീണ്ടും പരീക്ഷിക്കുക, കാരണം ആ മാറ്റങ്ങൾ അറിയിക്കാതെ മാപ്പിംഗ് വീണ്ടും എഴുതുന്നു.