ਨੈੱਟਵਰਕਾਂ ਨੂੰ ਇੱਕ L2 ਨੈੱਟਵਰਕ ਵਿੱਚ ਜੋੜਨ ਲਈ OpenVPN ਤੋਂ WireGuard ਵਿੱਚ ਬਦਲਣਾ

ਮੈਂ ਤਿੰਨ ਭੂਗੋਲਿਕ ਤੌਰ 'ਤੇ ਰਿਮੋਟ ਅਪਾਰਟਮੈਂਟਾਂ ਵਿੱਚ ਨੈੱਟਵਰਕਾਂ ਨੂੰ ਜੋੜਨ ਦੇ ਆਪਣੇ ਅਨੁਭਵ ਨੂੰ ਸਾਂਝਾ ਕਰਨਾ ਚਾਹਾਂਗਾ, ਜਿਨ੍ਹਾਂ ਵਿੱਚੋਂ ਹਰ ਇੱਕ ਓਪਨਡਬਲਯੂਆਰਟੀ ਰਾਊਟਰਾਂ ਨੂੰ ਇੱਕ ਗੇਟਵੇ ਵਜੋਂ, ਇੱਕ ਸਾਂਝੇ ਨੈੱਟਵਰਕ ਵਿੱਚ ਵਰਤਦਾ ਹੈ। ਸਬਨੈੱਟ ਰੂਟਿੰਗ ਦੇ ਨਾਲ L3 ਅਤੇ ਬ੍ਰਿਜਿੰਗ ਦੇ ਨਾਲ L2 ਦੇ ਵਿਚਕਾਰ ਨੈੱਟਵਰਕਾਂ ਨੂੰ ਜੋੜਨ ਲਈ ਇੱਕ ਵਿਧੀ ਦੀ ਚੋਣ ਕਰਦੇ ਸਮੇਂ, ਜਦੋਂ ਸਾਰੇ ਨੈਟਵਰਕ ਨੋਡ ਇੱਕੋ ਸਬਨੈੱਟ ਵਿੱਚ ਹੋਣਗੇ, ਦੂਜੀ ਵਿਧੀ ਨੂੰ ਤਰਜੀਹ ਦਿੱਤੀ ਗਈ ਸੀ, ਜੋ ਕਿ ਕੌਂਫਿਗਰ ਕਰਨਾ ਵਧੇਰੇ ਮੁਸ਼ਕਲ ਹੈ, ਪਰ ਵਧੇਰੇ ਮੌਕੇ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ, ਕਿਉਂਕਿ ਵੇਕ-ਆਨ-ਲੈਨ ਅਤੇ ਡੀਐਲਐਨਏ ਬਣਾਏ ਜਾ ਰਹੇ ਨੈਟਵਰਕ ਵਿੱਚ ਤਕਨਾਲੋਜੀਆਂ ਦੀ ਪਾਰਦਰਸ਼ੀ ਵਰਤੋਂ ਦੀ ਯੋਜਨਾ ਬਣਾਈ ਗਈ ਸੀ।

ਭਾਗ 1: ਪਿਛੋਕੜ

ਓਪਨਵੀਪੀਐਨ ਨੂੰ ਸ਼ੁਰੂ ਵਿੱਚ ਇਸ ਕੰਮ ਨੂੰ ਲਾਗੂ ਕਰਨ ਲਈ ਪ੍ਰੋਟੋਕੋਲ ਵਜੋਂ ਚੁਣਿਆ ਗਿਆ ਸੀ, ਕਿਉਂਕਿ, ਸਭ ਤੋਂ ਪਹਿਲਾਂ, ਇਹ ਇੱਕ ਟੈਪ ਡਿਵਾਈਸ ਬਣਾ ਸਕਦਾ ਹੈ ਜਿਸ ਨੂੰ ਬਿਨਾਂ ਕਿਸੇ ਸਮੱਸਿਆ ਦੇ ਪੁਲ ਵਿੱਚ ਜੋੜਿਆ ਜਾ ਸਕਦਾ ਹੈ, ਅਤੇ ਦੂਜਾ, ਓਪਨਵੀਪੀਐਨ ਟੀਸੀਪੀ ਪ੍ਰੋਟੋਕੋਲ ਉੱਤੇ ਓਪਰੇਸ਼ਨ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ, ਜੋ ਕਿ ਮਹੱਤਵਪੂਰਨ ਵੀ ਸੀ, ਕਿਉਂਕਿ ਕੋਈ ਨਹੀਂ ਅਪਾਰਟਮੈਂਟਾਂ ਦਾ ਇੱਕ ਸਮਰਪਿਤ IP ਪਤਾ ਸੀ, ਅਤੇ ਮੈਂ STUN ਦੀ ਵਰਤੋਂ ਕਰਨ ਵਿੱਚ ਅਸਮਰੱਥ ਸੀ, ਕਿਉਂਕਿ ਮੇਰੇ ਪ੍ਰਦਾਤਾ ਨੇ ਕਿਸੇ ਕਾਰਨ ਕਰਕੇ ਉਹਨਾਂ ਦੇ ਨੈੱਟਵਰਕਾਂ ਤੋਂ ਆਉਣ ਵਾਲੇ UDP ਕਨੈਕਸ਼ਨਾਂ ਨੂੰ ਰੋਕ ਦਿੱਤਾ, ਜਦੋਂ ਕਿ TCP ਪ੍ਰੋਟੋਕੋਲ ਨੇ ਮੈਨੂੰ SSH ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ VPN ਸਰਵਰ ਪੋਰਟ ਨੂੰ ਕਿਰਾਏ ਦੇ VPS 'ਤੇ ਅੱਗੇ ਭੇਜਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੱਤੀ। ਹਾਂ, ਇਹ ਪਹੁੰਚ ਇੱਕ ਵੱਡਾ ਲੋਡ ਦਿੰਦੀ ਹੈ, ਕਿਉਂਕਿ ਡੇਟਾ ਦੋ ਵਾਰ ਏਨਕ੍ਰਿਪਟ ਕੀਤਾ ਗਿਆ ਹੈ, ਪਰ ਮੈਂ ਆਪਣੇ ਨਿੱਜੀ ਨੈਟਵਰਕ ਵਿੱਚ ਇੱਕ VPS ਪੇਸ਼ ਨਹੀਂ ਕਰਨਾ ਚਾਹੁੰਦਾ ਸੀ, ਕਿਉਂਕਿ ਅਜੇ ਵੀ ਤੀਜੀ ਧਿਰਾਂ ਦਾ ਇਸ ਉੱਤੇ ਨਿਯੰਤਰਣ ਪ੍ਰਾਪਤ ਕਰਨ ਦਾ ਜੋਖਮ ਸੀ, ਇਸਲਈ, ਅਜਿਹੀ ਡਿਵਾਈਸ ਹੋਣ ਨਾਲ ਮੇਰੇ ਘਰੇਲੂ ਨੈੱਟਵਰਕ 'ਤੇ ਬਹੁਤ ਹੀ ਅਣਚਾਹੇ ਸੀ ਅਤੇ ਇਹ ਇੱਕ ਵੱਡੇ ਓਵਰਹੈੱਡ ਨਾਲ ਸੁਰੱਖਿਆ ਲਈ ਭੁਗਤਾਨ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਗਿਆ ਸੀ।

ਰਾਊਟਰ 'ਤੇ ਪੋਰਟ ਨੂੰ ਅੱਗੇ ਭੇਜਣ ਲਈ ਜਿਸ 'ਤੇ ਸਰਵਰ ਨੂੰ ਤੈਨਾਤ ਕਰਨ ਦੀ ਯੋਜਨਾ ਬਣਾਈ ਗਈ ਸੀ, sshtunnel ਪ੍ਰੋਗਰਾਮ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਗਈ ਸੀ। ਮੈਂ ਇਸਦੀ ਕੌਂਫਿਗਰੇਸ਼ਨ ਦੀਆਂ ਪੇਚੀਦਗੀਆਂ ਦਾ ਵਰਣਨ ਨਹੀਂ ਕਰਾਂਗਾ - ਇਹ ਕਾਫ਼ੀ ਅਸਾਨੀ ਨਾਲ ਕੀਤਾ ਗਿਆ ਹੈ, ਮੈਂ ਸਿਰਫ ਨੋਟ ਕਰਾਂਗਾ ਕਿ ਇਸਦਾ ਕੰਮ ਟੀਸੀਪੀ ਪੋਰਟ 1194 ਨੂੰ ਰਾਊਟਰ ਤੋਂ VPS ਤੱਕ ਭੇਜਣਾ ਸੀ. ਅੱਗੇ, OpenVPN ਸਰਵਰ ਨੂੰ tap0 ਡਿਵਾਈਸ 'ਤੇ ਕੌਂਫਿਗਰ ਕੀਤਾ ਗਿਆ ਸੀ, ਜੋ ਕਿ br-lan ਬ੍ਰਿਜ ਨਾਲ ਜੁੜਿਆ ਹੋਇਆ ਸੀ। ਲੈਪਟਾਪ ਤੋਂ ਨਵੇਂ ਬਣੇ ਸਰਵਰ ਨਾਲ ਕੁਨੈਕਸ਼ਨ ਦੀ ਜਾਂਚ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਇਹ ਸਪੱਸ਼ਟ ਹੋ ਗਿਆ ਕਿ ਪੋਰਟ ਫਾਰਵਰਡਿੰਗ ਦਾ ਵਿਚਾਰ ਜਾਇਜ਼ ਸੀ ਅਤੇ ਮੇਰਾ ਲੈਪਟਾਪ ਰਾਊਟਰ ਦੇ ਨੈਟਵਰਕ ਦਾ ਮੈਂਬਰ ਬਣ ਗਿਆ, ਹਾਲਾਂਕਿ ਇਹ ਸਰੀਰਕ ਤੌਰ 'ਤੇ ਇਸ ਵਿੱਚ ਨਹੀਂ ਸੀ।

ਕਰਨ ਲਈ ਸਿਰਫ ਇੱਕ ਛੋਟੀ ਜਿਹੀ ਚੀਜ਼ ਬਚੀ ਸੀ: ਵੱਖ-ਵੱਖ ਅਪਾਰਟਮੈਂਟਾਂ ਵਿੱਚ IP ਪਤਿਆਂ ਨੂੰ ਵੰਡਣਾ ਜ਼ਰੂਰੀ ਸੀ ਤਾਂ ਜੋ ਉਹ ਵਿਰੋਧ ਨਾ ਕਰਨ ਅਤੇ ਰਾਊਟਰਾਂ ਨੂੰ OpenVPN ਕਲਾਇੰਟਸ ਵਜੋਂ ਕੌਂਫਿਗਰ ਨਾ ਕਰਨ।
ਹੇਠਾਂ ਦਿੱਤੇ ਰਾਊਟਰ IP ਐਡਰੈੱਸ ਅਤੇ DHCP ਸਰਵਰ ਰੇਂਜਾਂ ਨੂੰ ਚੁਣਿਆ ਗਿਆ ਸੀ:

• 192.168.10.1 ਸੀਮਾ ਦੇ ਨਾਲ 192.168.10.2 - 192.168.10.80 ਸਰਵਰ ਲਈ
• 192.168.10.100 ਸੀਮਾ ਦੇ ਨਾਲ 192.168.10.101 - 192.168.10.149 ਅਪਾਰਟਮੈਂਟ ਨੰਬਰ 2 ਵਿੱਚ ਰਾਊਟਰ ਲਈ
• 192.168.10.150 ਸੀਮਾ ਦੇ ਨਾਲ 192.168.10.151 - 192.168.10.199 ਅਪਾਰਟਮੈਂਟ ਨੰਬਰ 3 ਵਿੱਚ ਰਾਊਟਰ ਲਈ

ਓਪਨਵੀਪੀਐਨ ਸਰਵਰ ਦੇ ਕਲਾਇੰਟ ਰਾਊਟਰਾਂ ਨੂੰ ਇਸਦੀ ਸੰਰਚਨਾ ਵਿੱਚ ਲਾਈਨ ਜੋੜ ਕੇ ਬਿਲਕੁਲ ਇਹਨਾਂ ਪਤਿਆਂ ਨੂੰ ਨਿਰਧਾਰਤ ਕਰਨਾ ਵੀ ਜ਼ਰੂਰੀ ਸੀ:

ifconfig-pool-persist /etc/openvpn/ipp.txt 0

ਅਤੇ ਹੇਠ ਲਿਖੀਆਂ ਲਾਈਨਾਂ ਨੂੰ /etc/openvpn/ipp.txt ਫਾਈਲ ਵਿੱਚ ਜੋੜਨਾ:

flat1_id 192.168.10.100
flat2_id 192.168.10.150

ਜਿੱਥੇ flat1_id ਅਤੇ flat2_id ਓਪਨਵੀਪੀਐਨ ਨਾਲ ਕਨੈਕਟ ਕਰਨ ਲਈ ਸਰਟੀਫਿਕੇਟ ਬਣਾਉਂਦੇ ਸਮੇਂ ਨਿਰਦਿਸ਼ਟ ਡਿਵਾਈਸ ਦੇ ਨਾਮ ਹੁੰਦੇ ਹਨ

ਅੱਗੇ, ਓਪਨਵੀਪੀਐਨ ਕਲਾਇੰਟਸ ਰਾਊਟਰਾਂ 'ਤੇ ਕੌਂਫਿਗਰ ਕੀਤੇ ਗਏ ਸਨ, ਦੋਵਾਂ 'ਤੇ ਟੈਪ0 ਡਿਵਾਈਸਾਂ ਨੂੰ br-lan ਬ੍ਰਿਜ ਵਿੱਚ ਜੋੜਿਆ ਗਿਆ ਸੀ। ਇਸ ਪੜਾਅ 'ਤੇ, ਸਭ ਕੁਝ ਠੀਕ ਜਾਪਦਾ ਸੀ ਕਿਉਂਕਿ ਸਾਰੇ ਤਿੰਨ ਨੈਟਵਰਕ ਇੱਕ ਦੂਜੇ ਨੂੰ ਦੇਖ ਸਕਦੇ ਸਨ ਅਤੇ ਇੱਕ ਦੇ ਰੂਪ ਵਿੱਚ ਕੰਮ ਕਰ ਸਕਦੇ ਸਨ। ਹਾਲਾਂਕਿ, ਇੱਕ ਬਹੁਤ ਹੀ ਸੁਹਾਵਣਾ ਵੇਰਵਾ ਸਾਹਮਣੇ ਨਹੀਂ ਆਇਆ: ਕਈ ਵਾਰ ਡਿਵਾਈਸਾਂ ਇੱਕ IP ਐਡਰੈੱਸ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੀਆਂ ਹਨ ਨਾ ਕਿ ਉਹਨਾਂ ਦੇ ਰਾਊਟਰ ਤੋਂ, ਆਉਣ ਵਾਲੇ ਸਾਰੇ ਨਤੀਜਿਆਂ ਦੇ ਨਾਲ। ਕਿਸੇ ਕਾਰਨ ਕਰਕੇ, ਕਿਸੇ ਇੱਕ ਅਪਾਰਟਮੈਂਟ ਵਿੱਚ ਰਾਊਟਰ ਕੋਲ ਸਮੇਂ ਵਿੱਚ DHCPDISCOVER ਨੂੰ ਜਵਾਬ ਦੇਣ ਲਈ ਸਮਾਂ ਨਹੀਂ ਸੀ ਅਤੇ ਡਿਵਾਈਸ ਨੂੰ ਇੱਕ ਅਜਿਹਾ ਪਤਾ ਪ੍ਰਾਪਤ ਹੋਇਆ ਜੋ ਇਰਾਦਾ ਨਹੀਂ ਸੀ। ਮੈਨੂੰ ਅਹਿਸਾਸ ਹੋਇਆ ਕਿ ਮੈਨੂੰ ਹਰ ਇੱਕ ਰਾਊਟਰ 'ਤੇ ਟੈਪ0 ਵਿੱਚ ਅਜਿਹੀਆਂ ਬੇਨਤੀਆਂ ਨੂੰ ਫਿਲਟਰ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੈ, ਪਰ ਜਿਵੇਂ ਕਿ ਇਹ ਨਿਕਲਿਆ, iptables ਡਿਵਾਈਸ ਨਾਲ ਕੰਮ ਨਹੀਂ ਕਰ ਸਕਦਾ ਜੇਕਰ ਇਹ ਇੱਕ ਬ੍ਰਿਜ ਦਾ ਹਿੱਸਾ ਹੈ ਅਤੇ ebtables ਮੇਰੀ ਸਹਾਇਤਾ ਲਈ ਆਉਣੇ ਚਾਹੀਦੇ ਹਨ. ਮੇਰੇ ਅਫਸੋਸ ਲਈ, ਇਹ ਮੇਰੇ ਫਰਮਵੇਅਰ ਵਿੱਚ ਨਹੀਂ ਸੀ ਅਤੇ ਮੈਨੂੰ ਹਰੇਕ ਡਿਵਾਈਸ ਲਈ ਚਿੱਤਰਾਂ ਨੂੰ ਦੁਬਾਰਾ ਬਣਾਉਣਾ ਪਿਆ. ਅਜਿਹਾ ਕਰਨ ਨਾਲ ਅਤੇ ਇਹਨਾਂ ਲਾਈਨਾਂ ਨੂੰ ਹਰੇਕ ਰਾਊਟਰ ਦੇ /etc/rc.local ਵਿੱਚ ਜੋੜ ਕੇ, ਸਮੱਸਿਆ ਹੱਲ ਹੋ ਗਈ ਸੀ:

ebtables -A INPUT --in-interface tap0 --protocol ipv4 --ip-protocol udp --ip-destination-port 67:68 -j DROP
ebtables -A INPUT --in-interface tap0 --protocol ipv4 --ip-protocol udp --ip-source-port 67:68 -j DROP
ebtables -A FORWARD --out-interface tap0 --protocol ipv4 --ip-protocol udp --ip-destination-port 67:68 -j DROP
ebtables -A FORWARD --out-interface tap0 --protocol ipv4 --ip-protocol udp --ip-source-port 67:68 -j DROP

ਇਹ ਸੰਰਚਨਾ ਤਿੰਨ ਸਾਲਾਂ ਤੱਕ ਚੱਲੀ।

ਭਾਗ 2: ਵਾਇਰਗਾਰਡ ਨੂੰ ਪੇਸ਼ ਕਰਨਾ

ਹਾਲ ਹੀ ਵਿੱਚ, ਇੰਟਰਨੈਟ ਤੇ ਲੋਕਾਂ ਨੇ ਵਾਇਰਗਾਰਡ ਬਾਰੇ ਗੱਲ ਕਰਨੀ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤੀ ਹੈ, ਇਸਦੀ ਸੰਰਚਨਾ ਦੀ ਸਾਦਗੀ, ਉੱਚ ਪ੍ਰਸਾਰਣ ਗਤੀ, ਤੁਲਨਾਤਮਕ ਸੁਰੱਖਿਆ ਦੇ ਨਾਲ ਘੱਟ ਪਿੰਗ ਦੀ ਪ੍ਰਸ਼ੰਸਾ ਕਰਦੇ ਹੋਏ. ਇਸ ਬਾਰੇ ਹੋਰ ਜਾਣਕਾਰੀ ਲਈ ਖੋਜ ਨੇ ਇਹ ਸਪੱਸ਼ਟ ਕੀਤਾ ਕਿ ਨਾ ਤਾਂ ਬ੍ਰਿਜ ਮੈਂਬਰ ਵਜੋਂ ਕੰਮ ਕਰਨਾ ਅਤੇ ਨਾ ਹੀ ਟੀਸੀਪੀ ਪ੍ਰੋਟੋਕੋਲ ਉੱਤੇ ਕੰਮ ਕਰਨਾ ਇਸ ਦੁਆਰਾ ਸਮਰਥਤ ਹੈ, ਜਿਸ ਨੇ ਮੈਨੂੰ ਇਹ ਸੋਚਣ ਲਈ ਮਜਬੂਰ ਕੀਤਾ ਕਿ ਮੇਰੇ ਲਈ ਓਪਨਵੀਪੀਐਨ ਦੇ ਅਜੇ ਵੀ ਕੋਈ ਵਿਕਲਪ ਨਹੀਂ ਸਨ। ਇਸ ਲਈ ਮੈਂ ਵਾਇਰਗਾਰਡ ਨੂੰ ਜਾਣਨਾ ਟਾਲ ਦਿੱਤਾ।

