ಎರಡು ಸೈಟ್, ಒಂದು ಸಬ್‌ನೆಟ್, ಒಂದು WireGuard ಹಬ್: ಇದನ್ನು ಕೆಲಸ ಮಾಡಿಸಿ

ಎರಡೂ ಸೈಟ್‌ಗಳು ಒಂದೇ LAN ಶ್ರೇಣಿಯನ್ನು ಬಳಸುತ್ತವೆ, ಮತ್ತು ಡಿಸೈನ್ ಅನ್ನು ನಿಜವಾಗಿ ಮುರಿಯುವುದು ಓವರ್‌ಲ್ಯಾಪ್ ಅಲ್ಲ. ಹಬ್ ಸೈಟ್ ಅನ್ನು ಕೇವಲ ಗಮ್ಯಸ್ಥಾನ ವಿಳಾಸದಿಂದ ಆಯ್ಕೆ ಮಾಡಬೇಕು, ಮತ್ತು ಎರಡು ಒಂದೇ ರೀತಿಯ ಗಮ್ಯಸ್ಥಾನಗಳು ಅದಕ್ಕೆ ಆಯ್ಕೆ ಮಾಡಲು ಏನನ್ನೂ ನೀಡುವುದಿಲ್ಲ. ಟನೆಲ್‌ಗೆ ಹೊಂದಿಸಲು ಕೆಲಸ ಮಾಡುತ್ತಿರುವ ಕಚೇರಿಯನ್ನು ಮರುಸಂಖ್ಯೆ ಮಾಡುವುದು ಸಾಮಾನ್ಯವಾಗಿ ಪ್ರತಿ ಪ್ರಕಟಿತ ಸೇವೆಗೆ ಟನೆಲ್ ಒಯ್ಯಬಲ್ಲ ಪ್ರತ್ಯೇಕ ವಿಳಾಸ ನೀಡುವುದಕ್ಕಿಂತ ಕೆಟ್ಟ ವ್ಯವಹಾರ. ಕೆಳಗಿನ ಡಿಸೈನ್ ಪ್ರತಿ ಸೈಟ್‌ಗೆ ಒಂದು HTTPS ಸೇವೆಯನ್ನು ಪ್ರಕಟಿಸುತ್ತದೆ, ಬೇರೆ ಏನೂ ಇಲ್ಲ.

ಓವರ್‌ಲ್ಯಾಪ್ ನಿಜವಾದ ಸಮಸ್ಯೆ ಏಕೆ ಅಲ್ಲ

WireGuard ಗಮ್ಯಸ್ಥಾನದ ಪ್ರಕಾರ ಮುಂದಿಸುತ್ತದೆ: peer ನ AllowedIPs ಯಾವ peer ಗೆ ಪ್ಯಾಕೆಟ್ ಸಿಗುತ್ತದೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ. ಎರಡು peer ಒಟ್ಟಿಗೆ 10.10.7.0/24 ಘೋಷಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ, ಅವುಗಳಲ್ಲಿ ಒಂದು ಪ್ರತಿ ಹುಡುಕಾಟವನ್ನೂ ಗೆಲ್ಲದ ಹೊರತು. ಇದು peer ಕೋಷ್ಟಕದ ಗುಣಲಕ್ಷಣ, ಟನೆಲ್‌ನದಲ್ಲ, ಆದ್ದರಿಂದ ಇಲ್ಲಿ ಪರಿಹಾರ ವಿಳಾಸ ಯೋಜನೆ, ರೂಟಿಂಗ್ ಉಪಾಯವಲ್ಲ.

ಯೋಜನೆ ಎಂದರೆ LAN ಅನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಘೋಷಿಸುವುದನ್ನು ನಿಲ್ಲಿಸುವುದು. ಬದಲಿಗೆ ಪ್ರತಿ ಸೇವೆಗೆ alias ಘೋಷಿಸಿ, ಪ್ರತಿ ಸೈಟ್‌ಗೆ ಒಂದು ವಿಳಾಸ, ಮತ್ತು ಪ್ರತಿ ಸೈಟ್‌ನ ಗೇಟ್‌ವೇ ಆ alias ಅನ್ನು ತನ್ನ ನಿಜವಾದ ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ಅನುವಾದಿಸಲಿ.

