ಖಾಸಗಿ ಎಂಡ್ಪಾಯಿಂಟ್, ಅದೇ ಸರ್ವರ್ ಹೆಸರು: Azure SQL ಸಂಪರ್ಕ ಸ್ಟ್ರಿಂಗ್ಗಳು

Private Link ಸಂಪರ್ಕ ಎಲ್ಲಿ ಇಳಿಯುತ್ತದೆ ಎಂಬುದನ್ನು ಬದಲಿಸುತ್ತದೆ, ಸಂಪರ್ಕವನ್ನು ಏನೆಂದು ಕರೆಯುತ್ತಾರೆ ಎಂಬುದನ್ನಲ್ಲ. Azure SQL Database ಗೆ ಆ ವ್ಯತ್ಯಾಸವೇ ಇಡೀ ವಿನ್ಯಾಸ: ಲಾಜಿಕಲ್ ಸರ್ವರ್ ತನ್ನ ಹೆಸರನ್ನು ಉಳಿಸಿಕೊಳ್ಳುತ್ತದೆ, ಮತ್ತು ಖಾಸಗಿ ಎಂಡ್ಪಾಯಿಂಟ್ ಹೆಸರು ಪರಿಹರಿಸಲ್ಪಡುವ ನೆಟ್ವರ್ಕ್ ನಮೂದನ್ನು ಒದಗಿಸುತ್ತದೆ. ಹೆಸರನ್ನು IP ವಿಳಾಸದಿಂದ ಬದಲಿಸುವುದು TLS, ರುಜುವಾತುಗಳು ಮತ್ತು ಪರಿಕರಗಳನ್ನು ಒಟ್ಟಿಗೆ ಮುರಿಯುವ ಏಕೈಕ ಬದಲಾವಣೆ. ಎರಡು ಸಂಪರ್ಕ ಸ್ಟ್ರಿಂಗ್ಗಳು ಸಮಾನವಾಗಿ ಕಾಣಬಹುದು ಮತ್ತು ಸಂಪೂರ್ಣವಾಗಿ ವಿಭಿನ್ನವಾಗಿ ವರ್ತಿಸಬಹುದು.

orders-db.database.windows.net ಉಳಿಸಿ ಮತ್ತು ಕ್ಲೈಂಟ್ಗೆ ಅದಕ್ಕಾಗಿ ಖಾಸಗಿ ಉತ್ತರ ನೀಡಿ.

ಹೆಸರು ಮತ್ತು ವಿಳಾಸಕ್ಕೆ ವಿಭಿನ್ನ ಕೆಲಸಗಳಿವೆ

ಹೆಸರು SQL ಸೇವೆಯನ್ನು ಗುರುತಿಸುತ್ತದೆ, ಪ್ರಮಾಣಪತ್ರ ಮತ್ತು ಲಾಗಿನ್ ನಿರೀಕ್ಷಿಸುವುದು ಅದನ್ನೇ. ಖಾಸಗಿ ವಿಳಾಸವು ಸಂಪರ್ಕಿತ ವರ್ಚುವಲ್ ನೆಟ್ವರ್ಕ್ನ ಒಳಗೆ ನೆಟ್ವರ್ಕ್ ನಮೂದನ್ನು ಒದಗಿಸುತ್ತದೆ. ಒಂದನ್ನು ಇನ್ನೊಂದರೊಂದಿಗೆ ಗೊಂದಲಿಸುವುದು ಯಾವುದನ್ನೋ ತಲುಪಿ ಯಾವುದಕ್ಕೂ ದೃಢೀಕರಿಸದ ಸಂಪರ್ಕವನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ.

Azure SQL ಗಾಗಿ Microsoft ಮಾರ್ಗದರ್ಶನವು ಕ್ಲೈಂಟ್ಗಳಿಂದ ಸಾಮಾನ್ಯ ಸರ್ವರ್ ಹೆಸರನ್ನು ಬಯಸುತ್ತದೆ. ನೇರ IP, ಮತ್ತು ಅದೇ ರೀತಿ privatelink ಪೂರ್ವಪ್ರತ್ಯಯದ ಹೆಸರು, ಪರಸ್ಪರ ಬದಲಾಯಿಸಬಹುದಾದ ಲಾಗಿನ್ ಗುರಿಯಲ್ಲ. IP ಸ್ವೀಕರಿಸುವ ಪರಿಕರಗಳು ಅದನ್ನು ಸ್ವೀಕರಿಸಿ ನಂತರ TLS ನಲ್ಲಿ ಅಥವಾ ದೃಢೀಕರಣದಲ್ಲಿ ವಿಫಲವಾಗುತ್ತವೆ, ಇದು ನಿಜವಾದ ತಪ್ಪನ್ನು ಮರೆಮಾಡುತ್ತದೆ. ಆ ವೈಫಲ್ಯಗಳು ದೋಷದಲ್ಲಿರುವ ಹೋಸ್ಟ್ನೇಮ್ ನೋಡುವವರೆಗೆ ರುಜುವಾತು ಸಮಸ್ಯೆಗಳಂತೆ ಓದಲ್ಪಡುತ್ತವೆ.