ਕੁਝ ਦਿਨ ਪਹਿਲਾਂ, ਆਈ.ਟੀ. ਨਾਲ ਸਬੰਧਤ ਕਿਸੇ ਨਾ ਕਿਸੇ ਸਰੋਤਾਂ ਵਿੱਚ ਖਬਰ ਫੈਲ ਗਈ ਸੀ ਕਿ ਵਾਇਰਗਾਰਡ ਨੂੰ ਅੰਤ ਵਿੱਚ ਲੀਨਕਸ ਕਰਨਲ ਵਿੱਚ ਸ਼ਾਮਲ ਕੀਤਾ ਜਾਵੇਗਾ, ਸੰਸਕਰਣ 5.6 ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ। ਖ਼ਬਰਾਂ ਦੇ ਲੇਖ, ਹਮੇਸ਼ਾ ਵਾਂਗ, ਵਾਇਰਗਾਰਡ ਦੀ ਪ੍ਰਸ਼ੰਸਾ ਕਰਦੇ ਹਨ। ਮੈਂ ਦੁਬਾਰਾ ਚੰਗੇ ਪੁਰਾਣੇ ਓਪਨਵੀਪੀਐਨ ਨੂੰ ਬਦਲਣ ਦੇ ਤਰੀਕਿਆਂ ਦੀ ਖੋਜ ਵਿੱਚ ਡੁੱਬ ਗਿਆ। ਇਸ ਵਾਰ ਮੈਂ ਅੰਦਰ ਭੱਜਿਆ ਇਹ ਲੇਖ. ਇਸਨੇ GRE ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ L3 ਉੱਤੇ ਇੱਕ ਈਥਰਨੈੱਟ ਸੁਰੰਗ ਬਣਾਉਣ ਬਾਰੇ ਗੱਲ ਕੀਤੀ। ਇਸ ਲੇਖ ਨੇ ਮੈਨੂੰ ਉਮੀਦ ਦਿੱਤੀ. ਇਹ ਅਸਪਸ਼ਟ ਰਿਹਾ ਕਿ UDP ਪ੍ਰੋਟੋਕੋਲ ਨਾਲ ਕੀ ਕਰਨਾ ਹੈ। ਖੋਜ ਨੇ ਮੈਨੂੰ ਇੱਕ UDP ਪੋਰਟ ਨੂੰ ਅੱਗੇ ਵਧਾਉਣ ਲਈ ਇੱਕ SSH ਸੁਰੰਗ ਦੇ ਨਾਲ ਜੋੜ ਕੇ socat ਦੀ ਵਰਤੋਂ ਕਰਨ ਬਾਰੇ ਲੇਖਾਂ ਵੱਲ ਅਗਵਾਈ ਕੀਤੀ, ਹਾਲਾਂਕਿ, ਉਹਨਾਂ ਨੇ ਨੋਟ ਕੀਤਾ ਕਿ ਇਹ ਪਹੁੰਚ ਸਿਰਫ ਸਿੰਗਲ ਕੁਨੈਕਸ਼ਨ ਮੋਡ ਵਿੱਚ ਕੰਮ ਕਰਦੀ ਹੈ, ਯਾਨੀ ਕਈ VPN ਕਲਾਇੰਟਸ ਦਾ ਕੰਮ ਅਸੰਭਵ ਹੋਵੇਗਾ. ਮੈਂ ਇੱਕ VPS 'ਤੇ ਇੱਕ VPN ਸਰਵਰ ਸਥਾਪਤ ਕਰਨ ਅਤੇ ਗਾਹਕਾਂ ਲਈ GRE ਸਥਾਪਤ ਕਰਨ ਦੇ ਵਿਚਾਰ ਨਾਲ ਆਇਆ ਸੀ, ਪਰ ਜਿਵੇਂ ਕਿ ਇਹ ਨਿਕਲਿਆ, GRE ਏਨਕ੍ਰਿਪਸ਼ਨ ਦਾ ਸਮਰਥਨ ਨਹੀਂ ਕਰਦਾ, ਜੋ ਇਸ ਤੱਥ ਵੱਲ ਲੈ ਜਾਵੇਗਾ ਕਿ ਜੇਕਰ ਤੀਜੀ ਧਿਰ ਸਰਵਰ ਤੱਕ ਪਹੁੰਚ ਪ੍ਰਾਪਤ ਕਰਦੀ ਹੈ. , ਮੇਰੇ ਨੈਟਵਰਕਾਂ ਵਿਚਕਾਰ ਸਾਰਾ ਟ੍ਰੈਫਿਕ ਉਹਨਾਂ ਦੇ ਹੱਥਾਂ ਵਿੱਚ ਹੋਵੇਗਾ, ਜੋ ਮੇਰੇ ਲਈ ਬਿਲਕੁਲ ਵੀ ਅਨੁਕੂਲ ਨਹੀਂ ਸੀ।

ਇੱਕ ਵਾਰ ਫਿਰ, ਹੇਠ ਦਿੱਤੀ ਸਕੀਮ ਦੀ ਵਰਤੋਂ ਕਰਕੇ VPN ਉੱਤੇ VPN ਦੀ ਵਰਤੋਂ ਕਰਕੇ, ਫਾਲਤੂ ਐਨਕ੍ਰਿਪਸ਼ਨ ਦੇ ਹੱਕ ਵਿੱਚ ਫੈਸਲਾ ਲਿਆ ਗਿਆ ਸੀ:

ਪੱਧਰ XNUMX VPN:
VPS ਇਹ ਇਸ ਲਈ ਹੈ ਸਰਵਰ ਅੰਦਰੂਨੀ ਪਤੇ ਦੇ ਨਾਲ 192.168.30.1
ਐਮ ਐਸ ਇਹ ਇਸ ਲਈ ਹੈ ਗਾਹਕ ਅੰਦਰੂਨੀ ਪਤੇ ਦੇ ਨਾਲ VPS 192.168.30.2
ਐਮਕੇ 2 ਇਹ ਇਸ ਲਈ ਹੈ ਗਾਹਕ ਅੰਦਰੂਨੀ ਪਤੇ ਦੇ ਨਾਲ VPS 192.168.30.3
ਐਮਕੇ 3 ਇਹ ਇਸ ਲਈ ਹੈ ਗਾਹਕ ਅੰਦਰੂਨੀ ਪਤੇ ਦੇ ਨਾਲ VPS 192.168.30.4

ਦੂਜਾ ਪੱਧਰ VPN:
ਐਮ ਐਸ ਇਹ ਇਸ ਲਈ ਹੈ ਸਰਵਰ ਬਾਹਰੀ ਪਤੇ 192.168.30.2 ਅਤੇ ਅੰਦਰੂਨੀ 192.168.31.1 ਦੇ ਨਾਲ
ਐਮਕੇ 2 ਇਹ ਇਸ ਲਈ ਹੈ ਗਾਹਕ ਐਮ ਐਸ ਪਤੇ 192.168.30.2 ਦੇ ਨਾਲ ਅਤੇ ਇੱਕ ਅੰਦਰੂਨੀ IP 192.168.31.2 ਹੈ
ਐਮਕੇ 3 ਇਹ ਇਸ ਲਈ ਹੈ ਗਾਹਕ ਐਮ ਐਸ ਪਤੇ 192.168.30.2 ਦੇ ਨਾਲ ਅਤੇ ਇੱਕ ਅੰਦਰੂਨੀ IP 192.168.31.3 ਹੈ

* ਐਮ ਐਸ - ਅਪਾਰਟਮੈਂਟ 1 ਵਿੱਚ ਰਾਊਟਰ-ਸਰਵਰ, ਐਮਕੇ 2 - ਅਪਾਰਟਮੈਂਟ 2 ਵਿੱਚ ਰਾਊਟਰ, ਐਮਕੇ 3 - ਅਪਾਰਟਮੈਂਟ 3 ਵਿੱਚ ਰਾਊਟਰ
* ਡਿਵਾਈਸ ਕੌਂਫਿਗਰੇਸ਼ਨ ਲੇਖ ਦੇ ਅੰਤ ਵਿੱਚ ਸਪੌਇਲਰ ਵਿੱਚ ਪ੍ਰਕਾਸ਼ਿਤ ਕੀਤੀ ਗਈ ਹੈ।

