ರಿಮೋಟ್ ಬಳಕೆದಾರರು VPN ಹಬ್ ಮೂಲಕ ಎರಡನೇ ಸೈಟ್ ತಲುಪಲಾರರು

ಒಬ್ಬ ರಿಮೋಟ್ ಬಳಕೆದಾರ ಹಬ್ಗೆ ಸಂಪರ್ಕಿಸುತ್ತಾನೆ, ಹಬ್ನ ಸ್ವಂತ LAN ನಲ್ಲಿರುವ ಫೈಲ್ ಸರ್ವರ್ ತಲುಪುತ್ತಾನೆ, ಎಲ್ಲವೂ ಆರೋಗ್ಯಕರವಾಗಿ ಕಾಣುತ್ತದೆ. ನಂತರ ಅವರು ಪ್ರಧಾನ ಕಚೇರಿಯಲ್ಲಿ 10.20.0.50 ನಲ್ಲಿನ ಶೇರ್ ತೆರೆಯುತ್ತಾರೆ, ಅಲ್ಲಿಗೆ ಹಬ್ ಪ್ರತ್ಯೇಕ ಸೈಟ್-ಟು-ಸೈಟ್ ಟನೆಲ್ ಮೂಲಕ ತಲುಪುತ್ತದೆ, ಮತ್ತು ಸಮಯ ಮೀರಿಹೋಗುತ್ತದೆ. ಎರಡೂ ಟನೆಲ್ಗಳು ಚಾಲನೆಯಲ್ಲಿವೆ ಮತ್ತು ಎರಡೂ ಕೌಂಟರ್ಗಳು ಏರುತ್ತಿವೆ, ಆದ್ದರಿಂದ ಯಾವುದೇ ಟನೆಲ್ ಮುರಿದಿಲ್ಲ. ಹಬ್ ದಾಟುವುದು ಮೂರು ಸಾಧನಗಳಲ್ಲಿ ಮೂರು ರೂಟಿಂಗ್ ನಿರ್ಧಾರಗಳು, ಮತ್ತು ಟನೆಲ್ ತಾನು ನಿರ್ಮಿಸಲಾದ ಪ್ರಿಫಿಕ್ಸ್ಗಳನ್ನು ಮಾತ್ರ ಸಾಗಿಸುತ್ತದೆ. ನಾನು ಪರಿಶೀಲಿಸುವ ಕ್ರಮ ಇಲ್ಲಿದೆ, ಮತ್ತು ಪ್ರತಿ ಹಂತ ಸರಿಯೇ ಎಂದು ತೋರಿಸುವ ಆಜ್ಞೆ.

ಸಾಗಣೆಗೆ ಮೂರು ಲುಕಪ್ ಬೇಕು, ಒಂದು ಟನೆಲ್ ಅಲ್ಲ

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

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

ದೂರದ ಪ್ರಿಫಿಕ್ಸ್ ಅನ್ನು ರಿಮೋಟ್ ಕ್ಲೈಂಟ್ಗೆ ತಳ್ಳಿರಿ

ಒಂದು OpenVPN ರಿಮೋಟ್-ಆಕ್ಸೆಸ್ ಸರ್ವರ್ನಲ್ಲಿ ಕ್ಲೈಂಟ್ ಸಂಪರ್ಕದ ಸಮಯದಲ್ಲಿ ರೂಟ್ಗಳನ್ನು ಕಲಿಯುತ್ತದೆ. push ಇಲ್ಲದೆ, ಸ್ಪ್ಲಿಟ್-ಟನೆಲ್ ಕ್ಲೈಂಟ್ 10.20.0.50 ಅನ್ನು ತನ್ನದೇ ಗೇಟ್ವೇಗೆ ಕಳುಹಿಸುತ್ತದೆ ಮತ್ತು ಪ್ಯಾಕೆಟ್ ಎಂದಿಗೂ ಟನೆಲ್ ಪ್ರವೇಶಿಸುವುದಿಲ್ಲ.

push "route 10.20.0.0 255.255.255.0"

