ಒಂದು NIC ಅಥವಾ ಎರಡು? VPN ಸರ್ವರ್ನ ಇಂಟರ್ಫೇಸ್ ಜೋಡಣೆ ನಿರ್ಧಾರ

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

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

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

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

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

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

ಸೇವೆ VPN ಹೋಸ್ಟ್ನಲ್ಲಿ ನಡೆಯುವಾಗ

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

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

ss -lntup | grep -E "5432|8080"
ip -brief addr show
ip route get 10.8.0.6 from 10.8.0.1

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

ಗಮ್ಯಸ್ಥಾನ LAN ನಲ್ಲಿದ್ದಾಗ

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

ಎರಡೂ ಉತ್ತರಗಳು ಕಾನೂನುಬದ್ಧ ಮತ್ತು ಅವು ಬೇರೆ ಬೇರೆ ರೀತಿಯಲ್ಲಿ ವಿಫಲವಾಗುತ್ತವೆ. ಹಿಂತಿರುಗುವ ರೂಟ್ ಮೂಲ ಕ್ಲೈಂಟ್ ವಿಳಾಸವನ್ನು ಗಮ್ಯಸ್ಥಾನಕ್ಕೆ ಗೋಚರವಾಗಿ ಇಡುತ್ತದೆ, ಅದು ಲಾಗ್ಗಳಿಗೆ ಒಳ್ಳೆಯದು ಮತ್ತು LAN ವಿಳಾಸಗಳನ್ನು ಊಹಿಸುವ ಫೈರ್ವಾಲ್ ನಿಯಮಗಳಿಗೆ ಕೆಟ್ಟದು. ಅನುವಾದ LAN ಅನ್ನು ಸರಳವಾಗಿ ಇಡುತ್ತದೆ ಮತ್ತು ಕ್ಲೈಂಟ್ನ ಗುರುತನ್ನು ಗಮ್ಯಸ್ಥಾನದಿಂದ ಮರೆಮಾಡುತ್ತದೆ.

sysctl net.ipv4.ip_forward
nft list ruleset | grep -A4 'chain forward'
ip route show table main | grep 10.8.0

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

alias ಎರಡನೇ ವಲಯವನ್ನು ಏಕೆ ಸೃಷ್ಟಿಸುವುದಿಲ್ಲ

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

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

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

ನೀವು ಅನುಮತಿಸುವ ಸಂಚಾರದ ವಿರುದ್ಧ ಜೋಡಣೆಯನ್ನು ಪರಿಶೀಲಿಸಿ

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

ನಂತರ ವಿನ್ಯಾಸ ದಾಖಲೆಯ ರೇಖಾಚಿತ್ರವಲ್ಲ, ನಿಜವಾದ ಇಂಟರ್ಫೇಸ್ಗಳು ಮತ್ತು ನಿಜವಾದ ಸೆರೆಹಿಡಿಯುವಿಕೆಯನ್ನು ಖಚಿತಪಡಿಸಿ. ಕೆಳಗಿನ ಆಜ್ಞೆಗಳು ಎರಡೂ ನೋಟಗಳನ್ನು ಮುದ್ರಿಸುತ್ತವೆ.

ip -brief addr
ip route
tcpdump -ni any udp port 51820 -c 5
tcpdump -ni tun0 -c 5

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