IPv6 ਸ਼ਾਖਾ ਉਪਸਰਗ: ਸਰਵਰ ਉੱਤੇ iroute-ipv6 ਜਾਂ route-ipv6?

ਲਗਭਗ ਇੱਕੋ ਨਾਂ ਵਾਲੀਆਂ ਦੋ ਹਦਾਇਤਾਂ ਹਰ ਕੰਮ ਕਰਦੀ ਉਦਾਹਰਨ ਵਿੱਚ ਆਉਂਦੀਆਂ ਹਨ, ਅਤੇ ਇੱਕ ਨੂੰ ਦੂਜੇ ਤੋਂ ਬਿਨਾਂ ਕਾਪੀ ਕਰਨਾ ਇੱਕ ਐਸੀ ਟਨਲ ਬਣਾਉਂਦਾ ਹੈ ਜੋ ਸਹੀ ਦਿਸਦੀ ਹੈ ਅਤੇ ਸ਼ਾਖਾ ਉਪਸਰਗ ਚੁੱਪਚਾਪ ਗੁਆ ਦਿੰਦੀ ਹੈ। ਉਹ ਇੱਕੋ ਸੀਮਾ ਦੇ ਦੋ ਵੱਖਰੇ ਪਾਸਿਆਂ ਉੱਤੇ ਵੱਖਰਾ ਕੰਮ ਕਰਦੀਆਂ ਹਨ: ਇੱਕ ਸਰਵਰ ਦੇ ਕਰਨਲ ਨੂੰ ਸਿਖਾਉਂਦੀ ਹੈ ਕਿ ਉਪਸਰਗ ਕਿੱਥੇ ਰਹਿੰਦਾ ਹੈ, ਅਤੇ ਦੂਜੀ OpenVPN ਨੂੰ ਸਿਖਾਉਂਦੀ ਹੈ ਕਿ ਕਿਹੜਾ ਪ੍ਰਮਾਣਿਤ ਕਲਾਇੰਟ ਇਸਨੂੰ ਲੈ ਕੇ ਚੱਲਦਾ ਹੈ। ਦੋਵੇਂ ਸਹੀ ਹੋਣ ਤਾਂ ਉਪਸਰਗ ਵਹਿੰਦਾ ਹੈ; ਇੱਕ ਸਹੀ ਹੋਵੇ ਤਾਂ ਪੈਕਟਾਂ ਦਾ ਰਾਹ ਹੈ ਪਰ ਮਾਲਕ ਨਹੀਂ।

ਦੋ ਹਦਾਇਤਾਂ, ਦੋ ਵੱਖਰੇ ਕੰਮ

route-ipv6 ਇੱਕ ਆਮ ਰੂਟ ਸਥਾਪਨਾ ਹੈ: ਸਰਵਰ ਇੱਕ ਕਰਨਲ ਰੂਟ ਜੋੜਦਾ ਹੈ ਜੋ ਉਪਸਰਗ ਨੂੰ ਆਪਣੇ ਟਨਲ ਇੰਟਰਫ਼ੇਸ ਵੱਲ ਦਿਖਾਉਂਦਾ ਹੈ। iroute-ipv6 ਕਿਸੇ ਖ਼ਾਸ ਕਲਾਇੰਟ ਦੇ ਸੰਦਰਭ ਨਾਲ ਸਬੰਧਤ ਹੈ ਅਤੇ ਅੰਦਰੂਨੀ ਮਾਲਕੀ ਦਾ ਐਲਾਨ ਕਰਦੀ ਹੈ, ਤਾਂ ਜੋ ਡੈਮਨ ਜਾਣ ਸਕੇ ਕਿ ਉਸ ਉਪਸਰਗ ਦੀ ਟ੍ਰੈਫ਼ਿਕ ਕਿਸੇ ਖ਼ਾਸ ਕਲਾਇੰਟ ਨੂੰ ਭੇਜਣੀ ਚਾਹੀਦੀ ਹੈ, ਨਾ ਕਿ ਉਸ ਪੀਅਰ ਨੂੰ ਜਿਸਦਾ ਨਾਂ ਕਰਨਲ ਰੂਟ ਸੰਜੋਗ ਨਾਲ ਲੈਂਦਾ ਹੈ।