ਅਤੇ ਇਸ ਤਰ੍ਹਾਂ, ਨੈਟਵਰਕ ਨੋਡਸ 192.168.31.0/24 ਦੇ ਵਿਚਕਾਰ ਪਿੰਗ ਚੱਲ ਰਹੇ ਹਨ, ਇਹ ਇੱਕ GRE ਸੁਰੰਗ ਸਥਾਪਤ ਕਰਨ ਲਈ ਅੱਗੇ ਵਧਣ ਦਾ ਸਮਾਂ ਹੈ। ਇਸ ਤੋਂ ਪਹਿਲਾਂ, ਰਾਊਟਰਾਂ ਤੱਕ ਪਹੁੰਚ ਨਾ ਗੁਆਉਣ ਲਈ, ਪੋਰਟ 22 ਨੂੰ VPS ਨੂੰ ਅੱਗੇ ਭੇਜਣ ਲਈ SSH ਟਨਲ ਸਥਾਪਤ ਕਰਨ ਦੇ ਯੋਗ ਹੈ, ਤਾਂ ਜੋ, ਉਦਾਹਰਨ ਲਈ, ਅਪਾਰਟਮੈਂਟ 10022 ਤੋਂ ਰਾਊਟਰ VPS ਦੇ ਪੋਰਟ 2 'ਤੇ ਪਹੁੰਚਯੋਗ ਹੋਵੇਗਾ, ਅਤੇ ਅਪਾਰਟਮੈਂਟ 11122 ਤੋਂ ਰਾਊਟਰ ਅਪਾਰਟਮੈਂਟ 3 ਤੋਂ ਪੋਰਟ XNUMX ਰਾਊਟਰ 'ਤੇ ਪਹੁੰਚਯੋਗ ਹੋਵੇਗਾ। ਉਸੇ sshtunnel ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਫਾਰਵਰਡਿੰਗ ਨੂੰ ਕੌਂਫਿਗਰ ਕਰਨਾ ਸਭ ਤੋਂ ਵਧੀਆ ਹੈ, ਕਿਉਂਕਿ ਇਹ ਫੇਲ ਹੋਣ 'ਤੇ ਸੁਰੰਗ ਨੂੰ ਬਹਾਲ ਕਰੇਗਾ।

ਸੁਰੰਗ ਕੌਂਫਿਗਰ ਕੀਤੀ ਗਈ ਹੈ, ਤੁਸੀਂ ਫਾਰਵਰਡ ਪੋਰਟ ਰਾਹੀਂ SSH ਨਾਲ ਜੁੜ ਸਕਦੇ ਹੋ:

ssh root@МОЙ_VPS -p 10022

ਅੱਗੇ ਤੁਹਾਨੂੰ OpenVPN ਨੂੰ ਅਯੋਗ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ:

/etc/init.d/openvpn stop

ਹੁਣ ਅਪਾਰਟਮੈਂਟ 2 ਤੋਂ ਰਾਊਟਰ 'ਤੇ ਇੱਕ GRE ਸੁਰੰਗ ਸੈਟ ਅਪ ਕਰੀਏ:

ip link add grelan0 type gretap remote 192.168.31.1 local 192.168.31.2
ip link set grelan0 up

ਅਤੇ ਬਣਾਏ ਗਏ ਇੰਟਰਫੇਸ ਨੂੰ ਬ੍ਰਿਜ ਵਿੱਚ ਸ਼ਾਮਲ ਕਰੋ:

brctl addif br-lan grelan0

ਆਓ ਸਰਵਰ ਰਾਊਟਰ 'ਤੇ ਇੱਕ ਸਮਾਨ ਪ੍ਰਕਿਰਿਆ ਕਰੀਏ:

ip link add grelan0 type gretap remote 192.168.31.2 local 192.168.31.1
ip link set grelan0 up

ਅਤੇ ਬ੍ਰਿਜ ਵਿੱਚ ਬਣਾਇਆ ਇੰਟਰਫੇਸ ਵੀ ਸ਼ਾਮਲ ਕਰੋ:

brctl addif br-lan grelan0

ਇਸ ਪਲ ਤੋਂ ਸ਼ੁਰੂ ਕਰਦੇ ਹੋਏ, ਪਿੰਗਜ਼ ਸਫਲਤਾਪੂਰਵਕ ਨਵੇਂ ਨੈਟਵਰਕ ਤੇ ਜਾਣਾ ਸ਼ੁਰੂ ਕਰ ਦਿੰਦੇ ਹਨ ਅਤੇ ਮੈਂ ਸੰਤੁਸ਼ਟੀ ਨਾਲ, ਕੌਫੀ ਪੀਣ ਲਈ ਜਾਂਦਾ ਹਾਂ. ਫਿਰ, ਇਹ ਮੁਲਾਂਕਣ ਕਰਨ ਲਈ ਕਿ ਲਾਈਨ ਦੇ ਦੂਜੇ ਸਿਰੇ 'ਤੇ ਨੈੱਟਵਰਕ ਕਿਵੇਂ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ, ਮੈਂ ਅਪਾਰਟਮੈਂਟ 2 ਦੇ ਕੰਪਿਊਟਰਾਂ ਵਿੱਚੋਂ ਇੱਕ ਵਿੱਚ SSH ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹਾਂ, ਪਰ ssh ਕਲਾਇੰਟ ਪਾਸਵਰਡ ਲਈ ਪੁੱਛੇ ਬਿਨਾਂ ਰੁਕ ਜਾਂਦਾ ਹੈ। ਮੈਂ ਪੋਰਟ 22 'ਤੇ ਟੈਲਨੈੱਟ ਰਾਹੀਂ ਇਸ ਕੰਪਿਊਟਰ ਨਾਲ ਜੁੜਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਿਹਾ/ਰਹੀ ਹਾਂ ਅਤੇ ਮੈਨੂੰ ਇੱਕ ਲਾਈਨ ਦਿਖਾਈ ਦੇ ਰਹੀ ਹੈ ਜਿਸ ਤੋਂ ਮੈਂ ਸਮਝ ਸਕਦਾ ਹਾਂ ਕਿ ਕਨੈਕਸ਼ਨ ਸਥਾਪਤ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੈ, SSH ਸਰਵਰ ਜਵਾਬ ਦੇ ਰਿਹਾ ਹੈ, ਪਰ ਕਿਸੇ ਕਾਰਨ ਕਰਕੇ ਇਹ ਮੈਨੂੰ ਲੌਗ ਕਰਨ ਲਈ ਨਹੀਂ ਕਹਿੰਦਾ। ਵਿੱਚ

$ telnet 192.168.10.110 22
SSH-2.0-OpenSSH_8.1

