IOS VPN ನಿರ್ಗಮನದಲ್ಲಿ ಯಾವ ಇಂಟರ್ಫೇಸ್ NAT ನ ಒಳಗಿನ ಮತ್ತು ಹೊರಗಿನ ಪಾತ್ರವನ್ನು ಪಡೆಯುತ್ತದೆ
ವರ್ಚುವಲ್ ಇಂಟರ್ಫೇಸ್ನಿಂದ ಅಪ್ಲಿಂಕ್ ವರೆಗೆ ಡಿಕ್ರಿಪ್ಟ್ ಆದ ಕ್ಲೈಂಟ್ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಅನುಸರಿಸಿ. ಅನುವಾದವು ಆ ಒಳಗಿನ ಹರಿವಿಗೆ ಸೇರಿದೆ, ಟನೆಲ್ನ ಹೊರಗಿನ ಸಾಗಣೆಗೆ ಅಲ್ಲ.
ಪೂರ್ಣ ಟನೆಲ್ ಇಂಟರ್ನೆಟ್ ನಿರ್ಗಮನ ನೀಡುವ ರೌಟರ್ಗಳು ಒಂದೇ ತರಹ ಕಾಣುವ ಎರಡು ಕೆಲಸಗಳನ್ನು ಮಾಡುತ್ತವೆ. ಅವು ಟನೆಲ್ ಅನ್ನು ಮುಗಿಸಿ, ಡಿಕ್ರಿಪ್ಟ್ ಆದ ಕ್ಲೈಂಟ್ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಇಂಟರ್ನೆಟ್ಗೆ ಕಳುಹಿಸುತ್ತವೆ. ಅನುವಾದ ಬೇಕಾಗಿರುವುದು ಎರಡನೇ ಕೆಲಸಕ್ಕೆ ಮಾತ್ರ, ಮತ್ತು ಅನುವಾದವು ಒಳಗಿನ ಹರಿವಿಗೆ ಹೊಂದಿಕೆಯಾಗಬೇಕು. ಈ ವ್ಯತ್ಯಾಸವೇ ಯಾವ ಇಂಟರ್ಫೇಸ್ಗಳು NAT ಪಾತ್ರಗಳನ್ನು ಹೊತ್ತುಕೊಳ್ಳುತ್ತವೆ ಮತ್ತು ನಿಯಮದಲ್ಲಿ ಯಾವ ವಿಳಾಸ ಶ್ರೇಣಿ ಕಾಣಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ.
ಒಂದು ಪ್ಯಾಕೆಟ್ ಅನ್ನು ರೌಟರ್ ಮೂಲಕ ಅನುಸರಿಸಿ
10.90.0.25 ನಲ್ಲಿರುವ ಕ್ಲೈಂಟ್ ಅನ್ನು ತೆಗೆದುಕೊಳ್ಳಿ, ಅದು ಸಾರ್ವಜನಿಕ HTTPS ಸೇವೆಯನ್ನು ತೆರೆಯುತ್ತದೆ. ಆ ಗಮ್ಯಸ್ಥಾನವು ಟನೆಲ್ಗೆ ಬರುತ್ತದೆಯೇ ಇಲ್ಲವೇ ಎಂಬುದು ಕ್ಲೈಂಟ್ನ ಸ್ವಂತ ನೀತಿಯ ನಿರ್ಧಾರ. ಬಂದ ನಂತರ ರೌಟರ್ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಡಿಕ್ರಿಪ್ಟ್ ಮಾಡಿ ವರ್ಚುವಲ್ ಇಂಟರ್ಫೇಸ್ಗೆ ನೀಡುತ್ತದೆ, ಅಲ್ಲಿಂದ ಅದು ಸಾರ್ವಜನಿಕ ಅಪ್ಲಿಂಕ್ಗೆ ರೂಟ್ ಆಗುತ್ತದೆ.
ಆ ವರ್ಚುವಲ್ ಇಂಟರ್ಫೇಸ್ ಅನುವಾದದ ಒಳಗಿನ ಭಾಗ. ಸಾರ್ವಜನಿಕ ಅಪ್ಲಿಂಕ್ ಹೊರಗಿನ ಭಾಗ. ಪಾತ್ರಗಳು ತಲೆಕೆಳಗಾದರೆ ಅಥವಾ ಇಲ್ಲದಿದ್ದರೆ, ಪ್ಯಾಕೆಟ್ ಖಾಸಗಿ ಮೂಲದೊಂದಿಗೆ ಹೊರಡುತ್ತದೆ ಅಥವಾ ಅನುವಾದಕ್ಕೆ ಮೊದಲೇ ಬಿಸಾಡಲ್ಪಡುತ್ತದೆ.
| Stage | Question to answer |
|---|---|
| VPN client | Does the client's policy put this destination inside the tunnel? |
| Decrypted ingress | Which virtual interface receives the inner packet? |
| Internet egress | Which route, access policy and source translation apply? |
| Reply | Is the client's flow translated back before it is delivered over the tunnel? |
ಅನುವಾದ ನೀತಿಯನ್ನು ಕ್ಲೈಂಟ್ ಪೂಲ್ಗೆ ಹೊಂದಿಸಿ
NAT ನಿಯಮವು ಕ್ಲೈಂಟ್ಗಳು ನಿಜವಾಗಿ ಪಡೆಯುವ ಶ್ರೇಣಿಯನ್ನು ಹೆಸರಿಸಬೇಕು, ಆಕಸ್ಮಿಕವಾಗಿ ಅದೇ ಅಪ್ಲಿಂಕ್ ಹಂಚಿಕೊಳ್ಳುವ ಕಚೇರಿ LAN ಅನ್ನಲ್ಲ. ಸ್ಥಳೀಯ ಸಬ್ನೆಟ್ ಮಾತ್ರ ಆವರಿಸುವ ನಿಯಮವು ದೂರದ ಕ್ಲೈಂಟ್ಗಳನ್ನು ತಪ್ಪಿಸುತ್ತದೆ, ಎರಡೂ ಒಂದೇ ಇಂಟರ್ಫೇಸ್ನಿಂದ ಹೊರಟರೂ.
ip access-list extended NAT-TUNNEL
permit ip 10.90.0.0 0.0.0.255 any
ip nat inside source list NAT-TUNNEL interface GigabitEthernet0/0/0 overloadಖಾಸಗಿ ಸೈಟ್ಗಳಿಗೆ ಅಪವಾದಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಇರಿಸಿ. ಒಳಗಿನ ಗಮ್ಯಸ್ಥಾನಗಳಿಗೆ ಹೋಗುವ ಸಂಚಾರವು ತನ್ನ ಮೂಲ ಮೂಲವನ್ನು ಉಳಿಸಿಕೊಳ್ಳಬೇಕು, ಇಲ್ಲದಿದ್ದರೆ ಗಮ್ಯಸ್ಥಾನವು ತಲುಪಲಾಗದ ವಿಳಾಸಕ್ಕೆ ಉತ್ತರಿಸುತ್ತದೆ ಮತ್ತು ಹಿಂತಿರುಗುವ ಮಾರ್ಗವು ರೂಟಿಂಗ್ ಲೂಪ್ನಂತೆ ಕಾಣುವ ರೀತಿಯಲ್ಲಿ ವಿಫಲವಾಗುತ್ತದೆ.
ನಿಯೋಜಿತ ವಿನ್ಯಾಸದ ನಿಜವಾದ ಇಂಟರ್ಫೇಸ್ಗಳಿಗೆ ಪಾತ್ರಗಳನ್ನು ಅನ್ವಯಿಸಿ. ಹಳೆಯ Easy VPN ಉತ್ತರದಿಂದ ನಕಲಿಸಿದ Virtual-Template ತುಣುಕು ಸಂಪೂರ್ಣ ಪ್ರಸ್ತುತ ಸಂರಚನೆ ಅಲ್ಲ, ಮತ್ತು ಬಳಸುವ ಟನೆಲ್ ಪ್ರಕಾರವು ಯಾವ ಇಂಟರ್ಫೇಸ್ ಡಿಕ್ರಿಪ್ಟ್ ಆದ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಪಡೆಯುತ್ತದೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ.
ಹೊರಗಿನ ಸಾಗಣೆ ಮತ್ತು ಒಳಗಿನ ಅನುವಾದವನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಇರಿಸಿ
ಡಿಕ್ರಿಪ್ಟ್ ಆದ ಅಪ್ಲಿಕೇಶನ್ ಮೂಲವನ್ನು ಅನುವಾದಿಸುವುದು IKE ಅಥವಾ ಸಂರಕ್ಷಿತ ಪ್ಯಾಕೆಟ್ಗಳನ್ನು ಮೇಲಿನ NAT ಸಾಧನದ ಮೂಲಕ ಕಳುಹಿಸುವುದಕ್ಕೆ ಸಮಾನವಾದ ಕ್ರಿಯೆ ಅಲ್ಲ. ಮೊದಲನೆಯದು ಇಂಟರ್ನೆಟ್ ಕ್ಲೈಂಟ್ನ ವಿನಂತಿಯ ಮೂಲವಾಗಿ ಏನನ್ನು ನೋಡುತ್ತದೆ ಎಂಬುದನ್ನು ಬದಲಿಸುತ್ತದೆ; ಎರಡನೆಯದು ಮಧ್ಯವರ್ತಿ ಪೆಟ್ಟಿಗೆಯ ಮೂಲಕ ಟನೆಲ್ ಅನ್ನು ಜೀವಂತವಾಗಿ ಇಡುತ್ತದೆ.
ಎರಡನ್ನೂ ಬೆರೆಸುವುದು ಎರಡು ಸಾಂಪ್ರದಾಯಿಕ ವೈಫಲ್ಯಗಳನ್ನು ತರುತ್ತದೆ. ತನ್ನದೇ ಟನೆಲ್ ಸಾಗಣೆಯನ್ನು ಅನುವಾದಿಸುವ ರೌಟರ್ ಜೋಡಿ ಸಂಬಂಧವನ್ನು ಮುರಿಯುತ್ತದೆ, ಆದರೆ ಒಳಗಿನ ಹರಿವನ್ನು ಎಂದಿಗೂ ಅನುವಾದಿಸದ ರೌಟರ್ ಖಾಸಗಿ ವಿಳಾಸಗಳನ್ನು ಇಂಟರ್ನೆಟ್ಗೆ ಕಳುಹಿಸುತ್ತದೆ. ನಿಯಮವನ್ನು ಸಂಪಾದಿಸುವ ಮೊದಲು ನೀವು ಯಾವ ಹರಿವನ್ನು ನೋಡುತ್ತಿದ್ದೀರಿ ಎಂದು ಓದಿ, ಮತ್ತು ಬದಲಾವಣೆಯ ನಂತರ ಟನೆಲ್ ಮೇಲೆ ಉಳಿದಿದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿ. ಬ್ರೌಸಿಂಗ್ ಸರಿಪಡಿಸಿ ಟನೆಲ್ ಅನ್ನು ಬೀಳಿಸುವ ನಿಯಮವು ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸದೆ ಸ್ಥಳಾಂತರಿಸಿದೆ.
ಎರಡೂ ವೈಫಲ್ಯಗಳಲ್ಲಿ ಒಂದನ್ನೂ ಇನ್ನೊಂದನ್ನು ಬದಲಿಸಿ ಸರಿಪಡಿಸಲಾಗದು. ನಿಯಮವನ್ನು ಸಂಪಾದಿಸುವ ಮೊದಲು ನೀವು ಯಾವ ಹರಿವನ್ನು ನೋಡುತ್ತಿದ್ದೀರಿ ಎಂದು ಓದಿ.
ಎರಡೂ ಗಡಿಗಳಲ್ಲಿ ಪರಿಶೀಲಿಸಿ
ಇಂಟರ್ನೆಟ್ ಗಡಿಯಲ್ಲಿ ಅಪ್ಲಿಕೇಶನ್ ಮೂಲವನ್ನು, ಮತ್ತು ಹಿಂತಿರುಗುವ ಮಾರ್ಗದಲ್ಲಿ ಮರುಸ್ಥಾಪಿಸಿದ ಗಮ್ಯಸ್ಥಾನವನ್ನು ಓದಿ. ಮೊದಲನೆಯದು ಅನುವಾದ ಆಯಿತೇ ಎಂದು ಹೇಳುತ್ತದೆ; ಎರಡನೆಯದು ಹಿಮ್ಮುಖ ಮ್ಯಾಪಿಂಗ್ ಸರಿಯಾದ ಕ್ಲೈಂಟ್ಗೆ ಮರಳಿತೇ ಎಂದು ಹೇಳುತ್ತದೆ.
ನಂತರ ಅನುಮೋದಿತ ವಿಭಜಿತ ಟನೆಲ್ ಮಾರ್ಗವನ್ನು ಬಳಸುವ ಕ್ಲೈಂಟ್ ಅನ್ನು ಪರೀಕ್ಷಿಸಿ. ಆ ಕ್ಲೈಂಟ್ ಈ ರೌಟರ್ನ ಇಂಟರ್ನೆಟ್ ಅನುವಾದವನ್ನು ಎಂದಿಗೂ ಬಳಸುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಅದು ಬೇರೆಯಾಗಿ ವರ್ತಿಸಬೇಕು, ಮತ್ತು ಆ ವ್ಯತ್ಯಾಸವು ಸಂಚಾರ ಯಾವ ಮಾರ್ಗದಲ್ಲಿ ಹೋಯಿತು ಎಂಬುದನ್ನು ದೃಢೀಕರಿಸುತ್ತದೆ.
ಎರಡೂ ಕ್ಲೈಂಟ್ಗಳು ಒಂದೇ ರೀತಿ ವರ್ತಿಸಿದರೆ, ವಿಭಜಿತ ಟನೆಲ್ ನೀತಿ ವಿನ್ಯಾಸ ಹೇಳಿದಂತೆ ಮಾಡುತ್ತಿಲ್ಲ. ಹೆಚ್ಚಿನ ಅನುವಾದ ನಿಯಮಗಳನ್ನು ಸೇರಿಸುವ ಮೊದಲು ಅದನ್ನು ಸರಿಪಡಿಸಿ, ಏಕೆಂದರೆ ಬಳಸದ ಮಾರ್ಗಕ್ಕೆ ಬರೆದ ನಿಯಮವು ನಿಜವಾದ ಸಮಸ್ಯೆಯನ್ನು ಮುಚ್ಚಿಡುತ್ತದೆ.