strongSwan ನಲ್ಲಿ ಪೂರ್ಣ ಟನೆಲ್ಗೆ ಎರಡೂ ಬದಿಗಳಲ್ಲಿ 0.0.0.0/0 ಬೇಕು

ಒಂದು ಖಾಸಗಿ ಸಬ್ನೆಟ್ಗೆ ಕೆಲಸ ಮಾಡುವ strongSwan ಸಂಪರ್ಕವು ಯಾರೋ ಒಂದು ಸಾಲನ್ನು ಸಂಪಾದಿಸಿದ್ದರಿಂದಲೇ ಇಂಟರ್ನೆಟ್ ಸಂಚಾರವನ್ನು ಸಾಗಿಸುವುದಿಲ್ಲ. ಪೂರ್ಣ ಟನೆಲ್ ಎಂದರೆ child SA ಯಾವ ವಿಳಾಸಗಳನ್ನು ರಕ್ಷಿಸುತ್ತದೆ ಎಂಬುದರ ಬಗ್ಗೆ ಎರಡು ಪಕ್ಷಗಳ ನಡುವಿನ ಒಪ್ಪಂದ, ಮತ್ತು ಪ್ರತಿ ಪಕ್ಷವೂ ಇನ್ನೊಂದನ್ನು ತನ್ನ ಸಂಬಂಧದಲ್ಲಿ ಹೆಸರಿಸುತ್ತದೆ. ಒಂದು ಬದಿಯನ್ನು ಸರಿ, ಇನ್ನೊಂದನ್ನು ತಪ್ಪು ಮಾಡಿದರೆ child SA ಏರುವುದಿಲ್ಲ ಅಥವಾ ಉದ್ದೇಶಕ್ಕಿಂತ ಕಿರಿದಾಗಿ ಏರುತ್ತದೆ. ಕೆಳಗಿನ ಐದು ಪರಿಶೀಲನೆಗಳು ಆ ಒಪ್ಪಂದವನ್ನು ಕ್ಲೈಂಟ್ನಿಂದ ಗೇಟ್ವೇ ಮೂಲಕ ಇಂಟರ್ನೆಟ್ವರೆಗೆ ಅನುಸರಿಸುತ್ತವೆ.

ಮೊದಲು ಕ್ಲೈಂಟ್ನ ಸೆಲೆಕ್ಟರ್ ಪರಿಶೀಲಿಸಿ

ಕ್ಲೈಂಟ್ ದೂರದ ಬದಿಯಲ್ಲಿ ಏನನ್ನು ರಕ್ಷಿಸಲು ಬಯಸುತ್ತದೆಯೋ ಅದನ್ನು remote_ts ಎಂದು ವಿವರಿಸುತ್ತದೆ, ಮತ್ತು ಅದು ಕಳುಹಿಸುವ ಎಲ್ಲವೂ ತನಗೆ ನಿಗದಿಯಾದ ವಿಳಾಸದಿಂದಲೇ ಹೊರಡುತ್ತದೆ. ಇಂಟರ್ನೆಟ್ ಸಂಚಾರಕ್ಕೆ ಆ ಮೌಲ್ಯವು ಬಳಕೆದಾರರು ನಿಜವಾಗಿ ತಲುಪುವ ಗಮ್ಯಸ್ಥಾನಗಳನ್ನು ಆವರಿಸಬೇಕು, ಅಂದರೆ ಪ್ರಾಯೋಗಿಕವಾಗಿ ಇಡೀ IPv4 ವ್ಯಾಪ್ತಿ. ಇನ್ನೂ ಒಂದು ಸಬ್ನೆಟ್ ಪಟ್ಟಿ ಮಾಡುವ ಕ್ಲೈಂಟ್ ಇಂಟರ್ಫೇಸ್ನಲ್ಲಿ ಪ್ರೊಫೈಲ್ ಯಾವ ಹೆಸರಿನಿಂದಲೇ ಇರಲಿ, ವಿಭಜಿತ ಟನೆಲ್ ಕೇಳುತ್ತಿದೆ. ಮೂಲ ಬದಿ ಸಾಮಾನ್ಯವಾಗಿ dynamic ಆಗಿರುತ್ತದೆ ಏಕೆಂದರೆ ಸಂಪರ್ಕದ ಸಮಯದಲ್ಲಿ ವಿಳಾಸ ನಿಗದಿಯಾಗುತ್ತದೆ. ಅಲ್ಲಿ ಬರೆದ ಸ್ಥಿರ ಮೂಲವು ವಿಳಾಸಗಳ ಗುಂಪು ಬದಲಾದ ಕ್ಷಣ ಮುರಿಯುತ್ತದೆ.

children {
    net {
        local_ts  = dynamic
        remote_ts = 0.0.0.0/0
    }
}

ಈ ತುಣುಕು ಪೂರ್ಣ ಸಂಪರ್ಕ ಕಡತವಲ್ಲ, ಮತ್ತು ಇದು ದೃಢೀಕರಣ, ಗುರುತುಗಳು ಮತ್ತು ವರ್ಚುವಲ್ ವಿಳಾಸಗಳ ಗುಂಪು ಈಗಾಗಲೇ ಸಂರಚಿಸಲ್ಪಟ್ಟಿವೆ ಎಂದು ಊಹಿಸುತ್ತದೆ. ಕ್ಲೈಂಟ್ನ ಮೂಲ ಸೆಲೆಕ್ಟರ್ ಮತ್ತು ಸರ್ವರ್ ನಿಗದಿಪಡಿಸುವ ವಿಳಾಸ ಇನ್ನೂ ಹೊಂದಿಕೆಯಾಗಬೇಕು, ಇಲ್ಲದಿದ್ದರೆ child SA ಯಾವ ಪಕ್ಷವೂ ನಿರೀಕ್ಷಿಸದ ವ್ಯಾಪ್ತಿಯೊಂದಿಗೆ ಏರುತ್ತದೆ. ಅದನ್ನು swanctl --load-all ನಿಂದ ಲೋಡ್ ಮಾಡಿ ಮತ್ತು ಯಶಸ್ಸನ್ನು ಊಹಿಸುವ ಮೊದಲು ಔಟ್ಪುಟ್ ಓದಿ. ಪಾರ್ಸ್ ಆಗುವ ಕಡತವೂ ಇನ್ನೊಂದು ಪಕ್ಷದ ಪ್ರಸ್ತಾವನೆಯೊಂದಿಗೆ ಜೋಡಣೆಯಾಗದ ಸೆಲೆಕ್ಟರ್ನಿಂದ ತಿರಸ್ಕೃತವಾಗಬಹುದು.

ಗೇಟ್ವೇಯ ಸೆಲೆಕ್ಟರ್ ಅನ್ನು ಅದರ ಸ್ವಂತ ಬದಿಯಲ್ಲಿ ಪರಿಶೀಲಿಸಿ

ಗೇಟ್ವೇ ಅದೇ ಪರಿಕಲ್ಪನೆಯನ್ನು ವಿರುದ್ಧ ದಿಕ್ಕಿನಿಂದ ಓದುತ್ತದೆ. ಇಂಟರ್ನೆಟ್ ಗಮ್ಯಸ್ಥಾನಗಳು ಗೇಟ್ವೇಗೆ ಸ್ಥಳೀಯ, ಆದ್ದರಿಂದ ಅದರ local_ts ಅಗಲವಾದದ್ದು ಮತ್ತು remote_ts ಕ್ಲೈಂಟ್ ಗುಂಪನ್ನು ವಿವರಿಸುತ್ತದೆ. ಈ ವ್ಯುತ್ಕ್ರಮ ಪೂರ್ಣ-ಟನೆಲ್ ಸಂರಚನೆಯಲ್ಲಿ ಅತ್ಯಂತ ಸಾಮಾನ್ಯ ತಪ್ಪು, ಮತ್ತು ಎರಡೂ ಸಾಲುಗಳು ಪ್ರತ್ಯೇಕವಾಗಿ ನಂಬಲರ್ಹವಾಗಿ ಕಾಣುವುದರಿಂದ ಇದು ಪರಿಶೀಲನೆಯನ್ನು ದಾಟುತ್ತದೆ.

children {
    rw {
        local_ts  = 0.0.0.0/0
        remote_ts = 10.77.0.0/24
    }
}

ಕ್ಲೈಂಟ್ ತುಣುಕನ್ನು ಗೇಟ್ವೇ ಕಡತಕ್ಕೆ ನಕಲಿಸುವುದರಿಂದ ಉಪಯುಕ್ತವಾದ ಯಾವುದನ್ನೂ ವಿವರಿಸದ ಸೆಲೆಕ್ಟರ್ ಜೋಡಿ ಉಂಟಾಗುತ್ತದೆ, ಏಕೆಂದರೆ ಎರಡೂ ಪಕ್ಷಗಳು ಒಂದೇ ಪಾತ್ರವನ್ನು ಕೋರುವವು. strongSwan ಫಾರ್ವರ್ಡಿಂಗ್ ಮಾರ್ಗದರ್ಶಿ ಕ್ಲೈಂಟ್ ಮತ್ತು ಗೇಟ್ವೇ ಜೋಡಣೆಯನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ದಾಖಲಿಸುತ್ತದೆ, ಮತ್ತು ಅದನ್ನು ವೈಫಲ್ಯದ ನಂತರವಲ್ಲ, ಸಂಪರ್ಕ ಕಡತದ ಪಕ್ಕದಲ್ಲಿ ಓದುವುದು ಯೋಗ್ಯ. ಗೇಟ್ವೇ ಕಡತಕ್ಕೆ remote_ts ಉಲ್ಲೇಖಿಸುವ ಗುಂಪಿನ ವ್ಯಾಖ್ಯಾನವೂ ಬೇಕು. ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲದ ಗುಂಪನ್ನು ಹೆಸರಿಸುವ ಸೆಲೆಕ್ಟರ್ ದೂರಿಲ್ಲದೆ ಲೋಡ್ ಆಗುತ್ತದೆ ಮತ್ತು ಸಂಪರ್ಕಿಸುವಾಗ ವಿಫಲವಾಗುತ್ತದೆ.

ಹಳೆಯ ipsec.conf ವಿಭಿನ್ನ ಕೀಗಳೊಂದಿಗೆ ಎಡ ಮತ್ತು ಬಲ ಪಾತ್ರಗಳನ್ನು ಬಳಸುತ್ತದೆ, ಮತ್ತು rightsubnet ಸಾಲು swanctl ಮೌಲ್ಯಕ್ಕೆ ನೇರ ಬದಲಿ ಅಲ್ಲ. ಎರಡು ವಾಕ್ಯರಚನೆಗಳನ್ನು ಒಂದನ್ನು ಇನ್ನೊಂದರೊಳಗೆ ಅಂಟಿಸುವ ಬದಲು ಪ್ರತ್ಯೇಕ ಕಡತಗಳಲ್ಲಿ ಇರಿಸಿ. ಅವುಗಳನ್ನು ಒಂದೇ ಡೈರೆಕ್ಟರಿಯಲ್ಲಿ ಬೆರೆಸುವುದೇ ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದ ಸಂಪರ್ಕವು ಮರುಬೂಟ್ನ ನಂತರ ಸದ್ದಿಲ್ಲದೆ ಹಿಂದೆ ಸರಿಯುವ ದಾರಿ.

ಕಡತವಲ್ಲ, ಸಮಾಲೋಚಿಸಿದ child SA ಪರಿಶೀಲಿಸಿ

ಉಳಿಸಿದ ಸಂರಚನೆ ಉದ್ದೇಶವನ್ನು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ, ಅಷ್ಟೇ. ಇನ್ನೊಂದು ಪಕ್ಷ ಕೇಳಿದ್ದನ್ನು ಕಿರಿದಾಗಿಸಬಹುದು, ಮತ್ತು ಅದರ ಕೆಳಗಿನ ಕಡತ ಬದಲಾದ ಕಾರಣಕ್ಕಷ್ಟೇ ಇರುವ child SA ಬದಲಾಗುವುದಿಲ್ಲ. ಬೇರೆ ಏನನ್ನಾದರೂ ಬದಲಿಸುವ ಮೊದಲು ನಿಜವಾಗಿ ಏನು ಸ್ಥಾಪಿತವಾಗಿದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ.

swanctl --list-conns
swanctl --list-sas
ip xfrm policy list

ಮೊದಲ ಆಜ್ಞೆ ಡೀಮನ್ ಏನನ್ನು ಲೋಡ್ ಮಾಡಿದೆ ಎಂದು ತೋರಿಸುತ್ತದೆ, ಎರಡನೆಯದು ಸ್ಥಾಪಿತ child SA ಗಳನ್ನು, ಮೂರನೆಯದು ಕರ್ನಲ್ ಅನ್ವಯಿಸುವ ನೀತಿಗಳನ್ನು ತೋರಿಸುತ್ತದೆ. ಕಡತ 0.0.0.0/0 ಎಂದು ಹೇಳಿ ಪಟ್ಟಿ ಒಂದು ಸಬ್ನೆಟ್ ತೋರಿಸಿದರೆ, ಸಮಾಲೋಚನೆ ವ್ಯಾಪ್ತಿಯನ್ನು ಕಿರಿದಾಗಿಸಿದೆ ಮತ್ತು ಕಡತವನ್ನು ಮತ್ತೆ ಓದುವುದರಿಂದ ಅದು ವಿವರಣೆಯಾಗುವುದಿಲ್ಲ. child ಅನ್ನು ಕೊನೆಗೊಳಿಸಿ, ಮತ್ತೆ ಪ್ರಾರಂಭಿಸಿ, ಮತ್ತು ಮೂರೂ ಔಟ್ಪುಟ್ಗಳನ್ನು ಮತ್ತೆ ಹೋಲಿಸಿ. ಅದೇ ಕಿರಿದಾದ ವ್ಯಾಪ್ತಿಯೊಂದಿಗೆ ಮರಳುವ child ಅನ್ನು ಸ್ಥಳೀಯ ಕಡತವಲ್ಲ, ದೂರದ ಪಕ್ಷ ಕಿರಿದಾಗಿಸುತ್ತದೆ, ಮತ್ತು ಅದು ಸ್ಥಳೀಯ ಸಂಪಾದನೆಯಲ್ಲ, ಇನ್ನೊಬ್ಬ ನಿರ್ವಾಹಕರೊಂದಿಗಿನ ಸಂಭಾಷಣೆ.

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

ಫಾರ್ವರ್ಡಿಂಗ್ ಮತ್ತು ಹಿಂತಿರುಗುವ ಮಾರ್ಗ ಪರಿಶೀಲಿಸಿ

ಸೆಲೆಕ್ಟರ್ ಸಂಚಾರವನ್ನು ಗೇಟ್ವೇಗೆ ಬಿಡುತ್ತದೆ; ಅದು ಗೇಟ್ವೇಯನ್ನು ಆ ಸಂಚಾರವನ್ನು ಮುಂದೆ ಮಾರ್ಗನಿರ್ದೇಶಿಸಲು ಒತ್ತಾಯಿಸುವುದಿಲ್ಲ. ಫಾರ್ವರ್ಡಿಂಗ್ ಸಕ್ರಿಯವಾಗಿರಬೇಕು, ಫೈರವಾಲ್ ಹರಿವನ್ನು ಅನುಮತಿಸಬೇಕು, ಮತ್ತು ಉತ್ತರವು ಕ್ಲೈಂಟ್ ಗುಂಪಿಗೆ ಹಿಂತಿರುಗುವ ದಾರಿ ಕಂಡುಕೊಳ್ಳಬೇಕು. ಇವು ಮೂರು ಪ್ರತ್ಯೇಕ ಅಗತ್ಯಗಳು, ಮತ್ತು ಪ್ರತಿಯೊಂದೂ ಬೇರೆ ಲಕ್ಷಣದೊಂದಿಗೆ ವಿಫಲವಾಗುತ್ತದೆ. ಕಾಣೆಯಾದ ಫಾರ್ವರ್ಡ್ ನಿಯಮ ಕಪ್ಪು ಕುಳಿಯಂತೆ ವರ್ತಿಸುತ್ತದೆ, ಆದರೆ ಕಾಣೆಯಾದ ಹಿಂತಿರುಗುವ ಮಾರ್ಗ ಏಕಮುಖ ಟನೆಲ್ನಂತೆ.

