ನಿಮ್ಮ iptables ನಿಯಮವು ಸೇತುವೆ ಮಾಡಿದ VPN ಸಂಚಾರವನ್ನು ಏಕೆ ಎಂದಿಗೂ ನೋಡುವುದಿಲ್ಲ
ಸೇತುವೆ ಮಾಡಿದ ಫ್ರೇಮ್ಗಳು ನೀವು ಗಮನಿಸುತ್ತಿರುವ IP ಸರಪಳಿಯನ್ನು ಬೈಪಾಸ್ ಮಾಡಬಹುದು. ಇನ್ನೊಂದು ನಿಯಮ ಸೇರಿಸುವ ಮೊದಲು ಸ್ಥಳೀಯ bridge ಕುಟುಂಬವನ್ನು ಹಳೆಯ br_netfilter ಜೊತೆ ಹೋಲಿಸಿ.
ಒಂದೇ ಹೋಸ್ಟ್ನಲ್ಲಿರುವ ಎರಡು ವರ್ಚುವಲ್ ಯಂತ್ರಗಳು ಸೇತುವೆಯ ಮೂಲಕ LAN ತಲುಪುತ್ತವೆ, ಆದರೆ ip forward ಸರಪಳಿಯಲ್ಲಿ ಇಟ್ಟ ನಿಯಮವು ಎಂದಿಗೂ ಚಲಿಸದ ಕೌಂಟರ್ ತೋರಿಸುತ್ತದೆ. ಫ್ರೇಮ್ಗಳು ನಿಜ, ಸಂಚಾರ ಹಾದುಹೋಗುತ್ತಿದೆ, ಆದರೆ ನಿಯಮ ಸರಳವಾಗಿ ಅದರ ಮಾರ್ಗದಲ್ಲಿಲ್ಲ. Linux ಸೇತುವೆ ಸಂಚಾರವನ್ನು ಬಹಿರಂಗಪಡಿಸುವ ಎರಡು ವಿಧಾನಗಳನ್ನು ಹೋಲಿಸುವುದು ಈ ಮೌನವನ್ನು ವಿವರಿಸುತ್ತದೆ, ಮತ್ತು ಒಂದು ಹಳೆಯ ಮಾಡ್ಯೂಲ್ ಲೋಡ್ ಮಾಡುವುದು ಕಾಣುವುದಕ್ಕಿಂತ ಕೆಟ್ಟ ಉತ್ತರ ಏಕೆ ಎಂಬುದನ್ನೂ ವಿವರಿಸುತ್ತದೆ.
ಒಂದು ಹೋಸ್ಟ್ ಮೂಲಕ ಎರಡು ಮಾರ್ಗಗಳು
ಪ್ಯಾಕೆಟ್ ಈ ಹೋಸ್ಟ್ನಿಂದ ಎರಡು ಬಹಳ ವಿಭಿನ್ನ ರೀತಿಯಲ್ಲಿ ಹೊರಡಬಹುದು, ಮತ್ತು ವ್ಯತ್ಯಾಸವು ಯಾವ ಹುಕ್ಗಳು ಅದನ್ನು ನೋಡುತ್ತವೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ. ಗಮ್ಯಸ್ಥಾನವು ಭೌತಿಕ ಪೋರ್ಟ್ನ ಆಚೆ ಇದ್ದರೆ ಮತ್ತು ಫ್ರೇಮ್ ಸೇತುವೆಯ ಎರಡು ಪೋರ್ಟ್ಗಳ ನಡುವೆ ಸ್ವಿಚ್ ಆದರೆ, ಹೋಸ್ಟ್ Ethernet ಫ್ರೇಮ್ ಅನ್ನು ಮುಂದಕ್ಕೆ ಕಳುಹಿಸುತ್ತದೆ; ರೂಟಿಂಗ್ ಕೋಡ್ ಅನ್ನು ಕೇಳುವುದಿಲ್ಲ, ಮತ್ತು ಯಾವುದೇ ರೂಟ್ ಮಾಡಿದ ಹಾಪ್ ಸಂಭವಿಸುವುದಿಲ್ಲ. ಗಮ್ಯಸ್ಥಾನವು ಹೋಸ್ಟ್ ಸ್ವತಃ ಅಥವಾ ಟನಲ್ ಇಂಟರ್ಫೇಸ್ ಮೂಲಕ ತಲುಪುವ ನೆಟ್ವರ್ಕ್ ಆಗಿದ್ದರೆ, ಪ್ಯಾಕೆಟ್ ರೂಟ್ ಆಗುತ್ತದೆ ಮತ್ತು IP ಪದರದ ಹುಕ್ಗಳು ನಿಜವಾಗಿಯೂ ಅನ್ವಯವಾಗುತ್ತವೆ. ಈ ಕವಲನ್ನು ನೆನಪಿಡಿ, ಏಕೆಂದರೆ ಸರಪಳಿಗಳು ಮತ್ತು ಕುಟುಂಬಗಳ ಬಗ್ಗೆ ಪ್ರತಿಯೊಂದು ನಂತರದ ಪ್ರಶ್ನೆಯು ಫ್ರೇಮ್ ಎರಡು ಮಾರ್ಗಗಳಲ್ಲಿ ಯಾವುದನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ ಎಂಬುದರಿಂದ ಬರುತ್ತದೆ.
ಆ ವ್ಯತ್ಯಾಸವೇ ಏನನ್ನೂ ಎಣಿಸದ ನಿಯಮದ ಹಿಂದಿನ ಇಡೀ ಕಥೆ. veth9a1 ನಿಂದ enp3s0 ಗೆ ಸೇತುವೆ ಮಾಡಿದ ಫ್ರೇಮ್ IP ಸ್ಟ್ಯಾಕ್ ಅನ್ನಲ್ಲ, ಸೇತುವೆಯನ್ನು ದಾಟುತ್ತದೆ, ಆದ್ದರಿಂದ ip forward ಸರಪಳಿಗೆ ಹೊಂದಿಸಲು ಏನೂ ಕಾಣುವುದಿಲ್ಲ. ಹಳೆಯ ಉದಾಹರಣೆಯ ಇಂಟರ್ಫೇಸ್ ಹೆಸರುಗಳು ನಿಮಗೆ ಯಾವ ಮಾರ್ಗ ಇದೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಮೊದಲ ಹೆಜ್ಜೆ ನಿಯಮ ಸಮೂಹದ ಬದಲು ಟೋಪಾಲಜಿಯನ್ನು ನೋಡುವುದು.
ಟನಲ್ ಹೆಸರು ನೀಡಲು ಯೋಗ್ಯವಾದ ಮೂರನೇ ಪ್ರಕರಣವನ್ನು ಸೇರಿಸುತ್ತದೆ. TUN ಸಾಧನವು IP ಪ್ಯಾಕೆಟ್ಗಳನ್ನು ಹೋಸ್ಟ್ಗೆ ನೀಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಅವು ರೂಟ್ ಆಗಿ ನಿಜವಾಗಿಯೂ IP ಸರಪಳಿಗಳ ಮೂಲಕ ಹಾದುಹೋಗುತ್ತವೆ, ಆದರೆ ಸೇತುವೆಗೆ ಜೋಡಿಸಿದ TAP ಸಾಧನವು ಫ್ರೇಮ್ಗಳನ್ನು ನೀಡುತ್ತದೆ ಮತ್ತು ಸೇತುವೆ ಪ್ರಕರಣದಂತೆ ವರ್ತಿಸುತ್ತದೆ. ಸಾಧನದ ಪ್ರಕಾರವೇ ನಿರ್ಧರಿಸುತ್ತದೆ, ಉತ್ಪನ್ನದ ಹೆಸರಲ್ಲ.
ಸೇತುವೆ ಮಾಡಿದ ಫ್ರೇಮ್ ನೋಡಬಲ್ಲ ಎರಡು ಕುಟುಂಬಗಳನ್ನು ಹೋಲಿಸಿ
Linux nftables ನ bridge ಕುಟುಂಬದ ಮೂಲಕ ಸ್ಥಳೀಯ ಸೇತುವೆ ಫಿಲ್ಟರಿಂಗ್ ಬೆಂಬಲಿಸುತ್ತದೆ, ಮತ್ತು ಹಾರಾಟದಲ್ಲಿ ಫ್ರೇಮ್ಗಳನ್ನು ಪರಿಶೀಲಿಸಿ ಬಿಡಲು ಅದಕ್ಕೆ ಯಾವುದೇ ಹಳೆಯ ಮಾಡ್ಯೂಲ್ ಬೇಕಿಲ್ಲ. ಕರ್ನಲ್ನ ಸ್ವಂತ ಸೇತುವೆ ದಾಖಲೆಗಳು ಈ ಶಿಫಾರಸನ್ನು ನೇರವಾಗಿ ನೀಡುತ್ತವೆ, ಹುಡುಕಾಟ ಫಲಿತಾಂಶವು ಮಾಡ್ಯೂಲ್ ಲೋಡ್ ಮಾಡಲು ಹೇಳುವ ಮೊದಲು ತಿಳಿಯುವುದು ಯೋಗ್ಯ.
| Observation point | What it sees | What it costs |
|---|---|---|
nftables bridge family chains | Ethernet frames forwarded between bridge ports, in both directions | Rules must be written in bridge syntax with link-layer matches |
Legacy br_netfilter plus an ip chain | Bridged IPv4 and IPv6 packets, re-exposed through IP-layer hooks | Existing host rules may begin matching traffic they never saw before |
inet chain for routed traffic | Packets the host routes, including traffic arriving from a TUN device | No visibility into purely switched frames |
iptables ಬದಲು nft ಆಜ್ಞೆ ಬಳಸುವುದು ತನ್ನದೇ ಆದ ರೀತಿಯಲ್ಲಿ ನಿಯಮವನ್ನು ಸರಿಯಾದ ಕುಟುಂಬದಲ್ಲಿ ಇಡುವುದಿಲ್ಲ. bridge ಕುಟುಂಬದಲ್ಲಿ ಘೋಷಿಸಿದ ಸರಪಳಿ ಫ್ರೇಮ್ಗಳನ್ನು ನೋಡುತ್ತದೆ; ip, ip6 ಅಥವಾ inet ನಲ್ಲಿ ಘೋಷಿಸಿದ ಸರಪಳಿ ಅವುಗಳನ್ನು ನೋಡುವುದಿಲ್ಲ, ಯಾವ ಬೈನರಿ ಅದನ್ನು ರಚಿಸಿದರೂ ಸಹ. ಕುಟುಂಬವು ಸರಪಳಿಯ ಗುಣಲಕ್ಷಣ, ಅದನ್ನು ಟೈಪ್ ಮಾಡಿದ ಸಾಧನದ್ದಲ್ಲ.
ಹಳೆಯ ಮಾರ್ಗ ಬೇರೆ ರೀತಿ ಕೆಲಸ ಮಾಡುತ್ತದೆ, ಮತ್ತು ಅದಕ್ಕಾಗಿಯೇ ಅಭ್ಯಾಸದಿಂದ ಪಕ್ಷ ಆರಿಸುವ ಬದಲು ಹೋಲಿಸಬೇಕು. br_netfilter ಲೋಡ್ ಮಾಡಿ bridge-nf-call ಸೆಟ್ಟಿಂಗ್ಗಳನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಿದರೆ ಸೇತುವೆ ಮಾಡಿದ IPv4 ಮತ್ತು IPv6 ಸಂಚಾರವು IP ಪದರದ ಹುಕ್ಗಳ ಮೂಲಕ ಮತ್ತೆ ಬಹಿರಂಗವಾಗುತ್ತದೆ, ಆದ್ದರಿಂದ ಸಾಮಾನ್ಯ iptables ನಿಯಮವು ಅಂತಿಮವಾಗಿ ಅದನ್ನು ಹೊಂದಿಸಬಲ್ಲದು. ಫ್ರೇಮ್ಗಳು ಬದಲಾಗುವುದಿಲ್ಲ; ಅವು ಹಾದುಹೋಗುವ ಹುಕ್ಗಳ ಗುಂಪೇ ಬದಲಾಗುತ್ತದೆ, ಅಂದರೆ ಪ್ರತಿ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಹೋಸ್ಟ್ ನಿಯಮಕ್ಕೂ ಈಗ ಹೊಸ ಪ್ರೇಕ್ಷಕರಿದ್ದಾರೆ.
ನಿಯಮ ಸೇರಿಸುವ ಮೊದಲು ಪರಿಣಾಮಕಾರಿ ಮಾರ್ಗ ಓದಿ
ಮೂರು ಆಜ್ಞೆಗಳು ನೀವು ಎಲ್ಲಿದ್ದೀರಿ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತವೆ: ಸೇತುವೆ ಯಾವುದಕ್ಕೆ ಜೋಡಿಸಲಾಗಿದೆ, ಹಳೆಯ ಮಾಡ್ಯೂಲ್ ಸಕ್ರಿಯವಾಗಿದೆಯೇ, ಮತ್ತು bridge ಕುಟುಂಬದಲ್ಲಿ ಯಾವ ಸರಪಳಿಗಳು ಈಗಾಗಲೇ ಇವೆ. ಏನನ್ನೂ ಬರೆಯುವ ಮೊದಲು ಅವುಗಳನ್ನು ಚಲಾಯಿಸಿ, ಏಕೆಂದರೆ ಉತ್ತರವು ಎರಡು ವಿನ್ಯಾಸಗಳಲ್ಲಿ ಯಾವುದನ್ನು ವಿಸ್ತರಿಸುತ್ತಿದ್ದೀರಿ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ. ಈ ಹೆಜ್ಜೆಯನ್ನು ಬಿಟ್ಟುಬಿಡುವುದೇ ಸರಿಯಾದ ನಿಯಮವು ಏನೂ ಹಾದುಹೋಗದ ಸರಪಳಿಗೆ ಸೇರುವ ರೀತಿ.
bridge link show
lsmod | grep br_netfilter
nft list ruleset | grep -A4 "chain forward"ಔಟ್ಪುಟ್ ಪ್ರಕರಣಗಳನ್ನು ಸ್ವಚ್ಛವಾಗಿ ಬೇರ್ಪಡಿಸುತ್ತದೆ. ಸೇತುವೆಯ ಕೆಳಗೆ ಪಟ್ಟಿ ಮಾಡಿದ ಪೋರ್ಟ್ಗಳು ಯಾವ ಇಂಟರ್ಫೇಸ್ಗಳು ಸ್ವಿಚ್ ಆಗುತ್ತಿವೆ ಎಂಬುದನ್ನು ತಿಳಿಸುತ್ತವೆ; ಖಾಲಿ lsmod ಫಲಿತಾಂಶ ಎಂದರೆ ಸೇತುವೆ ಮಾಡಿದ ಫ್ರೇಮ್ಗಳ IP ಪದರದಲ್ಲಿ ಯಾವುದೇ ಗೋಚರತೆ ಇಲ್ಲ; bridge ಕುಟುಂಬದ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ forward ಸರಪಳಿ ಎಂದರೆ ನೀತಿಯ ಮಾಲೀಕರು ಈಗಾಗಲೇ ಇದ್ದಾರೆ ಮತ್ತು ನಿಮ್ಮ ನಿಯಮವು ತನ್ನದೇ ಹೊಸ ಸರಪಳಿಗಲ್ಲ, ಅಲ್ಲಿಗೇ ಸೇರುತ್ತದೆ.
ನಂತರ ಮತ್ತೆ ಓದಲು ಸುಲಭವಾದ ಒಂದು ನಿಯಮ ಸೇರಿಸಿ, ಕೌಂಟರ್ನೊಂದಿಗೆ ಮತ್ತು ತೀರ್ಪು ಬದಲಿಸದೆ, ಮತ್ತು ಒಂದು ಪ್ರತಿನಿಧಿ ಹರಿವನ್ನು ಸೇತುವೆಯ ಮೂಲಕ ಕಳುಹಿಸಿ. ಚಲಿಸುವ ಕೌಂಟರ್ ಫ್ರೇಮ್ ನಿಯಮವನ್ನು ತಲುಪಿದೆ ಎಂದು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ. ಅಷ್ಟೇ ಅದು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ನಿರಾಕರಿಸಿದ ಮಾರ್ಗದೊಂದಿಗೂ ಮುಂದುವರಿಯಿರಿ, ಏಕೆಂದರೆ ಎಲ್ಲವನ್ನೂ ಸ್ವೀಕರಿಸುವ ನೀತಿಯೂ ಚಲಿಸುವ ಕೌಂಟರ್ ಉತ್ಪಾದಿಸುತ್ತದೆ.
nft add rule bridge filter forward iifname "veth9a1" oifname "enp3s0" counter acceptಹಳೆಯ ಮಾಡ್ಯೂಲ್ ವರ್ತನೆಯನ್ನು ಎಲ್ಲಿ ಬದಲಿಸುತ್ತದೆ
ಚಾಲನೆಯಲ್ಲಿರುವ ಸೇತುವೆಯಲ್ಲಿ ಹಳೆಯ ಮಾರ್ಗವನ್ನು ಸಕ್ರಿಯಗೊಳಿಸುವುದು ಗೋಚರತೆ ಸೇರಿಸುವ ತಟಸ್ಥ ಕ್ರಿಯೆಯಲ್ಲ. ಮೊದಲು ಸೇತುವೆ ಸಂಚಾರಕ್ಕೆ ತಲುಪಲಾಗದ ನಿಯಮಗಳು ತಲುಪಬಹುದಾದವಾಗುತ್ತವೆ, ಅವುಗಳಲ್ಲಿ ಬೇರೆ ಇಂಟರ್ಫೇಸ್ಗಾಗಿ ಬರೆದ ಹೋಸ್ಟ್ ನಿಯಮಗಳೂ ಸೇರಿವೆ, ಮತ್ತು ip forward ಸರಪಳಿಯ ಡೀಫಾಲ್ಟ್ drop ನೀತಿಯು ಮೊದಲು ಸ್ಪರ್ಶವಿಲ್ಲದೆ ಹಾದುಹೋಗುತ್ತಿದ್ದ ಫ್ರೇಮ್ಗಳಿಗೂ ಇದ್ದಕ್ಕಿದ್ದಂತೆ ಅನ್ವಯವಾಗಬಹುದು. ಆ ಸೇತುವೆಯ ಮೂಲಕ ನಿರ್ವಹಿಸಲ್ಪಡುವ ಹೋಸ್ಟ್ನಲ್ಲಿ ಫಲಿತಾಂಶ ಕನ್ಸೋಲ್ ಇಲ್ಲದ ಲಾಕ್ ಔಟ್. ಇದು ಕಾಲ್ಪನಿಕ ವೈಫಲ್ಯ ಮೋಡ್ ಅಲ್ಲ; ನೀವು ಈಗಷ್ಟೇ ವಿಸ್ತರಿಸಿದ ಮಾರ್ಗದಿಂದ ತಲುಪುವ ಯಂತ್ರದಲ್ಲಿ ಹುಕ್ಗಳ ಗುಂಪನ್ನು ವಿಸ್ತರಿಸುವ ಸಾಮಾನ್ಯ ಪರಿಣಾಮ ಇದು.
ಹೆಚ್ಚು ಸುರಕ್ಷಿತ ಕ್ರಮವೆಂದರೆ ಯಾವ ಕುಟುಂಬವು ನೀತಿಯನ್ನು ಹೊಂದಿದೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುವುದು, ನಿಯಮಗಳನ್ನು ಅಲ್ಲಿಯೇ ಬರೆಯುವುದು, ಮತ್ತು ಯಾವುದೇ sysctl ಬದಲಿಸುವ ಮೊದಲು ಸ್ವತಂತ್ರ ಮರುಪ್ರಾಪ್ತಿ ಮಾರ್ಗವನ್ನು ಇಟ್ಟುಕೊಳ್ಳುವುದು. ಎರಡು ಕುಟುಂಬಗಳು ನಿಯಮಗಳನ್ನು ಹೊಂದಿದ್ದರೆ, ಯಾವುದು ಅಧಿಕೃತ ಎಂಬುದನ್ನು ದಾಖಲಿಸಿ; ಎರಡು ಅತಿಕ್ರಮಿಸುವ ನೀತಿಗಳೇ ಪ್ಯಾಕೆಟ್ ಒಂದೆಡೆ ಸ್ವೀಕರಿಸಲ್ಪಟ್ಟು ಇನ್ನೊಂದೆಡೆ ತಿರಸ್ಕರಿಸಲ್ಪಡುವ ರೀತಿ, ಓದಲು ಒಂದೂ ಫೈಲ್ ಇಲ್ಲದೆ.
ಪ್ರತ್ಯೇಕತೆಗೆ ಸ್ವತಃ ಇನ್ನೂ ಪೂರ್ಣ ವಿನ್ಯಾಸ ಬೇಕು. ಒಂದು ಮೂಲವನ್ನು ಒಂದು ಗಮ್ಯಸ್ಥಾನಕ್ಕೆ ಅನುಮತಿಸುವುದು ಒಂದು ಹರಿವು ಕೆಲಸ ಮಾಡುತ್ತದೆ ಎಂದಷ್ಟೇ ಸಾಬೀತುಪಡಿಸುತ್ತದೆ, ಆದರೆ ಅಗತ್ಯ ಸಾಮಾನ್ಯವಾಗಿ VM ತನ್ನ ನೆರೆಹೊರೆಯವರಿಗೆ ಅಥವಾ ಹೋಸ್ಟ್ಗೆ ತಲುಪದಿರುವುದು. ನಿರಾಕರಣೆ ನಿಯಮಗಳ ಮೇಲಿನ ಕೌಂಟರ್ಗಳು ಸ್ವೀಕೃತಿ ನಿಯಮದ ಕೌಂಟರ್ಗಿಂತ ಹೆಚ್ಚು ಮುಖ್ಯ, ಏಕೆಂದರೆ ಸ್ವೀಕೃತಿ ಕೌಂಟರ್ ಚಲಿಸುತ್ತದೆ ಎಂದು ನೀವು ಈಗಾಗಲೇ ನಿರೀಕ್ಷಿಸಿದ್ದೀರಿ.
ಕೊನೆಯದಾಗಿ, ಹೋಸ್ಟ್ ಇನ್ಪುಟ್ ಪ್ರಕರಣವನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಇಡಿ. ಸೇತುವೆಯ ಸ್ವಂತ IP ಗೆ ಉದ್ದೇಶಿಸಿದ ಸಂಚಾರವು input ಗೆ ಬರುತ್ತದೆ, forward ಗೆ ಅಲ್ಲ, ಮತ್ತು forward ನಲ್ಲಿನ ನಿಯಮವು ನೀವು ಯಾವ ಕುಟುಂಬ ಆರಿಸಿದರೂ ಅದನ್ನು ಎಂದಿಗೂ ನೋಡುವುದಿಲ್ಲ. ಮೂರು ಪ್ರಕರಣ, ಎರಡು ಕುಟುಂಬ, ಒಂದು ಪಾಠ: ಮಾರ್ಗವು ಹುಕ್ ಅನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ, ಮತ್ತು ಹುಕ್ ನಿಮ್ಮ ನಿಯಮ ಎಲ್ಲಿಯಾದರೂ ಇದೆಯೇ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ.