OpenVPN ಗೆ ಸಂಪರ್ಕಗೊಂಡಿದ್ದೀರಿ ಆದರೆ ping ಅಥವಾ SMB ಹಂಚಿಕೆ ಇಲ್ಲವೇ? ಮೂರು ದ್ವಾರಗಳನ್ನು ಪರಿಶೀಲಿಸಿ

ಟನೆಲ್ ಮೇಲೆ ಬರುತ್ತದೆ, ಕ್ಲೈಂಟ್ ವಿಳಾಸ ಪಡೆಯುತ್ತದೆ, ಆದರೆ ದೂರದ LAN ನಲ್ಲಿ ಯಾವುದೂ ಉತ್ತರಿಸುವುದಿಲ್ಲ. ping ವಿಫಲವಾಗುತ್ತದೆ, ಹಂಚಿಕೆ ತೆರೆಯುವುದಿಲ್ಲ, ಮತ್ತು VPN ಲಾಗ್ ಸ್ವಚ್ಛವಾಗಿ ಕಾಣುತ್ತದೆ ಏಕೆಂದರೆ ಅದರ ದೃಷ್ಟಿಯಿಂದ ಸೆಷನ್ ಆರೋಗ್ಯಕರವಾಗಿದೆ. ಆ ಸೆಷನ್ ಮತ್ತು ಸರ್ವರ್ನಲ್ಲಿನ ಫೈಲ್ ನಡುವೆ ಮೂರು ಸ್ವತಂತ್ರ ದ್ವಾರಗಳಿವೆ: ಫಾರ್ವರ್ಡಿಂಗ್ ನೀತಿ, ಸೇವೆಗೆ ಬೇಕಾದ ಪೋರ್ಟ್ ಗಳು, ಮತ್ತು ವಿಳಾಸದ ಬದಲು ನೀವು ಟೈಪ್ ಮಾಡಿದ ಹೆಸರು.

ಪ್ರತಿ ದ್ವಾರವೂ ಬೇರೆ ಲಕ್ಷಣದೊಂದಿಗೆ ವಿಫಲವಾಗುತ್ತದೆ, ಮತ್ತು ಮೊದಲನೆಯದು ಮಾತ್ರ VPN ಸರ್ವರ್ನಲ್ಲಿದೆ.

ಫಾರ್ವರ್ಡಿಂಗ್ ಎಂಬುದು FORWARD ಸರಣಿಯ ಮೇಲಿನ ನೀತಿ

OpenVPN ಕೇಳುಗರ ಸ್ವೀಕೃತಿ INPUT ನಲ್ಲಿ ನಡೆಯುತ್ತದೆ, ಆದ್ದರಿಂದ LAN ಕಡೆಗೆ ಹೋಗುವ ಪ್ರತಿ ಪ್ಯಾಕೆಟ್ ಬಿಸಾಡಲ್ಪಟ್ಟರೂ ಟನೆಲ್ ಸಂಪರ್ಕಗೊಳ್ಳಬಹುದು. tun0 ನಿಂದ ಬಂದು LAN ಇಂಟರ್ಫೇಸ್ ಮೂಲಕ ಹೊರಹೋಗುವ ಟ್ರಾಫಿಕ್ FORWARD ಮೂಲಕ ಹಾದುಹೋಗುತ್ತದೆ, ಮತ್ತು ಅಲ್ಲಿ ಡೀಫಾಲ್ಟ್ DROP ನೀತಿ ಇರುವ ಹೋಸ್ಟ್ ಅದನ್ನು ಮೌನವಾಗಿ ಬಿಸಾಡುತ್ತದೆ. ಬೇರೆ ಯಾವುದನ್ನೂ ಮುಟ್ಟುವ ಮೊದಲು sysctl ಮತ್ತು ಸರಣಿ ಎರಡನ್ನೂ ಪರಿಶೀಲಿಸಿ: sysctl net.ipv4.ip_forward ಮತ್ತು iptables -L FORWARD -v -n.

