ಹಲವು NIC ಇರುವ GCP VM: ಉತ್ತರಗಳು ತಪ್ಪು ಇಂಟರ್ಫೇಸ್ನಿಂದ ಏಕೆ ಹೊರಡುತ್ತವೆ

Compute Engine VM ಗೆ ಎರಡನೇ ಇಂಟರ್ಫೇಸ್ ಜೋಡಿಸಿದರೆ ಅದಕ್ಕೆ ಇನ್ನೊಂದು ನೆಟ್ವರ್ಕ್ ಸಂಪರ್ಕ ಸಿಗುತ್ತದೆ, ಸಮಮಿತಿಯ ಮರಳು ಮಾರ್ಗವಲ್ಲ. ಅತಿಥಿ ಇನ್ನೂ ತನ್ನದೇ ಮಾರ್ಗಗಳು ಮತ್ತು ನಿಯಮಗಳಿಂದ ಇಂಟರ್ಫೇಸ್ ಮತ್ತು ಮೂಲ ವಿಳಾಸವನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ. ನಂತರ Google Cloud ಪ್ಯಾಕೆಟ್ ಹೊರಟ ಇಂಟರ್ಫೇಸ್ನ ಸುತ್ತ VPC ರೂಟಿಂಗ್ ಮತ್ತು ಫೈರ್ವಾಲ್ ನೀತಿಯನ್ನು ಅನ್ವಯಿಸುತ್ತದೆ. ಈ ಎರಡು ನಿರ್ಧಾರಗಳು ಹೊಂದಿಕೆಯಾಗದಿದ್ದಾಗ, ವಿನಂತಿಗಳು ಒಂದು NIC ಗೆ ಬರುತ್ತವೆ ಮತ್ತು ಉತ್ತರಗಳು ಇನ್ನೊಂದರಿಂದ ಹೊರಡುತ್ತವೆ, ಮತ್ತು ಶಾಖೆ ಅರ್ಧ-ತೆರೆದ ಸಂಭಾಷಣೆ ಕಾಣುತ್ತದೆ.

ಐದು ಹಂತಗಳಲ್ಲಿ ಮಾರ್ಗವನ್ನು ಸಾಗಿಸಿ, ನೀತಿ ನಿಯಮ ಬರೆಯುವ ಮೊದಲೇ ಅಸಂಗತಿ ಕಾಣಿಸುತ್ತದೆ.

ಹಂತ 1: ಕ್ಲೌಡ್ NIC ಗಳನ್ನು ಅತಿಥಿ ಸಾಧನಗಳಿಗೆ ಹೊಂದಿಸಿ

ಕ್ಲೌಡ್ ಇಂಟರ್ಫೇಸ್ಗಳಿಗೆ nic0, nic1 ಇತ್ಯಾದಿ ಹೆಸರುಗಳನ್ನು ನೀಡುತ್ತದೆ, ಅತಿಥಿ ಹೊಂದಿಕೆಯಾಗಬೇಕಿಲ್ಲದ ಸಾಧನ ಹೆಸರುಗಳನ್ನು ನೋಡುತ್ತದೆ. ಬೇರೆ ಯಾವುದಕ್ಕೂ ಮೊದಲು ಇನ್ಸ್ಟನ್ಸ್ ಮೆಟಾಡೇಟಾ ಅಥವಾ ಇಂಟರ್ಫೇಸ್ನ ಸ್ವಂತ ವಿಳಾಸದಿಂದ ಮ್ಯಾಪಿಂಗ್ ಬಗೆಹರಿಸಿ. DHCP ಒದಗಿಸುವ ಸಾಮಾನ್ಯ ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗ nic0 ಗೆ ಸಂಬಂಧಿಸಿದೆ, ಆದ್ದರಿಂದ ಇಂಟರ್ನೆಟ್ ಕಡೆಗಿನ ಮಾರ್ಗ ಹಲವು ಬಾರಿ ಆಕಸ್ಮಿಕವಾಗಿ ಗೆಲ್ಲುತ್ತದೆ. ಊಹಿಸಿದ ಸಾಧನ ಹೆಸರಿನ ಮೇಲೆ ನೀತಿ ಬರೆಯುವುದು ಸರಿಯಾದ ನಿಯಮ ತಪ್ಪು ಇಂಟರ್ಫೇಸ್ಗೆ ಬರುವ ದಾರಿ.

ವಿಳಾಸಗಳು, ಸಾಧನ ಹೆಸರುಗಳು ಮತ್ತು ಪ್ರತಿಯೊಂದು ಸೇರಿರುವ VPC ಅನ್ನು ದಾಖಲಿಸಿ. ಆ ಮೂರು-ಕಾಲಮ್ ನಕ್ಷೆ ಪ್ರತಿ ಮುಂದಿನ ಹಂತದ ಇನ್ಪುಟ್.

ಹಂತ 2: ಎರಡು ರೂಟಿಂಗ್ ನಿರ್ಧಾರಗಳಿಗೆ ಹೆಸರಿಡಿ

