ಬಹಳ ಹಿಂದೆಯೇ ನಾನು MetalLB ಗಾಗಿ ರೂಟಿಂಗ್ ಅನ್ನು ಹೊಂದಿಸುವ ಅಸಾಮಾನ್ಯ ಕೆಲಸವನ್ನು ಎದುರಿಸಿದೆ. ಎಲ್ಲವೂ ಚೆನ್ನಾಗಿರುತ್ತದೆ, ಏಕೆಂದರೆ ... ಸಾಮಾನ್ಯವಾಗಿ MetalLB ಗೆ ಯಾವುದೇ ಹೆಚ್ಚುವರಿ ಕ್ರಿಯೆಗಳ ಅಗತ್ಯವಿರುವುದಿಲ್ಲ, ಆದರೆ ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ ನಾವು ಸರಳವಾದ ನೆಟ್‌ವರ್ಕ್ ಕಾನ್ಫಿಗರೇಶನ್‌ನೊಂದಿಗೆ ಸಾಕಷ್ಟು ದೊಡ್ಡ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಹೊಂದಿದ್ದೇವೆ.

ಈ ಲೇಖನದಲ್ಲಿ ನಿಮ್ಮ ಕ್ಲಸ್ಟರ್‌ನ ಬಾಹ್ಯ ನೆಟ್‌ವರ್ಕ್‌ಗಾಗಿ ಮೂಲ-ಆಧಾರಿತ ಮತ್ತು ನೀತಿ-ಆಧಾರಿತ ರೂಟಿಂಗ್ ಅನ್ನು ಹೇಗೆ ಕಾನ್ಫಿಗರ್ ಮಾಡುವುದು ಎಂದು ನಾನು ನಿಮಗೆ ಹೇಳುತ್ತೇನೆ.

MetalLB ಅನ್ನು ಸ್ಥಾಪಿಸುವ ಮತ್ತು ಕಾನ್ಫಿಗರ್ ಮಾಡುವ ಬಗ್ಗೆ ನಾನು ವಿವರವಾಗಿ ಹೋಗುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ನೀವು ಈಗಾಗಲೇ ಕೆಲವು ಅನುಭವವನ್ನು ಹೊಂದಿದ್ದೀರಿ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ. ನಾನು ನೇರವಾಗಿ ಪಾಯಿಂಟ್‌ಗೆ ಹೋಗಲು ಸಲಹೆ ನೀಡುತ್ತೇನೆ, ಅವುಗಳೆಂದರೆ ರೂಟಿಂಗ್ ಅನ್ನು ಹೊಂದಿಸುವುದು. ಆದ್ದರಿಂದ ನಮಗೆ ನಾಲ್ಕು ಪ್ರಕರಣಗಳಿವೆ:

ಪ್ರಕರಣ 1: ಯಾವುದೇ ಕಾನ್ಫಿಗರೇಶನ್ ಅಗತ್ಯವಿಲ್ಲದಿದ್ದಾಗ

ಸರಳವಾದ ಪ್ರಕರಣವನ್ನು ನೋಡೋಣ.

MetalLB ನೀಡಿದ ವಿಳಾಸಗಳು ನಿಮ್ಮ ನೋಡ್‌ಗಳ ವಿಳಾಸಗಳಂತೆಯೇ ಅದೇ ಸಬ್‌ನೆಟ್‌ನಲ್ಲಿರುವಾಗ ಹೆಚ್ಚುವರಿ ರೂಟಿಂಗ್ ಕಾನ್ಫಿಗರೇಶನ್ ಅಗತ್ಯವಿಲ್ಲ.