ತಳ್ಳಿದ ರೂಟ್ ಕ್ಲೈಂಟ್ ಸಂಪರ್ಕಿಸಿದಾಗ ಜಾರಿಗೆ ಬರುತ್ತದೆ, ಆದ್ದರಿಂದ ಆನ್ಲೈನ್ ಉಳಿಯುವ ಬಳಕೆದಾರ ಮತ್ತೆ ಸಂಪರ್ಕಿಸುವವರೆಗೆ ಏನನ್ನೂ ಕಾಣುವುದಿಲ್ಲ. ಕ್ಲೈಂಟ್ನಲ್ಲಿ ಪರಿಶೀಲಿಸಿ: Linux ನಲ್ಲಿ ip route get 10.20.0.50, Windows ನಲ್ಲಿ route print. ಔಟ್ಪುಟ್ ಟನೆಲ್ ಇಂಟರ್ಫೇಸ್ ಹೆಸರಿಸಬೇಕು.

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

ಹಬ್ಗೆ ನಿಜವಾದ ಇಗ್ರೆಸ್ ರೂಟ್ ಕೊಡಿ

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

ip route get 10.20.0.50 from 10.80.0.25
sudo ip route add 10.20.0.0/24 via 172.30.0.2 dev s2s0

ಸೈಟ್-ಟು-ಸೈಟ್ ಕಾಲು ಸ್ವತಃ OpenVPN ಆಗಿದ್ದರೆ, ರೂಟ್ ಆ ಸಂರಚನೆಯಲ್ಲೇ ಪೀರ್ನ ಟನೆಲ್ ವಿಳಾಸವನ್ನು ಗೇಟ್ವೇ ಆಗಿ ಇಟ್ಟುಕೊಳ್ಳಬಹುದು: route 10.20.0.0 255.255.255.0 172.30.0.2. ಗೇಟ್ವೇ ಐಚ್ಛಿಕವಲ್ಲ. ಅದನ್ನು ಬಿಟ್ಟರೆ ಮುಂದಿನ ಹಾಪ್ ಅನುಷ್ಠಾನದ ಡೀಫಾಲ್ಟ್ಗೆ ಬೀಳುತ್ತದೆ, ಅದು ಒಂದೇ ರಿಮೋಟ್ ಇರುವ ಕ್ಲೈಂಟ್ ಮತ್ತು ಹಲವು ಪೀರ್ಗಳ ಹಬ್ ನಡುವೆ ಭಿನ್ನವಾಗಿರುತ್ತದೆ.

ನೀತಿ-ಆಧಾರಿತ IPsec ಬೇರೆ: ಹಬ್ನ ಕರ್ನಲ್ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ತನ್ನ ಸಾಮಾನ್ಯ LAN ಗೇಟ್ವೇಗೆ ಕಳುಹಿಸುತ್ತದೆ ಮತ್ತು ನೀತಿ ಅದನ್ನು ಹೊರಹೋಗುವ ದಾರಿಯಲ್ಲಿ ಹಿಡಿಯುತ್ತದೆ, ಆದ್ದರಿಂದ ಟನೆಲ್ ರೂಟ್ ಏನೂ ಮಾಡುವುದಿಲ್ಲ ಅಥವಾ ನೀತಿಯನ್ನು ಬಳಸಿಕೊಂಡು ಟ್ರಾಫಿಕ್ ಕಳುಹಿಸುತ್ತದೆ. ಮೇಲಿನ ಆಜ್ಞೆಯಲ್ಲಿ ಮೂಲವನ್ನು ಗಮನಿಸಿ, ಏಕೆಂದರೆ ಪೂಲ್ ವಿಳಾಸದ ಬದಲು 10.10.0.1 ಎಂದರೆ ಕರ್ನಲ್ ದೂರದ ಬದಿ ನಿರಾಕರಿಸುವ ವಿಳಾಸವನ್ನು ಆಯ್ಕೆ ಮಾಡಿದೆ ಎಂದರ್ಥ. iroute ಕೂಡ ಉತ್ತರವಲ್ಲ; ಅದು ಸರ್ವರ್ಗೆ ಯಾವ ಕ್ಲೈಂಟ್ ತನ್ನ ಟನೆಲ್ ಹಿಂದಿನ ಸಬ್ನೆಟ್ ಹೊಂದಿದೆ ಎಂದು ಹೇಳುತ್ತದೆ, ಮೂರನೇ ಸೈಟ್ಗೆ ಟ್ರಾಫಿಕ್ ಎಲ್ಲಿಗೆ ಕಳುಹಿಸಬೇಕು ಎಂದಲ್ಲ.

