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

ವಿನ್ಯಾಸವನ್ನು ನಿರ್ಧರಿಸುವ ಮೂರು ಷರತ್ತುಗಳು

ಮೊದಲನೆಯದಾಗಿ, ನಿಮಗೆ ನೆಟ್ವರ್ಕ್ ಮಾಲೀಕರಿಂದ ನಿಖರವಾದ ಪೂರ್ವಪ್ರತ್ಯಯ ಮತ್ತು ಮಾಸ್ಕ್ ಬೇಕು. 10.x ನೆಟ್ವರ್ಕ್ ಪೂರ್ವಪ್ರತ್ಯಯವಲ್ಲ; 10.20.0.0/16 ಪೂರ್ವಪ್ರತ್ಯಯ. ಇದು ನಿಮ್ಮ ಮನೆಯ LAN, Docker ಸೇತುವೆ ಅಥವಾ ನೀವು ನಡೆಸುವ ಇನ್ನೊಂದು VPN ಜೊತೆ ಅತಿಕ್ರಮಿಸುವುದಿಲ್ಲ ಎಂದು ಖಚಿತಪಡಿಸಿ, ಏಕೆಂದರೆ ಅತಿಕ್ರಮಣ ಮಾರ್ಗವನ್ನು ಅಸ್ಪಷ್ಟಗೊಳಿಸುತ್ತದೆ ಮತ್ತು ಕರ್ನಲ್ ನೀವು ಉದ್ದೇಶಿಸದ ನಮೂದನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ.

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

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

WireGuard: AllowedIPs ಎಂಬುದೇ ಮಾರ್ಗ ಪಟ್ಟಿ

ಕ್ಲೈಂಟ್ನಲ್ಲಿ, AllowedIPs ಸುರಂಗಕ್ಕೆ ಪ್ರವೇಶಿಸಬಹುದಾದ ಗಮ್ಯಸ್ಥಾನಗಳನ್ನು ಪಟ್ಟಿ ಮಾಡುತ್ತದೆ, ಮತ್ತು wg-quick ಪ್ರತಿ ನಮೂದನ್ನು ಸಾಮಾನ್ಯ ಮಾರ್ಗವಾಗಿ ಪರಿವರ್ತಿಸುತ್ತದೆ. ಹಾಗಾಗಿ ಈ ಕೆಲಸದ ಕ್ಲೈಂಟ್ ಅರ್ಧ ಭಾಗ ಒಂದೇ ಸಾಲು.

[Peer]
PublicKey = ...
Endpoint = vpn.example.net:51820
AllowedIPs = 10.20.0.0/16

ಈಗ ಅದೇ ಕ್ಲೈಂಟ್ಗೆ ಸರ್ವರ್ನ ನಮೂದನ್ನು ಹೋಲಿಸಿ. ಅದು ಸರ್ವರ್ ಕ್ಲೈಂಟ್ಗೆ ಏನು ಕಳುಹಿಸುತ್ತದೆ ಎಂದು ವಿವರಿಸುತ್ತದೆ, ಅದು ಸಾಮಾನ್ಯವಾಗಿ ಕ್ಲೈಂಟ್ನ ಸುರಂಗ ವಿಳಾಸ, ಖಾಸಗಿ ಸಬ್ನೆಟ್ ಅಲ್ಲ.

[Peer]
PublicKey = ...
AllowedIPs = 10.99.0.2/32

ಈ ಎರಡನ್ನು ಅದಲುಬದಲು ಮಾಡುವುದೇ ನಾನು ಹೆಚ್ಚು ಕಾಣುವ ತಪ್ಪು. ಸರ್ವರ್ನ peer ವಿಭಾಗದ ಅಡಿಯಲ್ಲಿ 10.20.0.0/16 ಇಡುವುದು ಇಡೀ ಸಬ್ನೆಟ್ ಆ ಕ್ಲೈಂಟ್ನ ಹಿಂದೆ ಇದೆ ಎಂದು ಹೇಳುತ್ತದೆ, ಅದು ಅನುಮತಿ ಅಲ್ಲ, ಸೈಟ್ನಿಂದ ಸೈಟ್ಗೆ ಎಂಬ ಪ್ರತಿಪಾದನೆ. ಯಾವುದೇ peer ನ AllowedIPs ಗೆ ಹೊಂದದ ಪ್ಯಾಕೆಟ್ಗಳನ್ನು ಮೌನವಾಗಿ ಬಿಡಲಾಗುತ್ತದೆ, ಹಾಗಾಗಿ ತಪ್ಪು ನಮೂದು ನಿಖರವಾಗಿ ಫೈರ್ವಾಲ್ ಸಮಸ್ಯೆಯಂತೆ ಕಾಣುತ್ತದೆ.

ನೀವೇ ಮಾರ್ಗಗಳನ್ನು ನಿರ್ವಹಿಸಿದರೆ, [Interface] ಅಡಿಯಲ್ಲಿ Table = off ಹೊಂದಿಸಿ ಮತ್ತು ಬಯಸಿದ ಮಾರ್ಗ ಸೇರಿಸಿ. ಆಗ ಯಾವುದೂ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಸೇರುವುದಿಲ್ಲ, ಹಾಗಾಗಿ ಮಾರ್ಗ ಇಂಟರ್ಫೇಸ್ ಎತ್ತುವ ವಸ್ತುವಿನೊಳಗೆ ಇರಬೇಕು.