ਮੈਂ VNC ਰਾਹੀਂ ਇਸ ਨਾਲ ਜੁੜਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਿਹਾ/ਰਹੀ ਹਾਂ ਅਤੇ ਇੱਕ ਕਾਲੀ ਸਕਰੀਨ ਵੇਖ ਰਿਹਾ/ਰਹੀ ਹਾਂ। ਮੈਂ ਆਪਣੇ ਆਪ ਨੂੰ ਯਕੀਨ ਦਿਵਾਉਂਦਾ ਹਾਂ ਕਿ ਸਮੱਸਿਆ ਰਿਮੋਟ ਕੰਪਿਊਟਰ ਨਾਲ ਹੈ, ਕਿਉਂਕਿ ਮੈਂ ਅੰਦਰੂਨੀ ਪਤੇ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਇਸ ਅਪਾਰਟਮੈਂਟ ਤੋਂ ਰਾਊਟਰ ਨਾਲ ਆਸਾਨੀ ਨਾਲ ਜੁੜ ਸਕਦਾ ਹਾਂ. ਹਾਲਾਂਕਿ, ਮੈਂ ਰਾਊਟਰ ਰਾਹੀਂ ਇਸ ਕੰਪਿਊਟਰ ਦੇ SSH ਨਾਲ ਜੁੜਨ ਦਾ ਫੈਸਲਾ ਕਰਦਾ ਹਾਂ ਅਤੇ ਇਹ ਜਾਣ ਕੇ ਹੈਰਾਨ ਹਾਂ ਕਿ ਕੁਨੈਕਸ਼ਨ ਸਫਲ ਹੈ, ਅਤੇ ਰਿਮੋਟ ਕੰਪਿਊਟਰ ਆਮ ਤੌਰ 'ਤੇ ਕੰਮ ਕਰਦਾ ਹੈ, ਪਰ ਇਹ ਮੇਰੇ ਕੰਪਿਊਟਰ ਨਾਲ ਵੀ ਕਨੈਕਟ ਨਹੀਂ ਹੋ ਸਕਦਾ ਹੈ।

ਮੈਂ ਬ੍ਰਿਜ ਤੋਂ grelan0 ਡਿਵਾਈਸ ਨੂੰ ਹਟਾ ਦਿੰਦਾ ਹਾਂ ਅਤੇ ਅਪਾਰਟਮੈਂਟ 2 ਵਿੱਚ ਰਾਊਟਰ 'ਤੇ OpenVPN ਚਲਾਉਂਦਾ ਹਾਂ ਅਤੇ ਇਹ ਯਕੀਨੀ ਬਣਾਉਂਦਾ ਹਾਂ ਕਿ ਨੈੱਟਵਰਕ ਦੁਬਾਰਾ ਉਮੀਦ ਅਨੁਸਾਰ ਕੰਮ ਕਰਦਾ ਹੈ ਅਤੇ ਕਨੈਕਸ਼ਨਾਂ ਨੂੰ ਛੱਡਿਆ ਨਹੀਂ ਜਾਂਦਾ ਹੈ। ਖੋਜ ਕਰਕੇ ਮੈਂ ਉਹਨਾਂ ਫੋਰਮਾਂ ਵਿੱਚ ਆਉਂਦਾ ਹਾਂ ਜਿੱਥੇ ਲੋਕ ਇੱਕੋ ਜਿਹੀਆਂ ਸਮੱਸਿਆਵਾਂ ਬਾਰੇ ਸ਼ਿਕਾਇਤ ਕਰਦੇ ਹਨ, ਜਿੱਥੇ ਉਹਨਾਂ ਨੂੰ MTU ਨੂੰ ਵਧਾਉਣ ਦੀ ਸਲਾਹ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ. ਤੁਰੰਤ ਕਰਨਾ. ਹਾਲਾਂਕਿ, ਜਦੋਂ ਤੱਕ MTU ਕਾਫ਼ੀ ਉੱਚਾ ਸੈੱਟ ਨਹੀਂ ਕੀਤਾ ਗਿਆ - gretap ਡਿਵਾਈਸਾਂ ਲਈ 7000, ਜਾਂ ਤਾਂ TCP ਕੁਨੈਕਸ਼ਨ ਘਟੇ ਜਾਂ ਘੱਟ ਟ੍ਰਾਂਸਫਰ ਦਰਾਂ ਵੇਖੀਆਂ ਗਈਆਂ। ਗ੍ਰੇਟੈਪ ਲਈ ਉੱਚ MTU ਦੇ ਕਾਰਨ, ਲੇਅਰ 8000 ਅਤੇ ਲੇਅਰ 7500 ਵਾਇਰਗਾਰਡ ਕਨੈਕਸ਼ਨਾਂ ਲਈ MTU ਕ੍ਰਮਵਾਰ XNUMX ਅਤੇ XNUMX 'ਤੇ ਸੈੱਟ ਕੀਤੇ ਗਏ ਸਨ।

ਮੈਂ ਅਪਾਰਟਮੈਂਟ 3 ਤੋਂ ਰਾਊਟਰ 'ਤੇ ਇੱਕ ਸਮਾਨ ਸੈਟਅਪ ਕੀਤਾ, ਸਿਰਫ ਫਰਕ ਇਹ ਹੈ ਕਿ ਸਰਵਰ ਰਾਊਟਰ ਵਿੱਚ grelan1 ਨਾਮ ਦਾ ਇੱਕ ਦੂਜਾ ਗ੍ਰੇਟੈਪ ਇੰਟਰਫੇਸ ਜੋੜਿਆ ਗਿਆ ਸੀ, ਜੋ ਕਿ br-lan ਬ੍ਰਿਜ ਵਿੱਚ ਵੀ ਜੋੜਿਆ ਗਿਆ ਸੀ।

ਸਭ ਕੁਝ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ। ਹੁਣ ਤੁਸੀਂ ਗ੍ਰੇਟੈਪ ਅਸੈਂਬਲੀ ਨੂੰ ਸਟਾਰਟਅੱਪ ਵਿੱਚ ਪਾ ਸਕਦੇ ਹੋ। ਇਸ ਲਈ:

ਮੈਂ ਇਹ ਲਾਈਨਾਂ ਅਪਾਰਟਮੈਂਟ 2 ਵਿੱਚ ਰਾਊਟਰ 'ਤੇ /etc/rc.local ਵਿੱਚ ਰੱਖੀਆਂ:

ip link add grelan0 type gretap remote 192.168.31.1 local 192.168.31.2
ip link set dev grelan0 mtu 7000
ip link set grelan0 up
brctl addif br-lan grelan0

ਇਸਨੂੰ ਅਪਾਰਟਮੈਂਟ 3 ਵਿੱਚ ਰਾਊਟਰ ਉੱਤੇ /etc/rc.local ਵਿੱਚ ਜੋੜਿਆ ਗਿਆ ਹੈ:

ip link add grelan0 type gretap remote 192.168.31.1 local 192.168.31.3
ip link set dev grelan0 mtu 7000
ip link set grelan0 up
brctl addif br-lan grelan0

ਅਤੇ ਸਰਵਰ ਰਾਊਟਰ 'ਤੇ:

ip link add grelan0 type gretap remote 192.168.31.2 local 192.168.31.1
ip link set dev grelan0 mtu 7000
ip link set grelan0 up
brctl addif br-lan grelan0

ip link add grelan1 type gretap remote 192.168.31.3 local 192.168.31.1
ip link set dev grelan1 mtu 7000
ip link set grelan1 up
brctl addif br-lan grelan1

