WireGuard ਰਾਹੀਂ ਇੱਕ ਐਪ: ਬਾਈਂਡਿੰਗ ਰਾਊਟਿੰਗ ਨਹੀਂ ਹੈ

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

ਇਸ ਮਕੈਨਿਜ਼ਮ ਦੇ ਦੋ ਅੱਧ ਹਨ: ਇੱਕ ਰਾਊਟਿੰਗ ਸਾਰਣੀ ਜੋ ਸਿਰਫ਼ ਟਨਲ ਦੀ ਆਵਾਜਾਈ ਵਰਤੇ, ਅਤੇ ਇੱਕ ਨਿਯਮ ਜੋ ਮਿਲਦੇ ਸਰੋਤ ਨੂੰ ਉੱਥੇ ਭੇਜੇ।

ਬਾਈਂਡਿੰਗ ਸਿਰਫ਼ ਸਰੋਤ ਪਤਾ ਸੈੱਟ ਕਰਦੀ ਹੈ, ਹੋਰ ਕੁਝ ਨਹੀਂ

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

ਇਸੇ ਲਈ ਇਹ ਨਾਕਾਮੀ ਇੰਨੀ ਅਜੀਬ ਲੱਗਦੀ ਹੈ। ਐਪ ਯਕੀਨੀ ਤੌਰ 'ਤੇ ਟਨਲ ਦਾ ਪਤਾ ਵਰਤ ਰਹੀ ਹੈ, ਟਨਲ ਯਕੀਨੀ ਤੌਰ 'ਤੇ ਚਾਲੂ ਹੈ, ਅਤੇ ਆਵਾਜਾਈ ਯਕੀਨੀ ਤੌਰ 'ਤੇ ਗ਼ਲਤ ਇੰਟਰਫ਼ੇਸ ਰਾਹੀਂ ਬਾਹਰ ਜਾ ਰਹੀ ਹੈ। ਹਰ ਬਿਆਨ ਸੱਚਾ ਹੈ, ਅਤੇ ਇਕੱਠੇ ਮਿਲ ਕੇ ਉਹ ਅਜਿਹਾ ਸਿਸਟਮ ਬਿਆਨ ਕਰਦੇ ਹਨ ਜਿੱਥੇ ਕਿਸੇ ਨੇ ਪਤੇ ਨੂੰ ਰੂਟ ਨਾਲ ਨਹੀਂ ਜੋੜਿਆ ਸੀ।

ਟਨਲ ਨੂੰ ਆਪਣੀ ਸਾਰਣੀ ਦਿਓ

wg-quick ਰੂਟ ਉੱਥੇ ਲਾਉਂਦਾ ਹੈ ਜਿੱਥੇ ਪ੍ਰੋਫ਼ਾਈਲ ਕਹਿੰਦਾ ਹੈ। [Interface] ਹੇਠ Table = 40 ਜੋੜਨ ਨਾਲ ਉਹ ਮੁੱਖ ਸਾਰਣੀ ਦੀ ਥਾਂ ਸਾਰਣੀ 40 ਵਿੱਚ ਚਲੇ ਜਾਂਦੇ ਹਨ। ਇੰਟਰਫ਼ੇਸ ਉੱਪਰ ਕਰੋ ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਉਹ ਪਹੁੰਚ ਗਏ: ip -4 route ls table 40 ਨੂੰ ਟਨਲ ਦੇ ਰੂਟ ਦਿਖਾਉਣੇ ਚਾਹੀਦੇ ਹਨ, ਅਤੇ ip -4 route get 10.66.127.142 ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਕਰਨਲ ਹੁਣ ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਇੱਕ ਨੂੰ ਕਿਵੇਂ ਹੱਲ ਕਰਦਾ ਹੈ। ਰੂਟ ਆਪਣੀ ਸਾਰਣੀ ਵਿੱਚ ਹੋਣ 'ਤੇ ਮੁੱਖ ਸਾਰਣੀ ਬਾਕੀ ਸਭ ਲਈ ਕੰਮ ਕਰਦੀ ਰਹਿੰਦੀ ਹੈ।

ਚੌੜਾ ਪ੍ਰੀਫ਼ਿਕਸ ਮਿਲਾਉਣ ਦੀ ਥਾਂ IPv6 ਲਈ ਵੀ ਇਹੀ ਕਰੋ। ip -6 rule add from fd00::2/128 lookup 40 ਇੱਕ ਪਤਾ ਪਿੰਨ ਕਰਦਾ ਹੈ; fc00::/8 ਹੋਸਟ ਦੇ ਹੋਰ ਇੰਟਰਫ਼ੇਸਾਂ ਨਾਲ ਟਕਰਾ ਸਕਦਾ ਹੈ ਅਤੇ ਇਰਾਦੇ ਤੋਂ ਵੱਧ ਮਿਲਦਾ ਨਿਯਮ ਬਣਾ ਸਕਦਾ ਹੈ।

