ಇನ್ನೊಂದು NAT ಸೇರಿಸುವ ಮೊದಲು ಖಾಸಗಿ LAN ನಡುವೆ ರೂಟಿಂಗ್ ಮಾಡಿ
ಅತಿವ್ಯಾಪಿಸುವ ವಿಳಾಸ ಸ್ಥಳ, ಕಾಣೆಯಾದ ಹಿಂತಿರುಗು ಮಾರ್ಗ ಅಥವಾ ಅವಿಶ್ವಾಸನೀಯ ಟ್ರಾನ್ಸಿಟ್ ರೂಟಿಂಗ್, NAT ಮತ್ತು ಸುರಂಗದ ನಡುವೆ ಆಯ್ಕೆಯನ್ನು ನಿರ್ಧರಿಸುತ್ತವೆ. ಫೈರ್ವಾಲ್ ಸಂಪಾದಿಸುವ ಮೊದಲು ಈ ಮೂರನ್ನು ಪರಿಶೀಲಿಸಿ.
ಎರಡು ಆಂತರಿಕ ಫೈರ್ವಾಲ್ಗಳು, ಒಂದು ಖಾಸಗಿ ಟ್ರಾನ್ಸಿಟ್ ವಿಭಾಗ, ಮತ್ತು ಪ್ರತಿ LAN ನಲ್ಲಿ ಕೆಲವು ಹೋಸ್ಟ್ಗಳು ಇನ್ನೊಂದರೊಂದಿಗೆ ಮಾತನಾಡಲು ಅನುಮತಿ ಕೋರಿಕೆ. ಸಹಜ ಪ್ರತಿಕ್ರಿಯೆ ಎಂದರೆ VPN ಎಬ್ಬಿಸುವುದು ಅಥವಾ ಎರಡನೇ NAT ಪದರ ಸೇರಿಸುವುದು, ಮತ್ತು ಎರಡೂ ಪ್ರತಿಕ್ರಿಯೆಗಳು ಸಮಸ್ಯೆಗೆ ಯೋಗ್ಯವಾದದ್ದಕ್ಕಿಂತ ಹೆಚ್ಚು ವೆಚ್ಚ ಮಾಡುತ್ತವೆ. ಸಾಮಾನ್ಯ ರೂಟಿಂಗ್ ಸಾಕು ಮೂರು ಷರತ್ತುಗಳು ಪೂರೈಸಿದಾಗ: ವಿಳಾಸ ಶ್ರೇಣಿಗಳು ಅತಿವ್ಯಾಪಿಸುವುದಿಲ್ಲ, ಎರಡೂ ಬದಿಗಳು ಇನ್ನೊಂದು LAN ಗೆ ಸಂಚಾರವನ್ನು ಹಿಂತಿರುಗಿಸಬಲ್ಲವು, ಮತ್ತು ಟ್ರಾನ್ಸಿಟ್ ವಿಭಾಗವು ಡೇಟಾಗೆ ಈಗಾಗಲೇ ಸಾಕಷ್ಟು ವಿಶ್ವಾಸನೀಯವಾಗಿದೆ. ಏನನ್ನೂ ವಿನ್ಯಾಸ ಮಾಡುವ ಮೊದಲು ಈ ಮೂರನ್ನು ಪರಿಶೀಲಿಸಿ, ಏಕೆಂದರೆ ಪ್ರತಿಯೊಂದೂ ಉತ್ತರವನ್ನು ಬದಲಿಸುತ್ತದೆ.
ವಿನ್ಯಾಸವನ್ನು ನಿರ್ಧರಿಸುವ ಮೂರು ಷರತ್ತುಗಳು
ಮೊದಲ ಷರತ್ತು ವಿಳಾಸ ಸ್ಥಳ. ಎರಡೂ LAN ಒಂದೇ RFC 1918 ಬ್ಲಾಕ್ ಬಳಸಿದರೆ, ರೂಟಿಂಗ್ ಅವನ್ನು ಪ್ರತ್ಯೇಕಿಸಲಾರದು ಮತ್ತು ಅನುವಾದವು ಐಚ್ಛಿಕವಲ್ಲದೆ ಅನಿವಾರ್ಯವಾಗುತ್ತದೆ. ಎರಡನೆಯದು ಹಿಂತಿರುಗು ಮಾರ್ಗ: A ಯಿಂದ B ಗೆ ಮಾರ್ಗವು B ಕೂಡ A ಯ LAN ತಲುಪುವ ಬಗ್ಗೆ ತಿಳಿಯದಿದ್ದರೆ ನಿಷ್ಪ್ರಯೋಜಕ, ಮತ್ತು ಅಸಮಮಿತ ಜ್ಞಾನವೇ ರೂಟೆಡ್ ವಿನ್ಯಾಸವು ಉತ್ತರಗಳನ್ನು ಸದ್ದಿಲ್ಲದೆ ಬಿಟ್ಟುಬಿಡುವ ಸಾಮಾನ್ಯ ಕಾರಣ.
ಮೂರನೆಯದು ವಿಶ್ವಾಸ. ರೂಟಿಂಗ್ ಪ್ಯಾಕೆಟ್ಗಳನ್ನು ಸಾಗಿಸುತ್ತದೆ; ಅವನ್ನು ರಕ್ಷಿಸುವುದಿಲ್ಲ. ಒಂದೇ ಕಟ್ಟಡದೊಳಗಿನ ಖಾಸಗಿ ಟ್ರಾನ್ಸಿಟ್ ವಿಭಾಗವು ಪೂರೈಕೆದಾರರಿಗೆ ಹಸ್ತಾಂತರಿಸುವುದಕ್ಕಿಂತ ಅಥವಾ ಹಂಚಿಕೆಯ ಕ್ಯಾಂಪಸ್ ಬೆನ್ನೆಲುಬನ್ನು ದಾಟುವ ಸಂಪರ್ಕಕ್ಕಿಂತ ಬೇರೆ ವಿಷಯ. ವಿಭಾಗವು ವಿಶ್ವಾಸನೀಯವಲ್ಲದಿದ್ದರೆ, ಉತ್ತರ ಎರಡು ಫೈರ್ವಾಲ್ಗಳ ನಡುವಿನ ಸುರಂಗ, ಮತ್ತು ಕೆಳಗಿನ ರೂಟಿಂಗ್ ಯೋಜನೆ ಅದರ ಒಳಗೂ ಅನ್ವಯಿಸುತ್ತದೆ.
ಮೂರೂ ಒಂದೇ ದಿಕ್ಕಿಗೆ ತೋರಿಸಿದಾಗ ಮಾತ್ರ ಸರಳ ವಿನ್ಯಾಸ ಗೆಲ್ಲುತ್ತದೆ. ಅವುಗಳಲ್ಲಿ ಒಂದು ವಿಫಲವಾದರೆ, ಅನುವಾದದಿಂದ ಮುಚ್ಚಿಡುವ ಬದಲು ಆ ಷರತ್ತನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಸರಿಪಡಿಸಿ, ಏಕೆಂದರೆ NAT ವೈಫಲ್ಯವನ್ನು ಮುಚ್ಚುತ್ತದೆ, ಪರಿಹರಿಸುವುದಿಲ್ಲ.
ಟ್ರಾನ್ಸಿಟ್ ನೆಟ್ವರ್ಕ್ನಲ್ಲಿ ರೂಟ್ ಯೋಜನೆ ಕಟ್ಟಿ
ಪ್ರತಿ ಫೈರ್ವಾಲ್ಗೆ ಹಂಚಿಕೆಯ ವಿಭಾಗದಲ್ಲಿ ಒಂದು ವಿಳಾಸ ಕೊಡಿ ಮತ್ತು ಪ್ರತಿ ದೂರದ LAN ಗೆ ಒಂದು ನಿರ್ದಿಷ್ಟ ಮಾರ್ಗ ಸೇರಿಸಿ. ಇರುವ ಸಂರಚನೆಯಲ್ಲಿ ಬೇರೆ ಏನನ್ನೂ ಸರಿಸಬೇಕಿಲ್ಲ, ವಿಶೇಷವಾಗಿ ಇಂಟರ್ನೆಟ್ ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗವು ಇರುವಲ್ಲೇ ಇರಬೇಕು. ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗವನ್ನು ಸಹವರ್ತಿ ಫೈರ್ವಾಲ್ನಿಂದ ಬದಲಿಸಿದರೆ ಪ್ರತಿ ಅಸಂಬದ್ಧ ಗಮ್ಯಸ್ಥಾನವೂ ಟ್ರಾನ್ಸಿಟ್ ಮೂಲಕ ಹೋಗುತ್ತದೆ, ಅದು ಕೇಳಿದ ಬದಲಾವಣೆಗಿಂತ ಬಹಳ ದೊಡ್ಡದು. pfSense ನ ಸ್ಥಿರ ರೂಟಿಂಗ್ ದಾಖಲೆ ಆ ವೇದಿಕೆಗೆ ಅದೇ ಮಾರ್ಗ-ಜೊತೆ-ಗೇಟ್ವೇ ಮಾದರಿಯನ್ನು ವಿವರಿಸುತ್ತದೆ, ಮತ್ತು ನೀವು ನಿಜವಾಗಿ ನಡೆಸುವ ಯಾವುದೇ ಫೈರ್ವಾಲ್ನಲ್ಲಿ ಸಮಾನ ನಿಯಂತ್ರಣ ಇದೆ.
| Firewall | Remote LAN | Next hop on the transit |
|---|---|---|
| A | 10.40.0.0/24 | 192.0.2.20 |
| B | 10.30.0.0/24 | 192.0.2.10 |
ಫೈರ್ವಾಲ್ A 10.30.0.0/24 ಸೇವೆ ಮಾಡುತ್ತದೆ ಮತ್ತು ಫೈರ್ವಾಲ್ B 10.40.0.0/24, ಎರಡು ಟ್ರಾನ್ಸಿಟ್ ವಿಳಾಸಗಳು 192.0.2.0/24 ನಲ್ಲಿವೆ. ಪ್ರತಿ LAN ಹೋಸ್ಟ್ ತನ್ನ ಸ್ಥಳೀಯ ಫೈರ್ವಾಲ್ ಅನ್ನು ಗೇಟ್ವೇ ಆಗಿ ಇಟ್ಟುಕೊಳ್ಳುತ್ತದೆ, ಹಾಗಾಗಿ ಹೊಸ ಸ್ಥಿತಿ ಪ್ರತಿ ಬದಿಯಲ್ಲಿ ಒಂದು ಮಾರ್ಗ ಮಾತ್ರ. Linux ಆಧಾರಿತ ಫೈರ್ವಾಲ್ನಲ್ಲಿ ಅದೇ ಯೋಜನೆ ಹೀಗೆ ಕಾಣುತ್ತದೆ, ಮತ್ತು ಫಾರ್ವರ್ಡಿಂಗ್ ಸಕ್ರಿಯವಾಗಿರಬೇಕು, ಇಲ್ಲದಿದ್ದರೆ ಮಾರ್ಗ ಪರಿಹಾರವಾಗುತ್ತದೆ ಆದರೆ ಪ್ಯಾಕೆಟ್ ಬಿಸಾಡಲ್ಪಡುತ್ತದೆ.
sysctl -w net.ipv4.ip_forward=1 ip route add 10.40.0.0/24 via 192.0.2.20 dev eth1 ip route get 10.40.0.15 traceroute -n 10.40.0.15
ಫಿಲ್ಟರಿಂಗ್ ಅನ್ನು ಅನುವಾದದಿಂದ ಬೇರ್ಪಡಿಸಿ
ರೂಟಿಂಗ್ ಮತ್ತು ನೀತಿ ಬೇರೆ ಬೇರೆ ನಿಯಂತ್ರಣಗಳು, ಮತ್ತು ಎರಡನೆಯದರಲ್ಲಿ ಹೆಚ್ಚಿನ ರೂಟೆಡ್ ವಿನ್ಯಾಸಗಳು ನಿಜವಾಗಿ ವಿಫಲವಾಗುತ್ತವೆ. ಪ್ಯಾಕೆಟ್ಗಳು ನಿಜವಾಗಿ ದಾಟುವ ಪ್ರವೇಶ ಗಡಿಯಲ್ಲಿ ನಿರ್ದಿಷ್ಟ ಮೂಲಗಳು, ಗಮ್ಯಸ್ಥಾನಗಳು ಮತ್ತು ಸೇವೆಗಳಿಗೆ ಅನುಮತಿ ನೀಡಿ, ಮತ್ತು WAN ನಂತಹ ಇಂಟರ್ಫೇಸ್ ಲೇಬಲ್ ಹೆಸರೇ ಹೊರತು ವಿಶ್ವಾಸದ ಹೇಳಿಕೆಯಲ್ಲ ಎಂದು ನೆನಪಿಡಿ. ಖಾಸಗಿ ಸಂಚಾರ ಸಾಗಿಸುವ ಟ್ರಾನ್ಸಿಟ್ ಪೋರ್ಟ್ನಲ್ಲಿ ಖಾಸಗಿ ವಿಳಾಸ ಬ್ಲಾಕಿಂಗ್ ಇನ್ನೂ ಡೀಫಾಲ್ಟ್ ಆಗಿ ಸಕ್ರಿಯವಾಗಿರಬಹುದು.
ನಂತರ NAT ಆಗುತ್ತಿಲ್ಲ ಎಂದು ತೀರ್ಮಾನಿಸುವ ಮೊದಲು ಹೊರಹೋಗುವ ಅನುವಾದವನ್ನು ನೋಡಿ. ಸ್ವಯಂಚಾಲಿತ ಹೊರಹೋಗುವ ನಿಯಮಗಳು ಎಂದಿಗೂ ಅನುವಾದಕ್ಕೆ ಉದ್ದೇಶಿಸದ ಸಂಚಾರವನ್ನು ಮತ್ತೆ ಬರೆಯಬಹುದು, ಮತ್ತು ಅದು ಇನ್ನೊಂದು ಬದಿಗೆ ತನ್ನ ನೀತಿ ಮತ್ತು ಲಾಗ್ಗಳಿಗೆ ಬೇಕಾದ ಮೂಲ ವಿಳಾಸಗಳನ್ನು ನಾಶ ಮಾಡುತ್ತದೆ. ಆಯ್ಕೆ ಮಾಡಿದ ಹರಿವುಗಳು ಮೂಲ ವಿಳಾಸಗಳನ್ನು ಉಳಿಸಿಕೊಳ್ಳುತ್ತವೆ ಎಂದು ಖಚಿತಪಡಿಸಿ, ಮತ್ತು ಇನ್ನೂ ಬೇಕಿರುವ ಸಂಚಾರಕ್ಕೆ ಇಂಟರ್ನೆಟ್ ಅನುವಾದ ನಿಯಮಗಳನ್ನು ಹಾಗೆಯೇ ಬಿಡಿ.
iptables -t nat -S POSTROUTING iptables -t nat -L POSTROUTING -n -v tcpdump -ni eth1 -c 5 host 10.40.0.15
NAT ಪ್ರಾಮಾಣಿಕ ಉತ್ತರವಾಗುವಾಗ
ವಿಳಾಸ ಶ್ರೇಣಿಗಳು ನಿಜವಾಗಿ ಅತಿವ್ಯಾಪಿಸಿದಾಗ ಮತ್ತು ಮರುಸಂಖ್ಯೀಕರಣ ಲಭ್ಯವಿಲ್ಲದಿದ್ದಾಗ, ಅಥವಾ ನೀತಿಯು ಒಂದು ಬದಿ ಉಪಜಾಲದ ಬದಲು ಒಂದೇ ವಿಳಾಸವನ್ನು ನೋಡಬೇಕೆಂದು ಒತ್ತಾಯಿಸಿದಾಗ ಅನುವಾದವು ತನ್ನ ಸ್ಥಾನ ಗಳಿಸುತ್ತದೆ. ಅಂತಹ ಸಂದರ್ಭಗಳಲ್ಲಿ ಉದ್ದೇಶಪೂರ್ವಕ ಒಂದಕ್ಕೊಂದು ಅಥವಾ ಪೋರ್ಟ್-ಸೀಮಿತ ಮ್ಯಾಪಿಂಗ್ ತಿಳಿದ ಪರಿಣಾಮಗಳಿರುವ ವಿನ್ಯಾಸ ನಿರ್ಣಯ, ಕೆಲಸ ನಡೆಸುವ ಉಪಾಯವಲ್ಲ.
ಗಟ್ಟಿಯಾಗಿ ಹೇಳಬೇಕಾದ ಪರಿಣಾಮ ಎಂದರೆ ಇನ್ನೊಂದು ಬದಿ ಇನ್ನು ಮುಂದೆ ಪ್ರತ್ಯೇಕ ಮೂಲಗಳನ್ನು ನೋಡಲಾಗದು ಅಥವಾ ಫಿಲ್ಟರ್ ಮಾಡಲಾಗದು. ಲಾಗ್ಗಳು ಅನುವಾದಿಸುವ ವಿಳಾಸಕ್ಕೆ ಕುಸಿಯುತ್ತವೆ, ಪ್ರತಿ-ಹೋಸ್ಟ್ ನೀತಿ ಕೆಲಸ ಮಾಡುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತದೆ, ಮತ್ತು ಸಮಸ್ಯೆ ಪರಿಹಾರವು ನಿರ್ದಿಷ್ಟ ಕ್ಷಣದಲ್ಲಿ ಯಾವ ಆಂತರಿಕ ಹೋಸ್ಟ್ ಹರಿವನ್ನು ಹೊಂದಿತ್ತು ಎಂಬ ಬೇಟೆಯಾಗುತ್ತದೆ. ಪ್ರಶ್ನೆಯ ಸಂಚಾರಕ್ಕೆ ಅವುಗಳಲ್ಲಿ ಯಾವುದೂ ಮುಖ್ಯವಲ್ಲದಿದ್ದರೆ, NAT ಸರಿ.
ಟ್ರಾನ್ಸಿಟ್ ಸ್ವತಃ ತಪ್ಪು ಊಹೆಯಾದಾಗ
ಹಂಚಿಕೆಯ ವಿಭಾಗವು ಪೂರೈಕೆದಾರ, ಹಂಚಿಕೆಯ ಸ್ವಿಚ್ ಫ್ಯಾಬ್ರಿಕ್, ಅಥವಾ ಇನ್ನೊಂದು ಪಕ್ಷ ಸಂಚಾರವನ್ನು ಓದಬಹುದಾದ ಯಾವುದೇ ಮಾರ್ಗವನ್ನು ದಾಟಿದರೆ, ಕೇವಲ ರೂಟಿಂಗ್ ಪೂರ್ಣ ಉತ್ತರವಲ್ಲ. ಎರಡು ಫೈರ್ವಾಲ್ಗಳ ನಡುವಿನ ಸುರಂಗ ನಿಮಗೆ ಗೋಪ್ಯತೆ ಮತ್ತು ಸಹವರ್ತಿ ದೃಢೀಕರಣ ನೀಡುತ್ತದೆ, ಮತ್ತು ಅದರೊಳಗಿನ ರೂಟ್ ಕೋಷ್ಟಕ ನೀವು ಟ್ರಾನ್ಸಿಟ್ನಲ್ಲಿ ಬರೆಯುತ್ತಿದ್ದ ಅದೇ ಕೋಷ್ಟಕ.
ಇದನ್ನು ಮೊದಲ ವಿಭಾಗದ ವಿಶ್ವಾಸ ಪ್ರಶ್ನೆಯಿಂದ ನಿರ್ಧರಿಸಿ, VPN ಹೆಚ್ಚು ಸುರಕ್ಷಿತ ಎಂಬ ಅಭ್ಯಾಸದಿಂದಲ್ಲ. ಈಗಾಗಲೇ ಖಾಸಗಿ ವಿಭಾಗದ ಮೇಲಿನ ಸುರಂಗವು ಯಾವುದೇ ಲಾಭವಿಲ್ಲದೆ ಕಾರ್ಯಾಚರಣೆ ವೆಚ್ಚ ಮತ್ತು ಇನ್ನೊಂದು ವೈಫಲ್ಯ ವಿಧಾನ ಸೇರಿಸುತ್ತದೆ, ಅವಿಶ್ವಾಸನೀಯ ವಿಭಾಗದ ಮೇಲಿನ ರೂಟಿಂಗ್ ಗೋಪ್ಯತೆಯನ್ನು ನೀವು ಭರಿಸಲಾಗದ ಸರಳತೆಗೆ ಬದಲಿಸುತ್ತದೆ. ಮೂರು ಷರತ್ತುಗಳಲ್ಲಿ ಯಾವುದು ಆಯ್ಕೆಯನ್ನು ನಡೆಸಿತು ಎಂದು ಬರೆಯಿರಿ, ಮುಂದಿನ ಎಂಜಿನಿಯರ್ ಅದನ್ನು ಮತ್ತೆ ಚರ್ಚಿಸಬೇಕಾಗಿಲ್ಲ.