ಉದಾಹರಣೆಗೆ, ನೀವು ಸಬ್ನೆಟ್ ಅನ್ನು ಹೊಂದಿದ್ದೀರಿ 192.168.1.0/24, ಇದು ರೂಟರ್ ಅನ್ನು ಹೊಂದಿದೆ 192.168.1.1, ಮತ್ತು ನಿಮ್ಮ ನೋಡ್‌ಗಳು ವಿಳಾಸಗಳನ್ನು ಸ್ವೀಕರಿಸುತ್ತವೆ: 192.168.1.10-30, ನಂತರ MetalLB ಗಾಗಿ ನೀವು ಶ್ರೇಣಿಯನ್ನು ಸರಿಹೊಂದಿಸಬಹುದು 192.168.1.100-120 ಮತ್ತು ಅವರು ಯಾವುದೇ ಹೆಚ್ಚುವರಿ ಸಂರಚನೆಯಿಲ್ಲದೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಾರೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ.

ಅದು ಏಕೆ? ನಿಮ್ಮ ನೋಡ್‌ಗಳು ಈಗಾಗಲೇ ಮಾರ್ಗಗಳನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಿರುವುದರಿಂದ:

# ip route
default via 192.168.1.1 dev eth0 onlink 
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.10

ಮತ್ತು ಅದೇ ಶ್ರೇಣಿಯ ವಿಳಾಸಗಳು ಯಾವುದೇ ಹೆಚ್ಚುವರಿ ಕ್ರಮಗಳಿಲ್ಲದೆ ಅವುಗಳನ್ನು ಮರುಬಳಕೆ ಮಾಡುತ್ತವೆ.

ಪ್ರಕರಣ 2: ಹೆಚ್ಚುವರಿ ಗ್ರಾಹಕೀಕರಣದ ಅಗತ್ಯವಿರುವಾಗ

ನಿಮ್ಮ ನೋಡ್‌ಗಳು ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾದ IP ವಿಳಾಸವನ್ನು ಹೊಂದಿರದಿದ್ದಾಗ ಅಥವಾ MetalLB ವಿಳಾಸಗಳನ್ನು ನೀಡುವ ಸಬ್‌ನೆಟ್‌ಗೆ ಮಾರ್ಗವನ್ನು ಹೊಂದಿರದಿದ್ದಲ್ಲಿ ನೀವು ಹೆಚ್ಚುವರಿ ಮಾರ್ಗಗಳನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಬೇಕು.

ನಾನು ಸ್ವಲ್ಪ ಹೆಚ್ಚು ವಿವರವಾಗಿ ವಿವರಿಸುತ್ತೇನೆ. MetalLB ವಿಳಾಸವನ್ನು ಔಟ್‌ಪುಟ್ ಮಾಡಿದಾಗಲೆಲ್ಲಾ, ಅದನ್ನು ಸರಳವಾದ ನಿಯೋಜನೆಗೆ ಹೋಲಿಸಬಹುದು:

ip addr add 10.9.8.7/32 dev lo

ಗಮನ ಕೊಡಿ:

• a) ವಿಳಾಸವನ್ನು ಪೂರ್ವಪ್ರತ್ಯಯದೊಂದಿಗೆ ನಿಗದಿಪಡಿಸಲಾಗಿದೆ /32 ಅಂದರೆ, ಒಂದು ಮಾರ್ಗವನ್ನು ಸಬ್‌ನೆಟ್‌ಗೆ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಸೇರಿಸಲಾಗುವುದಿಲ್ಲ (ಇದು ಕೇವಲ ವಿಳಾಸ)
• b) ವಿಳಾಸವನ್ನು ಯಾವುದೇ ನೋಡ್ ಇಂಟರ್ಫೇಸ್‌ಗೆ ಲಗತ್ತಿಸಲಾಗಿದೆ (ಉದಾಹರಣೆಗೆ ಲೂಪ್‌ಬ್ಯಾಕ್). ಲಿನಕ್ಸ್ ನೆಟ್‌ವರ್ಕ್ ಸ್ಟಾಕ್‌ನ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಇಲ್ಲಿ ಉಲ್ಲೇಖಿಸುವುದು ಯೋಗ್ಯವಾಗಿದೆ. ನೀವು ಯಾವ ಇಂಟರ್‌ಫೇಸ್‌ಗೆ ವಿಳಾಸವನ್ನು ಸೇರಿಸಿದರೂ, ಕರ್ನಲ್ ಯಾವಾಗಲೂ arp ವಿನಂತಿಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುತ್ತದೆ ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಯಾವುದಾದರೂ arp ಪ್ರತಿಕ್ರಿಯೆಗಳನ್ನು ಕಳುಹಿಸುತ್ತದೆ, ಈ ನಡವಳಿಕೆಯನ್ನು ಸರಿಯಾಗಿ ಪರಿಗಣಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಮೇಲಾಗಿ, ಕುಬರ್ನೆಟ್ಸ್ನಂತಹ ಕ್ರಿಯಾತ್ಮಕ ಪರಿಸರದಲ್ಲಿ ಸಾಕಷ್ಟು ವ್ಯಾಪಕವಾಗಿ ಬಳಸಲಾಗುತ್ತದೆ.