ದೂರದ ಬದಿಯನ್ನು ಬಳಕೆದಾರರ ಪೂಲ್ವರೆಗೆ ವಿಸ್ತರಿಸಿ

ಪ್ರಧಾನ ಕಚೇರಿ ಈಗಾಗಲೇ ಹಬ್ನ LAN, 10.10.0.0/24 ಅನ್ನು ಒಳಗೊಳ್ಳುತ್ತದೆ. ಬಳಕೆದಾರರ ಪೂಲ್ ಎರಡನೇ ಪ್ರಿಫಿಕ್ಸ್ ಮತ್ತು ಅದು ಸೆಲೆಕ್ಟರ್ಗಳಲ್ಲೂ ಇರಬೇಕು, ಇಲ್ಲದಿದ್ದರೆ 10.80.0.25 ಗೆ ಕಳುಹಿಸಿದ ಉತ್ತರವನ್ನು ಯಾವ ನೀತಿಯೂ ಒಳಗೊಳ್ಳುವುದಿಲ್ಲ. ಪ್ರತಿ ಪೀರ್ ತನ್ನ ಬದಿಯಿಂದ ಅದೇ ಜೋಡಿ ಪ್ರಿಫಿಕ್ಸ್ ಸೆಟ್ಗಳನ್ನು ಹೆಸರಿಸುತ್ತದೆ:

# strongSwan swanctl.conf, on the hub
local_ts  = 10.10.0.0/24, 10.80.0.0/24
remote_ts = 10.20.0.0/24

# on the headquarters peer
local_ts  = 10.20.0.0/24
remote_ts = 10.10.0.0/24, 10.80.0.0/24

ಒಂದು ಸಾಧನದ local_ts ಇನ್ನೊಂದರ remote_ts. ಹಬ್ನ ಬ್ಲಾಕ್ ಅನ್ನು ಪ್ರಧಾನ ಕಚೇರಿಗೆ ನಕಲಿಸಿ ಮತ್ತು ಜೋಡಿ ತಿರುಗುತ್ತದೆ, ಆದ್ದರಿಂದ ಚೈಲ್ಡ್ SA ಎಂದಿಗೂ ಮೇಲೇಳುವುದಿಲ್ಲ.

ಹಳೆಯ ipsec.conf ಸಿಂಟ್ಯಾಕ್ಸ್ ಕಾಮಾದಿಂದ ಬೇರ್ಪಡಿಸಿದ leftsubnet ಬಳಸುತ್ತದೆ. ಚಾಲ್ತಿಯಲ್ಲಿರುವ ಭದ್ರತಾ ಸಂಘಟನೆ ಮಾತುಕತೆ ನಡೆಸಿದ ಸೆಲೆಕ್ಟರ್ಗಳನ್ನು ಇಟ್ಟುಕೊಳ್ಳುತ್ತದೆ, ಆದ್ದರಿಂದ ಸಂಪಾದನೆಯ ನಂತರ ಟನೆಲ್ ಮರುಸ್ಥಾಪಿಸಿ. 10:00 ಕ್ಕೆ ಬದಲಾದ ಸೆಲೆಕ್ಟರ್ 09:40 ಕ್ಕೆ ಮೇಲೆದ್ದ SA ವಿರುದ್ಧ ಪರೀಕ್ಷಿಸಿದರೂ ವಿಫಲವಾಗುತ್ತದೆ, ಆದರೆ ಸಂರಚನಾ ಫೈಲ್ ಪೂರ್ತಿ ಸಮಯ ಸರಿಯಾಗಿ ಕಾಣುತ್ತದೆ.