sysctl net.ipv4.ip_forward
iptables -t nat -S | grep -i masq
ip route get 1.1.1.1

ಖಾಸಗಿ ಕ್ಲೈಂಟ್ ವಿಳಾಸಗಳಿಗೆ ಸಾಮಾನ್ಯವಾಗಿ ಸಾರ್ವಜನಿಕ ಇಂಟರ್ಫೇಸ್ ಬಿಡುವ ಮೊದಲು ಉದ್ದೇಶಪೂರ್ವಕ ಮೂಲ ಅನುವಾದ ಬೇಕು, ಆದರೆ ಸ್ಪಷ್ಟವಾಗಿ ಮಾರ್ಗನಿರ್ದೇಶಿತ ಹಂಚಿಕೆಗೆ ಬೇರೆ ನಡವಳಿಕೆ ಬೇಕು. NAT ಒಳಗೊಂಡಿದ್ದರೆ, ಸಂರಕ್ಷಣಾ ನೀತಿ ಪರಿಶೀಲಿಸಬೇಕಾದ ಸಂಚಾರವು ಅದನ್ನು ದಾಟಿ ಅನುವಾದವಾಗದಂತೆ ಅನುಷ್ಠಾನದ ಬೆಂಬಲಿತ ವಿನಾಯಿತಿಗಳನ್ನು ಇರಿಸಿಕೊಳ್ಳಿ. ಇನ್ನೊಂದು ಗೇಟ್ವೇಯಿಂದ ನಕಲಿಸಿದ ಅಗಲವಾದ masquerade ನಿಯಮವು ಲೇಖಕನ ಉದ್ದೇಶಕ್ಕಿಂತ ಹೆಚ್ಚು ಹರಿವುಗಳನ್ನು ಬದಲಿಸುತ್ತದೆ. ನಿಯಮವನ್ನು ಕ್ಲೈಂಟ್ ಗುಂಪಿಗೆ ಮಾತ್ರ ಬರೆಯಿರಿ, ಮತ್ತು ಅದು ಏಕೆ ಇದೆ ಎಂದು ವಿವರಿಸುವ ಟಿಪ್ಪಣಿ ಬಿಡಿ.

ಕ್ಲೈಂಟ್ನಲ್ಲಿ ನೀವು ಊಹಿಸಿದ ಮಾರ್ಗಗಳಲ್ಲ, ಬ್ಯಾಕೆಂಡ್ ಸ್ಥಾಪಿಸಿದ ಮಾರ್ಗಗಳನ್ನು ಖಚಿತಪಡಿಸಿ. ಮಾರ್ಗ ಸ್ಥಾಪನೆ ನಿಷ್ಕ್ರಿಯವಾಗಿರುವ ನಿರ್ವಾಹಕನಿಗೆ ಕೈಯಿಂದ ನಿರ್ವಹಿಸುವ ಮಾರ್ಗನಿರ್ದೇಶನ ವಿನ್ಯಾಸ ಬೇಕು, ಮತ್ತು ಟನೆಲ್ ಬದಲಾದಾಗಲೆಲ್ಲ ಆ ವಿನ್ಯಾಸವನ್ನು ನವೀಕರಿಸಬೇಕು. ಮತ್ತೆ ಸಂಪರ್ಕಿಸಿದ ನಂತರ ಮಾರ್ಗನಿರ್ದೇಶನ ಕೋಷ್ಟಕ ಪರಿಶೀಲಿಸಿ, ಹೊಸ ಬೂಟ್ನ ನಂತರ ಮಾತ್ರವಲ್ಲ.

ಟನೆಲ್ ಇನ್ನೂ ಏನನ್ನು ಆವರಿಸಿಲ್ಲ ಎಂದು ಪರಿಶೀಲಿಸಿ

