ਇੱਕ ਗੇਟਵੇ ਤੁਹਾਡੇ ਆਪਣੇ ਯੰਤਰਾਂ ਲਈ WireGuard ਅਤੇ ਕਿਸੇ ਹੋਰ ਦੇ ਨੈੱਟਵਰਕ ਵੱਲ OpenVPN ਕਲਾਇੰਟ ਚਲਾਉਂਦਾ ਹੈ। ਦੋ ਅੰਦਰੂਨੀ ਇੰਟਰਫੇਸਾਂ ਵਿਚਕਾਰ ਫਾਰਵਰਡਿੰਗ ਕੰਮ ਕਰਦੀ ਹੈ, ਅਤੇ ਇਹ ਸਿੱਟਾ ਕੱਢਣਾ ਸੌਖਾ ਹੈ ਕਿ ਡਾਊਨਸਟਰੀਮ ਸਬਨੈੱਟ ਹੁਣ ਅੱਪਸਟਰੀਮ ਸੇਵਾ ਦਾ ਹਿੱਸਾ ਹੈ। ਇਹ ਨਹੀਂ ਹੈ। ਕਲਾਇੰਟ ਵੱਲੋਂ ਖਿੱਚਿਆ ਰੂਟ ਤੁਹਾਡੇ ਗੇਟਵੇ ਨੂੰ ਦੱਸਦਾ ਹੈ ਕਿ ਬੇਨਤੀਆਂ ਕਿੱਥੇ ਭੇਜਣੀਆਂ ਹਨ; ਪਰ ਦੂਰ ਦਾ ਨੈੱਟਵਰਕ ਉਹਨਾਂ ਯੰਤਰਾਂ ਨੂੰ ਟ੍ਰੈਫਿਕ ਕਿਵੇਂ ਵਾਪਸ ਭੇਜਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਬਾਰੇ ਉਸ ਨੇ ਕਦੇ ਨਹੀਂ ਸੁਣਿਆ, ਇਸ ਬਾਰੇ ਇਹ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦਾ। ਇੱਕ ਵੀ ਨਿਯਮ ਜੋੜਨ ਤੋਂ ਪਹਿਲਾਂ ਉਹ ਰਿਟਰਨ ਮਾਡਲ ਚੁਣੋ ਜੋ ਅੱਪਸਟਰੀਮ ਸੱਚਮੁੱਚ ਸਮਰਥਨ ਕਰਦਾ ਹੈ।

ਰੂਟਿੰਗ ਨੂੰ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਰਿਟਰਨ ਮਾਡਲ ਤੈਅ ਕਰੋ

ਇਸ ਵਾਕਥਰੂ ਵਿੱਚ ਡਾਊਨਸਟਰੀਮ ਕਲਾਇੰਟ 10.90.0.0/24 ਵਰਤਦੇ ਹਨ, ਗੇਟਵੇ ਨੂੰ ਦਿੱਤਾ ਅੱਪਸਟਰੀਮ ਟਨਲ ਪਤਾ 10.80.0.6 ਹੈ, ਅਤੇ ਮਨਜ਼ੂਰ ਦੂਰ ਦਾ ਸਰੋਤ 172.20.0.30 ਹੈ। ਇਸ ਆਕਾਰ ਨਾਲ ਦੋ ਮਾਡਲ ਮੇਲ ਖਾਂਦੇ ਹਨ: ਡਾਊਨਸਟਰੀਮ ਸਰੋਤ ਬਚਾ ਕੇ ਦੂਰ ਵਾਲੇ ਪਾਸੇ ਤੋਂ ਉਸਨੂੰ ਰੂਟ ਕਰਵਾਉਣਾ, ਜਾਂ ਸਰੋਤ ਦਾ ਗੇਟਵੇ ਦੇ ਆਪਣੇ ਟਨਲ ਪਤੇ ਵਿੱਚ ਅਨੁਵਾਦ ਕਰਨਾ। ਇਸ ਫੈਸਲੇ ਤੋਂ ਬਾਅਦ ਸਭ ਕੁਝ ਯਾਂਤ੍ਰਿਕ ਹੈ, ਅਤੇ ਫੈਸਲੇ ਨੂੰ ਆਪਣੇ ਆਪ ਵਿੱਚ ਸੇਵਾ ਦੇ ਮਾਲਕ ਦੀ ਲੋੜ ਹੈ। ਉੱਪਰ ਦੀ ਇੱਕ ਕਤਾਰ ਦੂਰ ਵਾਲੇ ਪਾਸੇ ਨਾਲ ਰੂਟਿੰਗ ਸਮਝੌਤਾ ਹੈ; ਦੂਜੀ ਤੁਸੀਂ ਇਕੱਲੇ ਕਰ ਸਕਦੇ ਹੋ ਅਜਿਹਾ ਸਥਾਨਕ ਨੀਤੀ ਬਦਲਾਅ ਹੈ। ਇਹਨਾਂ ਦੋਹਾਂ ਨੂੰ ਮਿਲਾਉਣਾ ਹੀ ਦਸ ਮਿੰਟ ਦੇ ਕੰਮ ਨੂੰ ਗੱਲਬਾਤ ਵਿੱਚ ਬਦਲਦਾ ਹੈ।

preserved:  10.90.0.23 -> 172.20.0.30
translated: 10.80.0.6  -> 172.20.0.30

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

