GCP Cloud VPN: ಗೇಟ್ವೇ, ಟನೆಲ್ ಮತ್ತು ಫೈರ್ವಾಲ್ ಅನ್ನು ಕ್ರಮವಾಗಿ ಪರಿಶೀಲಿಸಿ
ಪ್ರತಿ ಪ್ರೋಬ್ ಸಮಯ ಮೀರಿದರೂ ಟನೆಲ್ ಸ್ಥಾಪಿತ ಎಂದು ವರದಿ ಮಾಡಿದರೆ ಸಾಮಾನ್ಯವಾಗಿ VPC ಫೈರ್ವಾಲ್ ನಿಯಮ ಇರುವುದಿಲ್ಲ. ಗೇಟ್ವೇ, ಸೆಲೆಕ್ಟರ್ಗಳು ಮತ್ತು ರೂಟಿಂಗ್ ಪ್ರಕಾರವನ್ನು ಆ ಕ್ರಮದಲ್ಲಿ ಪರಿಶೀಲಿಸಿ.
ನಿಮ್ಮ ಕನ್ಸೋಲ್ ಹಸಿರು ಟನೆಲ್ ತೋರಿಸುತ್ತದೆ, ಆನ್-ಪ್ರೆಮಿಸ್ ಮಾನಿಟರಿಂಗ್ ಇನ್ನೂ ಒಂದೇ ಒಂದು ಇನ್ಸ್ಟಾನ್ಸ್ ತಲುಪಲಾರದು, ಮತ್ತು ಟನೆಲ್ ಮರುನಿರ್ಮಾಣವೇ ಸ್ಪಷ್ಟ ಪರಿಹಾರ ಎನಿಸುತ್ತದೆ. ಹಾಗೆ ಆಗುವುದು ಅಪರೂಪ. ಸ್ಥಾಪಿತ ಟನೆಲ್ ಎರಡು ಗೇಟ್ವೇಗಳು IKE ವಿನಿಮಯ ಮುಗಿಸಿದ್ದನ್ನು ಮಾತ್ರ ಸಾಬೀತು ಮಾಡುತ್ತದೆ. ಪ್ಯಾಕೆಟ್ ಎಂದಾದರೂ ನಿಮ್ಮ VPC ಗೆ ಪ್ರವೇಶ ಪಡೆದಿತ್ತೇ ಎಂಬುದರ ಬಗ್ಗೆ ಅದು ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ.
ಆ ಹಸಿರು ಐಕಾನ್ ಮತ್ತು ಉತ್ತರದ ನಡುವೆ ನಾಲ್ಕು ನಿರ್ಧಾರಗಳಿವೆ, ಮತ್ತು ಅವು ಊಹಿಸಬಹುದಾದ ಕ್ರಮದಲ್ಲಿ ವಿಫಲವಾಗುತ್ತವೆ. ಅಗ್ಗದ್ದರಿಂದ ಪ್ರಾರಂಭಿಸಿ.
ಮೂರು ಆಬ್ಜೆಕ್ಟ್ಗಳು, ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಒಂದೇ ಎನ್ಕ್ರಿಪ್ಟ್ ಮಾಡುತ್ತದೆ
VPN ಗೇಟ್ವೇ ನಿಮ್ಮ ಪೀರ್ ಎನ್ಕ್ರಿಪ್ಟ್ ಮಾಡುವ ಬಾಹ್ಯ ವಿಳಾಸವನ್ನು ಹೊಂದಿದೆ. ಕನ್ಸೋಲ್ನಲ್ಲಿ ನೀವು ಅದನ್ನು ಎಂದಿಗೂ ಕೈಯಿಂದ ರಚಿಸುವುದಿಲ್ಲ: ಸಂಪರ್ಕ ಫಾರ್ಮ್ ಒಳಗೆ ವಿಳಾಸವನ್ನು ಆಯ್ಕೆ ಮಾಡಿ ಅಥವಾ ಕಾಯ್ದಿರಿಸಿ ಮತ್ತು ಗೇಟ್ವೇ ಅದರೊಂದಿಗೆ ಕಾಣಿಸುತ್ತದೆ. HA ಗೇಟ್ವೇ ಎರಡು ಇಂಟರ್ಫೇಸ್ಗಳಲ್ಲಿ ಎರಡು ವಿಳಾಸಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ, ಇದು ನಂತರದ ಕ್ವೋಟಾ ಪರಿಶೀಲನೆಯಲ್ಲಿ ಮುಖ್ಯ.
ಟನೆಲ್ ಎಂಬುದು ಆ ಗೇಟ್ವೇ ಮತ್ತು ಪೀರ್ ನಡುವಿನ ಜೋಡಿ. ಅದು ಹಂಚಿದ ರಹಸ್ಯ ಮತ್ತು ರಕ್ಷಿಸುವುದಾಗಿ ಭರವಸೆ ನೀಡುವ ಟ್ರಾಫಿಕ್ ಸೆಲೆಕ್ಟರ್ಗಳನ್ನು ಒಯ್ಯುತ್ತದೆ. ಬಹುಪಾಲು ಮೌನ ವೈಫಲ್ಯಗಳು ಆ ಸೆಲೆಕ್ಟರ್ಗಳಿಂದಲೇ ಆರಂಭವಾಗುತ್ತವೆ. ಸ್ಥಳೀಯ ಸೆಲೆಕ್ಟರ್ 10.0.0.0/24 ಅನ್ನು ಆವರಿಸುವ ಟನೆಲ್, ಸ್ಥಿತಿ ಎಷ್ಟೇ ಆರೋಗ್ಯಕರವಾಗಿ ಕಂಡರೂ 10.0.1.0/24 ಅನ್ನು ತಲುಪಿಸುವುದಿಲ್ಲ.
ದೂರದ ತುದಿ ತನ್ನದೇ ಪಟ್ಟಿಯನ್ನು ಇಟ್ಟುಕೊಳ್ಳುತ್ತದೆ, ಸಾಮಾನ್ಯವಾಗಿ ಅದನ್ನು ಎನ್ಕ್ರಿಪ್ಷನ್ ಡೊಮೇನ್ ಎನ್ನುತ್ತಾರೆ, ಮತ್ತು ಅಂತ್ಯಗೊಳಿಸುವ ಹಾರ್ಡ್ವೇರ್ ಅದನ್ನು ನಿಮ್ಮದರೊಂದಿಗೆ ಹೋಲಿಸುತ್ತದೆ. ಯಾವ ಪಕ್ಷವೂ ತನಗೆ ಎಂದೂ ನೀಡದ ಸೆಲೆಕ್ಟರ್ ಬಗ್ಗೆ ಮಾತುಕತೆ ನಡೆಸುವುದಿಲ್ಲ.
ರೂಟಿಂಗ್ ಪ್ರಕಾರವು ರೂಟ್ ಕೋಷ್ಟಕವನ್ನು ಏನು ತಲುಪುತ್ತದೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ
Cloud VPN ಮೂರು ರೂಟಿಂಗ್ ಆಕಾರಗಳನ್ನು ನೀಡುತ್ತದೆ ಮತ್ತು ಅವು ಸ್ವಚ್ಛವಾಗಿ ಬೆರೆಯುವುದಿಲ್ಲ. ನೀತಿ-ಆಧಾರಿತ ರೂಟಿಂಗ್ ಸ್ಥಿರ ಸೆಲೆಕ್ಟರ್ ಜೋಡಿಗಳನ್ನು ಇಟ್ಟುಕೊಳ್ಳುತ್ತದೆ, ರೂಟ್-ಆಧಾರಿತ ರೂಟಿಂಗ್ ನೀವೇ ಸ್ಥಿರ ರೂಟ್ಗಳನ್ನು ಸೇರಿಸುವುದನ್ನು ನಿರೀಕ್ಷಿಸುತ್ತದೆ, ಮತ್ತು ಕ್ರಿಯಾಶೀಲ ರೂಟಿಂಗ್ BGP ಮೇಲೆ Cloud Router ಮೂಲಕ ಪ್ರಿಫಿಕ್ಸ್ಗಳನ್ನು ಘೋಷಿಸುತ್ತದೆ. ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಒಂದನ್ನು ಆರಿಸಿ.
ಪಕ್ಕದಲ್ಲಿ ಕೈಯಿಂದ ಬರೆದ ಸ್ಥಿರ ರೂಟ್ಗಳಿರುವ ಕ್ರಿಯಾಶೀಲ ಟನೆಲ್, BGP ಸೆಷನ್ ತೂಗಾಡಿದಾಗಲೆಲ್ಲಾ ಖಾಲಿಯಾಗುವ ರೂಟ್ ಕೋಷ್ಟಕವನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ.
ಕ್ರಿಯಾಶೀಲವು ಟನೆಲ್ ಮರುನಿರ್ಮಿಸದೆ ರಕ್ಷಿತ ಪ್ರಿಫಿಕ್ಸ್ಗಳನ್ನು ಬದಲಿಸಲು ಅನುವು ಮಾಡುವ ಏಕೈಕ ಆಕಾರ, ಮತ್ತು ಅದು Cloud Router ಅನ್ನು ನೀವು ಪರಿಶೀಲಿಸಬೇಕಾದ ಆಬ್ಜೆಕ್ಟ್ಗಳ ಗುಂಪಿಗೆ ಎಳೆಯುತ್ತದೆ. ಪೀರ್ BGP ಮಾತನಾಡಲಾರದ ಹಾರ್ಡ್ವೇರ್ ಫೈರ್ವಾಲ್ ಆಗಿದ್ದಾಗ ಸ್ಥಿರ ಸೆಲೆಕ್ಟರ್ಗಳು ಕೆಲಸ ಮಾಡುತ್ತವೆ. ಆಗ ಎರಡೂ ತುದಿಗಳಿಗೆ ಒಂದೇ ಶ್ರೇಣಿಗಳು ಬೇಕು, ಮತ್ತು ಹೆಚ್ಚು ನಿರ್ದಿಷ್ಟ ನಮೂದು ಎರಡೂ ಕಡೆ ಗೆಲ್ಲಬೇಕು. ಒಂದು ಸಬ್ನೆಟ್ನಿಂದ ಭಿನ್ನವಾಗುವ ಜೋಡಿ ಸ್ಥಾಪನೆಯಾಗಿ ನಂತರ ನಿಮ್ಮ ಅರ್ಧ ಟ್ರಾಫಿಕ್ ಒಯ್ಯುತ್ತದೆ.
ಸೂಚ್ಯ ನಿರಾಕರಣೆ ಟನೆಲ್ನ ಹಿಂದೆ ಕುಳಿತಿದೆ
ಒಳಬರುವ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಅತ್ಯಂತ ಕಡಿಮೆ ಆದ್ಯತೆಯ ಸೂಚ್ಯ ನಿರಾಕರಣೆಯ ವಿರುದ್ಧ ಮೌಲ್ಯಮಾಪನ ಮಾಡಲಾಗುತ್ತದೆ, ಮತ್ತು ಆ ನಿಯಮವು ಪ್ಯಾಕೆಟ್ ಎನ್ಕ್ರಿಪ್ಟ್ ಆಗಿ ಬಂದದ್ದನ್ನು ಲೆಕ್ಕಿಸುವುದಿಲ್ಲ. ಫೈರ್ವಾಲ್ ನಿಯಮವು ಸ್ಥಳೀಯ ಶ್ರೇಣಿ ಮತ್ತು ಬಳಕೆಯಲ್ಲಿರುವ ಪೋರ್ಟ್ ಹೆಸರಿಸುವವರೆಗೆ, ಪ್ಯಾಕೆಟ್ ಡಿಕ್ರಿಪ್ಟ್ ಆಗಿ, ಪರಿಶೀಲಿಸಿ, ಬಿಸಾಡಲಾಗುತ್ತದೆ. VPN ಲಾಗ್ ಇಡೀ ಸಮಯ ಸ್ವಚ್ಛವಾಗಿರುತ್ತದೆ, ಏಕೆಂದರೆ ಟನೆಲ್ ಭರವಸೆ ನೀಡಿದ್ದನ್ನು ನಿಖರವಾಗಿ ಮಾಡಿತು.
ಬದಲಿಗೆ ಟನೆಲ್ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದ್ದು ಪ್ರೋಬ್ ಸಮಯ ಮೀರಿದಾಗ ಫೈರ್ವಾಲ್ ನಿರಾಕರಣೆ ಲಾಗ್ ಓದಿ, ನಂತರ ನಿಯಮವನ್ನು ಮೂಲ ಶ್ರೇಣಿ ಮತ್ತು ನಿಮಗೆ ಬೇಕಾದ ಪೋರ್ಟ್ಗಳಿಗೆ ಸೀಮಿತಗೊಳಿಸಿ:
gcloud compute firewall-rules create allow-from-dc \
--network=vpn-vpc \
--direction=INGRESS \
--source-ranges=192.168.10.0/24 \
--allow=tcp:22,tcp:5432,icmpಒಂದೇ ದಿಕ್ಕು ಕೆಲಸ ಮಾಡುವುದು ಫೈರ್ವಾಲ್ನ ಸುಳಿವು
ಹೊರಹೋಗುವ ಟ್ರಾಫಿಕ್ ಬೇರೆ ರೀತಿ ವರ್ತಿಸುತ್ತದೆ, ಏಕೆಂದರೆ ಸೂಚ್ಯ ಅನುಮತಿ ನಿಯಮ ಇನ್ಸ್ಟಾನ್ಸ್ಗಳಿಗೆ ಎಲ್ಲಿಗಾದರೂ ಕಳುಹಿಸಲು ಅನುವು ಮಾಡುತ್ತದೆ. VM ತಲುಪಲಾರದ ಡೇಟಾ ಸೆಂಟರ್ ಸಾಮಾನ್ಯವಾಗಿ ಇನ್ನೊಂದು ದಿಕ್ಕಿನಲ್ಲಿ ಸಂಪೂರ್ಣ ಕೆಲಸ ಮಾಡುವ ಹೊರಹೋಗುವ ಮಾರ್ಗದ ಹಿಂದೆ ಇರುತ್ತದೆ. ಈ ಅಸಮಮಿತಿ ಫೈರ್ವಾಲ್ ಕೊರತೆಯನ್ನು ರೂಟಿಂಗ್ ದೋಷದಿಂದ ಬೇರ್ಪಡಿಸುತ್ತದೆ, ಏಕೆಂದರೆ ರೂಟಿಂಗ್ ದೋಷ ಎರಡೂ ದಿಕ್ಕುಗಳನ್ನು ಒಟ್ಟಿಗೆ ಮುರಿಯುತ್ತದೆ. ಇನ್ನೊಂದು ನಿಯಮ ಸಂಪಾದಿಸುವ ಮೊದಲು ವಿರುದ್ಧ ದಿಕ್ಕನ್ನು ಪರೀಕ್ಷಿಸಿ.
ವಿಳಾಸ ರಚನೆಯೂ ಕ್ವೋಟಾ ಕಾರ್ಯಾಚರಣೆ. ಬಳಕೆಯಲ್ಲಿರುವ ಬಾಹ್ಯ ವಿಳಾಸಗಳ ಮಿತಿಗೆ ಹತ್ತಿರವಿರುವ ಪ್ರಾಜೆಕ್ಟ್ ಸಂಪರ್ಕವನ್ನು ಅನುಮತಿ ವೈಫಲ್ಯದಂತೆ ಕೇಳಿಸುವ ದೋಷದೊಂದಿಗೆ ನಿರಾಕರಿಸುತ್ತದೆ.
ಸೆಲೆಕ್ಟರ್ಗಳು, ಕ್ವೋಟಾಗಳು, ನಂತರ ನಾಲ್ಕು ಪರಿಶೀಲನೆಗಳು
ಕನ್ಸೋಲ್ನಲ್ಲಿ ರಚಿಸಿದ ಟನೆಲ್ಗಳು ಕೆಲವೊಮ್ಮೆ gcloud compute vpn-tunnels describe ನಿಂದ ಖಾಲಿ ದೂರದ ಟ್ರಾಫಿಕ್ ಸೆಲೆಕ್ಟರ್ ಹಿಂತಿರುಗಿಸುತ್ತವೆ, ಆದರೆ ಉತ್ಪಾದಿತ ರೂಟ್ಗಳು ಟ್ರಾಫಿಕ್ ಸರಿಯಾಗಿ ಒಯ್ಯುತ್ತವೆ. ಟನೆಲ್ ತಪ್ಪು ಎಂದು ನಿರ್ಧರಿಸುವ ಮೊದಲು API ದಾಖಲಿಸುವದನ್ನು ನೀವು ನಿಜವಾಗಿ ರಕ್ಷಿಸುವ ಶ್ರೇಣಿಗಳೊಂದಿಗೆ ಹೋಲಿಸಿ. API ಅಥವಾ SDK ಮೂಲಕ ರಚಿಸುವುದು ಸೆಲೆಕ್ಟರ್ ಸ್ಪಷ್ಟವಾಗಿರಿಸುತ್ತದೆ.
ಕ್ವೋಟಾಗಳು ಇನ್ನೊಂದು ಸುಲಭ ತಪ್ಪು. ನಿರ್ವಹಣಾ ವಿಂಡೋಗಿಂತ ಮೊದಲು ಹೆಚ್ಚಳ ಕೇಳಿ, ಅದರ ಸಮಯದಲ್ಲಿ ಅಲ್ಲ, ಮತ್ತು ಗೇಟ್ವೇ ಇರುವ ಅದೇ ಪ್ರಾಜೆಕ್ಟ್ನಲ್ಲಿ ವಿಳಾಸಗಳ ಸಂಖ್ಯೆ ಪರಿಶೀಲಿಸಿ.
ಹೊರಗಿನಿಂದ ಒಳಕ್ಕೆ ಕೆಲಸ ಮಾಡಿ: ಪೀರ್ ಸ್ಥಿತಿ, ಎರಡೂ ಸೆಲೆಕ್ಟರ್ ಪಟ್ಟಿಗಳು, ಪ್ರತಿ ಬದಿಗೂ ಒಂದು ರೂಟ್, ಮೂಲ ಶ್ರೇಣಿ ಮತ್ತು ಪೋರ್ಟ್ಗೆ ಒಳಬರುವ ನಿಯಮ, ನಂತರ ಪ್ಯಾಕೆಟ್ ಸೆರೆಹಿಡಿಯುವಿಕೆ. ಟನೆಲ್ ಹೊಸದಿರುವಾಗಲೇ ಗೇಟ್ವೇ ವಿಳಾಸ, ಎರಡೂ ಸೆಲೆಕ್ಟರ್ ಪಟ್ಟಿಗಳು ಮತ್ತು ರೂಟಿಂಗ್ ಪ್ರಕಾರವನ್ನು ಬದಲಾವಣೆ ಟಿಕೆಟ್ನಲ್ಲಿ ಬರೆಯಿರಿ, ಏಕೆಂದರೆ ಸಬ್ನೆಟ್ ಸೇರಿಸುವ ಮುಂದಿನ ಇಂಜಿನಿಯರ್ಗೆ ಮೂರೂ ಬೇಕಾಗುತ್ತವೆ.