ಬಳಕೆದಾರರು ಎರಡು ಅನನ್ಯ ವಿಳಾಸಗಳನ್ನು ರೂಟ್ ಮಾಡುತ್ತಾರೆ, ಅಸ್ಪಷ್ಟ ಪೂರ್ವಪ್ರತ್ಯಯವನ್ನು ಎಂದಿಗೂ ನೋಡುವುದಿಲ್ಲ, ಮತ್ತು ಎರಡೂ ಕಚೇರಿಗಳಲ್ಲಿ ಏನೂ ಬದಲಾಗುವುದಿಲ್ಲ. ಇದು ಮಿತಿಯನ್ನು ಪ್ರಾಮಾಣಿಕವಾಗಿ ಹೇಳುತ್ತದೆ: ನೀವು ಪ್ರತಿ ಸೈಟ್‌ನಿಂದ ಒಂದು HTTPS ಸೇವೆಯನ್ನು ಪ್ರಕಟಿಸುತ್ತಿದ್ದೀರಿ, ಎರಡು ನೆಟ್‌ವರ್ಕ್‌ಗಳನ್ನು ವಿಲೀನ ಮಾಡುತ್ತಿಲ್ಲ. ಮುಂದಿನ ನಿಯಮಗಳು ಚಿಕ್ಕದಾಗಿ ಉಳಿಯುತ್ತವೆ ಏಕೆಂದರೆ ಹೇಳಿಕೆ ಸಂಕುಚಿತವಾಗಿದೆ. ವಿಶಾಲ ಹೇಳಿಕೆಗೆ ವಿಶಾಲ ನಿಯಮಗಳು ಬೇಕಾಗುತ್ತವೆ, ಮತ್ತು ಈ ಡಿಸೈನ್‌ಗಳು ಹೀಗೆಯೇ ಸಂಕೀರ್ಣವಾಗುತ್ತವೆ.

ಪ್ರತಿ ಸೈಟ್‌ಗೆ ಬಳಕೆದಾರರು ರೂಟ್ ಮಾಡಬಹುದಾದ alias ನೀಡಿ

ಬಳಕೆದಾರರ ಯಂತ್ರ, ಹಬ್ ಅಥವಾ ಎರಡೂ LAN ಗಳ ಯಾವುದರೊಂದಿಗೂ ಘರ್ಷಣೆ ಇಲ್ಲದ ಶ್ರೇಣಿಯಿಂದ ವಿಳಾಸಗಳನ್ನು ಆಯ್ಕೆ ಮಾಡಿ. ಇಲ್ಲಿ ಹಬ್ 10.66.0.1, ಬಳಕೆದಾರರು 10.66.0.10, ಗೇಟ್‌ವೇಗಳು 10.66.0.21 ಮತ್ತು 10.66.0.22, ಮತ್ತು ಎರಡು alias ಗಳು 10.77.1.20 ಮತ್ತು 10.77.2.20. ಹಬ್ ಪ್ರತಿ alias ಅನ್ನು ಅದನ್ನು ಹೊಂದಿರುವ peer ಮೂಲಕ ಪ್ರಕಟಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಒಂದು alias ಗೆ ಕಳುಹಿಸಿದ ಹೊರಹೋಗುವ ಪ್ಯಾಕೆಟ್ ಹೊಂದಿಕೆಯಾಗುವ ಸೈಟ್ ಮೂಲಕವೇ ಹೊರಬರಬಹುದು:

[Interface]
Address = 10.66.0.1/32
ListenPort = 51820
PrivateKey = HUB_KEY

[Peer]
PublicKey = USER_PUBLIC_KEY
AllowedIPs = 10.66.0.10/32

[Peer]
PublicKey = SITE_A_PUBLIC_KEY
AllowedIPs = 10.66.0.21/32, 10.77.1.20/32

[Peer]
PublicKey = SITE_B_PUBLIC_KEY
AllowedIPs = 10.66.0.22/32, 10.77.2.20/32