ಈ ನಡವಳಿಕೆಯನ್ನು ಕಸ್ಟಮೈಸ್ ಮಾಡಬಹುದು, ಉದಾಹರಣೆಗೆ ಕಟ್ಟುನಿಟ್ಟಾದ ಆರ್ಪ್ ಅನ್ನು ಸಕ್ರಿಯಗೊಳಿಸುವ ಮೂಲಕ:

echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore
echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce

ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಇಂಟರ್ಫೇಸ್ ಸ್ಪಷ್ಟವಾಗಿ ನಿರ್ದಿಷ್ಟ IP ವಿಳಾಸವನ್ನು ಹೊಂದಿದ್ದರೆ ಮಾತ್ರ arp ಪ್ರತಿಕ್ರಿಯೆಗಳನ್ನು ಕಳುಹಿಸಲಾಗುತ್ತದೆ. ನೀವು MetalLB ಅನ್ನು ಬಳಸಲು ಯೋಜಿಸುತ್ತಿದ್ದರೆ ಮತ್ತು ನಿಮ್ಮ kube-proxy IPVS ಮೋಡ್‌ನಲ್ಲಿ ರನ್ ಆಗುತ್ತಿದ್ದರೆ ಈ ಸೆಟ್ಟಿಂಗ್ ಅಗತ್ಯವಿದೆ.

ಆದಾಗ್ಯೂ, arp ವಿನಂತಿಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು MetalLB ಕರ್ನಲ್ ಅನ್ನು ಬಳಸುವುದಿಲ್ಲ, ಆದರೆ ಅದನ್ನು ಸ್ವತಃ ಬಳಕೆದಾರ-ಸ್ಥಳದಲ್ಲಿ ಮಾಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಈ ಆಯ್ಕೆಯು MetalLB ನ ಕಾರ್ಯಾಚರಣೆಯ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುವುದಿಲ್ಲ.

ನಮ್ಮ ಕಾರ್ಯಕ್ಕೆ ಹಿಂತಿರುಗೋಣ. ನೀಡಲಾದ ವಿಳಾಸಗಳ ಮಾರ್ಗವು ನಿಮ್ಮ ನೋಡ್‌ಗಳಲ್ಲಿ ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲದಿದ್ದರೆ, ಅದನ್ನು ಎಲ್ಲಾ ನೋಡ್‌ಗಳಿಗೆ ಮುಂಚಿತವಾಗಿ ಸೇರಿಸಿ:

ip route add 10.9.8.0/24 dev eth1

ಪ್ರಕರಣ 3: ನಿಮಗೆ ಮೂಲ-ಆಧಾರಿತ ರೂಟಿಂಗ್ ಅಗತ್ಯವಿದ್ದಾಗ

