TUN OpenVPN ಸರ್ವರ್ ಮೂಲಕ host-only ನೆಟ್‌ವರ್ಕ್‌ನ VM ಸಂಚಾರವನ್ನು ರೂಟ್ ಮಾಡಿ

host-only ಅಡಾಪ್ಟರ್‌ಗಳು ಸ್ಥಳೀಯ ವರ್ಚುವಲ್ ನೆಟ್‌ವರ್ಕ್ ರಚಿಸುತ್ತವೆ, ಮತ್ತು ರೂಟ್ ಮಾಡಿದ TUN ಟನೆಲ್‌ಗಳು ವಿಳಾಸಗಳ ನಡುವೆ IP ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಸಾಗಿಸುತ್ತವೆ. ಎರಡೂ ಒಂದಕ್ಕೊಂದು ಸೇತುವೆ ಅಲ್ಲ, ಆದ್ದರಿಂದ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಸಂರಚನೆಯು ಯಾರು ಮುಂದಕ್ಕೆ ಕಳುಹಿಸುತ್ತಾರೆ ಮತ್ತು ಹಿಂತಿರುಗುವ ರೂಟ್ ಯಾರದ್ದು ಎಂದು ಹೇಳಬೇಕು. ಈ ಎರಡು ನಿಯೋಜನೆಗಳನ್ನು ತಪ್ಪಾಗಿ ಮಾಡಿದರೆ, ಅತಿಥಿಯು ಟನೆಲ್ ಕ್ಲೈಂಟ್ ಎಂದೂ ಕೇಳದ ಮೂಲದಿಂದ ಟನೆಲ್‌ಗೆ ಉತ್ತರಿಸುತ್ತದೆ. ಕೆಳಗಿನ ವಿನ್ಯಾಸವು ಎರಡೂ ಪ್ರಿಫಿಕ್ಸ್‌ಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಇರಿಸುತ್ತದೆ ಮತ್ತು ಹಿಂತಿರುಗುವ ದಾರಿಯನ್ನು ಸ್ಪಷ್ಟಪಡಿಸುತ್ತದೆ.

ಎರಡು ನೆಟ್‌ವರ್ಕ್‌ಗಳು, ಎರಡು ಪ್ರಿಫಿಕ್ಸ್‌ಗಳು

ಟನೆಲ್ ಪೂಲ್ ಮತ್ತು host-only ನೆಟ್‌ವರ್ಕ್‌ಗೆ ಬೇರೆ ಬೇರೆ ಪ್ರಿಫಿಕ್ಸ್‌ಗಳನ್ನು ನೀಡಿ ಮತ್ತು ಒಂದನ್ನು ಇನ್ನೊಂದಕ್ಕೆ ಎಂದೂ ಮರುಬಳಸಬೇಡಿ. ಈ ಉದಾಹರಣೆಯಲ್ಲಿ VPN ಪೂಲ್ 10.44.0.0/24 ಮತ್ತು host-only ನೆಟ್‌ವರ್ಕ್ 192.168.99.0/24, ಹೋಸ್ಟ್ 192.168.99.1 ನಲ್ಲಿ ಮತ್ತು ಅತಿಥಿ 192.168.99.20 ನಲ್ಲಿ. ಒಂದೇ ಪ್ರಿಫಿಕ್ಸ್ ಅನ್ನು TUN ಸಾಧನ ಮತ್ತು host-only ಅಡಾಪ್ಟರ್ ಎರಡಕ್ಕೂ ನೀಡುವುದು ಅವುಗಳನ್ನು ಸೇರಿಸುವುದಿಲ್ಲ. ಅದು ಒಂದು ವಿಳಾಸ ಶ್ರೇಣಿಯ ಮೇಲೆ ಎರಡು ಹಕ್ಕುಗಳನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ, ಮತ್ತು ರೂಟಿಂಗ್ ಕೋಷ್ಟಕವು ಆಗ ಆಕಸ್ಮಿಕವಾಗಿ ಉಳಿಸಿಕೊಂಡ ಹಕ್ಕಿನ ಪರವಾಗಿ ಉತ್ತರಿಸುತ್ತದೆ.

host-only ಅಡಾಪ್ಟರ್ ಹೋಸ್ಟ್‌ನಲ್ಲಿ ಮತ್ತು ಅತಿಥಿಯ ಒಳಗೆ ಇರುತ್ತದೆ, ಮತ್ತು ಅದಕ್ಕೆ ತಾನೇ ಯಂತ್ರದಿಂದ ಹೊರಗೆ ಹೋಗುವ ದಾರಿ ಇಲ್ಲ. ಸೇತುವೆ ಮತ್ತು NAT ಸಂಪರ್ಕಗಳಿಗೆ ಬೇರೆ ಮಟ್ಟದ ಒಡ್ಡುವಿಕೆ ಇರುತ್ತದೆ, ಮತ್ತು ಒಂದು ಅತಿಥಿ ಸೇವೆಯನ್ನು ತಲುಪಲು ಸೇತುವೆ ಮೋಡ್‌ಗೆ ಬದಲಾಗುವುದು ಅಗತ್ಯವಲ್ಲ.

ಹೋಸ್ಟ್ ಈಗಾಗಲೇ ದಾರಿಯನ್ನು ಹೊಂದಿದೆ

ಏನನ್ನಾದರೂ ಸೇರಿಸುವ ಮೊದಲು ಏನಿದೆ ಎಂದು ನೋಡಿ. ಹೋಸ್ಟ್‌ಗೆ host-only ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿ ಇಂಟರ್‌ಫೇಸ್ ಮತ್ತು ಆ ಪ್ರಿಫಿಕ್ಸ್‌ಗೆ ರೂಟ್ ಇದೆ, ಎರಡೂ ಅಡಾಪ್ಟರ್ ಎದ್ದಾಗ ರಚಿಸಲ್ಪಟ್ಟವು.

ip -br addr show
ip route show 192.168.99.0/24
sysctl net.ipv4.ip_forward

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

ರೂಟ್ ಪುಶ್ ಮಾಡಿ, ನಂತರ ಅದು ತಲುಪುವುದನ್ನು ಫಿಲ್ಟರ್ ಮಾಡಿ

ಪುಶ್ ಮಾಡಿದ ರೂಟ್‌ಗಳನ್ನು ಸ್ವೀಕರಿಸುವ ಕ್ಲೈಂಟ್‌ಗಳಿಗೆ ಸರ್ವರ್ host-only ಪ್ರಿಫಿಕ್ಸ್ ಅನ್ನು ಒದಗಿಸಬಹುದು, ಇದು ಟನೆಲ್‌ನ ಹಿಂದಿನ ಯಾವುದೇ ಸಬ್‌ನೆಟ್‌ಗೆ ಬಳಸುವ ಅದೇ ಕಾರ್ಯವಿಧಾನ.

push "route 192.168.99.0 255.255.255.0"
iptables -A FORWARD -i tun0 -o vboxnet0 -d 192.168.99.20 -p tcp --dport 5432 -j ACCEPT
iptables -A FORWARD -i vboxnet0 -o tun0 -s 192.168.99.20 -p tcp --sport 5432 -m conntrack --ctstate ESTABLISHED -j ACCEPT

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

ಅತಿಥಿಗೆ ಹಿಂತಿರುಗುವ ದಾರಿ ಬೇಕು

10.44.0.x ನಿಂದ ತಲುಪುವ ಅತಿಥಿಯು ತನ್ನ ಉತ್ತರಗಳನ್ನು ಹೋಸ್ಟ್‌ನ host-only ವಿಳಾಸಕ್ಕೆ ಕಳುಹಿಸಬೇಕು, ಅಥವಾ ಹೋಸ್ಟ್ ಮೂಲವನ್ನು ಅನುವಾದಿಸಬೇಕು. VirtualBox DHCP ನಿಂದ ವಿಳಾಸ ಪಡೆಯುವುದು ಈ ಎರಡೂ ವ್ಯವಸ್ಥೆಗಳ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ.

ip route add 10.44.0.0/24 via 192.168.99.1 dev enp0s8
ip route get 10.44.0.15