ਇੱਕ ਕਰਨਲ ਦੀ ਫਾਰਵਰਡਿੰਗ ਸਾਰਣੀ ਨਾਲ ਹੈ, ਦੂਜੀ ਡੈਮਨ ਦੇ ਅੰਦਰੂਨੀ ਰਾਊਟਿੰਗ ਮਾਡਲ ਨਾਲ। ਇਹਨਾਂ ਨੂੰ ਵੱਖਰਾ ਰੱਖਣਾ ਦੱਸਦਾ ਹੈ ਕਿ ਪੂਰੀ ਦਿਸਦੀ ਕਨਫ਼ਿਗਰੇਸ਼ਨ ਵੀ ਉਪਸਰਗ ਕਿਉਂ ਗੁਆ ਸਕਦੀ ਹੈ। ਇਹ ਵੀ ਦੱਸਦਾ ਹੈ ਕਿ ਉਹੀ ਨੈੱਟਵਰਕ ਹਰ ਕੰਮ ਕਰਦੀ ਉਦਾਹਰਨ ਵਿੱਚ ਦੋ ਵਾਰ ਕਿਉਂ ਆਉਂਦਾ ਹੈ। ਦੋਹਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਲਾਈਨ ਵਾਧੂ ਨਹੀਂ।

ਰਵਾਇਤੀ userspace ਸੈਟਅਪ ਵਿੱਚ ਦੋਵੇਂ ਲੋੜੀਂਦੇ ਹਨ ਅਤੇ ਇੱਕ ਦੂਜੇ ਨੂੰ ਪੂਰਾ ਕਰਦੇ ਹਨ। ਇਕੱਲਾ ਕਰਨਲ ਰੂਟ ਡੈਮਨ ਨੂੰ ਪੀਅਰ ਚੁਣਨ ਤੋਂ ਅਸਮਰੱਥ ਛੱਡ ਦਿੰਦਾ ਹੈ। ਇਕੱਲਾ iroute ਕਰਨਲ ਨੂੰ ਟਨਲ ਤੱਕ ਰਾਹ ਤੋਂ ਬਿਨਾਂ ਛੱਡ ਦਿੰਦਾ ਹੈ। ਇੱਥੋਂ ਹੀ ਪ੍ਰਤੀ-ਕਲਾਇੰਟ ਫਾਈਲਾਂ ਬਾਰੇ ਬਹੁਤੀ ਉਲਝਣ ਆਉਂਦੀ ਹੈ: ਫਾਈਲ ਰੂਟ ਸਾਰਣੀ ਦੀ ਐਂਟਰੀ ਨਹੀਂ ਹੈ, ਅਤੇ ਰੂਟ ਐਂਟਰੀ ਮਾਲਕੀ ਦਾ ਐਲਾਨ ਨਹੀਂ ਹੈ।

ip -6 route show | grep fd00:7a
ip -6 route get fd00:7a::1

ਕਿਹੜਾ ਕਿੱਥੇ ਜਾਂਦਾ ਹੈ

ਰੂਟ ਸਰਵਰ ਦੀ ਪ੍ਰਬੰਧਿਤ ਕਨਫ਼ਿਗਰੇਸ਼ਨ ਵਿੱਚ ਜਾਂਦਾ ਹੈ, ਜਿੱਥੇ ਇਹ ਉਸੇ ਸਰਵਰ ਪ੍ਰਕਿਰਿਆ ਉੱਤੇ ਲਾਗੂ ਹੁੰਦਾ ਹੈ। iroute ਕਲਾਇੰਟ-ਖ਼ਾਸ ਫਾਈਲ ਵਿੱਚ ਜਾਂਦਾ ਹੈ, ਜੋ ਸ਼ਾਖਾ ਡਿਵਾਈਸ ਦੀ ਪ੍ਰਮਾਣਿਤ ਪਛਾਣ ਦੇ ਨਾਂ ਉੱਤੇ ਹੈ।

ਅਜਿਹਾ ਫਾਈਲ ਨਾਂ ਜੋ ਅਸਲ ਪਛਾਣ ਨਾਲ ਨਹੀਂ ਮਿਲਦਾ, ਕਦੇ ਪੜ੍ਹਿਆ ਨਹੀਂ ਜਾਂਦਾ, ਅਤੇ ਲੱਛਣ ਬਿਲਕੁਲ ਗੁੰਮ iroute ਵਰਗਾ ਹੁੰਦਾ ਹੈ। ਜਿਹੜੀ ਪਛਾਣ ਸਰਵਰ ਨੇ ਪ੍ਰਮਾਣਿਤ ਕੀਤੀ ਉਸਨੂੰ ਜਾਂਚੋ, ਫਿਰ ਫਾਈਲ ਨਾਂ ਨੂੰ ਅੱਖਰ-ਦਰ-ਅੱਖਰ ਜਾਂਚੋ।

