ಕ್ಲೌಡ್ ಗಡಿಯಲ್ಲಿ VPN ಕ್ಲೈಂಟ್ IP ಗಳನ್ನು ಉಳಿಸಿಕೊಳ್ಳಿ ಅಥವಾ SNAT ಮಾಡಿ

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

ಮೂರು ಷರತ್ತುಗಳು ನಿರ್ಧರಿಸುತ್ತವೆ

ನೆಟ್ವರ್ಕ್ ರೇಖಾಚಿತ್ರದಿಂದ ಅಲ್ಲ, ಅಪ್ಲಿಕೇಶನ್ ನ ಅಗತ್ಯದಿಂದ ಪ್ರಾರಂಭಿಸಿ. ಅಧಿಕಾರ ನೀಡಿಕೆ ಅಥವಾ ಲೆಕ್ಕ ಪರಿಶೋಧನೆ ವೈಯಕ್ತಿಕ ಕ್ಲೈಂಟ್ ವಿಳಾಸವನ್ನು ಅವಲಂಬಿಸಿದ್ದರೆ, ಅದನ್ನು ಉಳಿಸಿಕೊಳ್ಳುವುದು ಕ್ರಿಯಾತ್ಮಕ ಅಗತ್ಯ ಮತ್ತು ಅನುವಾದ ಮಾಡುವುದು ಹಿನ್ನಡೆ. ಅಪ್ಲಿಕೇಶನ್ ಗೆ ಸಂಚಾರವು ದೂರಸ್ಥ ಪ್ರವೇಶ ಮಾರ್ಗದ ಮೂಲಕ ಬಂದಿದೆ ಎಂದು ತಿಳಿಯಲು ಮಾತ್ರ ಬೇಕಾದರೆ, ಅನುವಾದಿತ ವಿಳಾಸ ಸಾಕು ಮತ್ತು ನಿರ್ವಹಿಸಲು ಹೆಚ್ಚು ಅಗ್ಗವಾಗಿದೆ.

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

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

ಮಾರ್ಗ ಎಂದರೆ ಸೋಗಿನ ಅನುಮತಿ ಅಲ್ಲ

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

aws ec2 describe-instances --instance-ids i-0a1b2c3d4e5f60718 \
  --query "Reservations[].Instances[].SourceDestCheck"
aws ec2 modify-instance-attribute --instance-id i-0a1b2c3d4e5f60718 \
  --no-source-dest-check

ಅದನ್ನು ದಾಖಲಿತ ಕೆಲಸ ಮುಂದಕ್ಕೆ ಕಳುಹಿಸುವುದಾಗಿರುವ ಇನ್ಸ್ಟನ್ಸ್ ಗೆ ಮಾತ್ರ ಆಫ್ ಮಾಡಿ, ಬೇರೆ ಯಾವುದಕ್ಕೂ ಅಲ್ಲ. ಪರಿಶೀಲನೆಯನ್ನು ಆನ್ ಆಗಿ ಇಡುವ ಪ್ರತಿ ಅಪ್ಲಿಕೇಶನ್ VM ಎಂದರೆ ಎರವಲು ಪಡೆದ ಮೂಲದಿಂದ ಸಂಚಾರ ಹೊರಡಿಸಲು ಬಳಸಬಹುದಾದ ಒಂದು ಯಂತ್ರ ಕಡಿಮೆ. ನಿಮ್ಮ ವೇದಿಕೆ AWS ಅಲ್ಲದಿದ್ದರೆ, ನಡವಳಿಕೆ ವರ್ಗಾವಣೆಯಾಗುತ್ತದೆ ಎಂದು ಊಹಿಸುವ ಬದಲು ಸಮಾನವಾದ ಆಂಟಿ-ಸ್ಪೂಫಿಂಗ್ ಅಥವಾ ಅನುಮತಿಸಿದ ವಿಳಾಸ ಸೆಟ್ಟಿಂಗ್ ಅನ್ನು ಹುಡುಕಿ.

ತ್ವರಿತ ಪ್ಯಾಕೆಟ್ ಸೆರೆಹಿಡಿಯುವಿಕೆ ಕನ್ಸೋಲ್ ಓದುವುದಕ್ಕಿಂತ ಬೇಗ ಪ್ರಶ್ನೆಯನ್ನು ಬಗೆಹರಿಸುತ್ತದೆ. ಉತ್ತರಗಳು ಹೊರಟು ಕ್ಲೈಂಟ್ ಅವುಗಳನ್ನು ಎಂದಿಗೂ ನೋಡದಿದ್ದರೆ, ಅಪ್ಲಿಕೇಶನ್ ವಿಫಲವಾಗುತ್ತಿಲ್ಲ, ನೇಯ್ಗೆಯೇ ನಕಲಿ ಮೂಲವನ್ನು ಬಿಸಾಡುತ್ತಿದೆ.

