VPN ಆನ್ ಆದಾಗ ಕ್ಲೌಡ್ ಫೈರ್‍ವಾಲ್ ಯಾವ ವಿಳಾಸವನ್ನು ನೋಡುತ್ತದೆ
ಸಂಪೂರ್ಣ ಟನೆಲ್ ನಿಮ್ಮ ಡೇಟಾಬೇಸ್ ನೋಡುವ ಮೂಲ ವಿಳಾಸವನ್ನು ಬದಲಿಸುತ್ತದೆ. ಅನುಮತಿ ಪಟ್ಟಿ, ಖಾಸಗಿ ಮಾರ್ಗ ಅಥವಾ ಸ್ಪ್ಲಿಟ್ ಟನೆಲ್ ಸರಿಸಿ, ರುಜುವಾತು ಅಲ್ಲ.
VPN ಸಂಪರ್ಕಗೊಳ್ಳುವ ಮೊದಲು ಕೆಲಸ ಮಾಡಿ ನಂತರ ವಿಫಲವಾಗುವ ಡೇಟಾಬೇಸ್ ಅಪರೂಪವಾಗಿ ರುಜುವಾತಿನ ಸಮಸ್ಯೆಯಾಗಿರುತ್ತದೆ. ಕ್ಲೌಡ್ ಫೈರ್‍ವಾಲ್‍ಗಳು ಮೂಲ ವಿಳಾಸಗಳನ್ನು ಹೊಂದಿಸುತ್ತವೆ, ಮತ್ತು ಸಂಪೂರ್ಣ ಟನೆಲ್ ಅವು ಹೊಂದಿಸುತ್ತಿದ್ದ ವಿಳಾಸವನ್ನೇ ಬದಲಿಸುತ್ತದೆ. ನಿಮ್ಮ ಲ್ಯಾಪ್‍ಟಾಪ್ ಏನು ಕಳುಹಿಸುತ್ತದೆ ಎಂದು ನೀವು ಭಾವಿಸುವುದಕ್ಕೂ ಸರ್ವರ್ ಏನು ಸ್ವೀಕರಿಸುತ್ತದೆ ಎಂಬುದಕ್ಕೂ ನಡುವಿನ ಅಂತರವೇ ಇಡೀ ದೋಷ, ಮತ್ತು ಅದನ್ನು ಒಂದೇ ಹಂತದಲ್ಲಿ ಅಳೆಯಬಹುದು.
ಮೂಲ ವಿಳಾಸ ಏನಾಗುತ್ತದೆ
ಸಂಪೂರ್ಣ ಟನೆಲ್‍ನಲ್ಲಿ ಪ್ರತಿ ಪ್ಯಾಕೆಟ್ VPN ಗೇಟ್‍ವೇ ಮೂಲಕ ಹೊರಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಸರ್ವರ್ ನಿಮ್ಮ ಮನೆಯ ಸಂಪರ್ಕದ ಬದಲು ಗೇಟ್‍ವೇಯ ಔಟ್‍ಬೌಂಡ್ ವಿಳಾಸವನ್ನು ನೋಡುತ್ತದೆ. ಮಾರ್ಗದಲ್ಲಿ ಫಾರ್ವರ್ಡ್ ಪ್ರಾಕ್ಸಿ ಇದ್ದರೆ ಅದರ ವಿಳಾಸವೇ ತಲುಪುತ್ತದೆ. ಎರಡೂ ಕಾನೂನುಬದ್ಧ ಮೂಲಗಳು, ಮತ್ತು ನಿಮ್ಮ ಮೂಲ ನಿಯಮದಲ್ಲಿರುವ ವಿಳಾಸ ಅವುಗಳಲ್ಲಿ ಯಾವುದೂ ಅಲ್ಲ.
Azure SQL ನ ಸರ್ವರ್-ಹಂತ ಮತ್ತು ಡೇಟಾಬೇಸ್-ಹಂತದ ಫೈರ್‍ವಾಲ್ ನಿಯಮಗಳು ಲಾಜಿಕಲ್ ಸರ್ವರ್ ತಲುಪುವ ಕ್ಲೈಂಟ್ ವಿಳಾಸವನ್ನು ಹೊಂದಿಸುತ್ತವೆ, ಸಂಪೂರ್ಣ ಟನೆಲ್ ನಂತರ ಅದೇ ಔಟ್‍ಬೌಂಡ್ ವಿಳಾಸ. ಒಂದೇ ವಿಳಾಸಕ್ಕೆ ಅನುಮತಿ ನೀಡುವ AWS ಭದ್ರತಾ ಗುಂಪು ಕೂಡ ಅದೇ ರೀತಿ ವರ್ತಿಸುತ್ತದೆ. ಪ್ಯಾಕೆಟ್ ದೃಢೀಕರಣಕ್ಕೆ ಮೊದಲೇ ಬಿಟ್ಟುಬಿಡಲಾಗುತ್ತದೆ, ಆದ್ದರಿಂದ ಸಿಗುವ ದೋಷ ಅನುಮತಿ ಸಮಸ್ಯೆಯ ಬದಲು ನೆಟ್‍ವರ್ಕ್ ವೈಫಲ್ಯದಂತೆ ಕಾಣುತ್ತದೆ. ಜನರು ಪಾಸ್‍ವರ್ಡ್ ಮರುಹೊಂದಿಸಲು ಪ್ರಾರಂಭಿಸುವುದಕ್ಕೆ ಇದೇ ಕಾರಣ.
ಅನುಮತಿ ಪಟ್ಟಿ ಎಲ್ಲಿ ನಿರ್ಧಾರವಾಗುತ್ತದೆ
ವಿಫಲವಾಗುತ್ತಿರುವ ಮಾರ್ಗಕ್ಕೆ ಹೊಂದಿಕೆಯಾಗುವ ನಿಯಮವನ್ನು ಓದಿ, ನೀವು ರಚಿಸಿದ್ದೀರಿ ಎಂದು ನೆನಪಿರುವ ನಿಯಮವಲ್ಲ. ಅದರ ವ್ಯಾಪ್ತಿ, ಪೋರ್ಟ್, ಪ್ರೋಟೋಕಾಲ್ ಮತ್ತು ಯಾವುದೇ ಗುರುತಿನ ಪರಿಶೀಲನೆಗೆ ಮೊದಲು ಅದು ಮೌಲ್ಯಮಾಪನಗೊಳ್ಳುತ್ತದೆಯೇ ಎಂಬುದನ್ನು ಗಮನಿಸಿ.
ನಂತರ ಯಾವ ಪದರ ಈ ನಿರ್ಧಾರದ ಕಾನೂನುಬದ್ಧ ಮಾಲೀಕತ್ವ ಹೊಂದಿದೆ ಎಂದು ನಿರ್ಧರಿಸಿ. ವಿಳಾಸ ನಿಯಮ ಟ್ರಾಫಿಕ್ ಎಲ್ಲಿಂದ ಬರುತ್ತದೆ ಎಂದು ಉತ್ತರಿಸುತ್ತದೆ. ಖಾಸಗಿ ಎಂಡ್‍ಪಾಯಿಂಟ್ ಸೇವೆ ಖಾಸಗಿ ಮಾರ್ಗದ ಮೂಲಕ ತಲುಪಲು ಸಾಧ್ಯವೇ ಎಂದು ಉತ್ತರಿಸುತ್ತದೆ. ಸ್ಪ್ಲಿಟ್-ಟನೆಲ್ ಅಪವಾದ ಯಾವ ಗಮ್ಯಸ್ಥಾನಗಳು ಟನೆಲ್ ತಪ್ಪಿಸುತ್ತವೆ ಎಂದು ಉತ್ತರಿಸುತ್ತದೆ. ಇವು ಪರಸ್ಪರ ಬದಲಾಯಿಸಲಾಗದವು, ಮತ್ತು ಟನೆಲ್ ಬದಲಾದಾಗ ಪ್ರತಿಯೊಂದೂ ಬೇರೆ ರೀತಿಯಲ್ಲಿ ವಿಫಲವಾಗುತ್ತದೆ.
ಮೂರು ಸರಿಪಡಿಸುವಿಕೆಗಳು, ಮೂರು ಪದರಗಳು
ಕೆಳಗಿನ ಪ್ರತಿ ಆಯ್ಕೆಯೂ ಬೇರೆ ಕಾರಣಕ್ಕೆ ಹರಿವನ್ನು ಸರಿಪಡಿಸುತ್ತದೆ, ಮತ್ತು ತಪ್ಪಾದದನ್ನು ಆಯ್ಕೆ ಮಾಡಿದರೆ ಮುಂದಿನ ಗೇಟ್‍ವೇ ಬದಲಾವಣೆಯವರೆಗೆ ಕೆಲಸ ಮಾಡುವ ಸಂಪರ್ಕ ಉಂಟಾಗುತ್ತದೆ.
| Repair | Layer it changes | What it does not fix |
|---|---|---|
| Add the egress address to the rule | Source address matching | Nothing about routing, and it breaks when the egress moves |
| Use a private endpoint | Whether the service is reached privately | A client that still resolves the public name |
| Add a split-tunnel exception | Which flows bypass the tunnel | An expired credential or a wrong password |
ಔಟ್‍ಬೌಂಡ್ ವಿಳಾಸ ಸೇರಿಸುವುದು ಅತಿ ಚಿಕ್ಕ ಬದಲಾವಣೆ ಮತ್ತು ಅತ್ಯಂತ ಸೂಕ್ಷ್ಮ, ಏಕೆಂದರೆ ಹೊಸ ಗೇಟ್‍ವೇ ಅಥವಾ ಬೇರೆ ಪ್ರದೇಶ ಅದನ್ನು ಮೌನವಾಗಿ ಅಮಾನ್ಯಗೊಳಿಸುತ್ತದೆ. ಟನೆಲ್ ವ್ಯಾಖ್ಯಾನದ ಪಕ್ಕದಲ್ಲಿ ವಿಳಾಸವನ್ನು ದಾಖಲಿಸಿ, ಎರಡೂ ಒಟ್ಟಿಗೆ ಚಲಿಸುವಂತೆ ಮಾಡಿ. ತಾತ್ಕಾಲಿಕ ವಿಶಾಲ ಶ್ರೇಣಿ ಒಂದು ನಿದಾನ, ಸರಿಪಡಿಸುವಿಕೆ ಅಲ್ಲ; ಅದನ್ನು ಹಾಗೆಯೇ ಬಿಡುವುದೇ ಆಂತರಿಕ ಸೇವೆಗಳು ತೆರೆದುಕೊಂಡು ಉಳಿಯುವ ದಾರಿ.
ನಿರ್ವಹಿತ ಪ್ಲಾಟ್‍ಫಾರ್ಮ್ ಟನೆಲ್ ಸೇರಲು ಸಾಧ್ಯವಿಲ್ಲದ ಕಾರಣ
Heroku, AppHarbor ಅಥವಾ CloudBees ನಂತಹ ಅಪ್ಲಿಕೇಶನ್ ಪ್ಲಾಟ್‍ಫಾರ್ಮ್‍ಗಳು ನಿಮ್ಮ ಕೋಡ್ ಅನ್ನು tun ಅಥವಾ tap ಸಾಧನವಿಲ್ಲದ ಮತ್ತು ಅದನ್ನು ರಚಿಸುವ ಅಧಿಕಾರವಿಲ್ಲದ ಪರಿಸರದಲ್ಲಿ ರನ್ ಮಾಡುತ್ತವೆ. ಅವುಗಳ ಇನ್‍ಬೌಂಡ್ ಮಾದರಿ HTTP, ಯಾವುದೇ ಕೇಳುವ ಸಾಕೆಟ್ ಅಲ್ಲ. VPN ಬೈನರಿ ಒಯ್ಯುವ buildpack ಕೂಡ ಇಂಟರ್‍ಫೇಸ್ ಇಡಲು ಜಾಗ ಕಾಣುವುದಿಲ್ಲ. ಕೆಲಸ ಮಾಡುವ ಮಾದರಿಗಳೆಂದರೆ ಡೇಟಾಬೇಸ್ ಅನುಮತಿಸಬಹುದಾದ ಸ್ಥಿರ ಔಟ್‍ಬೌಂಡ್ ವಿಳಾಸ, ಪ್ಲಾಟ್‍ಫಾರ್ಮ್ ನೀಡುವ ಖಾಸಗಿ ಸಂಪರ್ಕ ಉತ್ಪನ್ನ, ಅಥವಾ DMZ ನಲ್ಲಿ HTTPS ಮೂಲಕ ತಲುಪುವ ಪ್ರಾಕ್ಸಿ.
ಆ ಪ್ರಾಕ್ಸಿ ತನ್ನದೇ ದೃಢೀಕರಣ ಮತ್ತು ಲಾಗಿಂಗ್ ಹೊಂದಿರುವ ಪ್ರವೇಶ ಮಾರ್ಗ. ಅದು ಪ್ಲಾಟ್‍ಫಾರ್ಮ್ ಅನ್ನು ನಿಮ್ಮ VPN ನ ಸದಸ್ಯನನ್ನಾಗಿ ಮಾಡುವುದಿಲ್ಲ, ಮತ್ತು ಹಾಗೆ ವಿವರಿಸುವುದರಿಂದ ಯಾರೂ ಪರಿಶೀಲಿಸಲಾಗದ ನಿಯಮಗಳು ಉಂಟಾಗುತ್ತವೆ.
ವಿಫಲವಾದ ಕ್ಲೈಂಟ್‍ನಿಂದ ಪರಿಶೀಲಿಸಿ
ಮತ್ತೆ ಸಂಪರ್ಕಿಸಿ ಮತ್ತು ಕ್ಲೈಂಟ್‍ನ ನಿಖರ ಮಾರ್ಗವನ್ನು ಪುನರಾವರ್ತಿಸಿ. ಸೇವೆ ದಾಖಲಿಸುವ ಮೂಲ ವಿಳಾಸ, ಡೇಟಾಬೇಸ್ ಹೆಸರಿಗೆ ಕ್ಲೈಂಟ್ ಆಯ್ಕೆ ಮಾಡುವ ರೂಟ್, ಮತ್ತು ನಿಜವಾದ ಪ್ರಶ್ನೆಯ ಫಲಿತಾಂಶವನ್ನು ಆ ಕ್ರಮದಲ್ಲಿ ಪರಿಶೀಲಿಸಿ. ಗೇಟ್‍ವೇಯಿಂದ ಮಾಡಿದ ಪರೀಕ್ಷೆ ಗೇಟ್‍ವೇ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಎಂದು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ, ಅದು ಎಂದೂ ಸಂದೇಹದಲ್ಲಿರಲಿಲ್ಲ. ಸಂಪರ್ಕ ಈಗ ದೃಢೀಕರಣಗೊಂಡರೂ ಪ್ರಶ್ನೆ ಇನ್ನೂ ವಿಫಲವಾದರೆ, ಉಳಿದ ಸಮಸ್ಯೆ ಡೇಟಾಬೇಸ್ ಅನುಮತಿ.
ಟನೆಲ್ ಬದಲಾದಾಗಲೆಲ್ಲಾ ಈ ನಿಯಮಗಳನ್ನು ಪರಿಶೀಲಿಸಿ. ಬದಲಾದ ಗೇಟ್‍ವೇ ಅಥವಾ ಹೊಸ ಔಟ್‍ಬೌಂಡ್ ಶ್ರೇಣಿ ಅಪ್ಲಿಕೇಶನ್ ಸಂರಚನೆಯಲ್ಲಿ ಯಾವುದೇ ಬದಲಾವಣೆ ಇಲ್ಲದೆ ಮಾರ್ಗವನ್ನು ಮುರಿಯುತ್ತದೆ.