ಟನೆಲ್ ಮೇಲೆದ್ದ ಕ್ಷಣವೇ UFW VPN ನ DNS ಸರ್ವರ್ ಅನ್ನು ಬಿಡುತ್ತದೆ
UFW ನ ಡೀಫಾಲ್ಟ್ ನಿರಾಕರಣ ನೀತಿ ಟನೆಲ್ ಇಂಟರ್ಫೇಸ್ ಅನ್ನೂ ಆವರಿಸುತ್ತದೆ. ಟ್ರಾಫಿಕ್ ಅನ್ನು ದಿಕ್ಕಿನಿಂದ ಜೋಡಿಸಿ, tun0 ನಲ್ಲಿ ತಳ್ಳಲಾದ resolver ಗೆ ಅನುಮತಿ ನೀಡಿ, ನಂತರ ಹೊರ ಮಾರ್ಗ ತೆರೆಯಿರಿ.
VPN ಸಂಪರ್ಕಗೊಂಡ ಕ್ಷಣವೇ ಹೆಸರುಗಳು ಪರಿಹರಿಸುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತವೆ, ಆದರೆ ಸಾರ್ವಜನಿಕ ವಿಳಾಸಕ್ಕೆ ping ಇನ್ನೂ ಉತ್ತರಿಸುತ್ತದೆ ಮತ್ತು firewall ಸ್ಥಿತಿಯಲ್ಲಿ ತಪ್ಪಾಗಿ ಕಾಣುವ ಯಾವುದೂ ಇಲ್ಲ. ನೀತಿಯಲ್ಲಿ ಏನೂ ಬದಲಾಗಿಲ್ಲ; ಬದಲಾಗಿರುವುದು ಹೊಸ ಇಂಟರ್ಫೇಸ್ ಬಂದಿರುವುದು, ಮತ್ತು ಡೀಫಾಲ್ಟ್ ನಿರಾಕರಣೆ ಮೊದಲ ಪ್ಯಾಕೆಟ್ನಿಂದಲೇ ಅದನ್ನು ಆವರಿಸುತ್ತದೆ. UFW ದಿಕ್ಕು ಮತ್ತು ಇಂಟರ್ಫೇಸ್ ಮೂಲಕ ನಿರ್ಧರಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ವೈರ್ಲೆಸ್ ಲಿಂಕ್ನಿಗಾಗಿ ಬರೆದ ನಿಯಮ ಟನೆಲ್ನಿಂದ ಹೊರಹೋಗುವ ಟ್ರಾಫಿಕ್ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ. ಸರಿಪಡಿಸುವಿಕೆ ಎಂದರೆ ನಿರ್ದಿಷ್ಟ ಕ್ರಮದಲ್ಲಿ ಅನ್ವಯಿಸುವ ಕೆಲವು ಸಣ್ಣ ನಿಯಮಗಳು.
ರೋಗಲಕ್ಷಣ ಟನೆಲ್ ಮೇಲೆದ್ದ ನಂತರವೇ ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತದೆ
ಡೀಫಾಲ್ಟ್ ನಿರಾಕರಣ ನೀತಿ ತನಗೆ ಹೇಳಿದ್ದನ್ನು ನಿಖರವಾಗಿ ಮಾಡುತ್ತದೆ: ಹೊಂದಿಕೆಯಾಗುವ ನಿಯಮವಿಲ್ಲದ ಎಲ್ಲವೂ, ಇರುವ ಪ್ರತಿಯೊಂದು ಇಂಟರ್ಫೇಸ್ನಲ್ಲೂ ನಿರಾಕರಿಸಲ್ಪಡುತ್ತದೆ. ನಿಯಮಗಳನ್ನು ಬರೆದಾಗ ಟನೆಲ್ ಇರಲಿಲ್ಲ, ಆದ್ದರಿಂದ ಅವುಗಳಲ್ಲಿ ಯಾವುದೂ ಅದನ್ನು ಹಿಡಿಯಲಾರದು, ಮತ್ತು ಯಾವಾಗಲೂ ಇದ್ದ ನಿರಾಕರಣೆ ಈಗ ಹೆಸರು ಪರಿಹರಣೆಗೆ ಅನ್ವಯಿಸುತ್ತದೆ. ಅಕ್ಷರಶಃ ವಿಳಾಸಕ್ಕೆ ನೇರ ಟ್ರಾಫಿಕ್, ಅಗಲವಾದ ಅನುಮತಿ ಅದನ್ನು ಆವರಿಸಿದಾಗ ಇನ್ನೂ ಕೆಲಸ ಮಾಡಬಹುದು, ಆದ್ದರಿಂದ ಸಾರ್ವಜನಿಕ resolver ಗೆ ping ಯಶಸ್ವಿಯಾಗುತ್ತದೆ ಆದರೆ ಹೆಸರು ಹುಡುಕುವಿಕೆ ವಿಫಲವಾಗುತ್ತದೆ. ಕೊರತೆ ಎಂದರೆ ನೀತಿ ಎಂದೂ ನೋಡದ ಇಂಟರ್ಫೇಸ್ಗೆ ಇರುವ ನಿಯಮ.
ವೈಫಲ್ಯವು ಸ್ವಚ್ಛವಾಗಿ ಹಿಮ್ಮುಖವಾಗುವುದಕ್ಕೂ ಇದೇ ಕಾರಣ: ಟನೆಲ್ ಇಳಿಸಿ, ಹೆಸರುಗಳು ಮತ್ತೆ ಪರಿಹರಿಸುತ್ತವೆ, ಏಕೆಂದರೆ ಪ್ರಶ್ನೆ ನಿಯಮಗಳಿರುವ ಇಂಟರ್ಫೇಸ್ಗೆ ಮರಳುತ್ತದೆ. ಟನೆಲ್ ಮೇಲಿದ್ದಾಗ ಮಾತ್ರ ವಿಫಲವಾಗುವ ನೀತಿ DNS ಸಮಸ್ಯೆ ಅಲ್ಲ, ಮತ್ತು resolver ಅನ್ನು ಸ್ವತಃ ಟ್ಯೂನ್ ಮಾಡುವುದು ಇಲ್ಲಿ ಹೆಚ್ಚು ಸಮಯ ವ್ಯರ್ಥ ಮಾಡುತ್ತದೆ. resolver ಸಂರಚನೆಯನ್ನು ಓದುವ ಮೊದಲು ಇಂಟರ್ಫೇಸ್ ಪಟ್ಟಿಯನ್ನು ಓದಿ.
ಮೂರು ದಿಕ್ಕುಗಳು, ಮೂರು ಬೇರೆ ಬೇರೆ ನಿಯಮ ಸಂಗ್ರಹಗಳು
ಒಂದು ಸೆಷನ್ ಒಂದಕ್ಕಿಂತ ಹೆಚ್ಚು ದಿಕ್ಕುಗಳಲ್ಲಿ ನಿಯಮಗಳನ್ನು ಮುಟ್ಟುತ್ತದೆ, ಮತ್ತು ಟನೆಲ್ ಅವುಗಳಿಗೆ ಬಹುತೇಕ ಎಲ್ಲದಕ್ಕೂ ಎರಡನೇ ಇಂಟರ್ಫೇಸ್ ಸೇರಿಸುತ್ತದೆ. ಟ್ರಾಫಿಕ್ ಅನ್ನು ಮೊದಲು ದಿಕ್ಕು ಮತ್ತು ಇಂಟರ್ಫೇಸ್ ಮೂಲಕ ಜೋಡಿಸಿದರೆ ಉಳಿದದ್ದು ಯಾಂತ್ರಿಕವಾಗುತ್ತದೆ, ಏಕೆಂದರೆ ಕೆಳಗಿನ ಪ್ರತಿ ಸಾಲಿಗೂ ತನ್ನ ಸ್ಥಳದಲ್ಲಿ ತನ್ನದೇ ನಿಯಮ ಬೇಕು. ಉದಾಹರಣೆಗಳು tun0 ಮತ್ತು 10.8.0.0/24 ಪೂಲ್ ಬಳಸುತ್ತವೆ, ಆದ್ದರಿಂದ ಹೆಸರುಗಳು ಮತ್ತು ಶ್ರೇಣಿಗಳನ್ನು ಕ್ಲೈಂಟ್ನ ಸ್ವಂತ ಔಟ್ಪುಟ್ನಿಂದ ಬದಲಿಸಿ.
| Direction | Example packet | Rule that admits it | Written on |
|---|---|---|---|
| Client to the pushed resolver | A DNS query to 10.8.0.1 | Destination port 53 over the tunnel | The client's tun0 |
| Client to the VPN server | A handshake to the server's public address | Server address and port on the physical link | The client's physical interface |
| Server to a service | SSH from the pool to port 22 | Source pool, destination port, tunnel interface | The server's tun0 |
| Anyone to the listener | The VPN listener itself | 1194/udp on the public side | The server's public interface |
ಎರಡು ಸಾಲುಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಗೊಂದಲಕ್ಕೊಳಗಾಗುತ್ತವೆ ಏಕೆಂದರೆ ಎರಡೂ ಟನೆಲ್ ಅನ್ನು ಉಲ್ಲೇಖಿಸುತ್ತವೆ. resolver ನಿಯಮ ಕ್ಲೈಂಟ್ ಟನೆಲ್ಗೆ ಕಳುಹಿಸುವ ಟ್ರಾಫಿಕ್ಗೆ ಅನುಮತಿ ನೀಡುತ್ತದೆ, ಆದರೆ SSH ನಿಯಮ ಸರ್ವರ್ ಅಲ್ಲಿಂದ ಪಡೆಯುವ ಟ್ರಾಫಿಕ್ಗೆ ಅನುಮತಿ ನೀಡುತ್ತದೆ; ಅವು ಬೇರೆ ಬೇರೆ ಯಂತ್ರಗಳಲ್ಲಿ ವಾಸಿಸುತ್ತವೆ ಮತ್ತು ಸ್ವತಂತ್ರವಾಗಿ ವಿಫಲವಾಗುತ್ತವೆ. ಅತ್ಯಂತ ಹೆಚ್ಚು ಮರೆತುಹೋಗುವ ಸಾಲು ಎರಡನೆಯದು, ಏಕೆಂದರೆ ಸರ್ವರ್ನ ಸಾರ್ವಜನಿಕ ವಿಳಾಸಕ್ಕೆ ಕ್ಲೈಂಟ್ನ ಟ್ರಾಫಿಕ್ಗೆ ಅನುಮತಿ ಸಿಗುವವರೆಗೆ ಕ್ಲೈಂಟ್ ಟನೆಲ್ ಅನ್ನು ಸ್ಥಾಪಿಸಲೇ ಸಾಧ್ಯವಿಲ್ಲ. ಮೇಲಿನಿಂದ ಕೆಳಗೆ ಕೆಲಸ ಮಾಡಿ ಮತ್ತು ಪ್ರತಿ ವೈಫಲ್ಯಕ್ಕೂ ಒಂದು ಸಂಭಾವ್ಯ ಕಾರಣ ಇರುತ್ತದೆ.
ತಳ್ಳಲಾದ resolver ಗೆ ತನ್ನದೇ ನಿಯಮ ಬೇಕು
ಟನೆಲ್ DNS ಸಾಗಿಸುತ್ತದೆಯೇ ಎಂಬುದು ಸರ್ವರ್ ಏನು ಕಳುಹಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಅವಲಂಬಿಸಿದೆ. resolver ಆಯ್ಕೆಯನ್ನು ತಳ್ಳುವ ಸರ್ವರ್ ಕ್ಲೈಂಟ್ನ ಸಂರಚನೆಯಲ್ಲಿ ಖಾಸಗಿ ವಿಳಾಸವನ್ನು ಸ್ಥಾಪಿಸುತ್ತದೆ, ಮತ್ತು ಆ ವಿಳಾಸ ಟನೆಲ್ ಮೂಲಕ ಮಾತ್ರ ಮಾರ್ಗೀಕರಿಸಬಹುದು. ಸರ್ವರ್ ಏನನ್ನೂ ತಳ್ಳದಿದ್ದರೆ, ಕ್ಲೈಂಟ್ ಈಗಾಗಲೇ ಇದ್ದ resolver ಅನ್ನು ಉಳಿಸಿಕೊಳ್ಳುತ್ತದೆ ಮತ್ತು ಕೆಳಗಿನ ನಿಯಮಗಳಿಗೆ ಅನುಮತಿಸಲು ಏನೂ ಇರುವುದಿಲ್ಲ. ಏನನ್ನಾದರೂ ಬರೆಯುವ ಮೊದಲು ತಳ್ಳಲಾದ ಸ್ಥಿತಿ ಮತ್ತು ಪ್ರಸ್ತುತ ಪ್ರಶ್ನೆ ಫಲಿತಾಂಶವನ್ನು ಪರಿಶೀಲಿಸಿ:
dig +short @10.8.0.1 example.com
resolvectl status tun0
sudo ufw status numberedಸ್ಥಿತಿ ಔಟ್ಪುಟ್ ಬಳಕೆಯಲ್ಲಿರುವ resolver ಮತ್ತು ಅದು ಬಂಧಿಸಲ್ಪಟ್ಟಿರುವ ಲಿಂಕ್ ಅನ್ನು ಹೆಸರಿಸುತ್ತದೆ, ಮತ್ತು ಅದರ ಹಿಂದಿನ ಮಾರ್ಗ ಹುಡುಕಾಟ ಆ ವಿಳಾಸಕ್ಕೆ ಪ್ರಶ್ನೆಯನ್ನು ಯಾವ ಇಂಟರ್ಫೇಸ್ ಸಾಗಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ತೋರಿಸುತ್ತದೆ. resolver ಬೇರೆ ಲಿಂಕ್ನಲ್ಲಿ ಕುಳಿತಿದ್ದರೆ, ಸಮಸ್ಯೆ firewall ಗಿಂತ ಮೊದಲೇ ಇದೆ ಮತ್ತು ಯಾವುದೇ ನಿಯಮ ಸಹಾಯ ಮಾಡುವುದಿಲ್ಲ. ಎರಡೂ ಟನೆಲ್ ಬಗ್ಗೆ ಒಪ್ಪಿದರೆ, ಎರಡು ನಿಯಮಗಳು ಬೇಕು, ಏಕೆಂದರೆ ಹೆಚ್ಚಿನ ಪ್ರಶ್ನೆಗಳನ್ನು UDP ಸಾಗಿಸುತ್ತದೆ ಮತ್ತು ಉತ್ತರ ಕತ್ತರಿಸಿದಾಗ TCP ಜವಾಬ್ದಾರಿ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. ಎರಡೂ ಮೌಲ್ಯಗಳನ್ನು ದಾಖಲಿಸಿ, ಏಕೆಂದರೆ ನಿಯಮಗಳು ಹೆಸರಿಸುವುದು ಅವನ್ನೇ:
sudo ufw allow out on tun0 to 10.8.0.1 port 53 proto udp comment 'pushed resolver'
sudo ufw allow out on tun0 to 10.8.0.1 port 53 proto tcp comment 'truncated answers'ಒಳಗಿನ ಮಾರ್ಗಕ್ಕಿಂತ ಮೊದಲು ಹೊರಗಿನ ಮಾರ್ಗ ತೆರೆಯಿರಿ
ಟನೆಲ್ ಇರುವ ಮೊದಲು ಕ್ಲೈಂಟ್ ಸರ್ವರ್ನ ಸಾರ್ವಜನಿಕ ವಿಳಾಸವನ್ನು ತಲುಪಬೇಕು, ಆದ್ದರಿಂದ ಅದಕ್ಕಿರುವ ನಿಯಮ ಭೌತಿಕ ಲಿಂಕ್ನಲ್ಲಿ ಕುಳಿತು ಮೊದಲು ಸ್ಥಳದಲ್ಲಿರಬೇಕು. resolver ಗೆ ಅನುಮತಿ ನೀಡಿ ಸರ್ವರ್ ಅನ್ನು ಮರೆತ ನೀತಿ ಕ್ಲೈಂಟ್ ಟನೆಲ್ ನಿರ್ಮಿಸಲೇ ಸಾಧ್ಯವಿಲ್ಲದಂತೆ ಬಿಡುತ್ತದೆ, ಮತ್ತು ಆ ರೋಗಲಕ್ಷಣ ಸಾಮಾನ್ಯವಾಗಿ kill switch ಮೇಲೆ ಹೊರಿಸಲ್ಪಡುತ್ತದೆ. ನಂತರ ನೀವು ನಿಜವಾಗಿ ಟನೆಲ್ ಮೂಲಕ ಬಯಸಿದ ಸೇವೆಗಳಿಗೆ ಅನುಮತಿ ನೀಡಿ, ಒಂದು ಸಮಯಕ್ಕೆ ಒಂದು ಸಣ್ಣ ನಿಯಮ, ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ತೆರೆಯುವ ಬದಲು. ಸಣ್ಣ ನಿಯಮಗಳೇ ನಿರಾಕರಣೆ ಸ್ಥಳದಲ್ಲಿರಲು ಕಾರಣ.
sudo ufw allow out to 198.51.100.10 port 1194 proto udp comment 'vpn server'
sudo ufw allow out on tun0 to any port 443 proto tcp comment 'web through tunnel'ಪರೀಕ್ಷಿಸುವಾಗ ಕ್ರಮ ಮುಖ್ಯ, ಏಕೆಂದರೆ ಟನೆಲ್ ಎದ್ದೇಳಲು ಅನುವು ಮಾಡುವುದು ಮೊದಲ ನಿಯಮ. ಅದನ್ನು ಸೇರಿಸಿ, ಸಂಪರ್ಕಿಸಿ, ಮತ್ತು ಸೇವಾ ನಿಯಮ ಸೇರಿಸುವ ಮೊದಲು ಟನೆಲ್ ಮೇಲಿದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ, ಏಕೆಂದರೆ ಎರಡನ್ನೂ ಒಟ್ಟಿಗೆ ಮಾಡಿದರೆ ವೈಫಲ್ಯ ಯಾವ ಅರ್ಧ ತಪ್ಪು ಎಂದು ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ. ಮೇಲಿನ ದಾಖಲೆ ವಿಳಾಸದ ಸ್ಥಳದಲ್ಲಿ ಕ್ಲೈಂಟ್ ಬಳಸಲು ಸಂರಚಿಸಲಾಗಿರುವ ಎಂಡ್ಪಾಯಿಂಟ್ ಇರಿಸಿ.
ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಸಂಪರ್ಕ ಕಡಿತಗೊಳಿಸಿ ಕ್ಲೈಂಟ್ ಭಾಗವನ್ನು ಮುಗಿಸಿ. ನಿರಾಕರಣೆ ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಹೊರಗಿಟ್ಟ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಇನ್ನೂ ನಿರಾಕರಿಸಬೇಕು, ಏಕೆಂದರೆ ಟನೆಲ್ ಮೇಲಿದ್ದಾಗ ಉತ್ತರಿಸುವ resolver ಸಂದೇಹದಲ್ಲಿ ನಿರಾಕರಿಸುವ ನೀತಿಯ ಅರ್ಧದಷ್ಟನ್ನು ಮಾತ್ರ ಆವರಿಸುತ್ತದೆ.
ಸಂಪರ್ಕಿಸುವ ಕ್ಲೈಂಟ್ ಇನ್ನೂ ಸ್ವೀಕೃತವಾಗಿಲ್ಲ
ಸರ್ವರ್ಗೆ ತನ್ನದೇ ದಿಕ್ಕನ್ನು ಪರಿಗಣಿಸಬೇಕು, ಮತ್ತು ಹ್ಯಾಂಡ್ಶೇಕ್ ಪೂರ್ಣಗೊಳಿಸುವ ಕ್ಲೈಂಟ್ ಸರ್ವರ್ ಅನ್ನು ಸ್ವೀಕರಿಸುವವರೆಗೆ ಸರ್ವರ್ನಲ್ಲಿ ಚಲಿಸುವ ಯಾವುದನ್ನೂ ತಲುಪಲಾರದು. ಸಾರ್ವಜನಿಕ listener ನಿಯಮ ಟನೆಲ್ ಇರುವುದಕ್ಕೆ ಮಾತ್ರ ಅನುಮತಿ ನೀಡುತ್ತದೆ; ಅದು ಟನೆಲ್ನ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಒಳಗೆ ಬಿಡುವುದಿಲ್ಲ. ಸರ್ವರ್ನಲ್ಲಿ ಅದು ಎರಡು ನಿಯಮಗಳು ಜೊತೆಗೆ ಸೇವೆ ನಿಜವಾಗಿ ಕೇಳುತ್ತಿದೆ ಎಂಬ ಒಂದು ಪರಿಶೀಲನೆ:
sudo ufw allow 1194/udp comment 'openvpn listener'
sudo ufw limit in on tun0 from 10.8.0.0/24 to any port 22 proto tcp comment 'admin over tunnel'
ss -ltn | grep ':22'ನಿಯಮದಲ್ಲಿನ ಪೂಲ್ ಸರ್ವರ್ ಹಂಚುವ ಶ್ರೇಣಿಗೆ ಸಮವಾಗಿರಬೇಕು, ಮತ್ತು ಟನೆಲ್ ಸಂಖ್ಯೆ ಸರ್ವರ್ ರಚಿಸಿದ ಸಂಖ್ಯೆಗೆ ಹೊಂದಿಕೆಯಾಗಬೇಕು, ಏಕೆಂದರೆ ಬೇರೆ ಇಂಟರ್ಫೇಸ್ಗೆ ಇರುವ ನಿಯಮ ನಿಯಮವಿಲ್ಲದಿರುವುದಕ್ಕಿಂತ ಬೇರೆಯಲ್ಲ. limit ಆಡಳಿತ ಪೋರ್ಟ್ಗೆ ಉದ್ದೇಶಪೂರ್ವಕ, ಏಕೆಂದರೆ ಅದು ಪುನರಾವರ್ತಿತ ಸಂಪರ್ಕಗಳನ್ನು ಮಿತಿಯಿಲ್ಲದೆ ಸ್ವೀಕರಿಸುವ ಬದಲು ಮಿತಿಗೊಳಿಸುತ್ತದೆ. listener ಪರಿಶೀಲನೆ ಮುಚ್ಚಿದ ಪೋರ್ಟ್ ಅನ್ನು ಎಸೆದ ಪ್ಯಾಕೆಟ್ನಿಂದ ಬೇರ್ಪಡಿಸುತ್ತದೆ, ಅವು ಕ್ಲೈಂಟ್ನ ದೃಷ್ಟಿಯಿಂದ ಒಂದೇ ರೀತಿ ಕಾಣುತ್ತವೆ. ಸಂಖ್ಯೆಯ ನಿಯಮಗಳೂ ಪೂರ್ಣ ಚಿತ್ರವಲ್ಲ: UFW ನ before ನಿಯಮಗಳು ಮತ್ತು ಕೈಯಿಂದ ಬರೆದ ಯಾವುದೇ nftables ಸಾಲು ಮೊದಲೇ ಹೊಂದಿಕೆಯಾಗುತ್ತವೆ ಮತ್ತು ಪಟ್ಟಿ ಅನುಮತಿಸುತ್ತದೆ ಎಂದು ತೋರುವ ಪ್ಯಾಕೆಟ್ ಅನ್ನೂ ಇನ್ನೂ ನಿರಾಕರಿಸಬಹುದು.