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 నిర్వచనాలతో పాటు అదే నిల్వలో నమోదు చేయండి.
- పూల్, ప్రామాణీకరణ లేదా గేట్‌వే మార్పు తర్వాత మళ్లీ పరీక్షించండి, ఎందుకంటే ఆ మార్పులు ప్రకటించకుండా మ్యాపింగ్‌ను తిరిగి రాస్తాయి.