ಹಬ್‌ನಲ್ಲಿ WireGuard ಪೀರ್ ಗುಂಪುಗಳು: ಮೂಲದ ಮಾಲೀಕತ್ವ ಮತ್ತು ನೀತಿ
ಪ್ರತಿ ಪೀರ್‌ಗೆ ಸಣ್ಣ ಮೂಲ ವಿಳಾಸಗಳು ಮತ್ತು ಫಾರ್ವರ್ಡ್ ನೀತಿಯೊಂದಿಗೆ ಪೀರ್ ಗುಂಪುಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಇರಿಸಿ, ಪ್ರತಿ ಗುಂಪಿಗೆ ಪ್ರತ್ಯೇಕ ಟನೆಲ್ ಇಂಟರ್ಫೇಸ್ ಇಲ್ಲದೆ.
WireGuard ಚಲಾಯಿಸುವ ಹಬ್ ಪ್ರತಿ ಗುಂಪಿಗೆ ಪ್ರತ್ಯೇಕ ಇಂಟರ್ಫೇಸ್ ಅಥವಾ ರೂಟಿಂಗ್ ಕೋಷ್ಟಕವಿಲ್ಲದೆ ಪೀರ್ ಗುಂಪುಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಇರಿಸಬಹುದು. ಎರಡು ಕಾರ್ಯವಿಧಾನಗಳು ಈ ಕೆಲಸ ಮಾಡುತ್ತವೆ, ಮತ್ತು ಅವನ್ನು ಗೊಂದಲಗೊಳಿಸುವುದೇ ನೀತಿಯು ಸರಿಯಾಗಿ ಕಾಣುತ್ತದೆ ಆದರೆ ಏನನ್ನೂ ಮಾಡುವುದಿಲ್ಲ ಎಂಬುದಕ್ಕೆ ಸಾಮಾನ್ಯ ಕಾರಣ. ಒಂದು ಪದರ ಯಾರು ಮೂಲ ವಿಳಾಸವನ್ನು ಕೇಳಬಹುದು ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ. ಇನ್ನೊಂದು ಆ ಪ್ಯಾಕೆಟ್ ಎಲ್ಲಿಗೆ ಹೋಗಬಹುದು ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ.
ಎರಡು ಕೆಲಸಗಳು, ಪ್ರತ್ಯೇಕವಾಗಿ ಇರಿಸಲಾಗಿದೆ
ಟನೆಲ್ ಪದರವು ಸಣ್ಣ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸುತ್ತದೆ: ಈ ಪೀರ್‌ನ ಕೀಲಿ ಈ ಒಳಗಿನ ಮೂಲ ವಿಳಾಸವನ್ನು ಅಧಿಕೃತಗೊಳಿಸಿದೆಯೇ. ಫಾರ್ವರ್ಡಿಂಗ್ ಪದರವು ವಿಶಾಲವಾದ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸುತ್ತದೆ: ಈ ಪ್ಯಾಕೆಟ್ ಆ ಗಮ್ಯದ ಕಡೆಗೆ ಹೊರಡಬಹುದೇ. ಯಾವುದೂ ಇನ್ನೊಂದರ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಯಾವುದೂ ಒಂಟಿಯಾಗಿ ಪೂರ್ಣ ಪ್ರವೇಶ ನೀತಿಯಲ್ಲ.
ಈ ವಿಭಜನೆಯಿಂದಾಗಿಯೇ ಪೀರ್ ದೃಢೀಕೃತವಾಗಿ, ಸರಿಯಾದ ವಿಳಾಸದೊಂದಿಗೆ ಇದ್ದರೂ ತಲುಪಬಾರದ ಹೋಸ್ಟ್‌ಗೆ ತಲುಪಲಾಗದಿರಬಹುದು. ಇದು ವಿರುದ್ಧವನ್ನೂ ವಿವರಿಸುತ್ತದೆ: ಎಲ್ಲವನ್ನೂ ಅನುಮತಿಸುವ ಫೈರ್‌ವಾಲ್ ನಿಯಮವು ಯಾರು ಯಾವ ವಿಳಾಸವನ್ನು ಕೇಳಬಹುದು ಎಂಬುದರ ಬಗ್ಗೆ ಏನನ್ನೂ ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ.
ಎರಡೂ ಪದರಗಳನ್ನು ಒಟ್ಟಿಗೆ ವಿನ್ಯಾಸ ಮಾಡಿ, ನಂತರ ಎರಡನ್ನೂ ಪರೀಕ್ಷಿಸಿ. ಒಂದು ಪದರದಲ್ಲಿ ಸರಿಯಾಗಿ ಮತ್ತೊಂದರಲ್ಲಿ ಪರೀಕ್ಷಿಸದಿರುವ ಸಂರಚನೆಯು ಡೀಫಾಲ್ಟ್ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿ ತೆರೆದ ಅಥವಾ ಮುಚ್ಚಿದ ವೈಫಲ್ಯಕ್ಕೆ ಒಳಗಾಗುತ್ತದೆ.
ಪ್ರತಿ ಪೀರ್‌ಗೆ ಅದರ ಸ್ವಂತ ವಿಳಾಸವನ್ನಷ್ಟೇ ಕೊಡಿ
ಬಹು-ಹೋಸ್ಟ್ ಪೀರ್‌ಗಳು ಸರ್ವರ್ ಬದಿಯಲ್ಲಿ ಇಡೀ ಗುಂಪಿನ ಶ್ರೇಣಿಯನ್ನು ನೀಡಲು ಪ್ರಚೋದಿಸುತ್ತವೆ. ಆ ಅನುಮತಿ ಮೂಲ-ವಿಳಾಸದ ಕೋರಿಕೆಯಾಗಿದೆ, ಆದ್ದರಿಂದ ರಾಜಿಯಾದ ಅಥವಾ ತಪ್ಪಾಗಿ ಸಂರಚಿಸಿದ ಕ್ಲೈಂಟ್ ಶ್ರೇಣಿಯ ಯಾವುದೇ ವಿಳಾಸವನ್ನು ಪ್ರಸ್ತುತಪಡಿಸಬಹುದು ಮತ್ತು ಟನೆಲ್ ಅದನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ. ತನ್ನ ಒಳಗಿನ ವಿಳಾಸಕ್ಕಾಗಿ ಪ್ರತಿ ಪೀರ್‌ಗೆ /32 ನೀಡಿ. ಗುಂಪು ಶ್ರೇಣಿಗಳನ್ನು ಕ್ಲೈಂಟ್‌ಗಳಲ್ಲಿ ಮಾತ್ರ ಹೊಂದಿಸಿ, ಅಲ್ಲಿ ಅವು ಆ ಕ್ಲೈಂಟ್ ಯಾವ ಗಮ್ಯಗಳನ್ನು ತಲುಪಬಹುದು ಎಂಬುದನ್ನು ವಿವರಿಸುತ್ತವೆ, ಯಾವ ಮೂಲಗಳನ್ನು ಬಳಸಬಹುದು ಎಂಬುದನ್ನಲ್ಲ.
ನಂತರ ಫೈರ್‌ವಾಲ್ ನಂಬಬಹುದಾದ ಮೂಲದೊಂದಿಗೆ ಹೊಂದಿಸುತ್ತದೆ. ಗುಂಪಿನ ಶ್ರೇಣಿಗೆ ಬರೆದ ನಿಯಮವು ಉಪಯುಕ್ತ ಗುಂಪೀಕರಣವಾಗಿ ಉಳಿಯುತ್ತದೆ, ಮತ್ತು ಯಾವುದೇ ಒಂದೇ ಪೀರ್ ಇನ್ನೊಬ್ಬ ಸದಸ್ಯರಿಗೆ ಸೇರಿದ ವಿಳಾಸವನ್ನು ಕೇಳಲಾಗದಿದ್ದಾಗ ಮಾತ್ರ ಅದು ಅರ್ಥಪೂರ್ಣವಾಗುತ್ತದೆ.
ಗುಂಪುಗಳನ್ನು ಪ್ರತ್ಯೇಕಿಸುವ ಫಾರ್ವರ್ಡ್ ನೀತಿಯನ್ನು ಬರೆಯಿರಿ
ಇಲ್ಲಿನ ಆಸಕ್ತಿಕರ ಸಂಚಾರವು ಅದೇ ಟನೆಲ್ ಇಂಟರ್ಫೇಸ್‌ನಿಂದ ಒಳಬಂದು ಹೊರಹೋಗುತ್ತದೆ, ಆದ್ದರಿಂದ ಅದು ಹೋಸ್ಟ್‌ನ ಇನ್‌ಪುಟ್ ಮಾರ್ಗವನ್ನಲ್ಲ, ಫಾರ್ವರ್ಡ್ ಮಾರ್ಗವನ್ನು ದಾಟುತ್ತದೆ. ನಿಯಮಗಳು ಹೋಸ್ಟ್ ಹೊಂದಿರುವ ಯಾವುದೇ ಫೈರ್‌ವಾಲ್ ನಿರ್ವಾಹಕರ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಫಾರ್ವರ್ಡ್ ಸರಪಳಿಗೆ ಸೇರುತ್ತವೆ, ಮತ್ತು ಅವು ಪೂರ್ಣ ನಿಯಮಸಂಗ್ರಹವಲ್ಲ, ತುಣುಕುಗಳು.
iifname "wg0" oifname "wg0" ip saddr 10.66.10.0/24 ip daddr 10.66.10.0/24 accept iifname "wg0" oifname "wg0" ip saddr 10.66.20.0/24 ip daddr 10.66.20.0/24 accept iifname "wg0" oifname "wg0" drop
ಮೊದಲ ಎರಡು ನಿಯಮಗಳು ಪ್ರತಿ ಗುಂಪಿನ ಒಳಗೆ ಸಂಚಾರಕ್ಕೆ ಅನುಮತಿ ನೀಡುತ್ತವೆ. ಕೊನೆಯದು ಆ ಇಂಟರ್ಫೇಸ್ ದಾಟುವ ಉಳಿದೆಲ್ಲವನ್ನೂ ನಿರ್ಬಂಧಿಸುತ್ತದೆ, ಮತ್ತು ಅದೇ ಗುಂಪುಗಳ ನಡುವೆ ಪ್ರತ್ಯೇಕತೆಯನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ. ಬೇಕಿದ್ದರೆ ಇನ್ನೊಂದು ವಿಳಾಸ ಕುಟುಂಬಕ್ಕೆ ಸ್ಪಷ್ಟ ನಿಯಮಗಳನ್ನು ಸೇರಿಸಿ, ಏಕೆಂದರೆ IPv4 ಗಾಗಿ ಬರೆದ drop IPv6 ನ ವರ್ತನೆಯನ್ನು ಅನುಮತಿಸುವುದೂ ಇಲ್ಲ, ವಿವರಿಸುವುದೂ ಇಲ್ಲ.
ನೀತಿ ಅನ್ವಯವಾಗುತ್ತದೆಯೇ ಎಂಬುದನ್ನು ಕ್ರಮ ನಿರ್ಧರಿಸುತ್ತದೆ
ನಿಯಮಗಳ ಕ್ರಮವು ತುಣುಕಿಗಿಂತ ಹೆಚ್ಚು ಮುಖ್ಯ. ಸ್ಥಾಪಿತ ಸಂಪರ್ಕಗಳನ್ನು ಸ್ವೀಕರಿಸುವ ಸಾಮಾನ್ಯ ನಿಯಮವು ಈ ನಮೂದುಗಳ ಮೊದಲು ಇದ್ದರೆ, ಹಳೆಯ ಅಂತರ-ಗುಂಪು ಹರಿವು ಮುಂದುವರಿಯುತ್ತದೆ, ಆದ್ದರಿಂದ ಪ್ರತ್ಯೇಕತೆ ಹೊಸ ಸಂಪರ್ಕಗಳಿಗೆ ಮಾತ್ರ ಅನ್ವಯವಾಗುತ್ತದೆ. ಮತ್ತೆ ಲೋಡ್ ಮಾಡುವ ಮೊದಲು ಈ ಎರಡು ಫಲಿತಾಂಶಗಳಲ್ಲಿ ಯಾವುದು ಬೇಕು ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸಿ.
ಸ್ವೀಕೃತಿ ತೀರ್ಪು ಸಹ ಒಂದೇ ಕೊಕ್ಕೆಯಲ್ಲಿ ಸರಪಳಿಗಳ ನಡುವೆ ಯಾವಾಗಲೂ ಅಂತಿಮವಲ್ಲ. ಇನ್ನೊಂದು ಮೂಲ ಸರಪಳಿ ನಂತರ ಚಲಿಸಿದರೆ, ಪರಿಣಾಮಕಾರಿ ನೀತಿ ಸಂಯೋಜನೆ, ಆದ್ದರಿಂದ ನೀವು ಸಂಪಾದಿಸಿದ ಕಡತವನ್ನಲ್ಲ, ಕೌಂಟರ್‌ಗಳನ್ನು ಪರಿಶೀಲಿಸಿ. ಕೌಂಟರ್‌ಗಳು ಲಭ್ಯವಿರುವ ಅಗ್ಗದ ಸಾಕ್ಷ್ಯ. ಪ್ಯಾಕೆಟ್ ಎಣಿಕೆ ಇಲ್ಲದ ನಿಯಮ ಹೊಂದಿಕೆಯಾಗುವುದಿಲ್ಲ, ಮತ್ತು ನಂತರದ ಸರಪಳಿ ಸ್ವೀಕರಿಸುತ್ತಿರುವಾಗ ಹೊಂದಿಕೆಯಾಗುವ ನಿಯಮವು drop ತಪ್ಪು ಸ್ಥಳದಲ್ಲಿದೆ ಎಂದು ಹೇಳುತ್ತದೆ.
ಕಡತಗಳ ಸಂಖ್ಯೆಯನ್ನಲ್ಲ, ಮ್ಯಾಟ್ರಿಕ್ಸ್ ಅನ್ನು ಪರೀಕ್ಷಿಸಿ
ನಿರೀಕ್ಷಿತ ಫಲಿತಾಂಶಗಳ ಸಣ್ಣ ಮ್ಯಾಟ್ರಿಕ್ಸ್ ನಿರ್ಮಿಸಿ ಪ್ರತಿ ಕೋಶವನ್ನೂ ಪರಿಶೀಲಿಸಿ. ಗುಂಪು A ದಿಂದ ಗುಂಪು A ಗೆ ಕೆಲಸ ಮಾಡಬೇಕು, ಗುಂಪು B ದಿಂದ ಗುಂಪು B ಗೆ ಕೆಲಸ ಮಾಡಬೇಕು, ಮತ್ತು A ದಿಂದ B ಗೆ ಮಾಡಬಾರದು, ಎರಡೂ ದಿಕ್ಕುಗಳಲ್ಲಿ ಮತ್ತು ನೀವು ಬೆಂಬಲಿಸಿದರೆ ಎರಡೂ ವಿಳಾಸ ಕುಟುಂಬಗಳಿಗೆ.
nft list ruleset wg show wg0 allowed-ips ping -c 2 10.66.10.5 conntrack -L -s 10.66.20.7 2>/dev/null | head
ಮೊದಲ ಎರಡು ಯಾವುದು ಸಂರಚಿಸಲಾಗಿದೆ ಎಂಬುದನ್ನು ತೋರಿಸುತ್ತವೆ. ತಪ್ಪು ಗುಂಪಿನ ಸದಸ್ಯರಿಂದ ping ವಾಸ್ತವವಾಗಿ ಏನಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ತೋರಿಸುತ್ತದೆ. conntrack ಪಟ್ಟಿ ಹಳೆಯ ಹರಿವು ಇನ್ನೂ ಸ್ವೀಕರಿಸಲ್ಪಡುತ್ತಿದೆಯೇ ಎಂಬುದನ್ನು ತೋರಿಸುತ್ತದೆ, ಮತ್ತು ಪ್ರತ್ಯೇಕತೆಯ ಬದಲಾವಣೆಯು ಸದ್ದಿಲ್ಲದೆ ಜಾರಿಗೆ ಬರದಿರುವುದು ಹೀಗೆಯೇ.
ಹಬ್‌ನಲ್ಲಿನ ಹೋಸ್ಟ್ ಸೇವೆಗಳು ಮತ್ತು ಅದರ ಹಿಂದಿನ LAN ಗೆ ಪ್ರವೇಶ ಪ್ರತ್ಯೇಕ ನೀತಿಯ ಪ್ರತ್ಯೇಕ ಮಾರ್ಗಗಳು. ಮ್ಯಾಟ್ರಿಕ್ಸ್ ಅವುಗಳಲ್ಲಿ ಯಾವುದನ್ನು ಆವರಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ದಾಖಲಿಸಿ, ಏಕೆಂದರೆ ಪೀರ್-ಪೀರ್ ಸಂಚಾರವನ್ನಷ್ಟೇ ಪರೀಕ್ಷಿಸುವ ಪರೀಕ್ಷೆ ಅವುಗಳ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ.