StrongSwan ਉਹ DNS ਪਤਾ ਭੇਜਦਾ ਹੈ ਜਿੱਥੇ Mac ਨਹੀਂ ਪਹੁੰਚ ਸਕਦਾ

ਸਭ ਕੁਝ ਕੰਮ ਕਰਦਾ ਹੈ ਜਦ ਤੱਕ ਕੋਈ MacBook ਨਹੀਂ ਖੋਲ੍ਹਦਾ। ਟਨਲ ਬਣ ਜਾਂਦਾ ਹੈ, ਅੰਦਰੂਨੀ ਹੋਸਟ ਪਤੇ ਨਾਲ ਜਵਾਬ ਦਿੰਦੇ ਹਨ, ਅਤੇ ਨਾਮ ਰਿਜ਼ੋਲਿਊਸ਼ਨ ਮਰ ਜਾਂਦਾ ਹੈ। iPhone 'ਤੇ ਉਹੀ ਪ੍ਰੋਫਾਈਲ ਉਸੇ ਤਰ੍ਹਾਂ ਵਿਵਹਾਰ ਕਰਦੀ ਹੈ, ਜਦਕਿ Windows ਅਤੇ Linux ਕਲਾਇੰਟ ਠੀਕ ਹਨ। ਆਮ ਤੌਰ 'ਤੇ ਭੇਜਿਆ DNS ਗੁਣ ਹੀ ਦੋਸ਼ੀ ਹੁੰਦਾ ਹੈ: ਸਰਵਰ ਆਪਣਾ ਜਨਤਕ ਇੰਟਰਫੇਸ ਪਤਾ ਵੰਡਦਾ ਹੈ, ਅਤੇ Apple ਦਾ IKEv2 ਕਲਾਇੰਟ ਟਨਲ ਰਾਹੀਂ ਉੱਥੇ ਕਿਊਰੀ ਨਹੀਂ ਭੇਜਦਾ। ਰਿਜ਼ੌਲਵਰ ਨੂੰ ਪੂਲ ਦੇ ਅੰਦਰ ਲੈ ਜਾਓ ਅਤੇ ਕਲਾਇੰਟ ਨੂੰ ਛੂਹੇ ਬਿਨਾਂ ਲੱਛਣ ਗਾਇਬ ਹੋ ਜਾਂਦਾ ਹੈ।

ਲੱਛਣ ਭੇਜੇ ਪਤੇ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ

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

ਜਨਤਕ ਪਤਾ ਆਮ ਚੋਣ ਹੈ ਕਿਉਂਕਿ ਇਹੀ ਇੱਕੋ ਪਤਾ ਹੈ ਜੋ ਪ੍ਰਸ਼ਾਸਕ ਪਹਿਲਾਂ ਹੀ ਜਾਣਦਾ ਹੈ। ਇਹ ਇੱਕੋ ਪਤਾ ਵੀ ਹੈ ਜੋ ਟਨਲ ਦੇ ਆਪਣੇ ਪ੍ਰੀਫਿਕਸ ਤੋਂ ਬਾਹਰ ਹੋਣ ਦੀ ਗਾਰੰਟੀ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਇਹੀ ਗੁਣ Apple ਦੇ ਕਲਾਇੰਟ ਤੋੜਦਾ ਹੈ।

ਕੁਝ ਵੀ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਮੁੱਲ ਵੇਖੋ। ਜੇ ਭੇਜਿਆ ਰਿਜ਼ੌਲਵਰ ਸਰਵਰ ਦਾ WAN ਪਤਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਸਮੱਸਿਆ ਦਾ ਰੂਪ ਲੱਭ ਲਿਆ ਹੈ ਅਤੇ ਬਾਕੀ ਅੰਦਾਜ਼ੇ ਛੱਡ ਸਕਦੇ ਹੋ। ਇਸ ਦੀ ਤੁਲਨਾ ਪੂਲ ਪ੍ਰੀਫਿਕਸ ਨਾਲ ਵੀ ਕਰੋ, ਕਿਉਂਕਿ ਪੂਲ ਦੇ ਅੰਦਰ ਪਰ ਲੀਜ਼ ਰੇਂਜ ਤੋਂ ਬਾਹਰ ਵਾਲਾ ਪਤਾ ਠੀਕ ਉਹੀ ਹੋਵੇਗਾ ਜਿਵੇਂ ਸੁਧਾਰ ਦਿਖੇਗਾ। ਕਨਫਿਗਰੇਸ਼ਨ ਨਾਲ ਦੋ ਮਿੰਟ ਕਲਾਇੰਟ 'ਤੇ ਪੂਰੀ ਦੁਪਹਿਰ ਪੈਕੇਟ ਫੜਨ ਤੋਂ ਬਿਹਤਰ ਹਨ।