ನೀವು ಉದ್ದೇಶಿಸಿದ ದಿಕ್ಕು ಮತ್ತು ಅದಕ್ಕೆ ಸೇರಿದ ಪ್ರತಿಕ್ರಿಯೆಗಳನ್ನು ಅನುಮತಿಸಿ, ಉದಾಹರಣೆಗೆ ಟನೆಲ್ ಇಂಟರ್ಫೇಸ್ನಿಂದ LAN ಇಂಟರ್ಫೇಸ್ಗೆ accept ನಿಯಮ ಮತ್ತು established ಹಾಗೂ related ಟ್ರಾಫಿಕ್ಗೆ stateful ನಿಯಮ. LAN ಬೇರೆ ರೌಟರ್ನ ಹಿಂದೆ ಇದ್ದರೆ, ಆ ರೌಟರ್ಗೆ ಕ್ಲೈಂಟ್ ಪೂಲ್ಗೆ ಮರಳುವ ಮಾರ್ಗ ಅಥವಾ VPN ಸರ್ವರ್ನಲ್ಲಿ source NAT ಬೇಕು. ಹೆಚ್ಚಿನ ನಿಯಮಗಳನ್ನು ಸೇರಿಸುವ ಮೊದಲು ಒಂದು ping ನಿಂದ ಆ ಮಾರ್ಗವನ್ನು ದೃಢೀಕರಿಸಿ, ಏಕೆಂದರೆ ತಲುಪಲು ಸಾಧ್ಯವಿಲ್ಲದ ನಿಯಮ ಎಂದಿಗೂ ಕೌಂಟರ್ನಲ್ಲಿ ಕಾಣಿಸುವುದಿಲ್ಲ.

SMB ಗೆ ಒಂದಕ್ಕಿಂತ ಹೆಚ್ಚು ಪೋರ್ಟ್ ಬೇಕು

ಫೈಲ್ ಹಂಚಿಕೆ ಒಂದೇ TCP 445 ಸಂಭಾಷಣೆ ಅಲ್ಲ. ಅನ್ವೇಷಣೆ UDP 137 ಮತ್ತು 138 ಬಳಸುತ್ತದೆ, ಹಳೆಯ NetBIOS ಸೆಷನ್ಗಳು TCP 139 ಬಳಸುತ್ತವೆ, ಮತ್ತು ಆಧುನಿಕ SMB ಸೆಷನ್ಗಳು TCP 445 ಬಳಸುತ್ತವೆ. ಕೇವಲ 445 ತೆರೆಯುವ ನಿಯಮವು ಮ್ಯಾಪ್ ಮಾಡಿದ ಡ್ರೈವ್ ಕೆಲಸ ಮಾಡಿ ನೆಟ್ವರ್ಕ್ ಬ್ರೌಸಿಂಗ್ ಮಾಡದಿರುವ, ಅಥವಾ ವಿರುದ್ಧವಾದ ಕಿರಿಕಿರಿಯ ಸ್ಥಿತಿಯನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ.

ಟನೆಲ್ ಮೂಲಕ ದೊಡ್ಡ ವರ್ಗಾವಣೆಗಳು ಸಹ ಮುರಿದ ಹಂಚಿಕೆಯಂತೆ ಕಾಣುವ MSS ಸಮಸ್ಯೆಗಳನ್ನು ಎದುರಿಸುತ್ತವೆ. LAN ನ ಪೂರ್ಣ ಸೆಗ್ಮೆಂಟ್ ಗಾತ್ರವನ್ನು ಘೋಷಿಸುವ SYN ಟನೆಲ್ನ ಚಿಕ್ಕ MTU ಯಿಂದ ಬಿಸಾಡಲ್ಪಡುತ್ತದೆ, ಮತ್ತು ಕೈಹಿಡಿತದ ನಂತರ ಸಂಪರ್ಕ ನೇತಾಡುತ್ತದೆ. ಫಾರ್ವರ್ಡಿಂಗ್ ಮಾರ್ಗದಲ್ಲಿ MSS ಕ್ಲ್ಯಾಂಪ್ ಮಾಡುವುದು, iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu, ಆ ರೀತಿಯ ನಿಲುಗಡೆಯನ್ನು ತೆಗೆದುಹಾಕುತ್ತದೆ. ಡೈರೆಕ್ಟರಿ ಪಟ್ಟಿಯ ಬದಲು ಕೆಲವು ಮೆಗಾಬೈಟ್ ನಕಲಿನಿಂದ ಪರಿಶೀಲಿಸಿ, ಏಕೆಂದರೆ ದೊಡ್ಡ ವರ್ಗಾವಣೆಗಳು ಹಾದುಹೋಗದಿದ್ದರೂ ಸಣ್ಣ ಪ್ರತಿಕ್ರಿಯೆಗಳು ಹಾದುಹೋಗುತ್ತವೆ.

ಟನೆಲ್ ಅಡಾಪ್ಟರ್ ಹೊಸ ನೆಟ್ವರ್ಕ್ ಪ್ರೊಫೈಲ್ ಆಗಿ ಬರುತ್ತದೆ