ಮೊದಲ ನಿರ್ಧಾರ ಅತಿಥಿಯದು: ಈ ಪ್ಯಾಕೆಟ್ಗೆ ಯಾವ ಇಂಟರ್ಫೇಸ್ ಮತ್ತು ಯಾವ ಮೂಲ ವಿಳಾಸ. ಎರಡನೆಯದು ಕ್ಲೌಡ್ನದು: VPC ಮಾರ್ಗಗಳು ಮತ್ತು ಫೈರ್ವಾಲ್ ನೀತಿ ಆ ಇಂಟರ್ಫೇಸ್ನ ಸುತ್ತ ಏನನ್ನು ಅನುಮತಿಸುತ್ತವೆ.

VPN ಕಡೆಗಿನ VPC ಯಲ್ಲಿ ಕಾಣುವ ಮಾರ್ಗ ಆ NIC ಅನ್ನು ಆಯ್ಕೆ ಮಾಡುವ ಅತಿಥಿ ಮಾರ್ಗವಾಗುವುದಿಲ್ಲ. ಕ್ಲೌಡ್ ಮಾರ್ಗ ನೆಟ್ವರ್ಕ್ ಏನನ್ನು ತಲುಪಿಸಬಲ್ಲದೆಂದು ವಿವರಿಸುತ್ತದೆ, ಆದರೆ ಅತಿಥಿ ಮಾರ್ಗ ಪ್ಯಾಕೆಟ್ ಏನು ಮಾಡುತ್ತದೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ.

ಹಂತ 3: ಮರಳು ಮಾರ್ಗದ ನೀತಿಯನ್ನು ಆಯ್ಕೆ ಮಾಡಿ

ಶಾಖೆ ಪ್ರಿಫಿಕ್ಸ್ಗಳ ಸಣ್ಣ, ಸ್ಥಿರ ಗುಂಪಿಗೆ ಅತಿಥಿಯಲ್ಲಿ ಸ್ಪಷ್ಟ ಗಮ್ಯಸ್ಥಾನ ಮಾರ್ಗಗಳು ಸರಳವಾದ ಅಭಿವ್ಯಕ್ತಿ: ಆ ಪ್ರಿಫಿಕ್ಸ್ಗಳಿಗೆ ಉತ್ತರಗಳು VPN ಕಡೆಗಿನ ಇಂಟರ್ಫೇಸ್ನಿಂದ ಹೊರಡುತ್ತವೆ. ಹಲವು ಸೇವೆಗಳು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ವಿವಿಧ ಸ್ಥಳೀಯ ಮೂಲ ವಿಳಾಸಗಳನ್ನು ಬಳಸಿದಾಗ, ಪ್ರತಿ ಇಂಟರ್ಫೇಸ್ಗೆ ಟೇಬಲ್ ಆಯ್ಕೆ ಮಾಡುವ ಮೂಲ-ಆಧಾರಿತ ನಿಯಮಗಳು ಪ್ರತಿ ಉತ್ತರವನ್ನು ಸರಿಯಾದ ಸಂದರ್ಭದಲ್ಲಿ ಇಡುತ್ತವೆ. ಹಲವು ಇಂಟರ್ಫೇಸ್ಗಳ ದಸ್ತಾವೇಜು ಈ ವಿನ್ಯಾಸಗಳು ಅವಲಂಬಿಸಿರುವ NIC ನಾಮಕರಣ ಮತ್ತು ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗದ ವರ್ತನೆಯನ್ನು ವಿವರಿಸುತ್ತದೆ.

ಪ್ರತಿ ಟೇಬಲ್ಗೆ ಮಾನ್ಯ ಸಂಪರ್ಕಿತ ಮಾರ್ಗಗಳು ಮತ್ತು ಮುಂದಿನ ಹಾಪ್ಗಳು, ಜೊತೆಗೆ ಅದರಿಂದ ಕೇಳಲಾಗುವ ಗಮ್ಯಸ್ಥಾನಗಳು ಬೇಕು. ಅಪೂರ್ಣ ಟೇಬಲ್ ಕಡೆಗೆ ತೋರಿಸುವ ನಿಯಮ ಮರಳು ಮಾರ್ಗದ ವಿನ್ಯಾಸವಲ್ಲ. ಆ NIC ಗೆ ದಸ್ತಾವೇಜಿತ ಗೇಟ್ವೇ ಬಳಸಿ, ಸಬ್ನೆಟ್ನ ನೋಟದಿಂದ Ethernet ಗೇಟ್ವೇ ಕಲ್ಪಿಸಬೇಡಿ.

ಹಂತ 4: ಅತಿಥಿಯ ಸ್ವಂತ ಫಿಲ್ಟರ್ಗಳನ್ನು ಪರಿಶೀಲಿಸಿ