OpenVPN: ಮಾರ್ಗವನ್ನು ತಳ್ಳಿ, ನಂತರ ಅದು ತಲುಪಿದೆಯೇ ಎಂದು ಖಚಿತಪಡಿಸಿ

ಸಾಮಾನ್ಯ ಸರ್ವರ್ನಲ್ಲಿ ಬದಲಾವಣೆ ಸರ್ವರ್ ಸಂರಚನೆಯಲ್ಲಿ ಕ್ಲೈಂಟ್ ಪೂಲ್ನ ಪಕ್ಕದಲ್ಲಿ ಒಂದು ಸೂಚನೆ.

push "route 10.20.0.0 255.255.0.0"

ಕ್ಲೈಂಟ್ ಸಂಪರ್ಕಿಸಿದಾಗ ಅದನ್ನು ಸೇರಿಸುತ್ತದೆ. ವೈಫಲ್ಯ ಮಾದರಿ ಕಾಣಿಸುವುದು ಅದೇ ಪ್ರೊಫೈಲ್ redirect-gateway ಅನ್ನೂ ತಳ್ಳಿದಾಗ, ಅಥವಾ ಯಾರಾದರೂ ಈಗಾಗಲೇ route-nopull ಸೇರಿಸಿದಾಗ: ಮೊದಲನೆಯದು ಸೆಷನ್ ಅನ್ನು ಪೂರ್ಣ ಸುರಂಗವಾಗಿ ಮಾಡುತ್ತದೆ, ಎರಡನೆಯದು ನಿಮ್ಮದೂ ಸೇರಿದಂತೆ ತಳ್ಳಿದ ಎಲ್ಲಾ ಮಾರ್ಗಗಳನ್ನು ಬಿಸಾಡುತ್ತದೆ.

ಪೂರ್ಣ ಸುರಂಗ ಸರ್ವರ್ ಎದುರು ಸಂಕುಚಿತ ವರ್ತನೆ ಬೇಕಾದ ಕ್ಲೈಂಟ್ ತನಗೆ ಬೇಡವಾದ ಭಾಗಗಳನ್ನು ಮಾತ್ರ ನಿರ್ಲಕ್ಷಿಸಬೇಕು. OpenVPN 2.4 ಮತ್ತು ನಂತರದ್ದರಲ್ಲಿ, pull-filter ಸರಿಯಾಗಿ ಇದಕ್ಕಾಗಿಯೇ ಇದೆ.

pull-filter ignore "redirect-gateway"
route 10.20.0.0 255.255.0.0

ವಿಳಾಸ ಕುಟುಂಬಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಇರಿಸಿ: ತಳ್ಳಿದ IPv4 ಮಾರ್ಗ IPv6 ಗೆ ಪರಿಹರಿಸುವ ಆಂತರಿಕ ಸೇವೆಗೆ ಏನನ್ನೂ ಮಾಡುವುದಿಲ್ಲ, ಮತ್ತು ಆ ಸೇವೆ ಸುರಂಗದ ಮೂಲಕ ವಿಫಲವಾಗುತ್ತದೆ, ಉಳಿದೆಲ್ಲವೂ ಸರಿಯಾಗಿ ಕಾಣುತ್ತಿರುವಾಗ.

ಖಾಸಗಿ ಸಬ್ನೆಟ್ VPN ಸರ್ವರ್ನಲ್ಲಿ ಇಲ್ಲದೆ ಇನ್ನೊಂದು ಕ್ಲೈಂಟ್ನ ಹಿಂದೆ ಇದ್ದಾಗ, ಸರ್ವರ್ಗೆ ತಿಳಿಸಬೇಕು. client-config-dir ಮೂಲಕ ಪ್ರತಿ ಕ್ಲೈಂಟ್ಗೆ iroute 10.20.0.0 255.255.0.0 ಹೊಂದಿರುವ ಫೈಲ್ ಸೇರಿಸಿ, ಜೊತೆಗೆ ಹೊಂದುವ route ಸೇರಿಸಿ ಇತರ ಕ್ಲೈಂಟ್ಗಳು ದಾರಿ ಕಲಿಯಲು. iroute ಇಲ್ಲದೆ ಆ ಪೂರ್ವಪ್ರತ್ಯಯವನ್ನು ಅದೇ ಸುರಂಗದ ಮೂಲಕ ಕಳುಹಿಸಲು ಸರ್ವರ್ಗೆ ಕಾರಣವಿಲ್ಲ.

IPsec: ಸಂಚಾರ ಸೆಲೆಕ್ಟರ್ಗಳು ಒಪ್ಪಬೇಕು

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

leftsubnet=192.168.1.0/24
rightsubnet=10.20.0.0/16