ਕਲਾਇੰਟ ਰਾਊਟਰਾਂ ਨੂੰ ਰੀਬੂਟ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਮੈਨੂੰ ਪਤਾ ਲੱਗਾ ਕਿ ਕਿਸੇ ਕਾਰਨ ਕਰਕੇ ਉਹ ਸਰਵਰ ਨਾਲ ਕਨੈਕਟ ਨਹੀਂ ਕਰ ਰਹੇ ਸਨ। ਉਹਨਾਂ ਦੇ SSH ਨਾਲ ਕਨੈਕਟ ਹੋਣ ਤੋਂ ਬਾਅਦ (ਖੁਦਕਿਸਮਤੀ ਨਾਲ, ਮੈਂ ਪਹਿਲਾਂ ਇਸ ਲਈ sshtunnel ਨੂੰ ਕੌਂਫਿਗਰ ਕੀਤਾ ਸੀ), ਇਹ ਪਤਾ ਲੱਗਾ ਕਿ ਵਾਇਰਗਾਰਡ ਕਿਸੇ ਕਾਰਨ ਕਰਕੇ ਅੰਤਮ ਬਿੰਦੂ ਲਈ ਇੱਕ ਰੂਟ ਬਣਾ ਰਿਹਾ ਸੀ, ਪਰ ਇਹ ਗਲਤ ਸੀ. ਇਸ ਲਈ, 192.168.30.2 ਲਈ, ਰੂਟ ਟੇਬਲ ਨੇ pppoe-wan ਇੰਟਰਫੇਸ ਦੁਆਰਾ ਇੱਕ ਰੂਟ ਦਾ ਸੰਕੇਤ ਦਿੱਤਾ ਹੈ, ਯਾਨੀ ਕਿ, ਇੰਟਰਨੈਟ ਦੁਆਰਾ, ਹਾਲਾਂਕਿ ਇਸਦੇ ਲਈ ਰੂਟ ਨੂੰ wg0 ਇੰਟਰਫੇਸ ਦੁਆਰਾ ਰੂਟ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਸੀ। ਇਸ ਰੂਟ ਨੂੰ ਮਿਟਾਉਣ ਤੋਂ ਬਾਅਦ, ਕੁਨੈਕਸ਼ਨ ਬਹਾਲ ਕੀਤਾ ਗਿਆ ਸੀ। ਮੈਂ ਵਾਇਰਗਾਰਡ ਨੂੰ ਇਹਨਾਂ ਰੂਟਾਂ ਨੂੰ ਨਾ ਬਣਾਉਣ ਲਈ ਮਜ਼ਬੂਰ ਕਰਨ ਬਾਰੇ ਕਿਤੇ ਵੀ ਨਿਰਦੇਸ਼ ਨਹੀਂ ਲੱਭ ਸਕਿਆ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਮੈਂ ਇਹ ਵੀ ਨਹੀਂ ਸਮਝਿਆ ਕਿ ਇਹ ਓਪਨਡਬਲਯੂਆਰਟੀ ਜਾਂ ਵਾਇਰਗਾਰਡ ਦੀ ਵਿਸ਼ੇਸ਼ਤਾ ਸੀ. ਲੰਬੇ ਸਮੇਂ ਲਈ ਇਸ ਸਮੱਸਿਆ ਨਾਲ ਨਜਿੱਠਣ ਤੋਂ ਬਿਨਾਂ, ਮੈਂ ਇੱਕ ਸਮਾਂਬੱਧ ਸਕ੍ਰਿਪਟ ਵਿੱਚ ਦੋਵਾਂ ਰਾਊਟਰਾਂ ਲਈ ਇੱਕ ਲਾਈਨ ਜੋੜ ਦਿੱਤੀ ਹੈ ਜਿਸ ਨੇ ਇਸ ਰੂਟ ਨੂੰ ਮਿਟਾ ਦਿੱਤਾ ਹੈ:

route del 192.168.30.2

ਸੰਖੇਪ

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

ਓਪਨਵੀਪੀਐਨ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਸਮੇਂ:

[r0ck3r@desktop ~]$ ping -c 20 192.168.10.110
PING 192.168.10.110 (192.168.10.110) 56(84) bytes of data.
64 bytes from 192.168.10.110: icmp_seq=1 ttl=64 time=133 ms
...
64 bytes from 192.168.10.110: icmp_seq=20 ttl=64 time=125 ms

--- 192.168.10.110 ping statistics ---
20 packets transmitted, 20 received, 0% packet loss, time 19006ms
rtt min/avg/max/mdev = 124.722/126.152/136.907/3.065 ms

ਵਾਇਰਗਾਰਡ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਸਮੇਂ:

[r0ck3r@desktop ~]$ ping -c 20 192.168.10.110
PING 192.168.10.110 (192.168.10.110) 56(84) bytes of data.
64 bytes from 192.168.10.110: icmp_seq=1 ttl=64 time=124 ms
...
64 bytes from 192.168.10.110: icmp_seq=20 ttl=64 time=124 ms
--- 192.168.10.110 ping statistics ---
20 packets transmitted, 20 received, 0% packet loss, time 19003ms
rtt min/avg/max/mdev = 123.954/124.423/126.708/0.675 ms

ਇਹ VPS ਨੂੰ ਉੱਚ ਪਿੰਗ ਦੁਆਰਾ ਵਧੇਰੇ ਪ੍ਰਭਾਵਿਤ ਹੁੰਦਾ ਹੈ, ਜੋ ਕਿ ਲਗਭਗ 61.5 ਐਮ.ਐਸ.

ਹਾਲਾਂਕਿ, ਗਤੀ ਵਿੱਚ ਕਾਫ਼ੀ ਵਾਧਾ ਹੋਇਆ ਹੈ. ਇਸ ਲਈ, ਸਰਵਰ ਰਾਊਟਰ ਵਾਲੇ ਇੱਕ ਅਪਾਰਟਮੈਂਟ ਵਿੱਚ ਮੇਰੇ ਕੋਲ 30 Mbit/sec ਦੀ ਇੰਟਰਨੈਟ ਕਨੈਕਸ਼ਨ ਸਪੀਡ ਹੈ, ਅਤੇ ਦੂਜੇ ਅਪਾਰਟਮੈਂਟਾਂ ਵਿੱਚ ਇਹ 5 Mbit/sec ਹੈ। ਉਸੇ ਸਮੇਂ, ਓਪਨਵੀਪੀਐਨ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਸਮੇਂ, ਮੈਂ iperf ਰੀਡਿੰਗਾਂ ਦੇ ਅਨੁਸਾਰ 3,8 Mbit/sec ਤੋਂ ਵੱਧ ਦੇ ਨੈੱਟਵਰਕਾਂ ਵਿਚਕਾਰ ਡਾਟਾ ਟ੍ਰਾਂਸਫਰ ਸਪੀਡ ਪ੍ਰਾਪਤ ਕਰਨ ਦੇ ਯੋਗ ਨਹੀਂ ਸੀ, ਜਦੋਂ ਕਿ WireGuard ਨੇ ਇਸਨੂੰ ਉਸੇ 5 Mbit/sec ਤੱਕ "ਬੂਸਟ" ਕੀਤਾ।

VPS 'ਤੇ ਵਾਇਰਗਾਰਡ ਕੌਂਫਿਗਰੇਸ਼ਨ[Interface] Address = 192.168.30.1/24
ListenPort = 51820
PrivateKey = <ЗАКРЫТЫЙ_КЛЮЧ_ДЛЯ_VPS>

[Peer] PublicKey = <ОТКРЫТЫЙ_КЛЮЧ_VPN_1_МС>
AllowedIPs = 192.168.30.2/32