ನಂತರ ಕೊನೆಯ ಹಾಪ್ ಪರಿಶೀಲಿಸಿ. ದೂರದ ಎಂಡ್ಪಾಯಿಂಟ್ನಲ್ಲಿ ip route get 10.80.0.25 ಟನೆಲ್ನೊಳಗೆ ತೋರಿಸಬೇಕು. ಸೇವೆ LAN ರೌಟರ್ ಅನ್ನು ತನ್ನ ಡೀಫಾಲ್ಟ್ ಗೇಟ್ವೇ ಆಗಿ ಬಳಸಿದರೆ, ಆ ರೌಟರ್ಗೂ ರಿಟರ್ನ್ ರೂಟ್ ಬೇಕು, ಇಲ್ಲದಿದ್ದರೆ ಉತ್ತರ ಅಲ್ಲೇ ಸಾಯುತ್ತದೆ. ಆ ವಿಭಾಗದಲ್ಲಿ tcpdump -ni eth1 host 10.80.0.25 ಚಲಾಯಿಸುವುದು ಉತ್ತರ ಎಂಡ್ಪಾಯಿಂಟ್ನಿಂದ ಹೊರಟಿತೇ ಎಂದು ತೋರಿಸುತ್ತದೆ.

ಹಬ್ನಲ್ಲಿ ಹರಿವಿಗೆ ಅನುಮತಿ ಕೊಡಿ

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

sysctl -w net.ipv4.ip_forward=1
iptables -I FORWARD -i tun0 -o s2s0 -s 10.80.0.0/24 -d 10.20.0.0/24 -j ACCEPT
iptables -I FORWARD -i s2s0 -o tun0 -s 10.20.0.0/24 -d 10.80.0.0/24 -j ACCEPT

ರಿವರ್ಸ್-ಪಾತ್ ಫಿಲ್ಟರಿಂಗ್ ಅದರ ಪಕ್ಕದ ಮೌನ ವಿಫಲತೆ: ಎರಡು ಕಾಲುಗಳು ಬೇರೆ ಬೇರೆ ಇಂಟರ್ಫೇಸ್ಗಳಲ್ಲಿದ್ದಾಗ, rp_filter=1 ಉತ್ತರವನ್ನು ಬಿಡಬಹುದು, ಆದರೆ ಸ್ವೀಕಾರ ನಿಯಮದ ಕೌಂಟರ್ ಎಂದಿಗೂ ಅಲುಗಾಡುವುದಿಲ್ಲ. ಒಂದು ಪ್ರಯತ್ನಕ್ಕೆ ಮೊದಲು ಮತ್ತು ನಂತರ iptables -vnL FORWARD ಹೋಲಿಸಿ. ಎಂದಿಗೂ ಹೆಚ್ಚದ ನಿಯಮವನ್ನು ತಲುಪುವುದೇ ಇಲ್ಲ, ಆದ್ದರಿಂದ ಅದನ್ನು ಮತ್ತೆ ಬರೆಯುವ ಬದಲು ಒಂದು ಪದರ ಕೆಳಗೆ ನೋಡಿ.

ಒಂದೇ ಗುಂಪಿಗೆ ಸಾಗಣೆ ಬೇಕಿದ್ದರೆ, ಜಾಗತಿಕ push ಅನ್ನು ವಿಸ್ತರಿಸುವ ಬದಲು client-config-dir ಅಡಿಯಲ್ಲಿ ಪ್ರತಿ-ಕ್ಲೈಂಟ್ ಫೈಲ್ನಲ್ಲಿ ರೂಟ್ ಇಡಿ. ಹಬ್ನಲ್ಲಿ Source NAT ಕೂಡ ದೂರದ ಬದಿಯ ರಿಟರ್ನ್ ರೂಟ್ ಅಗತ್ಯವನ್ನು ತೆಗೆದುಹಾಕುತ್ತದೆ, ಆದರೆ ಅದು ಬಳಕೆದಾರರ ವಿಳಾಸವನ್ನು ಮರೆಮಾಡುತ್ತದೆ, ಆದ್ದರಿಂದ ದೂರದ ಸೈಟ್ನ ಲಾಗ್ಗಳು ಮತ್ತು ವಿಳಾಸ-ಆಧಾರಿತ ನಿಯಮಗಳು ಬಳಕೆದಾರರನ್ನು ಬೇರ್ಪಡಿಸುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತವೆ.