ಸರ್ವರ್ ಎಲ್ಲಿ ಕೇಳುತ್ತದೆ ಮತ್ತು ಉತ್ತರ ಯಾವ ಸ್ಥಳೀಯ ಮೂಲವನ್ನು ಹೊತ್ತುಕೊಂಡಿದೆ ಎಂದು ಪರಿಶೀಲಿಸಿ. ಎಲ್ಲಾ ವಿಳಾಸಗಳಲ್ಲಿ ಕೇಳುವ ಶ್ರೋತೃ ರೂಟಿಂಗ್ ನೀತಿಯನ್ನು ರದ್ದು ಮಾಡುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಎಲ್ಲಾ ವಿಳಾಸಗಳಿಗೆ ಬಂಧಿಸುವುದು ಉತ್ತರ ಹೊರಡುವ ಇಂಟರ್ಫೇಸ್ ಬಗ್ಗೆ ಏನನ್ನೂ ಬದಲಿಸುವುದಿಲ್ಲ.

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

ಹಂತ 5: ಪ್ರತಿ ಮಾರ್ಗಕ್ಕೆ ಒಂದು ಹರಿವನ್ನು ಪರೀಕ್ಷಿಸಿ

ಅನುಮತಿಸಿದ ಶಾಖೆ ವಿನಂತಿ ಮತ್ತು ಸಂಬಂಧವಿಲ್ಲದ ಇಂಟರ್ನೆಟ್ ವಿನಂತಿಯನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಪರಿಶೀಲಿಸಿ, ಪ್ರತಿಯೊಂದೂ ತನ್ನ ನಿಜವಾದ ಮೂಲ ಮತ್ತು ಗಮ್ಯಸ್ಥಾನದೊಂದಿಗೆ. ಸಾಧ್ಯವಾದಾಗ ಎರಡೂ ಇಂಟರ್ಫೇಸ್ಗಳಲ್ಲಿ ಸೆರೆಹಿಡಿಯಿರಿ, ಏಕೆಂದರೆ ಉಪಯುಕ್ತ ಸಾಕ್ಷ್ಯ ಯಾವ ಇಂಟರ್ಫೇಸ್ ಉತ್ತರವನ್ನು ಸಾಗಿಸಿತು ಎಂಬುದು. ನಂತರ ಕ್ಲೌಡ್-ಬದಿಯ ನೀತಿ ನೀವು ವಿನ್ಯಾಸ ಮಾಡಿದ ಮಾರ್ಗವನ್ನು ಗೌರವಿಸಿದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ. ಒಂದು ಯಶಸ್ವಿ ವಿನಂತಿ ಒಂದು ಹರಿವನ್ನು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ, ಸಮಮಿತಿಯ ವಿನ್ಯಾಸವನ್ನಲ್ಲ.

ಎರಡು ಪರೀಕ್ಷೆಗಳನ್ನು ನಿಮ್ಮ ಟಿಪ್ಪಣಿಗಳಲ್ಲಿ ಪ್ರತ್ಯೇಕವಾಗಿ ಇಡಿ, ಏಕೆಂದರೆ ಅವು ವಿಭಿನ್ನ ಮಾರ್ಗಗಳು ಮತ್ತು ವಿಭಿನ್ನ ಫೈರ್ವಾಲ್ ನಿಯಮಗಳನ್ನು ಬಳಸುತ್ತವೆ.

ಎರಡನೇ NIC ನಿಮಗೆ ಏನನ್ನು ಕೊಡುವುದಿಲ್ಲ

ಎರಡನೇ ಇಂಟರ್ಫೇಸ್ ನೆಟ್ವರ್ಕ್ ಸಂಪರ್ಕ ಮತ್ತು ಇನ್ನೊಂದು ವಿಳಾಸವನ್ನು ಸೇರಿಸುತ್ತದೆ. ಅದು ಸ್ವಯಂಚಾಲಿತ ಸಮಮಿತಿಯ ರೂಟಿಂಗ್ ಸೇರಿಸುವುದಿಲ್ಲ ಮತ್ತು ಫೈರ್ವಾಲ್ ನೀತಿಯನ್ನು ತಪ್ಪಿಸಿಕೊಳ್ಳುವುದಿಲ್ಲ. ಅದನ್ನು ರೂಟಿಂಗ್ ಸರಿಪಡಿಸುವಿಕೆ ಎಂದು ಪರಿಗಣಿಸುವುದೇ ಹಲವು NIC ವಿನ್ಯಾಸಗಳಲ್ಲಿ ನಂತರ ಯಾರೂ ವಿವರಿಸಲಾಗದ ನಿಯಮಗಳು ಸಂಗ್ರಹವಾಗುವ ಕಾರಣ.

VM ಇತರ ಯಂತ್ರಗಳ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಮುಂದಕ್ಕೆ ರವಾನಿಸಬೇಕಿದ್ದರೆ, ಆ ರೌಟರ್ ಪಾತ್ರವನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಯೋಜಿಸಿ, ರವಾನೆಗೆ ಅನುಮತಿಸುವ ಕ್ಲೌಡ್ ಸೆಟ್ಟಿಂಗ್ ಮತ್ತು ಅದರೊಂದಿಗೆ ಹೋಗುವ ಅತಿಥಿ ಫಿಲ್ಟರ್ಗಳೂ ಸೇರಿದಂತೆ.