NAT VPN ಸರ್ವರ್ನಲ್ಲಿ ಅಥವಾ ರೂಟರ್ನಲ್ಲಿ? ಎರಡೂ ಕೆಲಸ ಮಾಡಬಹುದು

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

ಪುರಾಣ: ಕ್ಲೈಂಟ್ ಮಾರ್ಗವೇ ನಿರ್ಗಮನವನ್ನು ನಿರ್ಮಿಸುತ್ತದೆ

ಒತ್ತಾಯದ ಸುರಂಗೀಕರಣವು ಕ್ಲೈಂಟ್-ಬದಿಯ ನೀತಿ: ಸಂಚಾರವು ಭೌತಿಕ ಅಡಾಪ್ಟರ್ಗೆ ಬದಲಾಗಿ VPN ಅಡಾಪ್ಟರ್ಗೆ ಹೋಗುತ್ತದೆ ಎಂದು ಅದು ನಿರ್ಧರಿಸುತ್ತದೆ. Microsoft ನ VPN ರೂಟಿಂಗ್ ದಾಖಲೆ ಆ ವಿಭಜನೆ ಮತ್ತು ಒತ್ತಾಯದ ವರ್ತನೆಯನ್ನು ವಿವರಿಸುತ್ತದೆ, ಮತ್ತು ಅದು ಕ್ಲೈಂಟ್ನ ಮಾರ್ಗ ಕೋಷ್ಟಕದ ಬಗ್ಗೆ ಹೇಳಿಕೆ, ಸರ್ವರ್ನ ಫಾರ್ವರ್ಡಿಂಗ್ ನಿಯಮಗಳ ಬಗ್ಗೆ ಅಲ್ಲ. ಕ್ಲೈಂಟ್ನ ದೃಷ್ಟಿಯಿಂದ ಸುರಂಗವು ಇಂಟರ್ನೆಟ್ ವಾಸಿಸುವ ಸ್ಥಳ; ಗೇಟ್ವೇನ ದೃಷ್ಟಿಯಿಂದ ಪ್ಯಾಕೆಟ್ ಮೇಲೆ ಯಾರೂ ಎಂದೂ ಕೇಳದ ವಿಳಾಸದಿಂದ ಬಂದಿದೆ. ಯಾವ ಪಕ್ಷವೂ ಒಂಟಿಯಾಗಿ ತಪ್ಪಾಗಿ ಕಾನ್ಫಿಗರ್ ಆಗಿಲ್ಲ, ಮತ್ತು ಆದ್ದರಿಂದ ಲ್ಯಾಪ್ಟಾಪ್ ಬಳಿಯ ವ್ಯಕ್ತಿಗೆ ವೈಫಲ್ಯವು ಮುರಿದ ಸರ್ವರ್ನಂತೆ ಕಾಣುತ್ತದೆ.

ಈ ಅಸಾಮರಸ್ಯವೇ ಈ ಲೇಖನದ ಉಳಿದ ಭಾಗವು ಪರಿಹರಿಸುವ ಸಂಪೂರ್ಣ ಸಮಸ್ಯೆ. ಯಾವುದೋ ಒಂದು ಕ್ಲೈಂಟ್ನ ಖಾಸಗಿ ವಿಳಾಸವನ್ನು ಹಿಂತಿರುಗಿಸಬಹುದಾದಂತೆ ಮಾಡಬೇಕು, ಮತ್ತು ಆಯ್ಕೆ ಎಲ್ಲಿದೆ ಎಂಬುದು.

ಮೊದಲು ಉತ್ತರದ ಮಾರ್ಗವನ್ನು ಬಿಡಿಸಿ

ಯಾವುದೇ ಸೆಟ್ಟಿಂಗ್ ಅನ್ನು ಮುಟ್ಟುವ ಮೊದಲು ಮಾರ್ಗವನ್ನು ನಿಜವಾದ ವಿಳಾಸಗಳೊಂದಿಗೆ ಬರೆಯಿರಿ, ಮತ್ತು ಅದರ ಮೇಲೆ ಎರಡು ಸಂಭಾವ್ಯ ಅನುವಾದ ಬಿಂದುಗಳನ್ನು ಗುರುತಿಸಿ. ಈ ಪ್ರಯೋಗಾಲಯವು 10.70.0.0/24 ನ VPN ಪೂಲ್ ಬಳಸುತ್ತದೆ, ಅದರಲ್ಲಿ ಒಂದು ಕ್ಲೈಂಟ್ 10.70.0.37 ನಲ್ಲಿ, ಸರ್ವರ್ನ LAN ವಿಳಾಸ 172.16.40.10, ರೂಟರ್ 172.16.40.1 ನಲ್ಲಿ ಮತ್ತು ಸಾರ್ವಜನಿಕ ನಿರ್ಗಮನ 203.0.113.40 ನಲ್ಲಿ ಇದೆ.

client 10.70.0.37 -- tunnel --> RRAS 172.16.40.10 -- LAN --> router 172.16.40.1 --> 203.0.113.40
                                  (translate here?)                             (or here?)

ಈಗಾಗಲೇ ಇಂಟರ್ನೆಟ್ ಬ್ರೌಸ್ ಮಾಡುತ್ತಿರುವ ಸರ್ವರ್ ತನ್ನದೇ ಮಾರ್ಗವನ್ನು ಮಾತ್ರ ಸಾಬೀತುಪಡಿಸುತ್ತದೆ. ಕ್ಲೈಂಟ್ನ ಪರವಾಗಿ ಫಾರ್ವರ್ಡ್ ಆದ ಪ್ಯಾಕೆಟ್ ಬೇರೆ ನಿರ್ಧಾರ, ಅದೇ ಯಂತ್ರದಲ್ಲಿನ ಫಾರ್ವರ್ಡಿಂಗ್ ನೀತಿಯು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ, ಮತ್ತು ಸಾಮಾನ್ಯವಾಗಿ ಅದೇ ಕಾಣೆಯಾಗಿರುತ್ತದೆ. ರೇಖಾಚಿತ್ರದಲ್ಲಿ ಮೂರು ನಿರ್ಧಾರ ಬಿಂದುಗಳನ್ನು ಗುರುತಿಸುವುದು ಸಂಭಾಷಣೆಯನ್ನು ಒಂದು ಸಮಯಕ್ಕೆ ಅವುಗಳಲ್ಲಿ ಒಂದರ ಮೇಲೆ ಇಡುತ್ತದೆ.

ಆಯ್ಕೆ A: VPN ಸರ್ವರ್ನಲ್ಲಿ ಅನುವಾದ

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

Get-RemoteAccess | Select-Object VpnS2SInterface, RoutingDomain
Get-NetNat | Select-Object Name, InternalIPInterfaceAddressPrefix

NAT ಇದೆ ಎಂದು ಊಹಿಸುವ ಬದಲು ಸರ್ವರ್ನಲ್ಲಿ ಈಗಾಗಲೇ ಏನಿದೆ ಎಂದು ನೋಡಲು ಈ ಓದುಗಳನ್ನು ಬಳಸಿ. ಬ್ಲಾಗ್ನಿಂದ ನಕಲಿಸಿದ Linux masquerade ನಿಯಮ Windows ಸಂರಚನೆ ಅಲ್ಲ, ಮತ್ತು VPN ಶ್ರೋತೃವಿಗಾಗಿ ಹೋಸ್ಟ್ ಫೈರ್ವಾಲ್ನಲ್ಲಿನ ಅನುಮತಿ ಕ್ಲೈಂಟ್ನ ವಿನಂತಿಯನ್ನು ಮುಂದೆ ಫಾರ್ವರ್ಡ್ ಮಾಡುವ ಅನುಮತಿಯಂತೆಯೇ ಅದೇ ನೀತಿ ಅಲ್ಲ. ಸರ್ವರ್ನ ಫಾರ್ವರ್ಡಿಂಗ್ ಪಾತ್ರವನ್ನು ಅದರದೇ ನಿರ್ವಹಣಾ ಇಂಟರ್ಫೇಸ್ನಿಂದ ದೃಢೀಕರಿಸಿ, ನಂತರ ಅನುವಾದವನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ನೋಡಿ, ಏಕೆಂದರೆ ಎರಡನ್ನೂ ಸಾಮಾನ್ಯವಾಗಿ ನಿಯೋಜನೆಯ ಬೇರೆ ಬೇರೆ ಭಾಗಗಳು ಸಕ್ರಿಯಗೊಳಿಸುತ್ತವೆ.

ಆಯ್ಕೆ B: ಪೂಲ್ ಅನ್ನು ರೂಟರ್ಗೆ ಸಾಗಿಸುವುದು

ಎರಡನೇ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ಸರ್ವರ್ ಕ್ಲೈಂಟ್ನ ನಿಜವಾದ ಮೂಲ ವಿಳಾಸವನ್ನು ಫಾರ್ವರ್ಡ್ ಮಾಡುತ್ತದೆ, ಮತ್ತು ರೂಟರ್ ಅದನ್ನು ಅನುವಾದಿಸುತ್ತದೆ. ಇದು ಕ್ಲೈಂಟ್ ಪೂಲ್ ಅನ್ನು ಅಂಚಿನಲ್ಲಿ ಗೋಚರವಾಗಿ ಇಡುತ್ತದೆ, ಇದು ರೂಟರ್ ಸಂಚಾರ ನೀತಿ, ಲಾಗಿಂಗ್ ಅಥವಾ ಪರಿಶೀಲನೆಯ ಸ್ಥಳವಾಗಿದ್ದರೆ ಸಹಾಯ ಮಾಡುತ್ತದೆ. ಇದರರ್ಥ ರೂಟರ್ಗೆ 10.70.0.0/24 ಗಾಗಿ 172.16.40.10 ಗೆ ತೋರಿಸುವ ಹಿಂತಿರುಗುವ ಮಾರ್ಗ ಬೇಕು, ಜೊತೆಗೆ ಆ ಪ್ರಿಫಿಕ್ಸ್ ಅನ್ನು ನಿಜವಾಗಿಯೂ ಒಳಗೊಂಡ ಇಂಟರ್ನೆಟ್ ನೀತಿಯೂ ಬೇಕು; LAN ಉಪಜಾಲಕ್ಕಾಗಿ ಬರೆದ ನಿಯಮವು ಪೂಲ್ಗೆ ಮೌನವಾಗಿ ವಿಸ್ತರಿಸುವುದಿಲ್ಲ.

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

DNS, IPv6 ಮತ್ತು ಸ್ವೀಕಾರವನ್ನು ಸ್ಪಷ್ಟಗೊಳಿಸಿ

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

IPv6 ಗೆ ವಿನ್ಯಾಸದಲ್ಲಿ ತನ್ನದೇ ಪ್ಯಾರಾಗ್ರಾಫ್ ಬೇಕು. ಕೆಲಸ ಮಾಡುವ IPv4 ಅನುವಾದವು IPv6 ಕ್ಲೈಂಟ್ಗಳಿಗೆ ಮಾರ್ಗ, ಮಾನ್ಯ ಸಾರ್ವಜನಿಕ ಮೂಲ ಅಥವಾ ಸುರಂಗ ಬಿದ್ದಾಗ ಅವನ್ನು ತಡೆಯುವ ನೀತಿ ಇದೆಯೇ ಎಂಬುದರ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ. ಅದನ್ನು ಹೇಳದೆ ಬಿಡುವುದು ಎಂದರೆ ಅರ್ಧದಷ್ಟು ಕ್ಲೈಂಟ್ಗಳು ಮೌನವಾಗಿ ಗೇಟ್ವೇ ಅನ್ನು ಬಳಸದೆ ಹೋಗುತ್ತಾರೆ ಮತ್ತು ಉಳಿದ ಅರ್ಧ ಕೆಲಸ ಮಾಡುತ್ತದೆ.

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