ಕ್ಲೈಂಟ್ನಿಂದ ಪರಿಶೀಲಿಸಿ, ನಂತರ ಹಿಮ್ಮುಖ ಕ್ರಮದಲ್ಲಿ ರೋಲ್ಬ್ಯಾಕ್ ಮಾಡಿ

ಕೇವಲ ICMP ಅಲ್ಲ, TCP ಪೋರ್ಟ್ ಪರೀಕ್ಷಿಸಿ, ಏಕೆಂದರೆ ಸೇವೆ ನಿರ್ಬಂಧಿತವಾಗಿರುವಾಗ ಪಿಂಗ್ ಪಾಸಾಗಬಹುದು. ಕ್ಲೈಂಟ್ನಿಂದ nc -vz 10.20.0.50 445 ಮತ್ತು traceroute -n 10.20.0.50 ಎರಡನೇ ಹಾಪ್ ಹಬ್ನ ಟನೆಲ್ ವಿಳಾಸವೇ ಎಂದು ತೋರಿಸುತ್ತವೆ. ಹಬ್ನಲ್ಲಿ, tcpdump -ni tun0 host 10.20.0.50 ಮತ್ತು ಸೈಟ್-ಟು-ಸೈಟ್ ಇಂಟರ್ಫೇಸ್ನಲ್ಲಿ ಅದೇ ಫಿಲ್ಟರ್: ಎರಡರಲ್ಲೂ ವಿನಂತಿ ಆದರೆ ಯಾವುದರಲ್ಲೂ ಉತ್ತರ ಇಲ್ಲದಿದ್ದರೆ ಸಮಸ್ಯೆ ದೂರದ ಬದಿಗೆ ಹೋಗುತ್ತದೆ.

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

ರೋಲ್ಬ್ಯಾಕ್ ಪಟ್ಟಿ ಇಟ್ಟುಕೊಳ್ಳಿ, ಏಕೆಂದರೆ ನಾಲ್ಕು ವಸ್ತುಗಳು ಬದಲಾಗಿವೆ ಮತ್ತು ಮೂರು ಮರೆಯುವುದು ಸುಲಭ: ತಳ್ಳಿದ ರೂಟ್, ಹಬ್ನ ರೂಟ್, ಸೆಲೆಕ್ಟರ್ಗಳು ಮತ್ತು ಫೈರ್ವಾಲ್ ನಿಯಮಗಳು. ಅವುಗಳನ್ನು ಹಿಮ್ಮುಖ ಕ್ರಮದಲ್ಲಿ ಹಿಂತೆಗೆದುಕೊಳ್ಳಿ, SA ಮರುಸ್ಥಾಪಿಸಿ, ಮತ್ತು ಒಬ್ಬ ಬಳಕೆದಾರ ಮತ್ತೆ ಸಂಪರ್ಕಿಸಲಿ. ಭಾಗಶಃ ರೋಲ್ಬ್ಯಾಕ್ ಇನ್ನು ಹೊಂದಿಕೆಯಾಗದ ಟನೆಲ್ಗೆ ತೋರಿಸುವ ರೂಟ್ ಬಿಡುತ್ತದೆ, ಅದನ್ನು ಓದುವುದು ಮೂಲ ಮೌನಕ್ಕಿಂತ ಕಷ್ಟ. OpenVPN 2.6 ಕೈಪಿಡಿ ನಿಮ್ಮ ಆವೃತ್ತಿಗೆ push, route ಮತ್ತು iroute ಅನ್ನು ದಾಖಲಿಸುತ್ತದೆ.