ഒരു Azure VPN VM-ൽ രണ്ട് പൊതു IP: ഏത് എന്ത് ചെയ്യുന്നു

ഒരു Azure VPN VM-ൽ രണ്ട് പൊതു IP ഉണ്ടെങ്കിൽ അപൂർവ്വമായി മാത്രം ശരിയാകുന്ന ഒരു പ്രതീക്ഷ ഉണ്ടാകുന്നു: ക്ലയന്റുകൾ ബന്ധിപ്പിക്കുന്ന വിലാസം തന്നെ വെബ്സൈറ്റുകൾ കാണുന്ന വിലാസവുമാകും. ഈ ഫലം മൂന്ന് സ്വതന്ത്ര തീരുമാനങ്ങളിൽ നിന്നാണ് ഉണ്ടാകുന്നത്, അവയിൽ ആദ്യത്തേത് മാത്രമാണ് ടണൽ ശ്രോതാവിനെക്കുറിച്ചുള്ളത്. രണ്ടാമത്തേത് ഫോർവേഡ് ചെയ്ത ക്ലയന്റ് ട്രാഫിക്കിന് ഉപയോഗിക്കുന്ന ഗസ്റ്റ് ഉറവിടമാണ്, മൂന്നാമത്തേത് ആ ഉറവിടത്തിന് ബാധകമായ Azure-ന്റെ പുറത്തേക്കുള്ള രീതിയാണ്. ഒന്ന് മാറ്റിയാൽ ബാക്കി രണ്ടും ഉണ്ടായിരുന്നിടത്ത് തന്നെ നിൽക്കും, അതിനാൽ ഓരോന്നും വ്യക്തമായി തീരുമാനിക്കുക.

തീരുമാനം 1: ടണൽ എവിടെ അവസാനിക്കുന്നു

Azure-ന്റെ പൊതു IP NIC-ലെ സ്വകാര്യ IP കോൺഫിഗറേഷനുമായി ബന്ധിപ്പിച്ചിരിക്കുന്നു; ഗസ്റ്റ് ഓപ്പറേറ്റിംഗ് സിസ്റ്റത്തിനുള്ളിൽ നിങ്ങൾ ചേർക്കുന്ന വിലാസമല്ല ഇത്. ഊഹിക്കുന്നതിന് പകരം മാപ്പിംഗ് വായിക്കുക: az network nic show --ids /subscriptions/.../networkInterfaces/vpn-nic --query 'ipConfigurations[].{private:privateIPAddress,public:publicIPAddress.id}'. ആ ക്വറി ഏത് സ്വകാര്യ വിലാസം തിരികെ നൽകിയാലും, ഗസ്റ്റ് യഥാർത്ഥത്തിൽ അത് തന്നെ വേണം.

ഒരു NIC നിരവധി IP കോൺഫിഗറേഷനുകൾ വഹിക്കാം, അതിനാൽ രണ്ട് പൊതു വിലാസങ്ങൾക്ക് രണ്ട് NIC ആവശ്യമില്ല. ഡിസൈൻ യഥാർത്ഥത്തിൽ രണ്ട് NIC ഉപയോഗിക്കുന്നുവെങ്കിൽ, ഓരോന്നും അതിന്റേതായ ഗസ്റ്റ് റൂട്ടുകളും അടുത്ത ഹോപ്പുകളും കൊണ്ടുവരുന്നു, നിങ്ങൾ ലളിതമാക്കുന്നതിന് പകരം ഒരു റൂട്ടിംഗ് തീരുമാനം ചേർത്തു.

വ്യക്തമായ ലോക്കൽ ബൈൻഡുള്ള സേവനത്തിന് ഗസ്റ്റിന്റെ യഥാർത്ഥ സ്വകാര്യ വിലാസത്തിലേക്ക് ബൈൻഡ് ചെയ്യുക, ഒരിക്കലും പൊതു പ്ലേസ്ഹോൾഡറിലേക്ക് അല്ല. എല്ലാ വിലാസങ്ങളും സ്വീകരിക്കുന്ന ശ്രോതാവ് അതിലേക്ക് എത്തുന്ന ഓരോ IP കോൺഫിഗറേഷനിലൂടെയും ട്രാഫിക് സ്വീകരിക്കുന്നു, അതിനാൽ ബൈൻഡ് ക്രമം തീരുമാനിക്കുമെന്ന് പ്രതീക്ഷിക്കുന്നതിന് പകരം നെറ്റ്വർക്ക് സെക്യൂരിറ്റി ഗ്രൂപ്പും ഹോസ്റ്റ് ഫയർവാളും ഉപയോഗിച്ച് പ്രവേശനം പരിമിതപ്പെടുത്തുക.

