SoftEther SecureNAT: DHCP ಮತ್ತು NAT ಎರಡು ಪ್ರತ್ಯೇಕ ನಿರ್ಣಯಗಳು

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

ಒಂದು ಚೆಕ್ಬಾಕ್ಸ್ನ ಹಿಂದೆ ಎರಡು ಸೇವೆಗಳು

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

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

ನಿರ್ಣಯ 1: ವಿಳಾಸವನ್ನು ಯಾರು ನೀಡುತ್ತಾರೆ

ವರ್ಚುವಲ್ DHCP ಆನ್ ಆಗಿದ್ದರೆ, ಕ್ಲೈಂಟ್ಗಳು ನೀವು ಕಾನ್ಫಿಗರ್ ಮಾಡಿದ ಪೂಲ್ನಲ್ಲಿ ಲೀಜ್ ಪಡೆಯಬೇಕು, ಗೇಟ್ವೇ ಆಗಿ ವರ್ಚುವಲ್ ಹೋಸ್ಟ್ ಇಂಟರ್ಫೇಸ್ ಮತ್ತು ರಿಸಾಲ್ವರ್ ಆಗಿ ನೀವು ನೀಡಿದ್ದು. ಕ್ಲೈಂಟ್ನ ಸ್ಟೇಟಸ್ ಪಠ್ಯವಲ್ಲ, ಲೀಜ್ ಪರಿಶೀಲಿಸಿ, ಏಕೆಂದರೆ «ಸಂಪರ್ಕಗೊಂಡಿದೆ» ಟನೆಲ್ ಅನ್ನು ವಿವರಿಸುತ್ತದೆ, ವಿಳಾಸ ಹಂಚಿಕೆಯನ್ನಲ್ಲ:

vpncmd localhost /SERVER /CMD SecureNatStatusGet
vpncmd localhost /SERVER /CMD DhcpGet
ip -4 addr show
ip route

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

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

ನಿರ್ಣಯ 2: ವರ್ಚುವಲ್ ಗೇಟ್ವೇಯ ಆಚೆ ಯಾರು ಕಳುಹಿಸುತ್ತಾರೆ

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

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

vpncmd localhost /SERVER /CMD NatGet
vpncmd localhost /SERVER /CMD NatTable
dig +short example.com
ip route get 203.0.113.10

ಹೆಸರು ವಿಭೇದನ ಕೆಲಸ ಮಾಡಿ ಸಾರ್ವಜನಿಕ ವಿಳಾಸಕ್ಕೆ ಸಂಪರ್ಕಗಳು ವಿಫಲವಾದರೆ, ನೀವು DHCPನಲ್ಲಿ ಅಲ್ಲ, ಫಾರ್ವರ್ಡಿಂಗ್ ಸರಪಳಿಯಲ್ಲಿದ್ದೀರಿ. ಎರಡೂ ವಿಫಲವಾದರೆ, ಮೊದಲು ರಿಸಾಲ್ವರ್ ಪರಿಶೀಲಿಸಿ, ಏಕೆಂದರೆ ತಲುಪಲಾಗದ ಒಳಗಿನ ವಿಳಾಸವಾಗಿ ಕಳುಹಿಸಿದ ರಿಸಾಲ್ವರ್ ಕೆಲಸ ಮಾಡುವ ಮಾರ್ಗವನ್ನೂ ಸಂಪೂರ್ಣ ಮುರಿದಂತೆ ತೋರಿಸುತ್ತದೆ.

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

ಹೋಸ್ಟ್ನ ಸ್ವಂತ ಮಾರ್ಗ ಮೂರನೇ ವಿಷಯ

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

SecureNAT ಸರ್ವರ್ಗೆ ಜೋಡಿಸಿದ ಪ್ರತಿ ನೆಟ್ವರ್ಕ್ ತಲುಪುವ ಅಧಿಕಾರವೂ ಅಲ್ಲ. ಅದು ತನ್ನನ್ನು ತಲುಪುವ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಅನುವಾದಿಸಿ ಫಾರ್ವರ್ಡ್ ಮಾಡುತ್ತದೆ; ಹೋಸ್ಟ್ ಯಾವುದನ್ನು ತಲುಪಬಹುದು ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುವುದು ಇನ್ನೂ ಹೋಸ್ಟ್ನ ಫೈರವಾಲ್ ಮತ್ತು ರೂಟಿಂಗ್ನ ಕೆಲಸ, ಮತ್ತು ಪ್ರವೇಶ ನೀಡಲು ಟನೆಲ್ ಅನ್ನು ಅವಲಂಬಿಸುವ ವಿನ್ಯಾಸವು ಅತಿಯಾಗಿ ನೀಡುವುದಕ್ಕಿಂತ ಒಂದು ಕೆಟ್ಟ ನಿಯಮ ದೂರದಲ್ಲಿದೆ.

ವಿಳಾಸ ಕುಟುಂಬಗಳಿಗೆ ತಮ್ಮದೇ ಪರಿಶೀಲನೆ ಬೇಕು. ಕೆಲಸ ಮಾಡುವ IPv4 DHCP ಉದಾಹರಣೆ ನಿಮ್ಮ ಬಿಲ್ಡ್ನಲ್ಲಿ ಪ್ರತಿ IPv6 ಸಾಮರ್ಥ್ಯವೂ ಇದೆ ಎಂದು ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ದ್ವಂದ್ವ ಸ್ಟ್ಯಾಕ್ ವರ್ತನೆಯ ಭರವಸೆ ನೀಡುವ ಮೊದಲು ನೀವು ನಿಜವಾಗಿ ಚಲಾಯಿಸುವ ಆವೃತ್ತಿಯ ಕೈಪಿಡಿ ಓದಿ. ಕೈಪಿಡಿಯ SecureNAT ವಿಭಾಗ ಪ್ರಸ್ತುತ ಬಿಡುಗಡೆಗೆ ವರ್ಚುವಲ್ NAT ಮತ್ತು DHCP ಕಾರ್ಯಗಳನ್ನು ಒಳಗೊಂಡಿದೆ.

ಪ್ರತಿ ನಿರ್ಣಯವನ್ನು ಅದರದೇ ಪರೀಕ್ಷೆಯಿಂದ ಪರಿಶೀಲಿಸಿ

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

ನಂತರ ವಿಭಜನೆಯನ್ನು ವಿನ್ಯಾಸ ಟಿಪ್ಪಣಿಯಲ್ಲಿ ದಾಖಲಿಸಿ: ಯಾವ ಘಟಕ ವಿಳಾಸ ನೀಡುತ್ತದೆ, ಯಾವ ಘಟಕ ಫಾರ್ವರ್ಡ್ ಮಾಡುತ್ತದೆ, ಮತ್ತು ಟ್ರಾಫಿಕ್ ಯಾವ ಹೋಸ್ಟ್ ಇಂಟರ್ಫೇಸ್ನಿಂದ ಹೊರಹೋಗುತ್ತದೆ. ಮರುಪ್ರಾರಂಭ ವರ್ತನೆಯನ್ನು ಬದಲಿಸಿದಾಗ, ಆ ಟಿಪ್ಪಣಿ ಮೂರರಲ್ಲಿ ಯಾವುದನ್ನು ಪರಿಶೀಲಿಸಬೇಕೆಂದು ಹೇಳುತ್ತದೆ, ಎಲ್ಲವನ್ನೂ ಮರುಪ್ರಾರಂಭಿಸಿ ಲಕ್ಷಣ ಸರಿಯುತ್ತದೆಂದು ನಿರೀಕ್ಷಿಸುವ ಬದಲು.

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