ಬಳಕೆದಾರರ ಬದಿಗೆ ಎರಡು alias ಗಳು ಮಾತ್ರ ಬೇಕು, ಇದು ಕ್ಲೈಂಟ್ ಸಂರಚನೆಯನ್ನು ಎರಡೂ LAN ಪೂರ್ವಪ್ರತ್ಯಯಗಳಿಂದ ಮುಕ್ತವಾಗಿರಿಸುತ್ತದೆ. ಆ ಸಂರಚನೆಯಲ್ಲಿ ಯಾವುದೇ ನಿಜವಾದ LAN ಅನ್ನು ಉಲ್ಲೇಖಿಸುವುದಿಲ್ಲ:

[Interface]
Address = 10.66.0.10/32
PrivateKey = USER_KEY

[Peer]
PublicKey = HUB_PUBLIC_KEY
Endpoint = hub.example.net:51820
AllowedIPs = 10.77.1.20/32, 10.77.2.20/32
PersistentKeepalive = 25

ಪ್ರತಿ ಗೇಟ್‌ವೇ ಹಬ್ ಮತ್ತು ಬಳಕೆದಾರರ ಮೂಲವನ್ನು ಘೋಷಿಸುತ್ತದೆ, ಬೇರೆ ಏನೂ ಇಲ್ಲ, ಆದ್ದರಿಂದ ಒಂದು ಸೈಟ್ ಎಂದಿಗೂ ಇನ್ನೊಂದು ಸೈಟ್‌ನ LAN ಅನ್ನು ತಿಳಿಯುವುದಿಲ್ಲ. Keepalive ಸೈಟ್‌ನ ಅಪ್‌ಲಿಂಕ್‌ನಲ್ಲಿ NAT ಮ್ಯಾಪಿಂಗ್ ಅನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ; ಅದು ಸಂಚಾರಕ್ಕೆ ಅನುಮತಿ ನೀಡುವುದಿಲ್ಲ, ಮತ್ತು ಫೈರ್‌ವಾಲ್ ಏನನ್ನು ಸ್ವೀಕರಿಸಬೇಕೆಂದು ಇನ್ನೂ ನಿರ್ಧರಿಸುತ್ತದೆ. ಒಂದು ಗೇಟ್‌ವೇಯ ಸಂರಚನೆಯನ್ನು ಇನ್ನೊಂದಕ್ಕೆ ನಕಲಿಸುವುದು ಸರಿ, ಖಾಸಗಿ ಕೀ, ಇಂಟರ್‌ಫೇಸ್ ವಿಳಾಸ ಮತ್ತು alias ಎಲ್ಲವೂ ಬದಲಾದರೆ.

ಹಬ್ ತನ್ನ ಎರಡು peer ಗಳ ನಡುವೆ ಏನನ್ನು ಅನುಮತಿಸಬೇಕು

ಹಬ್ ತನ್ನದೇ ಎರಡು peer ಗಳ ನಡುವೆ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಮುಂದಿಸುತ್ತದೆ, ಇದು forward ಸರಣಿಯ ನಿರ್ಧಾರ, ಇನ್‌ಪುಟ್ ನಿರ್ಧಾರವಲ್ಲ. ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ನ ಸಾಮಾನ್ಯ ವಿಧಾನದಿಂದ IPv4 ಮುಂದುವರಿಸುವಿಕೆಯನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಿ, ನಂತರ ಡಿಸೈನ್‌ಗೆ ಬೇಕಾದ ಜೋಡಿಗಳಿಗೆ ಮಾತ್ರ ಅನುಮತಿ ನೀಡಿ.

ಕೆಳಗಿನ ನಿಯಮ ಬಳಕೆದಾರರಿಗೆ ಒಂದು alias ಮತ್ತು ಒಂದು ಪೋರ್ಟ್‌ಗೆ ಅನುಮತಿ ನೀಡುತ್ತದೆ, ಮತ್ತು ಸಂಪರ್ಕ ಟ್ರ್ಯಾಕಿಂಗ್ ಮೂಲಕ ಹಿಂತಿರುಗುವ ಸಂಚಾರಕ್ಕೆ ಅನುಮತಿ ನೀಡುತ್ತದೆ. ಇದು forward ಮಾರ್ಗದಲ್ಲಿ ಉಳಿದೆಲ್ಲವನ್ನೂ ಬಿಡುತ್ತದೆ, ಮತ್ತು ಅದೇ ಮುಖ್ಯಾಂಶ:

nft add table inet hub_transit
nft add chain inet hub_transit forward '{ type filter hook forward priority 0 ; policy drop ; }'
nft add rule inet hub_transit forward ct state established,related accept
nft add rule inet hub_transit forward iifname wg0 oifname wg0 tcp dport 443 ip saddr 10.66.0.10 ip daddr 10.77.1.20 accept

ಎರಡು ವಿವರಗಳನ್ನು ಹೇಳುವುದು ಯೋಗ್ಯ, ಏಕೆಂದರೆ ಅವು ಮೌನ ವೈಫಲ್ಯಗಳನ್ನು ಉಂಟುಮಾಡುತ್ತವೆ. ಒಂದು ಮೂಲ ಸರಣಿಯಲ್ಲಿನ accept ಇನ್ನೊಂದರಲ್ಲಿನ drop ಅನ್ನು ಅತಿಕ್ರಮಿಸುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಇದನ್ನು ಇರುವ ನೀತಿಯೊಂದಿಗೆ ವಿಲೀನ ಮಾಡಿ, ಪಕ್ಕದಲ್ಲಿ ಲೋಡ್ ಮಾಡಬೇಡಿ. ಮತ್ತು ಮೂಲ ವಿಳಾಸ ವ್ಯಕ್ತಿಯನ್ನಲ್ಲ, ಸಾಧನವನ್ನು ಗುರುತಿಸುತ್ತದೆ; ಅಪ್ಲಿಕೇಶನ್ ದೃಢೀಕರಣವನ್ನು ನೆಟ್‌ವರ್ಕ್ ಸ್ವೀಕೃತಿಯಿಂದ ಪ್ರತ್ಯೇಕವಾಗಿರಿಸಿ.

Alias ನಿಜವಾದ ವಿಳಾಸವಾಗುವ ಸ್ಥಳ

ಸೈಟ್ A 10.77.1.20 ಗೆ ವಿನಂತಿಯನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ, ಗಮ್ಯಸ್ಥಾನವನ್ನು ನಿಜವಾದ ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ಮರುಬರೆಯುತ್ತದೆ, ಮತ್ತು ಮೂಲವನ್ನು ತನ್ನದೇ LAN ವಿಳಾಸಕ್ಕೆ ಮರುಬರೆಯುತ್ತದೆ, ಇದರಿಂದ ಉತ್ತರ ಟನೆಲ್‌ಗೆ ಮಾರ್ಗವಿಲ್ಲದೆ ಹಿಂತಿರುಗಬಹುದು. ಎರಡೂ ಅನುವಾದಗಳನ್ನು ಒಂದೇ ಸ್ಥಳದಲ್ಲಿ ಮಾಡುವುದು ಉಳಿದ ನೆಟ್‌ವರ್ಕ್ ಅನ್ನು alias ಬಗ್ಗೆ ಅಜ್ಞಾನವಾಗಿರಿಸುತ್ತದೆ. ಕೆಳಗಿನ ನಿಯಮಗಳೇ ಸಂಪೂರ್ಣ ಕಾರ್ಯವಿಧಾನ:

nft add table ip site_a_nat
nft add chain ip site_a_nat pre '{ type nat hook prerouting priority -100 ; policy accept ; }'
nft add chain ip site_a_nat post '{ type nat hook postrouting priority 100 ; policy accept ; }'
nft add rule ip site_a_nat pre iifname wg0 tcp dport 443 ip saddr 10.66.0.10 ip daddr 10.77.1.20 dnat to 10.10.7.20:443
nft add rule ip site_a_nat post iifname wg0 oifname lan0 tcp dport 443 ip saddr 10.66.0.10 ip daddr 10.10.7.20 snat to 10.10.7.2