[Peer] PublicKey = <ОТКРЫТЫЙ_КЛЮЧ_VPN_2_МК2>
AllowedIPs = 192.168.30.3/32

[Peer] PublicKey = <ОТКРЫТЫЙ_КЛЮЧ_VPN_2_МК3>
AllowedIPs = 192.168.30.4/32

MS ਉੱਤੇ ਵਾਇਰਗਾਰਡ ਕੌਂਫਿਗਰੇਸ਼ਨ (/etc/config/network ਵਿੱਚ ਜੋੜਿਆ ਗਿਆ)

#VPN первого уровня - клиент
config interface 'wg0'
        option proto 'wireguard'
        list addresses '192.168.30.2/24'
        option private_key 'ЗАКРЫТЫЙ_КЛЮЧ_VPN_1_МС'
        option auto '1'
        option mtu '8000'

config wireguard_wg0
        option public_key 'ОТКРЫТЫЙ_КЛЮЧ_VPN_1_VPS'
        option endpoint_port '51820'
        option route_allowed_ips '1'
        option persistent_keepalive '25'
        list allowed_ips '192.168.30.0/24'
        option endpoint_host 'IP_АДРЕС_VPS'

#VPN второго уровня - сервер
config interface 'wg1'
        option proto 'wireguard'
        option private_key 'ЗАКРЫТЫЙ_КЛЮЧ_VPN_2_МС'
        option listen_port '51821'
        list addresses '192.168.31.1/24'
        option auto '1'
        option mtu '7500'

config wireguard_wg1
        option public_key 'ОТКРЫТЫЙ_КЛЮЧ_VPN_2_МК2'
        list allowed_ips '192.168.31.2'

config wireguard_wg1ip link add grelan0 type gretap remote 192.168.31.1 local 192.168.31.3

        option public_key 'ОТКРЫТЫЙ_КЛЮЧ_VPN_2_МК3'
        list allowed_ips '192.168.31.3'

MK2 'ਤੇ ਵਾਇਰਗਾਰਡ ਕੌਂਫਿਗਰੇਸ਼ਨ (/etc/config/network ਵਿੱਚ ਜੋੜਿਆ ਗਿਆ)

#VPN первого уровня - клиент
config interface 'wg0'
        option proto 'wireguard'
        list addresses '192.168.30.3/24'
        option private_key 'ЗАКРЫТЫЙ_КЛЮЧ_VPN_1_МК2'
        option auto '1'
        option mtu '8000'

config wireguard_wg0
        option public_key 'ОТКРЫТЫЙ_КЛЮЧ_VPN_1_VPS'
        option endpoint_port '51820'
        option persistent_keepalive '25'
        list allowed_ips '192.168.30.0/24'
        option endpoint_host 'IP_АДРЕС_VPS'

#VPN второго уровня - клиент
config interface 'wg1'
        option proto 'wireguard'
        option private_key 'ЗАКРЫТЫЙ_КЛЮЧ_VPN_2_МК2'
        list addresses '192.168.31.2/24'
        option auto '1'
        option listen_port '51821'
        option mtu '7500'

config wireguard_wg1
        option public_key 'ОТКРЫТЫЙ_КЛЮЧ_VPN_2_МС'
        option endpoint_host '192.168.30.2'
        option endpoint_port '51821'
        option persistent_keepalive '25'
        list allowed_ips '192.168.31.0/24'

MK3 'ਤੇ ਵਾਇਰਗਾਰਡ ਕੌਂਫਿਗਰੇਸ਼ਨ (/etc/config/network ਵਿੱਚ ਜੋੜਿਆ ਗਿਆ)

#VPN первого уровня - клиент
config interface 'wg0'
        option proto 'wireguard'
        list addresses '192.168.30.4/24'
        option private_key 'ЗАКРЫТЫЙ_КЛЮЧ_VPN_1_МК3'
        option auto '1'
        option mtu '8000'

config wireguard_wg0
        option public_key 'ОТКРЫТЫЙ_КЛЮЧ_VPN_1_VPS'
        option endpoint_port '51820'
        option persistent_keepalive '25'
        list allowed_ips '192.168.30.0/24'
        option endpoint_host 'IP_АДРЕС_VPS'

#VPN второго уровня - клиент
config interface 'wg1'
        option proto 'wireguard'
        option private_key 'ЗАКРЫТЫЙ_КЛЮЧ_VPN_2_МК3'
        list addresses '192.168.31.3/24'
        option auto '1'
        option listen_port '51821'
        option mtu '7500'

config wireguard_wg1
        option public_key 'ОТКРЫТЫЙ_КЛЮЧ_VPN_2_МС'
        option endpoint_host '192.168.30.2'
        option endpoint_port '51821'
        option persistent_keepalive '25'
        list allowed_ips '192.168.31.0/24'

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

ਮੈਨੂੰ ਉਮੀਦ ਹੈ ਕਿ ਲੇਖ ਕਿਸੇ ਲਈ ਲਾਭਦਾਇਕ ਹੋਵੇਗਾ.

PS ਨਾਲ ਹੀ, ਮੈਂ ਆਪਣੀ ਸਕ੍ਰਿਪਟ ਨੂੰ ਸਾਂਝਾ ਕਰਨਾ ਚਾਹੁੰਦਾ ਹਾਂ ਜੋ ਮੈਨੂੰ ਵਾਇਰਪੁਸ਼ਰ ਐਪਲੀਕੇਸ਼ਨ ਵਿੱਚ ਮੇਰੇ ਫ਼ੋਨ 'ਤੇ ਇੱਕ ਪੁਸ਼ ਸੂਚਨਾ ਭੇਜਦੀ ਹੈ ਜਦੋਂ ਮੇਰੇ ਨੈੱਟਵਰਕ 'ਤੇ ਕੋਈ ਨਵੀਂ ਡਿਵਾਈਸ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ। ਇੱਥੇ ਸਕ੍ਰਿਪਟ ਦਾ ਲਿੰਕ ਹੈ: github.com/r0ck3r/device_discover.

ਅੱਪਡੇਟ: ਓਪਨਵੀਪੀਐਨ ਸਰਵਰ ਅਤੇ ਕਲਾਇੰਟਸ ਦੀ ਸੰਰਚਨਾ

OpenVPN ਸਰਵਰ

client-to-client

ca /etc/openvpn/server/ca.crt
cert /etc/openvpn/server/vpn-server.crt
dh /etc/openvpn/server/dh.pem
key /etc/openvpn/server/vpn-server.key

dev tap
ifconfig-pool-persist /etc/openvpn/ipp.txt 0
keepalive 10 60
proto tcp4
server-bridge 192.168.10.1 255.255.255.0 192.168.10.80 192.168.10.254
status /var/log/openvpn-status.log
verb 3
comp-lzo

OpenVPN ਕਲਾਇੰਟ

client
tls-client
dev tap
proto tcp
remote VPS_IP 1194 # Change to your router's External IP
resolv-retry infinite
nobind

ca client/ca.crt
cert client/client.crt
key client/client.key
dh client/dh.pem

comp-lzo
persist-tun
persist-key
verb 3

ਮੈਂ ਸਰਟੀਫਿਕੇਟ ਬਣਾਉਣ ਲਈ ਆਸਾਨ-rsa ਦੀ ਵਰਤੋਂ ਕੀਤੀ

ਸਰੋਤ: www.habr.com