ಅನುವಾದ ಏನನ್ನು ಖರೀದಿಸುತ್ತದೆ ಮತ್ತು ಏನು ವೆಚ್ಚವಾಗುತ್ತದೆ

ಗೇಟ್ವೇ ನಲ್ಲಿ ಮೂಲವನ್ನು ಮತ್ತೆ ಬರೆಯುವುದು ಹಿಂತಿರುಗುವ ಮಾರ್ಗದ ಸಮಸ್ಯೆಯನ್ನು ನಿವಾರಿಸುತ್ತದೆ. ಅಪ್ಲಿಕೇಶನ್ ತನಗೆ ತಲುಪುವ ದಾರಿ ಈಗಾಗಲೇ ತಿಳಿದಿರುವ ಒಂದು ವಿಳಾಸವನ್ನು ನೋಡುತ್ತದೆ, ಮತ್ತು ಕ್ಲೈಂಟ್ ಪೂರ್ವಪ್ರತ್ಯಯವು ಎಂದಿಗೂ ಕ್ಲೌಡ್ ರೂಟ್ ಕೋಷ್ಟಕದಲ್ಲಿ ಕಾಣಬೇಕಾಗಿಲ್ಲ. Linux ನಲ್ಲಿ ನಿಯಮ ಒಂದೇ ಸಾಲು, ಮತ್ತು ನೀವು ಮಾಡಬಹುದಾದ ಅತ್ಯಂತ ಸಂಕುಚಿತ ಆವೃತ್ತಿಯನ್ನು ಬರೆಯುವುದು ಯೋಗ್ಯ:

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 172.20.8.0/24 -o ens5 -j SNAT --to-source 10.40.3.10

ಅಪ್ಲಿಕೇಶನ್ ಈಗ ಏನನ್ನು ದಾಖಲಿಸುತ್ತದೆ ಎಂದು ಗಮನಿಸಿ: ಪ್ರತಿ ಬಳಕೆದಾರರಿಗೂ 10.40.3.10, ಪ್ರತಿ ಸಂಪರ್ಕದಲ್ಲೂ, ಶಾಶ್ವತವಾಗಿ. ಆ ಮೌಲ್ಯದ ಮೇಲೆ ನಿರ್ಮಿಸಿದ ಯಾವುದೇ ವಿಳಾಸ ಅನುಮತಿ ಪಟ್ಟಿ ಈಗ ಇಡೀ ದೂರಸ್ಥ ಪ್ರವೇಶ ಜನಸಂಖ್ಯೆಗೆ ಪ್ರವೇಶ ನೀಡುತ್ತದೆ, ಮತ್ತು ಯಾವುದೇ ಘಟನೆ ಪರಿಶೀಲನೆ ಇದು ಯಾರು ಎಂದು ಉತ್ತರಿಸಲು ಗೇಟ್ವೇ ಗೆ ಹಿಂತಿರುಗಬೇಕು.

ಪರಿಹಾರ ಅನುವಾದವನ್ನು ತೊರೆಯುವುದಲ್ಲ, ವಿಳಾಸವೇ ಗುರುತು ಎಂಬ ನಟನೆಯನ್ನು ನಿಲ್ಲಿಸುವುದು. ಕ್ಲೈಂಟ್ ನ ಗುರುತನ್ನು ದೃಢೀಕರಿಸಿದ ಕ್ಷೇತ್ರದಲ್ಲಿ ಒಯ್ಯಿರಿ, ಅನುವಾದಿತ ಟುಪಲ್ ಜೊತೆಗೆ ಗೇಟ್ವೇ ನಲ್ಲಿ ಅದನ್ನು ಲಾಗ್ ಮಾಡಿ, ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಅದರ ಮೇಲೆ ಸೇರಲು ಬಿಡಿ. ಸೇರುವ ಕೀಲಿ ಇಲ್ಲದಿದ್ದರೆ, ಅನುವಾದವು ಜಾಲ ಸಮಸ್ಯೆಯನ್ನು ಶಾಶ್ವತ ಫೋರೆನ್ಸಿಕ್ ಸಮಸ್ಯೆಯಾಗಿ ಪರಿವರ್ತಿಸುತ್ತದೆ.