ಗೇಟ್ವೇ ಎರಡೂ ಬದಿಯಲ್ಲಿ 0.0.0.0/0 ನೊಂದಿಗೆ ಸಂರಚಿಸಲಾಗಿದ್ದರೆ, IKEv2 ಸಂಕೋಚನ ಸಾಮಾನ್ಯವಾಗಿ ಚೈಲ್ಡ್ SA ಅನ್ನು ಎರಡು ಪ್ರಸ್ತಾವನೆಗಳ ಛೇದಕ್ಕೆ ಇಳಿಸುತ್ತದೆ, ಅದೇ ಬಯಸಿದ ಫಲಿತಾಂಶ. ಕೆಲವು ಗೇಟ್ವೇಗಳು ಬದಲಿಗೆ ತಮ್ಮ ಸಂರಚಿತ ಸೆಲೆಕ್ಟರ್ಗಳಿಗೆ ಹೊಂದದ ಪ್ರಸ್ತಾವನೆಯನ್ನು ತಿರಸ್ಕರಿಸುತ್ತವೆ, ಮತ್ತು ಲಾಗ್ ಆಗ ಮಾರ್ಗ ದೂರಿನ ಬದಲು ವಿಫಲ ಚೈಲ್ಡ್ SA ತೋರಿಸುತ್ತದೆ. ಹಾಗಾದಾಗ ಬದಲಾವಣೆ ಗೇಟ್ವೇಗೆ ಸೇರಿದ್ದು, ಏಕೆಂದರೆ ಕ್ಲೈಂಟ್ ಮಾರ್ಗ ಇನ್ನೊಂದು ಬದಿ ಒಪ್ಪದ ಸೆಲೆಕ್ಟರ್ಗೆ ಸುರಂಗವನ್ನು ಸೃಷ್ಟಿಸಲಾರದು.

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

Set-VpnConnection -Name Office -SplitTunneling $true
Add-VpnConnectionRoute -ConnectionName Office -DestinationPrefix 10.20.0.0/16

ಪೂರ್ವಪ್ರತ್ಯಯವನ್ನು ನೋಂದಾಯಿಸುವುದೇ ಅದನ್ನು ಮರುಸಂಪರ್ಕದ ನಂತರ ಉಳಿಸುವುದು, ಕೈಯಿಂದ ಸೇರಿಸಿದ ಮಾರ್ಗ ಅದನ್ನು ಮಾಡುವುದಿಲ್ಲ.

ಎಂಡ್ಪಾಯಿಂಟ್ ಮತ್ತು DNS ಅನ್ನು ನಿರ್ಧಾರದ ಹೊರಗೆ ಇರಿಸಿ

VPN ಎಂಡ್ಪಾಯಿಂಟ್ ಸುರಂಗವಿಲ್ಲದೆ ತಲುಪಬಹುದಾಗಿರಬೇಕು, ಇಲ್ಲದಿದ್ದರೆ ಸುರಂಗ ತನ್ನೊಳಗೇ ಕುಸಿಯುತ್ತದೆ. ಕೇವಲ 10.20.0.0/16 ಮಾರ್ಗವಾದಾಗ ಅದು ಸ್ವಯಂಚಾಲಿತ, ಏಕೆಂದರೆ ಎಂಡ್ಪಾಯಿಂಟ್ ಸಾರ್ವಜನಿಕ ವಿಳಾಸ. ಪೂರ್ಣ ಸುರಂಗ ಪ್ರೊಫೈಲ್ನಲ್ಲಿ ಹಾಗಿಲ್ಲ, ಮತ್ತು ಸುರಂಗ ಏರುವ ಮೊದಲು ಕ್ಲೈಂಟ್ಗೆ ಎಂಡ್ಪಾಯಿಂಟ್ಗೆ ಸ್ಪಷ್ಟ ಹೋಸ್ಟ್ ಮಾರ್ಗ ಬೇಕು.

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

ಪರಿಶೀಲಿಸಿ, ನಂತರ ಮರುಬೂಟ್ ಮಾಡಿ ಮತ್ತು ಮತ್ತೆ ಪರಿಶೀಲಿಸಿ

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

ip route get 10.20.5.7
curl -sS http://10.20.5.7/health
curl -sS https://ifconfig.me

ಮೊದಲ ಸಾಲು ಒಂದು ಇಂಟರ್ಫೇಸ್ ಹೆಸರಿಸುತ್ತದೆ. ಅದು ನಿಮ್ಮ ಭೌತಿಕ ಇಂಟರ್ಫೇಸ್ ಹೆಸರಿಸಿದರೆ, ಮಾರ್ಗ ಎಂದೂ ತಲುಪಿಲ್ಲ. Windows ನಲ್ಲಿ Find-NetRoute -RemoteIPAddress 10.20.5.7 ಅದೇ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸುತ್ತದೆ, ಮತ್ತು ಕೊನೆಯ ಪರೀಕ್ಷೆ ಇನ್ನೂ ನಿಮ್ಮ ಸಾಮಾನ್ಯ ವಿಳಾಸ ತೋರಿಸಬೇಕು, VPN ಸರ್ವರ್ನದಲ್ಲ.

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

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

ಸಂಬಂಧಿತ ಲೇಖನಗಳು