ಖಾಸಗಿ ವಲಯವು ನಿಜವಾಗಿ ಏನನ್ನು ಬದಲಿಸುತ್ತದೆ

ಖಾಸಗಿ DNS ವಲಯವು privatelink ಹೆಸರಿನ ಜಾಗದೊಳಗೆ ಸರ್ವರ್ಗೆ ಒಂದು ವಿಳಾಸವನ್ನು ದಾಖಲಿಸುತ್ತದೆ, ಮತ್ತು ವಲಯವು ಅದನ್ನು ಬಳಸಬೇಕಾದ ವರ್ಚುವಲ್ ನೆಟ್ವರ್ಕ್ಗೆ ಜೋಡಣೆಯಾಗಿದೆ. ಪರಿಹಾರ ಚಲಿಸುತ್ತದೆ; ಸಂಪರ್ಕ ಸ್ಟ್ರಿಂಗ್ ಚಲಿಸುವುದಿಲ್ಲ. ಕೆಳಗಿನ ಆಕಾರವು ಉದಾಹರಣೆ, ಸಾರ್ವಜನಿಕ ವಲಯಕ್ಕೆ ಅಂಟಿಸುವ ದಾಖಲೆಯಲ್ಲ.

Application name:        orders-db.database.windows.net
Private DNS zone:        privatelink.database.windows.net
Resolved private entry:  the approved private endpoint address

ಆ ದಾಖಲೆ ಮತ್ತು ಅದರ ವಲಯ ಕೊಂಡಿಯನ್ನು ಮಾಲೀಕ ಮತ್ತು ಪರಿಶೀಲನಾ ದಿನಾಂಕದೊಂದಿಗೆ ಮೂಲಸೌಕರ್ಯವಾಗಿ ನಿರ್ವಹಿಸಿ.

ಒಂದೇ ಮೂಲ ಮತ್ತು ವಿಭಿನ್ನ ಉತ್ತರಗಳನ್ನು ಹೊಂದಿರುವ ಎರಡು ವಲಯಗಳು ಸಾಮಾನ್ಯ ಅಂತಿಮ ಸ್ಥಿತಿ, ಸಂಘರ್ಷವಲ್ಲ. ಸಾರ್ವಜನಿಕ ಕ್ಲೈಂಟ್ಗಳು ಸಾರ್ವಜನಿಕ ಉತ್ತರವನ್ನು ಉಳಿಸಿಕೊಳ್ಳುತ್ತವೆ, ಮತ್ತು ಖಾಸಗಿ ಕ್ಲೈಂಟ್ಗಳು ಎಂಡ್ಪಾಯಿಂಟ್ ವಿಳಾಸವನ್ನು ಪಡೆಯುತ್ತವೆ. ಗಮನಿಸಬೇಕಾದ ವೈಫಲ್ಯ ವಿಧಾನವೆಂದರೆ ಖಾಸಗಿ ನೋಟದ ಭಾಗಶಃ ಪ್ರಸರಣ, ಅಲ್ಲಿ ಒಂದು ಉಪಜಾಲವು ಖಾಸಗಿಯಾಗಿ ಪರಿಹರಿಸಲ್ಪಡುತ್ತದೆ ಮತ್ತು ಇನ್ನೊಂದು ಸದ್ದಿಲ್ಲದೆ ಆಗುವುದಿಲ್ಲ.

Azure ಹೊರಗಿನ ಕ್ಲೈಂಟ್ಗಳಿಗೆ ಆ ವಲಯಕ್ಕೆ ಮಾರ್ಗ ಬೇಕು