Windows ಪ್ರತಿ ಅಡಾಪ್ಟರ್ ಅನ್ನು ನೆಟ್ವರ್ಕ್ ಪ್ರೊಫೈಲ್ಗೆ ವರ್ಗೀಕರಿಸುತ್ತದೆ, ಮತ್ತು ಹೊಸ ಟನೆಲ್ ಅಡಾಪ್ಟರ್ ಸಾಮಾನ್ಯವಾಗಿ Public ನಲ್ಲಿ ಬೀಳುತ್ತದೆ, ಅಲ್ಲಿ ಫೈಲ್ ಮತ್ತು ಪ್ರಿಂಟರ್ ಹಂಚಿಕೆ ನಿಯಮಗಳು ಬ್ಲಾಕ್ ಆಗಿರುತ್ತವೆ. ಅದು ಫೈಲ್ ಸರ್ವರ್ನಲ್ಲಿನ ಹೋಸ್ಟ್ ಫೈರ್‌ವಾಲ್‌ನ ನಿರ್ಧಾರ, VPN ಸರ್ವರ್ನಲ್ಲಿನ ರೌಟಿಂಗ್ ಸಮಸ್ಯೆ ಅಲ್ಲ. ನೀತಿ ಅನುಮತಿಸುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿದ ನಂತರ ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ವರ್ಗ ಬದಲಿಸಿ Set-NetConnectionProfile -InterfaceAlias "Ethernet 3" -NetworkCategory Private ಬಳಸಿ, ಏಕೆಂದರೆ ವರ್ಗವು ಯಾವ ಒಳಬರುವ ನಿಯಮಗಳು ಅನ್ವಯವಾಗುತ್ತವೆ ಎಂಬುದನ್ನೂ ಬದಲಿಸುತ್ತದೆ.

ಅದೇ ಪ್ರೊಫೈಲ್ TCP 445 ಯಶಸ್ವಿಯಾದರೂ ping ವಿಫಲವಾಗುವುದನ್ನು ವಿವರಿಸುತ್ತದೆ: Public ನಲ್ಲಿ ಎಕೋ ವಿನಂತಿಗಳು ಡೀಫಾಲ್ಟ್ ಆಗಿ ಬಿಸಾಡಲ್ಪಡುತ್ತವೆ.

ಹೆಸರುಗಳು ರೌಟ್ ಮಾಡಿದ ಟನೆಲ್ ಅನ್ನು ತಾವಾಗಿಯೇ ದಾಟುವುದಿಲ್ಲ

NetBIOS ಹೆಸರು ವಿಭಜನೆ ಮತ್ತು ಸ್ಥಳೀಯ ಅನ್ವೇಷಣೆ ರೌಟ್ ಮಾಡಿದ ಟನೆಲ್ ಒಯ್ಯದ ಪ್ರಸಾರಗಳನ್ನು ಅವಲಂಬಿಸಿವೆ. ಆದ್ದರಿಂದ ಸರ್ವರ್ನ ಸಣ್ಣ ಹೆಸರನ್ನು ಟೈಪ್ ಮಾಡುವುದು ವಿಫಲವಾಗುತ್ತದೆ ಆದರೆ ಅದರ ವಿಳಾಸ ಕೆಲಸ ಮಾಡುತ್ತದೆ, ಮತ್ತು ಹುಡುಕಾಟ ಮಾತ್ರ ಕೆಟ್ಟಾಗಿದ್ದರೂ ಹಂಚಿಕೆ ಮುರಿದಂತೆ ಕಾಣುತ್ತದೆ. ಟನೆಲ್ ನೀಡುವ ಪರಿಹಾರಕದಲ್ಲಿ ಸರ್ವರ್ಗೆ DNS ದಾಖಲೆ ಸೇರಿಸಿ, ಅಥವಾ ಶಾರ್ಟ್ಕಟ್ನಲ್ಲಿ ವಿಳಾಸ ಬಳಸಿ.

ನಿಯೋಜನೆ ಇನ್ನೂ WINS ಅನ್ನು ಅವಲಂಬಿಸಿದ್ದರೆ, ಪ್ರಸಾರ ಟ್ರಾಫಿಕ್ ಬರುತ್ತದೆ ಎಂದು ನಿರೀಕ್ಷಿಸುವ ಬದಲು ಕ್ಲೈಂಟ್ನಲ್ಲಿ ಅದನ್ನು ಸಂರಚಿಸಿ. ಮೊದಲು ವಿಳಾಸದಿಂದ ಪರೀಕ್ಷಿಸಿ, ಹೆಸರಿನ ವೈಫಲ್ಯವನ್ನು ಫೈರ್‌ವಾಲ್ ವೈಫಲ್ಯವೆಂದು ತಪ್ಪಾಗಿ ಭಾವಿಸದಂತೆ.