ಸೆಲೆಕ್ಟರ್ ಜೋಡಿ IPv4 ಅನ್ನು ಆವರಿಸುತ್ತದೆ, ಬೇರೇನನ್ನೂ ಅಲ್ಲ. IPv6, DNS ಮತ್ತು ಯಾವುದೇ ಅನ್ವಯ ಮಟ್ಟದ ನೀತಿ ಪ್ರತ್ಯೇಕ ನಿರ್ಣಯಗಳು, ಅವನ್ನು ಅಗಲವಾದ IPv4 ಸೆಲೆಕ್ಟರ್ ಸದ್ದಿಲ್ಲದೆ ನಿರ್ಲಕ್ಷಿಸುತ್ತದೆ. ಪ್ರತಿ IPv4 ಪ್ಯಾಕೆಟ್ ಸಾಗಿಸುವ ಟನೆಲ್ ಕೂಡ ಪ್ರತಿ ಹೆಸರಿನ ಹುಡುಕಾಟವನ್ನು ಸೋರಿಸಬಹುದು.

ಉದ್ದೇಶಿತ DNS ಮಾರ್ಗವನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಹೇಳಿ, ಏಕೆಂದರೆ ಸ್ಥಳೀಯ ರೆಸಾಲ್ವರ್ ಮೂಲಕ ಹೆಸರುಗಳನ್ನು ಇನ್ನೂ ಪರಿಹರಿಸುವ ಪೂರ್ಣ ಟನೆಲ್ ಪ್ರಶ್ನೆಗಳನ್ನು ಟನೆಲ್ನ ಹೊರಗೆ ಸೋರಿಸುತ್ತದೆ ಮತ್ತು ಖಾಸಗಿ ಹೆಸರುಗಳನ್ನು ಮುರಿಯುತ್ತದೆ. ಕ್ಲೈಂಟ್ಗೆ IPv6 ವಿಳಾಸ ನಿಗದಿಯಾದರೆ, ಆ ವಿಳಾಸ ಕುಟುಂಬಕ್ಕೂ ಅದೇ ನಡವಳಿಕೆ ಬೇಕು, ಇಲ್ಲದಿದ್ದರೆ ಹೋಸ್ಟ್ ಟನೆಲ್ ರಕ್ಷಿಸದ ಮಾರ್ಗಕ್ಕೆ ಆದ್ಯತೆ ನೀಡುತ್ತದೆ. ಖಾಸಗಿ ಬದಿ ಮಾತ್ರ ಉತ್ತರಿಸಬಲ್ಲ ಹೆಸರಿನೊಂದಿಗೆ ಪರೀಕ್ಷಿಸಿ, ಮತ್ತು ಸಾರ್ವಜನಿಕ ಉತ್ತರವನ್ನು ಸೋರಿಕೆ ಎಂದು ಪರಿಗಣಿಸಿ.

resolvectl query intranet.example.internal
traceroute -n 1.1.1.1

ಮೇಲಿನ ಪಟ್ಟಿಯಿಂದ ಸಮಾಲೋಚಿಸಿದ ಸೆಲೆಕ್ಟರ್ಗಳೊಂದಿಗೆ ಆ ಎರಡು ಆಜ್ಞೆಗಳಿಂದ ಸರಪಳಿಯನ್ನು ಖಚಿತಪಡಿಸಿ. traceroute ಸ್ಥಳೀಯ ರೌಟರ್ ಅನ್ನು ಮೊದಲ ಹಾಪ್ ಎಂದು ತೋರಿಸಿದರೆ, ಸೆಲೆಕ್ಟರ್ಗಳು ಏನೇ ಹೇಳಿಕೊಂಡರೂ ಸಂಚಾರ ಟನೆಲ್ ಬಳಸುತ್ತಿಲ್ಲ. ಇಂಟರ್ನೆಟ್ ಪ್ರವೇಶವು ಆಯ್ದ ಸಂಚಾರವು ವಿನ್ಯಾಸಗೊಳಿಸಿದ ಗೇಟ್ವೇ ಮೂಲಕ ಸ್ವೀಕರಿಸಲ್ಪಟ್ಟು, ಫಾರ್ವರ್ಡ್ ಆಗಿ, ಹಿಂತಿರುಗಿಸಲ್ಪಟ್ಟಾಗ ಮಾತ್ರ ಪೂರ್ಣ. ಪ್ರೊಫೈಲ್ನಲ್ಲಿ 0.0.0.0/0 ಕಂಡುಹಿಡಿಯುವುದು ಆ ಸರಪಳಿಯ ಪ್ರಾರಂಭ, ಅದರ ಸಾಕ್ಷಿ ಅಲ್ಲ.