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 વ્યાખ્યાઓ સાથેના એ જ ભંડારમાં નોંધો.
- પૂલ, પ્રમાણીકરણ કે ગેટવેમાં કોઈપણ ફેરફાર પછી ફરી પરીક્ષણ કરો, કારણ કે તે ફેરફારો જાહેર કર્યા વિના મેપિંગ ફરી લખે છે.