ਰੂਟ ਰਾਹੀਂ ਸਰੋਤ ਸੰਭਾਲ

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

ਜੇ ਜਵਾਬ ਹਾਂ ਹੈ, ਤਾਂ ਸਥਾਨਕ ਸੰਰਚਨਾ ਛੋਟੀ ਹੈ: ਫਾਰਵਰਡਿੰਗ ਸਮਰੱਥ, ਡਾਊਨਸਟਰੀਮ ਰੇਂਜ ਨੂੰ ਢਕਣ ਵਾਲੇ WireGuard ਪੀਅਰ ਦੇ allowed-ips, ਅਤੇ ਦੋਵੇਂ ਦਿਸ਼ਾਵਾਂ ਵਿੱਚ ਲੰਘਣ ਦੀ ਆਗਿਆ ਦੇਣ ਵਾਲੀ ਫਾਇਰਵਾਲ ਨੀਤੀ।

ਜਾਣ-ਬੁੱਝ ਕੇ ਸਰੋਤ ਅਨੁਵਾਦ

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

IPv6 ਨੂੰ ਆਪਣਾ ਡਿਜ਼ਾਈਨ ਚਾਹੀਦਾ ਹੈ; IPv4 masquerade ਲਾਈਨ ਕਾਪੀ ਕਰਨਾ ਆਰਕੀਟੈਕਚਰ ਨਹੀਂ ਹੈ। ਅਨੁਵਾਦਿਤ ਰਾਹ ਨੂੰ ਕੈਸ਼ ਕੀਤੇ ਕਨੈਕਸ਼ਨ ਦੀ ਬਜਾਏ ਨਵੇਂ ਕਨੈਕਸ਼ਨ ਨਾਲ ਪਰਖੋ।

ਸਥਾਨਕ ਡੇਟਾ ਰਾਹ ਨੂੰ ਅਜੇ ਵੀ ਕੰਮ ਕਰਨਾ ਹੈ

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

ਗੇਟਵੇ ਤੋਂ ਨਹੀਂ, ਅਸਲ ਡਾਊਨਸਟਰੀਮ ਯੰਤਰ ਤੋਂ ਪਰਖੋ। ਸਰੋਤ ਪਤਾ ਹੀ ਇਸ ਅਭਿਆਸ ਦਾ ਪੂਰਾ ਮਕਸਦ ਹੈ।

ਇੱਕ ਸਰੋਤ ਦਾ ਮਤਲਬ ਇੱਕ ਸੈਸ਼ਨ ਪਛਾਣ

ਦੂਰ ਦੀ ਸੇਵਾ ਹਰ ਡਾਊਨਸਟਰੀਮ ਯੰਤਰ ਲਈ ਵੱਖਰੀ ਪ੍ਰਮਾਣਿਕਤਾ ਨਹੀਂ, ਸਗੋਂ ਗੇਟਵੇ ਦਾ ਪ੍ਰਮਾਣਿਤ ਸੈਸ਼ਨ ਅਤੇ ਉਸਦਾ ਅਨੁਵਾਦਿਤ ਪਤਾ ਦੇਖਦੀ ਹੈ। ਪ੍ਰਤੀ-ਯੰਤਰ ਆਗਿਆਵਾਂ ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਪਛਾਣਾਂ ਸਪਸ਼ਟ ਰੱਖੋ, ਅਤੇ ਸੇਵਾ ਦੇ ਮਾਲਕ ਤੋਂ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਕਈ ਯੰਤਰਾਂ ਵੱਲੋਂ ਕੰਮ ਕਰਨ ਵਾਲੇ ਗੇਟਵੇ ਨੂੰ ਬਿਲਕੁਲ ਆਗਿਆ ਹੈ। ਅਨੁਵਾਦ ਪ੍ਰਤੀ-ਯੰਤਰ ਰਜਿਸਟਰੇਸ਼ਨ ਦੀ ਲੋੜ ਨੂੰ ਟਾਲਣ ਦਾ ਤਰੀਕਾ ਨਹੀਂ ਹੈ; ਜੇ ਸੇਵਾ ਹਰ ਯੰਤਰ ਦੀ ਰਜਿਸਟਰੇਸ਼ਨ ਮੰਗਦੀ ਹੈ, ਤਾਂ ਉਹੀ ਮਾਡਲ ਵਰਤੋ ਜਾਂ ਸਾਈਟ-ਟੂ-ਸਾਈਟ ਪ੍ਰਬੰਧ ਲਈ ਗੱਲਬਾਤ ਕਰੋ।

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

ਡਿਸਕਨੈਕਟ ਹੋਈ ਸਥਿਤੀ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ, ਫਿਰ ਤਿੰਨ ਬੇਨਤੀਆਂ ਪਰਖੋ

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

ਹਰ ਨਿਯਮ ਲਈ ਇੱਕ ਲਾਈਨ ਵਿੱਚ ਰੋਲਬੈਕ ਦਰਜ ਕਰੋ, ਤਾਂ ਜੋ ਇਰਾਦਾ ਮੁੜ ਬਣਾਏ ਬਿਨਾਂ ਬਦਲਾਅ ਰੱਦ ਕੀਤਾ ਜਾ ਸਕੇ।

ਸੰਬੰਧਿਤ ਲੇਖ