ನೀವು ಪ್ರತ್ಯೇಕ ಗೇಟ್‌ವೇ ಮೂಲಕ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಸ್ವೀಕರಿಸಿದಾಗ ಮೂಲ-ಆಧಾರಿತ ರೂಟಿಂಗ್ ಅನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಬೇಕಾಗುತ್ತದೆ, ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಿಲ್ಲ, ಆದ್ದರಿಂದ ಪ್ರತಿಕ್ರಿಯೆ ಪ್ಯಾಕೆಟ್‌ಗಳು ಸಹ ಅದೇ ಗೇಟ್‌ವೇ ಮೂಲಕ ಹೋಗಬೇಕು.

ಉದಾಹರಣೆಗೆ, ನೀವು ಅದೇ ಸಬ್ನೆಟ್ ಅನ್ನು ಹೊಂದಿರುವಿರಿ 192.168.1.0/24 ನಿಮ್ಮ ನೋಡ್‌ಗಳಿಗೆ ಮೀಸಲಾಗಿದೆ, ಆದರೆ ನೀವು MetalLB ಬಳಸಿಕೊಂಡು ಬಾಹ್ಯ ವಿಳಾಸಗಳನ್ನು ನೀಡಲು ಬಯಸುತ್ತೀರಿ. ನೀವು ಸಬ್‌ನೆಟ್‌ನಿಂದ ಬಹು ವಿಳಾಸಗಳನ್ನು ಹೊಂದಿರುವಿರಿ ಎಂದು ಭಾವಿಸೋಣ 1.2.3.0/24 VLAN 100 ನಲ್ಲಿದೆ ಮತ್ತು ಬಾಹ್ಯವಾಗಿ Kubernetes ಸೇವೆಗಳನ್ನು ಪ್ರವೇಶಿಸಲು ನೀವು ಅವುಗಳನ್ನು ಬಳಸಲು ಬಯಸುತ್ತೀರಿ.

ಸಂಪರ್ಕಿಸುವಾಗ 1.2.3.4 ನೀವು ಬೇರೆ ಸಬ್‌ನೆಟ್‌ನಿಂದ ವಿನಂತಿಗಳನ್ನು ಮಾಡುತ್ತಿರುವಿರಿ 1.2.3.0/24 ಮತ್ತು ಉತ್ತರಕ್ಕಾಗಿ ನಿರೀಕ್ಷಿಸಿ. MetalLB-ನೀಡಿದ ವಿಳಾಸಕ್ಕೆ ಪ್ರಸ್ತುತವಾಗಿ ಮಾಸ್ಟರ್ ಆಗಿರುವ ನೋಡ್ 1.2.3.4, ರೂಟರ್‌ನಿಂದ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ 1.2.3.1, ಆದರೆ ಅವನಿಗೆ ಉತ್ತರವು ಅಗತ್ಯವಾಗಿ ಅದೇ ಮಾರ್ಗದಲ್ಲಿ ಹೋಗಬೇಕು 1.2.3.1.

ನಮ್ಮ ನೋಡ್ ಈಗಾಗಲೇ ಕಾನ್ಫಿಗರ್ ಮಾಡಿದ ಡೀಫಾಲ್ಟ್ ಗೇಟ್‌ವೇ ಹೊಂದಿರುವುದರಿಂದ 192.168.1.1, ನಂತರ ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ ಪ್ರತಿಕ್ರಿಯೆಯು ಅವನಿಗೆ ಹೋಗುತ್ತದೆ, ಮತ್ತು ಅಲ್ಲ 1.2.3.1, ಅದರ ಮೂಲಕ ನಾವು ಪ್ಯಾಕೇಜ್ ಅನ್ನು ಸ್ವೀಕರಿಸಿದ್ದೇವೆ.

ಈ ಪರಿಸ್ಥಿತಿಯನ್ನು ನಿಭಾಯಿಸುವುದು ಹೇಗೆ?

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

ip link add link eth0 name eth0.100 type vlan id 100
ip link set eth0.100 up

ತದನಂತರ ಮಾರ್ಗಗಳನ್ನು ಸೇರಿಸಿ:

ip route add 1.2.3.0/24 dev eth0.100 table 100
ip route add default via 1.2.3.1 table 100

ಪ್ರತ್ಯೇಕ ರೂಟಿಂಗ್ ಟೇಬಲ್‌ಗೆ ನಾವು ಮಾರ್ಗಗಳನ್ನು ಸೇರಿಸುತ್ತೇವೆ ಎಂಬುದನ್ನು ದಯವಿಟ್ಟು ಗಮನಿಸಿ 100 ಇದು ಗೇಟ್‌ವೇ ಮೂಲಕ ಪ್ರತಿಕ್ರಿಯೆ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಕಳುಹಿಸಲು ಅಗತ್ಯವಿರುವ ಎರಡು ಮಾರ್ಗಗಳನ್ನು ಮಾತ್ರ ಹೊಂದಿರುತ್ತದೆ 1.2.3.1, ಇಂಟರ್ಫೇಸ್ ಹಿಂದೆ ಇದೆ eth0.100.

ಈಗ ನಾವು ಸರಳ ನಿಯಮವನ್ನು ಸೇರಿಸಬೇಕಾಗಿದೆ:

ip rule add from 1.2.3.0/24 lookup 100

ಇದು ಸ್ಪಷ್ಟವಾಗಿ ಹೇಳುತ್ತದೆ: ಪ್ಯಾಕೆಟ್‌ನ ಮೂಲ ವಿಳಾಸ ಇದ್ದರೆ 1.2.3.0/24, ನಂತರ ನೀವು ರೂಟಿಂಗ್ ಟೇಬಲ್ ಅನ್ನು ಬಳಸಬೇಕಾಗುತ್ತದೆ 100. ಅದರಲ್ಲಿ ನಾವು ಅವನನ್ನು ಕಳುಹಿಸುವ ಮಾರ್ಗವನ್ನು ಈಗಾಗಲೇ ವಿವರಿಸಿದ್ದೇವೆ 1.2.3.1

ಪ್ರಕರಣ 4: ನಿಮಗೆ ನೀತಿ ಆಧಾರಿತ ರೂಟಿಂಗ್ ಅಗತ್ಯವಿದ್ದಾಗ

ನೆಟ್‌ವರ್ಕ್ ಟೋಪೋಲಜಿಯು ಹಿಂದಿನ ಉದಾಹರಣೆಯಂತೆಯೇ ಇದೆ, ಆದರೆ ನೀವು ಬಾಹ್ಯ ಪೂಲ್ ವಿಳಾಸಗಳನ್ನು ಪ್ರವೇಶಿಸಲು ಬಯಸುತ್ತೀರಿ ಎಂದು ಹೇಳೋಣ 1.2.3.0/24 ನಿಮ್ಮ ಪಾಡ್‌ಗಳಿಂದ:

ವಿಶೇಷವೆಂದರೆ ಯಾವುದೇ ವಿಳಾಸವನ್ನು ಪ್ರವೇಶಿಸುವಾಗ 1.2.3.0/24, ಪ್ರತಿಕ್ರಿಯೆ ಪ್ಯಾಕೆಟ್ ನೋಡ್ ಅನ್ನು ಹಿಟ್ ಮಾಡುತ್ತದೆ ಮತ್ತು ಶ್ರೇಣಿಯಲ್ಲಿ ಮೂಲ ವಿಳಾಸವನ್ನು ಹೊಂದಿರುತ್ತದೆ 1.2.3.0/24 ಗೆ ವಿಧೇಯತೆಯಿಂದ ಕಳುಹಿಸಲಾಗುವುದು eth0.100, ಆದರೆ ಮೂಲ ವಿನಂತಿಯನ್ನು ರಚಿಸಿದ ನಮ್ಮ ಮೊದಲ ಪಾಡ್‌ಗೆ ಕುಬರ್ನೆಟ್ಸ್ ಅದನ್ನು ಮರುನಿರ್ದೇಶಿಸಬೇಕೆಂದು ನಾವು ಬಯಸುತ್ತೇವೆ.