VPN ಕ್ಲೈಂಟ್ Azure ನ ಪರಿಹಾರಕದ ಹೊರಗೆ ಕುಳಿತಿರುತ್ತದೆ, ಆದ್ದರಿಂದ ಖಾಸಗಿ ವಲಯವು ಸಂಕರ ಮಾರ್ಗದಿಂದ ತಲುಪಬಲ್ಲದಾಗಿರಬೇಕು. Azure DNS ಫಾರ್ವರ್ಡರ್ ಅಥವಾ Azure DNS Private Resolver ಆ ನೆಟ್ವರ್ಕ್ ಮೂಲಕ ಬರುವ ಪ್ರಶ್ನೆಗಳಿಗೆ ಸೇವೆ ನೀಡಬಹುದು. Microsoft ನ ಮಾರ್ಗದರ್ಶನವೆಂದರೆ ಕ್ಲೈಂಟ್ಗಳು ನೇರವಾಗಿ privatelink ಹೆಸರನ್ನು ಕೇಳುತ್ತಾರೆ ಎಂದು ಊಹಿಸುವ ಬದಲು ಸಂಬಂಧಿತ ಸಾರ್ವಜನಿಕ ಸೇವಾ ವಲಯವನ್ನು ಆ ವ್ಯವಸ್ಥೆಯ ಮೂಲಕ ಫಾರ್ವರ್ಡ್ ಮಾಡುವುದು. ಖಾಸಗಿ ಉತ್ತರವನ್ನು ಪರಿಹರಿಸಲಾಗದ ಕ್ಲೈಂಟ್ಗಳು ದೂರಿಲ್ಲದೆ ಸಾರ್ವಜನಿಕ ಉತ್ತರಕ್ಕೆ ಹಿಂತಿರುಗುತ್ತವೆ.

ಫಾರ್ವರ್ಡಿಂಗ್ ವ್ಯಾಪ್ತಿಯನ್ನು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಇರಿಸಿ, ಏಕೆಂದರೆ ಬಳಕೆಯಲ್ಲಿರುವ ಸಾರ್ವಜನಿಕ ವಲಯವನ್ನು ಬದಲಿಸುವುದು ಬದಲಿಯಲ್ಲಿ ಇಲ್ಲದ ಹೆಸರುಗಳನ್ನು ಮುರಿಯುತ್ತದೆ.

ಗುರುತನ್ನು ಸ್ಥಿರವಾಗಿ ಇರಿಸುವ ಕ್ರಮದಲ್ಲಿ ಒದಗಿಸಿ

ಹಂತಗಳಿಗೆ ಪ್ರತ್ಯೇಕ ಮಾಲೀಕರಿದ್ದಾರೆ: ಎಂಡ್ಪಾಯಿಂಟ್ ರಚಿಸಿ ಅನುಮೋದಿಸಿ, VPN ಮಾರ್ಗ ಒದಗಿಸಿ, ಖಾಸಗಿ DNS ಸಂಯೋಜಿಸಿ, ನಂತರ ಕ್ಲೈಂಟ್ ಅನ್ನು ಅದರ ಸಾಮಾನ್ಯ ಸರ್ವರ್ ಹೆಸರಿನೊಂದಿಗೆ ಸಂರಚಿಸಿ. ಮಾರ್ಗಕ್ಕೆ ಮೊದಲು DNS ಮಾಡಿದರೆ DNS ವೈಫಲ್ಯಗಳಂತೆ ಕಾಣುವ ಸಮಯ ಮೀರುವಿಕೆಗಳು ಉಂಟಾಗುತ್ತವೆ. ಕ್ಲೈಂಟ್ ಅನ್ನು ಕೊನೆಯದಾಗಿ ಮಾಡಿದರೆ ಒಂದೇ ಬಾರಿಗೆ ಒಂದು ಚರ ಚಲನೆಯಲ್ಲಿರುತ್ತದೆ. ಪ್ರತಿ ಹಂತಕ್ಕೂ ವೀಕ್ಷಿಸಬಹುದಾದ ಫಲಿತಾಂಶವಿದೆ, ಆದ್ದರಿಂದ ಯಾವುದನ್ನೂ ಊಹಿಸಿ ಪರೀಕ್ಷಿಸಬೇಕಿಲ್ಲ.

ಸಂಪರ್ಕಗೊಳಿಸಿದ VPN ಐಕಾನ್ ತಾನೇ ಖಾಸಗಿ ಗಮ್ಯಸ್ಥಾನವನ್ನು ಆಯ್ಕೆ ಮಾಡುವುದಿಲ್ಲ.

ಖಾಸಗಿ ಎಂಡ್ಪಾಯಿಂಟ್ ಏನನ್ನು ಆಫ್ ಮಾಡುವುದಿಲ್ಲ

