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 ਲੱਭਣਾ ਉਸ ਲੜੀ ਦੀ ਸ਼ੁਰੂਆਤ ਹੈ, ਉਸਦਾ ਸਬੂਤ ਨਹੀਂ।