# /etc/openvpn/server/server.conf
route-ipv6 fd00:7a::/64
client-config-dir /etc/openvpn/server/ccd

# /etc/openvpn/server/ccd/branch-b
iroute-ipv6 fd00:7a::/64

ਪੂਲ ਅਤੇ ਸ਼ਾਖਾ ਉਪਸਰਗ ਵੱਖਰੇ ਰੱਖੋ, ਕਿਉਂਕਿ ਇਹਨਾਂ ਦਾ ਓਵਰਲੈਪ ਐਸੀ ਬੁਝਾਰਤ ਬਣਾਉਂਦਾ ਹੈ ਜਿਸਨੂੰ ਕੋਈ ਹਦਾਇਤ ਹੱਲ ਨਹੀਂ ਕਰ ਸਕਦੀ।

ਦੂਜੇ ਕਲਾਇੰਟ ਨੂੰ ਕੀ ਚਾਹੀਦਾ ਹੈ

ਉਸ ਸ਼ਾਖਾ ਤੱਕ ਪਹੁੰਚਣ ਵਾਲੇ ਦੂਜੇ ਕਲਾਇੰਟ ਨੂੰ ਮਾਲਕੀ ਨਹੀਂ, ਐਲਾਨ ਚਾਹੀਦਾ ਹੈ। ਉਪਸਰਗ ਉਹਨਾਂ ਕਲਾਇੰਟਾਂ ਨੂੰ ਭੇਜੋ ਜਿਹਨਾਂ ਨੂੰ ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ, ਤੁਹਾਡੀ ਕਨਫ਼ਿਗਰੇਸ਼ਨ ਨਾਲ ਮੇਲ ਖਾਂਦੇ ਕਲਾਇੰਟ ਜਾਂ ਗਰੁੱਪ ਸੰਦਰਭ ਵਿੱਚ।

ਇਸਨੂੰ ਸ਼ਾਖਾ ਨੂੰ ਹੀ ਨਾ ਭੇਜੋ, ਕਿਉਂਕਿ ਉਸ ਡਿਵਾਈਸ ਕੋਲ ਉਪਸਰਗ ਪਹਿਲਾਂ ਹੀ ਜੁੜੇ ਨੈੱਟਵਰਕ ਵਜੋਂ ਹੈ।

ਇਸਨੂੰ ਸਭ ਨੂੰ ਭੇਜਣਾ ਨਤੀਜਿਆਂ ਵਾਲੀ ਚੋਣ ਹੈ: ਫਿਰ ਹਰ ਕਲਾਇੰਟ ਮੰਨਦਾ ਹੈ ਕਿ ਸ਼ਾਖਾ ਟਨਲ ਰਾਹੀਂ ਪਹੁੰਚਯੋਗ ਹੈ, ਉਹਨਾਂ ਕਲਾਇੰਟਾਂ ਸਮੇਤ ਜਿਹਨਾਂ ਨੂੰ ਤੁਸੀਂ ਕਦੇ ਇਹ ਪਹੁੰਚ ਦੇਣੀ ਨਹੀਂ ਸੀ ਚਾਹੁੰਦੇ। ਐਲਾਨ ਵਿਵਹਾਰ ਵਿੱਚ ਪਹੁੰਚ ਦਾ ਫ਼ੈਸਲਾ ਹੈ, ਭਾਵੇਂ ਹਦਾਇਤ ਪਲੰਬਿੰਗ ਦੇ ਕੰਮ ਵਰਗੀ ਲੱਗਦੀ ਹੈ। ਸਰਵਰ ਵਿਕਲਪ ਸੰਦਰਭ iroute-ipv6 ਨੂੰ ਕਲਾਇੰਟ-ਖ਼ਾਸ ਮਾਲਕੀ ਵਜੋਂ ਦਸਤਾਵੇਜ਼ ਕਰਦਾ ਹੈ, ਅਤੇ ਇਹੀ ਉਹ ਫ਼ਰਕ ਹੈ ਜਿਸਨੂੰ ਰੱਖਣਾ ਕੀਮਤੀ ਹੈ।

ਸ਼ਾਖਾ ਡਿਵਾਈਸ ਉੱਤੇ ਵਾਪਸੀ ਦਾ ਰਾਹ