ಖಾಸಗಿ ಎಂಡ್ಪಾಯಿಂಟ್ ರಚಿಸುವುದು ಲಾಜಿಕಲ್ ಸರ್ವರ್ಗೆ ಸಾರ್ವಜನಿಕ ಪ್ರವೇಶವನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ನಿಷ್ಕ್ರಿಯಗೊಳಿಸುವುದಿಲ್ಲ. ಅದು ಪ್ರತ್ಯೇಕ ನಿಯೋಜನೆ ನಿರ್ಧಾರ, ಮತ್ತು ಉದ್ದೇಶಿತ ಖಾಸಗಿ ಕ್ಲೈಂಟ್ಗಳು ಕೆಲಸ ಮಾಡುತ್ತವೆ ಎಂದು ದೃಢೀಕರಿಸಿದ ನಂತರ ಅದು ಬರುತ್ತದೆ. ಪುನಃಪ್ರಾಪ್ತಿ ಮಾರ್ಗವನ್ನು ಇರಿಸಿ ಮತ್ತು ಇನ್ನೂ ಸಾರ್ವಜನಿಕ ಪ್ರವೇಶವನ್ನು ಬಳಸುವ ಅಪ್ಲಿಕೇಶನ್ಗಳನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳಿ. ಸಾರ್ವಜನಿಕ ಪ್ರವೇಶವನ್ನು ಮೊದಲು ಆಫ್ ಮಾಡುವುದು ಕೆಲಸ ಮಾಡುತ್ತಿರುವ ಸೇವೆಯು ಅಚ್ಚುಕಟ್ಟಾದ ಆಡಿಟ್ ಜಾಡಿನೊಂದಿಗೆ ಅಡಚಣೆಯಾಗುವ ದಾರಿ.

ಸರ್ವರ್ ಯಾವ ಸಂಪರ್ಕ ನೀತಿಯನ್ನು ಬಳಸುತ್ತದೆ ಎಂಬುದನ್ನೂ ಪರಿಶೀಲಿಸಿ.

Redirect ಆರಂಭಿಕ ಗೇಟ್ವೇ ಸಂಪರ್ಕದ ನಂತರ ಕ್ಲೈಂಟ್ ಅನ್ನು ನೋಡ್ನ ಪೋರ್ಟ್ಗೆ ಕಳುಹಿಸುತ್ತದೆ, ಇದು ಕ್ಲೈಂಟ್ ನೆಟ್ವರ್ಕ್ ಏನನ್ನು ಅನುಮತಿಸಬೇಕು ಎಂಬುದನ್ನು ಬದಲಿಸುತ್ತದೆ. Proxy ಸಂಚಾರವನ್ನು ಗೇಟ್ವೇನಲ್ಲಿ ಇರಿಸುತ್ತದೆ. ಒಂದು ಪೋರ್ಟ್ನಲ್ಲಿ ಯಶಸ್ವಿ TCP ಹ್ಯಾಂಡ್ಶೇಕ್ ಸಂಪೂರ್ಣ ಲಾಗಿನ್ ಕಾರ್ಯಹರಿವಲ್ಲ.

ಇದು Azure SQL Database, SQL Managed Instance ಅಲ್ಲ, ಅದಕ್ಕೆ ತನ್ನದೇ ಸಂಪರ್ಕ ಮಾದರಿ ಇದೆ ಮತ್ತು ಸಮಾನ ಖಾಸಗಿ ಎಂಡ್ಪಾಯಿಂಟ್ ಕಥೆ ಇಲ್ಲ. ಎರಡೂ ಸಂದರ್ಭಗಳಲ್ಲಿ ಮೂರು ವಿಷಯಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಲೇಬಲ್ ಮಾಡಿ: ಹೆಸರು, ನೆಟ್ವರ್ಕ್ ನಮೂದು ಮತ್ತು ರುಜುವಾತು. ಸಂಪರ್ಕ ಎಲ್ಲಿ ಪ್ರಯಾಣಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಬದಲಿಸುವುದು ಕ್ಲೈಂಟ್ ಯಾವ ಸೇವೆಯೊಂದಿಗೆ ಮಾತನಾಡುತ್ತಿದೆ ಎಂದು ಭಾವಿಸುತ್ತದೆಯೋ ಅದನ್ನು ಎಂದಿಗೂ ಬದಲಿಸಬಾರದು.