ಒಂದು ಸಮಯಕ್ಕೆ ಒಂದು ಪದರವನ್ನು ಪರೀಕ್ಷಿಸಿ ಮತ್ತು ಮೊದಲ ವೈಫಲ್ಯವನ್ನು ಓದಿ

ಮೇಲಕ್ಕೆ ಸಾಗಿ: ಟನೆಲ್ ಗೇಟ್‌ವೇಗೆ ping ಮಾಡಿ, ವಿಳಾಸದಿಂದ LAN ಹೋಸ್ಟ್‌ಗೆ ping ಮಾಡಿ, ನಂತರ Test-NetConnection -ComputerName 10.8.0.5 -Port 445 ನಿಂದ ಸೇವೆಯ ಪೋರ್ಟ್ ತೆರೆಯಿರಿ, ಮತ್ತು ನಂತರವೇ ಹಂಚಿಕೆಗೆ ದೃಢೀಕರಣ ಮಾಡಿ. ಮೊದಲು ವಿಫಲವಾಗುವ ಹಂತವೇ ಸರಿಪಡಿಸಬೇಕಾದ ಪದರ, ಮತ್ತು ಅದು ದಾಟುವವರೆಗೆ ಪ್ರತಿ ಮುಂದಿನ ಹಂತವೂ ಗದ್ದಲ. ಪೋರ್ಟ್ ಮುಚ್ಚಿದ್ದರೂ ping ಉತ್ತರಿಸಿದರೆ ಅದು ಫೈಲ್ ಸರ್ವರ್ನ ಸ್ವಂತ ಫೈರ್‌ವಾಲ್ ಅನ್ನು ಸೂಚಿಸುತ್ತದೆ, ಆದರೆ ಮೌನ ping ಗಳ ಹೊರತಾಗಿಯೂ ಪೋರ್ಟ್ ತೆರೆದರೆ ಅದು ICMP ಶೋಧನೆಯನ್ನು ಸೂಚಿಸುತ್ತದೆ. ಏನನ್ನಾದರೂ ಬದಲಿಸುವ ಮೊದಲು ಮೊದಲ ವಿಫಲ ಹಂತವನ್ನು ಬರೆದಿಡಿ, ಏಕೆಂದರೆ ಎರಡನೆಯ ಬದಲಾವಣೆ ಮೊದಲನೆಯ ಫಲಿತಾಂಶವನ್ನು ಮರೆಮಾಡುತ್ತದೆ.

VPN ಸರ್ವರ್ LAN ನ ರೌಟರ್ ಅಲ್ಲದಿದ್ದರೆ, ಆ ರೌಟರ್ನಲ್ಲಿ ಹಿಂತಿರುಗುವ ಮಾರ್ಗವನ್ನು ದೃಢೀಕರಿಸಿ ಸರ್ವರ್ಗೆ ಹೆಚ್ಚಿನ ನಿಯಮಗಳನ್ನು ಸೇರಿಸುವ ಮೊದಲು. ಅದಿಲ್ಲದೆ ವಿನಂತಿಗಳು ಹೋಸ್ಟ್ ತಲುಪುತ್ತವೆ ಮತ್ತು ಪ್ರತಿಕ್ರಿಯೆಗಳು ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗದಲ್ಲಿ ಇಂಟರ್ನೆಟ್ ಕಡೆಗೆ ಹೊರಡುತ್ತವೆ, ಇದು ಕ್ಲೈಂಟ್ ಬದಿಯಿಂದ ನಿಖರವಾಗಿ ಫೈರ್‌ವಾಲ್ ಬಿಸಾಡುವಿಕೆಯಂತೆ ಕಾಣುತ್ತದೆ.

ನಿಮ್ಮ ಟಿಪ್ಪಣಿಗಳಲ್ಲಿ ಹಂಚಿಕೆ ಖಾತೆಯನ್ನು VPN ಲಾಗಿನ್ನಿಂದ ಪ್ರತ್ಯೇಕವಾಗಿಡಿ, ಏಕೆಂದರೆ ಯಶಸ್ವಿ ಟನೆಲ್ ಫೈಲ್ ಅನುಮತಿಗಳ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ. ಕಾಣೆಯಾದ ನಿಯಮವನ್ನು ತಪ್ಪಿಸಲು SMB ಅನ್ನು ಇಂಟರ್ನೆಟ್ಗೆ ಒಡ್ಡುವುದು ಪರಿಹಾರವಲ್ಲ.