ರಿಲೇ ಬೇರೆ ಇಂಟರ್ಫೇಸ್

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

ಆ ಹೆಡರ್ ಬ್ಯಾಕೆಂಡ್ ಅದನ್ನು ಪ್ರಾಕ್ಸಿಯಿಂದ ಸ್ವೀಕರಿಸಿ ಬೇರೆ ಯಾವುದರಿಂದಲೂ ಸ್ವೀಕರಿಸದಿದ್ದಾಗ ಮಾತ್ರ ವಿಶ್ವಾಸಾರ್ಹ. nginx ಪದಗಳಲ್ಲಿ ಇದರರ್ಥ ಬರುವ ಎಲ್ಲವನ್ನೂ ನಂಬುವ ಬದಲು ವಿಶ್ವಾಸಾರ್ಹ ಪಾಲುದಾರನನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಹೆಸರಿಸುವುದು:

set_real_ip_from 10.40.3.10;
real_ip_header X-Forwarded-For;
real_ip_recursive on;

ಬ್ಯಾಕೆಂಡ್ ಗೆ ನೇರವಾಗಿ ತಲುಪಬಲ್ಲ ಯಾವುದೇ ಕ್ಲೈಂಟ್ ಅದೇ ಹೆಡರ್ ಅನ್ನು ನಕಲಿಸಬಹುದು, ಆದ್ದರಿಂದ ಬ್ಯಾಕೆಂಡ್ ಪ್ರಾಕ್ಸಿ ಮೂಲಕವಲ್ಲದೆ ತಲುಪಲಾಗದಂತಿರಬೇಕು. ಇದು ಫೈರ್ ವಾಲ್ ಸತ್ಯ, ಸಂರಚನೆಯ ಅಭಿಪ್ರಾಯವಲ್ಲ, ಮತ್ತು ಸ್ನಿಪ್ಪೆಟ್ ನಕಲಿಸುವಾಗ ಜನರು ಬಿಟ್ಟುಬಿಡುವ ಊಹೆ ಇದೇ.

ರಿಲೇ ನೀವು ಏನನ್ನು ಖರೀದಿಸುತ್ತೀರಿ ಎಂಬುದನ್ನೂ ಬದಲಾಯಿಸುತ್ತದೆ. ನಿಮಗೆ ಅಪ್ಲಿಕೇಶನ್ ಮಟ್ಟದ ಗುರುತು ಮತ್ತು ಅದನ್ನು ಲಾಗ್ ಮಾಡಲು ಸಹಜ ಸ್ಥಳ ಸಿಗುತ್ತದೆ; ನೀವು ಸಾಮಾನ್ಯತೆಯನ್ನು ಬಿಟ್ಟುಕೊಡುತ್ತೀರಿ, ಏಕೆಂದರೆ ಪ್ರತಿ ಹೊಸ ಪ್ರೋಟೋಕಾಲ್ ಗೆ ತನ್ನದೇ ಪ್ರಾಕ್ಸಿ ಬೆಂಬಲ ಬೇಕು. HTTP ಸೇವೆಗಳಿಗೆ ಈ ವಿನಿಮಯ ಸಾಮಾನ್ಯವಾಗಿ ಒಳ್ಳೆಯದು, ಮತ್ತು HTTP ಅಲ್ಲದ ಯಾವುದಕ್ಕೂ ಸಾಮಾನ್ಯವಾಗಿ ಅದು ಸಿಗುವುದೇ ಇಲ್ಲ.

ಪ್ರತಿ ಗಡಿ ಏನನ್ನು ನೋಡುತ್ತದೆ ಎಂದು ಬರೆಯಿರಿ

ನೀವು ಏನನ್ನು ಆರಿಸಿದರೂ, ವಿನ್ಯಾಸ ಪರಿಶೀಲನೆ ಪ್ರತಿ ಹಾರಿಕೆಯಲ್ಲಿ ಮೂಲ ವಿಳಾಸ ಮತ್ತು ಸಾಬೀತುಪಡಿಸಬಹುದಾದ ಗುರುತನ್ನು ಹೆಸರಿಸುವ ಒಂದು ಕೋಷ್ಟಕದೊಂದಿಗೆ ಕೊನೆಗೊಳ್ಳಬೇಕು. ಅದಿಲ್ಲದೆ, ಮೊದಲ ಘಟನೆ ಮೂರು ತಂಡಗಳನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ, ಪ್ರತಿಯೊಂದೂ ಬೇರೆ ಕ್ಲೈಂಟ್ ಅನ್ನು ವಿವರಿಸುತ್ತದೆ.

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