ਮਾਲਕੀ ਤਦ ਹੀ ਮਦਦ ਕਰਦੀ ਹੈ ਜਦੋਂ ਸ਼ਾਖਾ ਪੈਕਟ ਫਾਰਵਰਡ ਕਰੇ ਅਤੇ ਉਸਦਾ LAN ਜਵਾਬ ਦੇਣਾ ਜਾਣੇ। ਸ਼ਾਖਾ ਡਿਵਾਈਸ ਉੱਤੇ IPv6 ਫਾਰਵਰਡਿੰਗ ਸਮਰੱਥ ਕਰੋ, ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਉਸਦੇ LAN ਦੇ ਹੋਸਟ VPN ਪੂਲ ਦੀ ਟ੍ਰੈਫ਼ਿਕ ਵਾਪਸ ਸ਼ਾਖਾ ਵੱਲ ਭੇਜਦੇ ਹਨ, ਨਾ ਕਿ ਪੂਲ ਨਾ ਜਾਣਨ ਵਾਲੇ ਡਿਫ਼ਾਲਟ ਰੂਟ ਵੱਲ।

ਉਹ ਵਾਪਸੀ ਦਾ ਰਾਹ IPv6 ਵਿੱਚ ਉਸ ਗੁੰਮ ਰੂਟ ਸਮੱਸਿਆ ਦਾ ਸਮਕੱਖ ਹੈ ਜੋ ਲੋਕਾਂ ਨੂੰ IPv4 ਵਿੱਚ ਮਿਲਦੀ ਹੈ।

ਇਸਨੂੰ LAN ਦੇ ਹੋਸਟ ਤੋਂ VPN ਪੂਲ ਦੇ ਪਤੇ ਦੀ ਕਵੈਰੀ ਨਾਲ ਜਾਂਚੋ, ਸ਼ਾਖਾ ਤੋਂ ਹੀ ਨਹੀਂ। ਰਾਊਟਰ ਉੱਤੇ ਕੀਤੀ ਕਵੈਰੀ ਤੁਹਾਡੇ ਵਰਤੋਂਕਾਰਾਂ ਦੇ ਸਵਾਲ ਤੋਂ ਵੱਖਰੇ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦਿੰਦੀ ਹੈ, ਅਤੇ ਦੋਵੇਂ ਇੰਨੇ ਵਾਰ ਵੱਖਰੇ ਹੁੰਦੇ ਹਨ ਕਿ ਵਾਧੂ ਕਮਾਂਡ ਕੀਮਤੀ ਹੋਵੇ।

ਜਦੋਂ ਜੋੜੀ ਅਜੇ ਵੀ ਕਾਫ਼ੀ ਨਾ ਹੋਵੇ

ਕੁਝ ਤੈਨਾਤੀਆਂ ਇਹ ਰਾਹ ਬਿਲਕੁਲ ਨਹੀਂ ਵਰਤਦੀਆਂ। ਕਰਨਲ ਦਾ ਡੇਟਾ ਰਾਹ ਅਤੇ ਉਤਪਾਦ-ਪ੍ਰਬੰਧਿਤ ਸਰਵਰਾਂ ਕੋਲ ਆਪਣੀ ਸਮਰਥਿਤ ਰੂਟ ਹੈਂਡਲਿੰਗ ਹੈ, ਅਤੇ userspace ਉਦਾਹਰਨ ਸਿੱਧੀ ਤਬਦੀਲ ਨਾ ਹੋ ਸਕੇ।

ਦੂਜੇ ਲਈ ਲਿਖੀ ਗਾਈਡ ਤੋਂ ਹਦਾਇਤਾਂ ਕਾਪੀ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਤੁਹਾਡਾ ਬਿਲਡ ਕਿਹੜਾ ਡੇਟਾ ਰਾਹ ਵਰਤਦਾ ਹੈ।

ਅਤੇ ਅੰਤ ਵਿੱਚ, ਪਤਿਆਂ ਦਾ ਦਾਇਰਾ ਯਾਦ ਰੱਖੋ: ਵਿਲੱਖਣ ਸਥਾਨਕ ਉਪਸਰਗ ਜਿਵੇਂ fd00:7a::/64 ਡਿਜ਼ਾਈਨ ਨਾਲ ਨਿੱਜੀ ਹੈ ਅਤੇ ਜਨਤਕ IPv6 ਪਹੁੰਚ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦਾ। ਇਸਨੂੰ ਅੰਦਰੂਨੀ ਪਹੁੰਚ ਮੰਨੋ, ਅਤੇ ਇੰਟਰਨੈੱਟ ਤੋਂ ਬਾਹਰ ਜਾਣ ਨੂੰ ਆਪਣੀ ਨੀਤੀ ਵਾਲਾ ਵੱਖਰਾ ਮਾਮਲਾ ਰੱਖੋ।