ನಂತರ ಸೈಟ್ A ಯ forward ನೀತಿ ಅನುವಾದಿತ ಹರಿವನ್ನು ಟನೆಲ್ ಇಂಟರ್‌ಫೇಸ್‌ನಿಂದ LAN ಇಂಟರ್‌ಫೇಸ್‌ಗೆ, ಜೊತೆಗೆ ಹಿಂತಿರುಗುವ ದಿಕ್ಕನ್ನೂ ಅನುಮತಿಸಬೇಕು. forward hook ಗಮ್ಯಸ್ಥಾನವನ್ನು ಗಮ್ಯಸ್ಥಾನ ಅನುವಾದದ ನಂತರ ಮತ್ತು ಮೂಲ ಮರುಬರವಿಕೆಗೆ ಮೊದಲು ನೋಡುತ್ತದೆ, ಆದ್ದರಿಂದ ನಿಯಮ ನಿಜವಾದ ಅಪ್ಲಿಕೇಶನ್ ವಿಳಾಸವನ್ನು ಹೆಸರಿಸುತ್ತದೆ. ನಿಯಮ ಯಾವುದಕ್ಕೂ ಹೊಂದಿಕೆಯಾಗದಂತೆ ಕಂಡಾಗಲೆಲ್ಲ ಈ ಎರಡು hook ಗಳನ್ನು ಈ ಕ್ರಮದಲ್ಲಿ ಓದಿ. alias ವಿರುದ್ಧ ಬರೆದ forward ನಿಯಮ ಎಂದಿಗೂ ಹೊಂದಿಕೆಯಾಗಲಾರದು, ಏಕೆಂದರೆ ಆ hook ನಲ್ಲಿ alias ಇನ್ನು ಇಲ್ಲ.

ಸೈಟ್ B ಇದನ್ನು ತನ್ನದೇ alias ಮತ್ತು ತನ್ನದೇ ಕೀ ಜೊತೆ ಪುನರಾವರ್ತಿಸುತ್ತದೆ. ಇದು ಸೈಟ್ A ಯ ಖಾಸಗಿ ಕೀಯನ್ನು ಮತ್ತೆ ಬಳಸಬಾರದು, ಏಕೆಂದರೆ ಎರಡು peer ಒಂದೇ ಗುರುತನ್ನು ಹಂಚಿಕೊಳ್ಳುವುದು ನೋಡಲು ಕಷ್ಟ ಮತ್ತು ಫೈಲ್ ನಕಲಿಸಿ ಮಾಡಲು ಸುಲಭವಾದ ಸಂರಚನಾ ದೋಷ. ಎರಡೂ ಗೇಟ್‌ವೇ ದಾಖಲೆಗಳನ್ನು ಭಿನ್ನವಾಗಿರಬೇಕಾದ ಮೌಲ್ಯಗಳನ್ನು ಹೊರತುಪಡಿಸಿ ಒಂದೇ ರೀತಿ ಇರಿಸಿ, ಪರಿಶೀಲನೆಯಲ್ಲಿ ವ್ಯತ್ಯಾಸ ಎದ್ದು ಕಾಣಲಿ. ನಕಲಿಸಿದ ಫೈಲ್ ಆ ದೋಷದ ಸಾಮಾನ್ಯ ಮೂಲ.

ಮೂಲ ಮರುಬರವಿಕೆಗೆ ಬೆಲೆ ಇದೆ. ಅಪ್ಲಿಕೇಶನ್ ಗೇಟ್‌ವೇಯನ್ನು ತನ್ನ ಕ್ಲೈಂಟ್ ಎಂದು ನೋಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಅದರ ಲಾಗ್‌ಗಳು ಯಾವ ಬಳಕೆದಾರ ಸಂಪರ್ಕಿಸಿದನೆಂದು ತೋರಿಸುವುದಿಲ್ಲ. ಗೇಟ್‌ವೇಯ ಆಡಿಟ್ ಜಾಡನ್ನು ಇರಿಸಿ, ಮತ್ತು ಅನುವಾದ ತೆಗೆದುಹಾಕಿದ ನೆಟ್‌ವರ್ಕ್ ಗುರುತನ್ನು ಸರಿದೂಗಿಸಲು ಅಪ್ಲಿಕೇಶನ್ ಲಾಗಿನ್ ಅನ್ನು ದುರ್ಬಲಗೊಳಿಸಬೇಡಿ.