തീരുമാനം 2: ഫോർവേഡ് ചെയ്ത ക്ലയന്റ് ഏത് ഉറവിടം ഉപയോഗിക്കുന്നു

ഗേറ്റ്വേ ക്ലയന്റ് അഭ്യർത്ഥന ഡീക്രിപ്റ്റ് ചെയ്തതിന് ശേഷം, അത് ഫോർവേഡ് ചെയ്യുന്ന പാക്കറ്റ് VPN ശ്രോതാവിലേക്ക് എത്തിയ പാക്കറ്റിൽ നിന്ന് വ്യത്യസ്തമാണ്. ഗസ്റ്റിന് ഫോർവേഡിംഗ് സജീവമാക്കിയതും, ഫ്ലോ അനുവദിക്കുന്ന ഫയർവാൾ നയവും, ക്ലൗഡ് ഡിസൈൻ അനുവദിക്കുന്ന ഉറവിട വിലാസവും വേണം. ക്ലയന്റിന്റെ ആന്തരിക വിലാസം വിവർത്തനം ചെയ്താൽ, Azure വിലയിരുത്തുന്നത് ആ വിവർത്തനം ചെയ്ത ഉറവിടമാണ്, ക്ലയന്റിന്റെ ആന്തരിക വിലാസമല്ല.

ഇടുങ്ങിയ SNAT നിയമത്തിന് ഗസ്റ്റ്-സ്വകാര്യ ഉറവിടം തിരഞ്ഞെടുക്കാം, പക്ഷേ തുടർന്നുള്ള Azure വിവർത്തനത്തെ മറികടക്കാൻ കഴിയില്ല. VM-നുള്ളിൽ ഓരോ ക്ലയന്റിനും ഉത്തരവാദിത്തം വേണമെങ്കിൽ SNAT തിരഞ്ഞെടുക്കുക; സബ്നെറ്റിന്റെ പുറത്തേക്കുള്ള ഡിസൈൻ ഇതിനകം സ്ഥിരമായ പൊതു ഉറവിടം നൽകുന്നുവെങ്കിൽ, രണ്ടാമത്തെ വിവർത്തനം അവസ്ഥ മാത്രം ചേർക്കുമെങ്കിൽ അത് ഒഴിവാക്കുക.

തീരുമാനം 3: ഏത് Azure പുറത്തേക്കുള്ള രീതി ജയിക്കുന്നു

Microsoftപുറത്തേക്കുള്ള മുൻഗണനാ ക്രമംരേഖപ്പെടുത്തുന്നു: ഉപകരണത്തിലേക്കോ ഗേറ്റ്വേയിലേക്കോ ഉള്ള ബാധകമായ റൂട്ടിന് മുൻഗണന ലഭിക്കുന്നു, കൂടാതെ ബന്ധപ്പെട്ട പാതയിൽ സബ്നെറ്റ് NAT Gateway കണക്റ്റിവിറ്റിക്ക് ഇൻസ്റ്റൻസ് തലത്തിലുള്ള പൊതു IP-യെക്കാൾ മുൻഗണന ലഭിക്കുന്നു. ഈ ക്രമം കാരണമാണ് 10.20.0.5-ലേക്ക് വിവർത്തനം ചെയ്യുന്നത് വെബ്സൈറ്റ് 198.51.100.20 കാണുമെന്ന് തെളിയിക്കാത്തത്. പുറത്തേക്കുള്ള ഡിസൈൻ സ്വീകരിക്കുന്നതിന് മുമ്പ് ഫലപ്രദമായ റൂട്ട് ടേബിൾ, NAT Gateway അസോസിയേഷൻ, NIC-ന്റെ പൊതു IP എന്നിവ ഒരുമിച്ച് വായിക്കുക.

സൂക്ഷിക്കുകAzure NIC ഫോർവേഡിംഗ് ക്രമീകരണംLinux ഫോർവേഡിംഗിൽ നിന്ന് വേറിട്ട്. ഉറവിടമോ ലക്ഷ്യമോ NIC-ന് അനുവദിച്ചിട്ടില്ലാത്ത പാക്കറ്റുകൾ ക്ലൗഡ് ഫ്ലാഗ് അനുവദിക്കുന്നു; അത് net.ipv4.ip_forward സജീവമാക്കുന്നില്ല, ഗസ്റ്റ് ക്രമീകരണം ക്ലൗഡ് അനുമതി നൽകുന്നുമില്ല.

