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

ਇੱਕ ਲੜੀ ਜੋ ਵਿਚਕਾਰਲੇ ਡੱਬੇ ਨਾਲ ਗੱਲ ਕਰਨ ਤੱਕ ਕੰਮ ਕਰਦੀ ਹੈ

ਇੱਕ ਉਦਾਹਰਨ ਲੜੀ ਲਓ: ਕਲਾਇੰਟ A UDP 500 ’ਤੇ ਸਰਵਰ B ਤੱਕ ਪਹੁੰਚਦਾ ਹੈ, ਅਤੇ B UDP 500 ’ਤੇ ਸਰਵਰ C ਵੱਲ ਅੱਗੇ ਵਧਦਾ ਹੈ। C ਸਿਰਫ਼ ਆਪਣੇ ਇੱਕਲੌਤੇ ਸਾਥੀ ਦੇ ਪਤੇ ਤੋਂ ਟ੍ਰੈਫ਼ਿਕ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ, ਜੋ ਇਸ ਨੂੰ ਪੱਤਾ ਬਣਾਉਂਦਾ ਹੈ ਅਤੇ ਇਸ ਦਾ ਵਿਵਹਾਰ ਸਧਾਰਨ ਰੱਖਦਾ ਹੈ। B ਪੱਤਾ ਨਹੀਂ ਹੈ, ਅਤੇ ਇਸ ਖ਼ਰਾਬੀ ਬਾਰੇ ਹਰ ਦਿਲਚਸਪ ਗੱਲ ਉੱਥੇ ਹੀ ਹੁੰਦੀ ਹੈ।

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

ਜਵਾਬ ਟਨਲ ਵਿੱਚੋਂ ਕਿਉਂ ਨਿਕਲਦਾ ਹੈ

B ’ਤੇ, C ਵੱਲ ਦਾ ਇੰਟਰਫ਼ੇਸ ਮਿਲਦੀ ਡਿਫ਼ਾਲਟ ਰੂਟ ਦੇ ਨਾਲ AllowedIPs = 0.0.0.0/0 ਰੱਖਦਾ ਹੈ। ਇਸ ਲਈ B ਵੱਲੋਂ ਬਣਾਇਆ ਹਰ ਪੈਕਟ ਉਸ ਟਨਲ ਵਿੱਚ ਜਾਂਦਾ ਹੈ, ਜਦੋਂ ਤੱਕ ਕੋਈ ਵਧੇਰੇ ਖ਼ਾਸ ਚੀਜ਼ ਤਰਜੀਹ ਨਹੀਂ ਲੈਂਦੀ।

A ਤੋਂ B ਵੱਲ ਭੇਜਿਆ ਪੈਕਟ ਆਉਂਦਾ ਹੈ ਅਤੇ ਸਵੀਕਾਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਕਿਉਂਕਿ B ਮੰਜ਼ਿਲ ਹੈ ਅਤੇ ਸਥਾਨਕ ਡਿਲੀਵਰੀ ਪਹਿਲਾਂ ਹੁੰਦੀ ਹੈ। ਜਵਾਬ A ਦੇ ਜਨਤਕ ਪਤੇ ਵੱਲ ਨਿਸ਼ਾਨਾ ਬਿਲਕੁਲ ਨਵਾਂ ਸਥਾਨਕ ਤੌਰ ’ਤੇ ਬਣਾਇਆ ਪੈਕਟ ਹੈ, ਅਤੇ ਉਹ ਮੰਜ਼ਿਲ ਟਨਲ ਵਿੱਚ ਜਾਣ ਵਾਲੀ ਡਿਫ਼ਾਲਟ ਰੂਟ ਨਾਲ ਮਿਲਦੀ ਹੈ। C ਇਸ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ, ਉਸ ਪਤੇ ਦਾ ਮਾਲਕ ਨਹੀਂ ਹੈ, ਅਤੇ ਇਸ ਨੂੰ ਸੁੱਟ ਦਿੰਦਾ ਹੈ।

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

ਸੰਕਰਾ ਮੁਰੰਮਤ: ਸਰੋਤ ਪੋਰਟ ਨਾਲ ਮਿਲਦੇ ਨੀਤੀ ਨਿਯਮ

B ਦੇ ਸੁਣਨ ਵਾਲੇ ਸਾਕਟ ਤੋਂ ਜਵਾਬ ਸਰੋਤ ਪੋਰਟ 500 ਨਾਲ ਬਾਹਰ ਨਿਕਲਦੇ ਹਨ। ਇੱਕ ਨੀਤੀ ਨਿਯਮ ਉਸ ਨਾਲ ਮਿਲ ਸਕਦਾ ਹੈ ਅਤੇ ਉਹ ਪੈਕਟ ਆਮ ਸਾਰਣੀ ਵਿੱਚ ਵਾਪਸ ਭੇਜ ਸਕਦਾ ਹੈ:

ip rule add sport 500 table main priority 100
ip rule add sport 8080 table main priority 101

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

ਇਸ ਤਰਕੀਬ ਦੀ ਹੱਦ ਜਾਣੋ। sport ਚੋਣਕਰਤਾ ਸਥਾਨਕ ਤੌਰ ’ਤੇ ਬਣੇ ਪੈਕਟਾਂ ਨਾਲ ਮਿਲਦਾ ਹੈ, ਜੋ ਬਿਲਕੁਲ ਜਵਾਬ ਵਾਲੇ ਕੇਸ ਨੂੰ ਕਵਰ ਕਰਦਾ ਹੈ ਅਤੇ ਜਾਣ-ਬੁੱਝ ਕੇ ਉਸ ਟ੍ਰੈਫ਼ਿਕ ਨੂੰ ਕਵਰ ਨਹੀਂ ਕਰਦਾ ਜੋ B ਸਿਰਫ਼ ਕਿਸੇ ਹੋਰ ਲਈ ਅੱਗੇ ਭੇਜਦਾ ਹੈ। B ਦੇ ਪਿੱਛੇ ਹੋਸਟ ਕੀਤੀ ਸੇਵਾ ਨੂੰ ਅਜੇ ਵੀ ਆਪਣਾ ਜਵਾਬ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਉਲਟ ਦਾ ਨਾਟਕ ਕਰਨ ਨਾਲ ਅਜਿਹਾ ਹੱਲ ਮਿਲਦਾ ਹੈ ਜੋ ਪਹਿਲੀ ਸੇਵਾ ਲਈ ਕੰਮ ਕਰਦਾ ਹੈ ਅਤੇ ਦੂਜੀ ਲਈ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ।

ਨਿਯਮ ਨੂੰ ਮਾਲਕ ਦਿਓ

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

PostUp = ip rule add sport 500 table main priority 100
PostDown = ip rule del sport 500 table main priority 100

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

ਬਦਲਾਂ ਦੀ ਇਮਾਨਦਾਰ ਤੁਲਨਾ ਕਰੋ

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

ApproachWhat it costsWhere it breaks
Source-port policy ruleOne rule per exposed portAnything B forwards rather than originates
Destination exception routeA route pinned to specific client addressesClients whose address changes
Stop full-tunnelling on BLoses the catch-all path toward CDesigns that depend on it
Split into two tunnelsMore interfaces and more policyNothing, at the cost of complexity

ਚੁਣਨ ਤੋਂ ਬਾਅਦ ਦੋਵੇਂ ਸਿਰਿਆਂ ਤੋਂ ਪੁਸ਼ਟੀ ਕਰੋ। A ਤੋਂ, B ਦੇ ਪੋਰਟ ’ਤੇ ਕਨੈਕਸ਼ਨ ਸ਼ੁਰੂ ਕਰੋ ਅਤੇ ਥੋੜ੍ਹੀ ਦੇਰ ਇਸ ਨੂੰ ਰੁੱਝਿਆ ਰੱਖੋ। B ’ਤੇ, ਕਰਨਲ ਨੂੰ ip route get <address-of-A> sport 500 ਵਰਗੀ ਕਿਸੇ ਚੀਜ਼ ਨਾਲ ਜਵਾਬ-ਰਾਹ ਨੂੰ ਜਾਇਜ਼ ਠਹਿਰਾਉਣ ਲਈ ਕਹੋ, ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਇਹ ਟਨਲ ਦੀ ਥਾਂ WAN ਇੰਟਰਫ਼ੇਸ ਦਾ ਨਾਮ ਲੈਂਦਾ ਹੈ। ਉਸ ਤੋਂ ਬਾਅਦ, ਜਾਂਚੋ ਕਿ C ਦੇ ਪਿੱਛੇ ਕੁਝ ਅਜੇ ਵੀ ਲੜੀ ਰਾਹੀਂ ਜਵਾਬ ਦੇ ਰਿਹਾ ਹੈ, ਜੋ ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ ਅਪਵਾਦ ਬਾਈਪਾਸ ਬਣਨ ਦੀ ਥਾਂ ਸੰਕਰਾ ਹੀ ਰਿਹਾ। ਅੰਤ ਵਿੱਚ, ਪੋਰਟ ਡਿਜ਼ਾਈਨ ਨੋਟਾਂ ਵਿੱਚ ਦਰਜ ਕਰੋ, ਵਰਨਾ ਅਗਲਾ ਆਪਰੇਟਰ ਇਹ ਕਿਸੇ ਹੋਰ ਸੇਵਾ ’ਤੇ ਮੁੜ ਲੱਭੇਗਾ।

ਸੰਬੰਧਿਤ ਲੇਖ