ಈ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುವುದು ಕಷ್ಟಕರವಾಗಿತ್ತು, ಆದರೆ ನೀತಿ ಆಧಾರಿತ ರೂಟಿಂಗ್‌ನಿಂದ ಇದು ಸಾಧ್ಯವಾಯಿತು:

ಪ್ರಕ್ರಿಯೆಯ ಉತ್ತಮ ತಿಳುವಳಿಕೆಗಾಗಿ, ಇಲ್ಲಿ ನೆಟ್‌ಫಿಲ್ಟರ್ ಬ್ಲಾಕ್ ರೇಖಾಚಿತ್ರವಿದೆ:

ಮೊದಲಿಗೆ, ಹಿಂದಿನ ಉದಾಹರಣೆಯಲ್ಲಿರುವಂತೆ, ಹೆಚ್ಚುವರಿ ರೂಟಿಂಗ್ ಟೇಬಲ್ ಅನ್ನು ರಚಿಸೋಣ:

ip route add 1.2.3.0/24 dev eth0.100 table 100
ip route add default via 1.2.3.1 table 100

ಈಗ ನಾವು iptables ಗೆ ಕೆಲವು ನಿಯಮಗಳನ್ನು ಸೇರಿಸೋಣ:

iptables -t mangle -A PREROUTING -i eth0.100 -j CONNMARK --set-mark 0x100
iptables -t mangle -A PREROUTING  -j CONNMARK --restore-mark
iptables -t mangle -A PREROUTING -m mark ! --mark 0 -j RETURN
iptables -t mangle -A POSTROUTING -j CONNMARK --save-mark

ಈ ನಿಯಮಗಳು ಇಂಟರ್ಫೇಸ್‌ಗೆ ಒಳಬರುವ ಸಂಪರ್ಕಗಳನ್ನು ಗುರುತಿಸುತ್ತವೆ eth0.100, ಎಲ್ಲಾ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಟ್ಯಾಗ್‌ನೊಂದಿಗೆ ಗುರುತಿಸುವುದು 0x100, ಅದೇ ಸಂಪರ್ಕದೊಳಗಿನ ಪ್ರತಿಕ್ರಿಯೆಗಳನ್ನು ಅದೇ ಟ್ಯಾಗ್‌ನೊಂದಿಗೆ ಗುರುತಿಸಲಾಗುತ್ತದೆ.

ಈಗ ನಾವು ರೂಟಿಂಗ್ ನಿಯಮವನ್ನು ಸೇರಿಸಬಹುದು:

ip rule add from 1.2.3.0/24 fwmark 0x100 lookup 100

ಅಂದರೆ, ಮೂಲ ವಿಳಾಸದೊಂದಿಗೆ ಎಲ್ಲಾ ಪ್ಯಾಕೆಟ್‌ಗಳು 1.2.3.0/24 ಮತ್ತು ಟ್ಯಾಗ್ 0x100 ಟೇಬಲ್ ಬಳಸಿ ರೂಟ್ ಮಾಡಬೇಕು 100.

ಹೀಗಾಗಿ, ಇನ್ನೊಂದು ಇಂಟರ್‌ಫೇಸ್‌ನಲ್ಲಿ ಸ್ವೀಕರಿಸಿದ ಇತರ ಪ್ಯಾಕೆಟ್‌ಗಳು ಈ ನಿಯಮಕ್ಕೆ ಒಳಪಟ್ಟಿರುವುದಿಲ್ಲ, ಇದು ಪ್ರಮಾಣಿತ ಕುಬರ್ನೆಟ್ಸ್ ಉಪಕರಣಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಅವುಗಳನ್ನು ರೂಟ್ ಮಾಡಲು ಅನುಮತಿಸುತ್ತದೆ.