ਲੀਜ਼ ਰੇਂਜ ਤੋਂ ਰਿਜ਼ੌਲਵਰ ਕੱਟੋ

ਟਨਲ ਨੂੰ ਅਜਿਹੀ ਪਤਾ ਯੋਜਨਾ ਦਿਓ ਜਿਸ ਵਿੱਚ ਰਿਜ਼ੌਲਵਰ ਪੂਲ ਦੇ ਆਪਣੇ ਸਬਨੈੱਟ ਦਾ ਮੈਂਬਰ ਹੋਵੇ, ਫਿਰ ਉਹ ਪਤਾ ਰਾਖਵਾਂ ਰੱਖੋ ਤਾਂ ਜੋ ਇਹ ਕਦੇ ਕਿਸੇ ਕਲਾਇੰਟ ਨੂੰ ਲੀਜ਼ 'ਤੇ ਨਾ ਮਿਲੇ। ਇਸ ਉਦਾਹਰਨ ਵਿੱਚ ਪੂਲ 10.180.7.0/24 ਹੈ, ਸਰਵਰ 10.180.7.1 ਰੱਖਦਾ ਹੈ, ਅਤੇ ਲੀਜ਼ਾਂ 10.180.7.2 ਤੋਂ ਸ਼ੁਰੂ ਹੁੰਦੀਆਂ ਹਨ।

rightsourceip=10.180.7.2/24
rightdns=10.180.7.1

ਪੂਲ ਪ੍ਰੀਫਿਕਸ ਅਤੇ ਰਿਜ਼ੌਲਵਰ ਇੱਕੋ ਸਬਨੈੱਟ ਸਾਂਝਾ ਕਰਦੇ ਹਨ, ਇਸ ਲਈ ਜੋ ਰੂਟ ਪਹਿਲਾਂ ਹੀ ਟਨਲ ਟ੍ਰੈਫਿਕ ਢੋਂਦਾ ਹੈ ਉਹੀ ਕਿਊਰੀ ਵੀ ਢੋਂਦਾ ਹੈ। ਇਹੀ ਇੱਕ ਗੁਣ ਸੁਧਾਰ ਨੂੰ ਕਲਾਇੰਟਾਂ ਵਿਚਕਾਰ ਲਿਜਾਣਯੋਗ ਬਣਾਉਂਦਾ ਹੈ। swanctl ਕਨਫਿਗਰੇਸ਼ਨ ਵਿੱਚ ਉਹੀ ਦੋ ਤੱਥ ipsec.conf ਸਿੰਟੈਕਸ ਵਿੱਚ ਨਹੀਂ, ਸਗੋਂ ਪੂਲ ਪਰਿਭਾਸ਼ਾ ਅਤੇ ਕਨੈਕਸ਼ਨ 'ਤੇ DNS ਸੈਟਿੰਗ ਵਜੋਂ ਦਿਖਦੇ ਹਨ।

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

ਰਿਜ਼ੌਲਵਰ ਬਾਈਂਡ ਕਰੋ ਅਤੇ ਪੋਰਟ 53 ਬੰਦ ਕਰੋ

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

interface: 10.180.7.1
access-control: 10.180.7.0/24 allow
access-control: 0.0.0.0/0 refuse

ਇਹ unbound ਟੁਕੜਾ ਟਨਲ ਪੂਲ ਤੋਂ ਕਿਊਰੀਆਂ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ ਅਤੇ ਬਾਕੀ ਸਭ ਰੱਦ ਕਰਦਾ ਹੈ, ਜੋ ਬਹੁਤੇ ਕਾਰਪੋਰੇਟ ਰਿਜ਼ੌਲਵਰ ਚਾਹੁੰਦੇ ਹਨ। ਜੇ ਉਹੀ ਇੰਸਟੈਂਸ LAN ਕਲਾਇੰਟਾਂ ਨੂੰ ਵੀ ਜਵਾਬ ਦਿੰਦਾ ਹੈ, ਤਾਂ ਸਰੋਤਿਆਂ ਨੂੰ ਸਾਰੇ ਸਰੋਤਾਂ ਤੱਕ ਫੈਲਾਉਣ ਦੀ ਥਾਂ LAN ਪ੍ਰੀਫਿਕਸ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਜੋੜੋ।