ടണൽ സോക്കറ്റിന് അതിന്റേതായ ഉറവിട തീരുമാനമുണ്ട്

wg-quick-ന് കീഴിലുള്ള WireGuard-ന്റെ Address WireGuard ഇന്റർഫേസിന് വിലാസം നൽകുന്നു; ഇത് ബാഹ്യ UDP ബൈൻഡിംഗ് നിർദ്ദേശമല്ല. എൻക്രിപ്റ്റ് ചെയ്ത സോക്കറ്റിന്റെ ഉറവിടം റൂട്ടിംഗ് ടേബിൾ പിന്തുടരുന്നു, അതിനാൽ പോളിസി റൂട്ടോ രണ്ടാമത്തെ ഡിഫോൾട്ട് ഇന്റർഫേസോ വിലാസം തൊടാതെ അതിനെ നീക്കാം.OpenVPN-ന്റെ local ഓപ്ഷനും UDP multihome-ഉം അതേ രീതിയിൽ പെരുമാറുന്നു: അവ ശ്രോതാവിനെയും അതിന്റെ മറുപടികളെയും കുറിച്ചാണ്, ഫോർവേഡ് ചെയ്യുന്ന ഓരോ ക്ലയന്റിന്റെയും ഇന്റർനെറ്റ് ഉറവിടത്തെക്കുറിച്ചല്ല.

ടണൽ വഹിക്കുന്ന അണ്ടർലേ റൂട്ട് സംരക്ഷിക്കുക, കൂടാതെ ക്ലയന്റ് ഇപ്പോഴും പ്രതീക്ഷിച്ച പ്രവേശന ക്രമീകരണത്തിൽ നിന്ന് പ്രാമാണീകരിച്ച മറുപടികൾ സ്വീകരിക്കുന്നുവെന്ന് ഉറപ്പാക്കുക. വിലാസ പട്ടികയുടെ ക്രമം സ്ഥിരമായ ഉറവിട-തിരഞ്ഞെടുപ്പ് നയമായി ആശ്രയിക്കരുത്, കാരണം NIC-ലേക്ക് ചേർക്കുന്ന അടുത്ത വിലാസം ഏത് ജയിക്കുമെന്ന് മാറ്റാം.

എന്ത് സ്വീകരിക്കണം, ഏത് ക്രമത്തിൽ

മൂന്ന് ഫലങ്ങൾ വെവ്വേറെ സ്വീകരിക്കുക. ആദ്യം, ഒരു ബാഹ്യ ക്ലയന്റ് ഉദ്ദേശിച്ച VPN പ്രവേശനത്തിൽ എത്തുന്നു. രണ്ടാമത്, ആ VPN ക്ലയന്റിൽ നിന്നുള്ള പുതിയ അനുവദിച്ച അഭ്യർത്ഥന രേഖപ്പെടുത്തിയ ഇന്റർനെറ്റ് പുറത്തുകടക്കലിലൂടെ പുറത്തുപോകുന്നു. മൂന്നാമത്, ഉദ്ദേശിക്കാത്ത ശ്രോതാവ്, ഫോർവേഡിംഗ് പാതകൾ നിരസിക്കപ്പെട്ടു തന്നെ നിൽക്കുന്നു. പൊതു-മുതൽ-സ്വകാര്യ മാപ്പിംഗുകളും ഓരോ തീരുമാനത്തിന്റെയും ഗസ്റ്റ്, ക്ലൗഡ് ഉടമകളും ഒരേ സ്ഥലത്ത് രേഖപ്പെടുത്തുക.

വിജയകരമായ ടണൽ ആദ്യ ഭാഗം മാത്രമാണ് തെളിയിക്കുന്നത്. പുതിയ ഫ്ലോ ഉപയോഗിച്ച് പുറത്തുകടക്കൽ പരിശോധിക്കുക, കാരണം കാഷെ ചെയ്ത കണക്ഷൻ റൂട്ട് മാറിയതിന് ശേഷവും വളരെക്കാലം പഴയ ഉറവിടം ഉപയോഗിച്ചേക്കാം.