ಇನ್ನೂ ಒಂದು ವಿಷಯವಿದೆ, ಲಿನಕ್ಸ್‌ನಲ್ಲಿ ರಿವರ್ಸ್ ಪಾತ್ ಫಿಲ್ಟರ್ ಎಂದು ಕರೆಯಲ್ಪಡುತ್ತದೆ, ಅದು ಇಡೀ ವಿಷಯವನ್ನು ಹಾಳು ಮಾಡುತ್ತದೆ; ಇದು ಸರಳವಾದ ಪರಿಶೀಲನೆಯನ್ನು ಮಾಡುತ್ತದೆ: ಎಲ್ಲಾ ಒಳಬರುವ ಪ್ಯಾಕೆಟ್‌ಗಳಿಗೆ, ಇದು ಕಳುಹಿಸುವವರ ವಿಳಾಸದೊಂದಿಗೆ ಪ್ಯಾಕೆಟ್‌ನ ಮೂಲ ವಿಳಾಸವನ್ನು ಬದಲಾಯಿಸುತ್ತದೆ ಮತ್ತು ಪರಿಶೀಲಿಸುತ್ತದೆ. ಪ್ಯಾಕೆಟ್ ಅದನ್ನು ಸ್ವೀಕರಿಸಿದ ಅದೇ ಇಂಟರ್ಫೇಸ್ ಮೂಲಕ ಬಿಡಬಹುದು, ಇಲ್ಲದಿದ್ದರೆ, ಅದು ಅದನ್ನು ಫಿಲ್ಟರ್ ಮಾಡುತ್ತದೆ.

ಸಮಸ್ಯೆಯೆಂದರೆ ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ ಅದು ಸರಿಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವುದಿಲ್ಲ, ಆದರೆ ನಾವು ಅದನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಬಹುದು:

echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter
echo 0 > /proc/sys/net/ipv4/conf/eth0.100/rp_filter

ಮೊದಲ ಆಜ್ಞೆಯು rp_filter ನ ಜಾಗತಿಕ ನಡವಳಿಕೆಯನ್ನು ನಿಯಂತ್ರಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ದಯವಿಟ್ಟು ಗಮನಿಸಿ; ಅದನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸದಿದ್ದರೆ, ಎರಡನೇ ಆಜ್ಞೆಯು ಯಾವುದೇ ಪರಿಣಾಮವನ್ನು ಬೀರುವುದಿಲ್ಲ. ಆದಾಗ್ಯೂ, ಉಳಿದ ಇಂಟರ್‌ಫೇಸ್‌ಗಳು rp_filter ಸಕ್ರಿಯಗೊಳಿಸುವಿಕೆಯೊಂದಿಗೆ ಉಳಿಯುತ್ತವೆ.

ಫಿಲ್ಟರ್‌ನ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಮಿತಿಗೊಳಿಸದಿರಲು, ನಾವು ನೆಟ್‌ಫಿಲ್ಟರ್‌ಗಾಗಿ rp_filter ಅನುಷ್ಠಾನವನ್ನು ಬಳಸಬಹುದು. rpfilter ಅನ್ನು iptables ಮಾಡ್ಯೂಲ್ ಆಗಿ ಬಳಸಿ, ನೀವು ಸಾಕಷ್ಟು ಹೊಂದಿಕೊಳ್ಳುವ ನಿಯಮಗಳನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಬಹುದು, ಉದಾಹರಣೆಗೆ:

iptables -t raw -A PREROUTING -i eth0.100 -d 1.2.3.0/24 -j RETURN
iptables -t raw -A PREROUTING -i eth0.100 -m rpfilter --invert -j DROP

ಇಂಟರ್ಫೇಸ್ನಲ್ಲಿ rp_filter ಅನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಿ eth0.100 ಹೊರತುಪಡಿಸಿ ಎಲ್ಲಾ ವಿಳಾಸಗಳಿಗೆ 1.2.3.0/24.

ಮೂಲ: www.habr.com