ਸਰੋਤ ਨਿਯਮ ਜੋੜੋ ਅਤੇ ਕਾਊਂਟਰ ਵੇਖੋ

ਫਿਰ ਦੋਵੇਂ ਅੱਧ ਜੋੜੋ: ip -4 rule add from 10.66.127.142/32 lookup 40, ਉਹੀ ਪਤਾ WireGuard ਇੰਟਰਫ਼ੇਸ ਨਾਲ ਜੋੜਿਆ ਰੱਖ ਕੇ। ਦੋਵੇਂ ਨਿਯਮ PostUp ਵਿੱਚ ਰੱਖੋ ਤਾਂ ਜੋ ਮੁੜ ਕਨੈਕਟ ਹੋਣ 'ਤੇ ਉਹ ਬਹਾਲ ਹੋ ਜਾਣ। ਸੈਟਿੰਗ ਨਾਲ ਨਹੀਂ, ਅਸਲ ਬੇਨਤੀ ਨਾਲ ਜਾਂਚੋ: ip route get 1.1.1.1 from 10.66.127.142 ਨੂੰ ਟਨਲ ਡਿਵਾਈਸ ਦਾ ਨਾਮ ਦੱਸਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ curl --interface wg0 ifconfig.me ਨੂੰ ਘਰ ਦੇ ਪਤੇ ਦੀ ਥਾਂ ਟਨਲ ਦਾ ਪਤਾ ਦੱਸਣਾ ਚਾਹੀਦਾ ਹੈ।

ਜੇ ਫਿਰ ਵੀ ਨਾਕਾਮ ਹੋਵੇ ਤਾਂ ip -s rule ਪੜ੍ਹੋ। ਜੋ ਨਿਯਮ ਮੌਜੂਦ ਹੈ ਪਰ ਕਦੇ ਨਹੀਂ ਮਿਲਿਆ, ਉਹ ਸਿਫ਼ਰ ਕਾਊਂਟਰ ਦਿਖਾਉਂਦਾ ਹੈ, ਅਤੇ ਇਹੀ ਗ਼ਲਤ ਨਿਯਮ ਨੂੰ ਨਿਯਮ ਨਾ ਹੋਣ ਤੋਂ ਵੱਖ ਕਰਦਾ ਹੈ। ਉਹ ਇੱਕ ਕਮਾਂਡ ਐਪ ਨੇ ਆਪਣੀ ਇੰਟਰਫ਼ੇਸ ਸੈਟਿੰਗ ਨਜ਼ਰਅੰਦਾਜ਼ ਕੀਤੀ ਜਾਂ ਨਹੀਂ, ਇਸ ਬਾਰੇ ਬਹੁਤ ਅੰਦਾਜ਼ਾ ਬਚਾਉਂਦੀ ਹੈ।

ਉਲਟਾ ਮਾਮਲਾ: SSH ਨੂੰ ਟਨਲ ਤੋਂ ਬਾਹਰ ਰੱਖੋ

ਉਲਟੀ ਸਮੱਸਿਆ ਵੀ ਓਨੀ ਹੀ ਆਮ ਹੈ: wg-quick ਡਿਫ਼ਾਲਟ ਰੂਟ ਦਾ ਮਾਲਕ ਹੈ ਅਤੇ ਸਰਵਰ ਵੱਲ SSH ਸੈਸ਼ਨ ਵਿਚਕਾਰ ਹੀ ਮਰ ਜਾਂਦਾ ਹੈ। ਇਸਦੇ ਨਿਯਮ ਘੱਟ ਤਰਜੀਹ ਨੰਬਰ 'ਤੇ ਬੈਠਦੇ ਹਨ, ਇਸ ਲਈ ਅਪਵਾਦ ਦਾ ਮੁਲਾਂਕਣ ਉਨ੍ਹਾਂ ਤੋਂ ਪਹਿਲਾਂ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ip rule add dport 22 ipproto tcp table main priority 123 ਹਾਲੀਆ iproute2 'ਤੇ ਇਹ ਕਰਦਾ ਹੈ; ਜਿੱਥੇ ਚੋਣਕਰਤਾ ਉਪਲਬਧ ਨਹੀਂ, ਉੱਥੇ nftables ਵਿੱਚ ਪ੍ਰਵਾਹ 'ਤੇ ਨਿਸ਼ਾਨ ਲਗਾਓ ਅਤੇ ਇਸਦੀ ਥਾਂ ਨਿਸ਼ਾਨ ਮਿਲਾਓ।

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

ਸਾਰਣੀ ਨੰਬਰ, ਸਰੋਤ ਨਿਯਮ ਅਤੇ ਅਪਵਾਦ ਪ੍ਰੋਫ਼ਾਈਲ ਵਿੱਚ ਹੀ ਦਰਜ ਕਰੋ। ਤਿੰਨੇ ਇੱਕੋ ਡਿਜ਼ਾਈਨ ਦੇ ਹਨ ਅਤੇ ਇਕੱਠੇ ਸੰਪਾਦਿਤ ਕੀਤੇ ਜਾਣਗੇ।