ಪ್ರಕಟಿತ ಎರಡೂ ಹೆಸರುಗಳು ಉತ್ತರಿಸುತ್ತವೆ ಎಂದು ಸಾಬೀತುಪಡಿಸುವುದು ಹೇಗೆ

ಪ್ರತಿ alias ಗೆ DNS ಹೆಸರು ನೀಡಿ ಮತ್ತು ಆ ಹೆಸರಿಗೆ ಅಪ್ಲಿಕೇಶನ್ ಮತ್ತು ಪ್ರಮಾಣಪತ್ರವನ್ನು ಸಂರಚಿಸಿ, ಏಕೆಂದರೆ ಅನುವಾದ ಮರುನಿರ್ದೇಶನಗಳನ್ನು ಅಥವಾ ಎಂಬೆಡ್ ಮಾಡಿದ ಸಂಪೂರ್ಣ URL ಗಳನ್ನು ಮರುಬರೆಯುವುದಿಲ್ಲ. ಪ್ರತಿ ಸೈಟ್‌ಗೆ ಒಂದು ಹೆಸರು ಬಳಸಿ, ಪ್ರಮಾಣಪತ್ರದ ಅಸಾಮರಸ್ಯ ಎಂದಿಗೂ ರೂಟಿಂಗ್ ದೋಷ ಎಂದು ತಪ್ಪಾಗಿ ಗ್ರಹಿಸದಿರಲಿ.

ನಿಜವಾದ ಕ್ಲೈಂಟ್‌ನಿಂದ ಪರೀಕ್ಷಿಸಿ, ಯಾವ ಸೈಟ್ ಉತ್ತರಿಸಿತೆಂದು ಖಚಿತಪಡಿಸಿ, ಮತ್ತು ಅನಧಿಕೃತ ಪೋರ್ಟ್ ಅನ್ನೂ ಪರೀಕ್ಷಿಸಿ. ಯಾವುದೇ NAT ಬದಲಾವಣೆಯ ನಂತರ ಹೊಸ ಸಂಪರ್ಕಗಳನ್ನು ಬಳಸಿ, ಏಕೆಂದರೆ ಸ್ಥಾಪಿತ ಸ್ಥಿತಿ ಹಳೆಯ ಮ್ಯಾಪಿಂಗ್ ಅನ್ನು ಉಳಿಸಿಕೊಳ್ಳುತ್ತದೆ:

wg show wg0 allowed-ips
sudo nft list ruleset
curl -sS -o /dev/null -w "%{http_code}\n" https://site-a.example.net/

ಮೊದಲ ಆಜ್ಞೆಯಲ್ಲಿ ಖಾಲಿ ಅಥವಾ ಅನಿರೀಕ್ಷಿತ alias ಎಂದರೆ ಯಾವುದೇ ಫೈರ್‌ವಾಲ್ ನಿಯಮ ಮುಖ್ಯವಾಗುವ ಮೊದಲೇ peer ಆಯ್ಕೆ ತಪ್ಪಾಗಿದೆ. alias ಸರಿಯಾಗಿದ್ದು ಹೆಸರು ಇನ್ನೂ ವಿಫಲವಾದರೆ, ಸಮಸ್ಯೆ DNS ಮತ್ತು ಪ್ರಮಾಣಪತ್ರಗಳಿಗೆ ಸ್ಥಳಾಂತರಗೊಂಡಿದೆ. ಎರಡೂ ಹೆಸರುಗಳು ಉತ್ತರಿಸಿ ಮೂರನೇ ಪೋರ್ಟ್ ಮುಚ್ಚಿದ್ದರೆ, ಡಿಸೈನ್ ತಾನು ಹೇಳಿದ್ದನ್ನು ಮಾಡುತ್ತದೆ: ಸಂಕುಚಿತವಾಗಿ ಪ್ರಕಟಿಸಿದ ಎರಡು ಸೇವೆಗಳು, ವಿಲೀನವಾದ ಎರಡು LAN ಅಲ್ಲ.