ਫਿਰ ਫਾਇਰਵਾਲ ਨਿਯਮ ਰਿਜ਼ੌਲਵਰ ਦੇ ਆਪਣੇ ਐਕਸੈਸ ਕੰਟਰੋਲ ਨਾਲ ਮੇਲ ਖਾਣੇ ਚਾਹੀਦੇ ਹਨ। ਪੂਲ ਤੋਂ ਪੋਰਟ 53 ਸਵੀਕਾਰ ਕਰੋ ਅਤੇ ਬਾਕੀ ਹਰ ਥਾਂ ਇਸ ਨੂੰ ਛੱਡ ਦਿਓ, ਪਰ ਪਹਿਲਾਂ ਚੇਨ ਦਾ ਕ੍ਰਮ ਜਾਂਚੋ।

iptables -A INPUT -p udp --dport 53 -s 10.180.7.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 53 -s 10.180.7.0/24 -j ACCEPT
iptables -A INPUT -p udp --dport 53 -j DROP
iptables -A INPUT -p tcp --dport 53 -j DROP

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

ਜਾਂਚੋ ਕਿ ਕਲਾਇੰਟ ਨੇ ਅਸਲ ਵਿੱਚ ਕੀ ਪ੍ਰਾਪਤ ਕੀਤਾ

ਪਹਿਲਾਂ ਸਰਵਰ ਦਾ ਨਜ਼ਰੀਆ ਵੇਖੋ, ਫਿਰ ਕਲਾਇੰਟ ਦਾ, ਕਿਉਂਕਿ ਦੋਵੇਂ ਜਾਣਕਾਰੀਪੂਰਨ ਢੰਗ ਨਾਲ ਵੱਖਰੇ ਹਨ। ਪੂਲ ਸੂਚੀ ਦਿਖਾਉਂਦੀ ਹੈ ਕਿਹੜਾ ਪਤਾ ਲੀਜ਼ 'ਤੇ ਦਿੱਤਾ ਗਿਆ, ਅਤੇ ਸੁਰੱਖਿਆ ਸੰਗਠਨਾਂ ਦੀ ਸੂਚੀ ਦਿਖਾਉਂਦੀ ਹੈ ਕਿ ਕਨੈਕਸ਼ਨ ਉਮੀਦ ਕੀਤੀ ਪਛਾਣ ਨਾਲ ਚਾਲੂ ਹੈ ਜਾਂ ਨਹੀਂ।

swanctl --list-sas
swanctl --list-pools
dig +short @10.180.7.1 intranet.plant.example

ਸਿੱਧੀ ਕਿਊਰੀ ਸਾਬਤ ਕਰਦੀ ਹੈ ਕਿ ਰਿਜ਼ੌਲਵਰ ਪੂਲ ਪਤੇ 'ਤੇ ਉੱਥੇ ਪਹੁੰਚ ਸਕਣ ਵਾਲੇ ਹੋਸਟ ਤੋਂ ਜਵਾਬ ਦਿੰਦਾ ਹੈ। ਇਹ ਸਾਬਤ ਨਹੀਂ ਕਰਦੀ ਕਿ Mac ਨੇ ਉਹੀ ਸਰਵਰ ਚੁਣਿਆ। macOS 'ਤੇ scutil --dns ਹਰ ਸਕੋਪਡ ਸੇਵਾ ਲਈ ਰਿਜ਼ੌਲਵਰ ਸੂਚੀਬੱਧ ਕਰਦਾ ਹੈ ਅਤੇ ਸਾਰਾਂਸ਼ ਪੈਨਲ ਨਾਲੋਂ ਵਧੇਰੇ ਜਾਣਕਾਰੀਪੂਰਨ ਹੈ; Windows 'ਤੇ Get-DnsClientServerAddress ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਟਨਲ ਅਡੈਪਟਰ ਨੇ ਭੇਜਿਆ ਮੁੱਲ ਸਵੀਕਾਰ ਕੀਤਾ ਜਾਂ ਨਹੀਂ।

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