ಅತಿಥಿಯ ಒಳಗೆ ಆ ರೂಟ್ ಸೇರಿಸುವುದು ಮೂಲ ಮೂಲವನ್ನು ಉಳಿಸುತ್ತದೆ, ಇದು ಪ್ರತಿ ಕ್ಲೈಂಟ್‌ನ ನೀತಿ ಮತ್ತು ಲಾಗ್‌ಗಳನ್ನು ಅರ್ಥಪೂರ್ಣವಾಗಿರಿಸುತ್ತದೆ. ಹೋಸ್ಟ್‌ನಲ್ಲಿ ಸೀಮಿತ ಮೂಲ ಅನುವಾದವು ಪರ್ಯಾಯವಾಗಿದೆ, ಮತ್ತು ಅದು ಕೆಲಸ ಮಾಡುತ್ತದೆ, ಆದರೆ ಯಾವ ಕ್ಲೈಂಟ್ ಸಂಪರ್ಕಿಸಿತು ಎಂಬುದನ್ನು ಮರೆಮಾಡುವ ಬೆಲೆಯಲ್ಲಿ. ಅತಿಕ್ರಮಣವು ಮತ್ತೊಂದು ವಿಫಲತೆಯ ವಿಧಾನ. ತಮ್ಮ ಮನೆಯ LAN ಈಗಾಗಲೇ 192.168.99.0/24 ಬಳಸುವ ದೂರದ ಕ್ಲೈಂಟ್ ಪುಶ್ ಮಾಡಿದ ರೂಟ್ ಅನ್ನು ತಮ್ಮ ನೆಟ್‌ವರ್ಕ್ ಎಂದು ಓದುತ್ತಾರೆ, ಮತ್ತು ಸರ್ವರ್ ಬದಿಯಲ್ಲಿ ಯಾವುದೇ ಬದಲಾವಣೆ ಆ ಅಸ್ಪಷ್ಟತೆಯನ್ನು ಸರಿಪಡಿಸುವುದಿಲ್ಲ. ಒಂದು ಬದಿಯನ್ನು ಮರುಸಂಖ್ಯೆ ಮಾಡಿ ಅಥವಾ ಘರ್ಷಣೆಯ ಸಂಭವನೀಯತೆ ಕಡಿಮೆ ಇರುವ ಪ್ರಿಫಿಕ್ಸ್ ಆಯ್ಕೆ ಮಾಡಿ.

TUN ಸಾಧನ IP ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಸಾಗಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಅತಿಥಿಯ ಒಳಗೆ ಡೀಫಾಲ್ಟ್ ಗೇಟ್‌ವೇ ಸೇರಿಸುವುದು ಟನೆಲ್ ಅನ್ನು host-only ಅಡಾಪ್ಟರ್ ಜೊತೆಗೆ ಈಥರ್ನೆಟ್ ವಿಭಾಗವಾಗಿ ಮಾಡುವುದಿಲ್ಲ. TAP ಸೇತುವೆ ತನ್ನದೇ ಕ್ಲೈಂಟ್ ಬೆಂಬಲ ಮತ್ತು ವಿಳಾಸ ಮಾಲೀಕತ್ವ ಹೊಂದಿರುವ ಬೇರೆ ವಿನ್ಯಾಸ, ಮತ್ತು ಎರಡೂ ವಿವರಣೆಗಳನ್ನು ಮಿಶ್ರಣ ಮಾಡುವುದು ಎಂದೂ ಒಮ್ಮುಖವಾಗದ ಸಂರಚನೆಗಳಿಗೆ ಕಾರಣವಾಗುತ್ತದೆ.

ಪರಿಶೀಲಿಸಿ, ನಂತರ ಅದು ಮರುಪ್ರಾರಂಭವನ್ನು ತಾಳಿಕೊಳ್ಳುವಂತೆ ಮಾಡಿ

ಸಾಮಾನ್ಯ ದೂರದ ಕ್ಲೈಂಟ್‌ನಿಂದ ಒಂದು ನಿರುಪದ್ರವ ಸೇವೆಯನ್ನು ಪರೀಕ್ಷಿಸಿ, ಅತಿಥಿಯ ಹಿಂತಿರುಗುವ ರೂಟ್ ಪರಿಶೀಲಿಸಿ, ಮತ್ತು ನೀವು ಅನುಮತಿಸದ ಸೇವೆ ನಿಧಾನವಾಗಿರುವುದಿಲ್ಲ, ನಿರಾಕರಿಸಲ್ಪಡುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ.

ss -lntp '( sport = :5432 )'
conntrack -L | grep 192.168.99.20

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