Garde-câble incapable de terminer la poignée de main sur Android Seuls 4G Réseau
J'ai un serveur métallurgique sur mon réseau domestique qui fonctionne bien sur tous mes appareils, y compris mon téléphone lorsqu'il est connecté sur Wi-Fi. Le problème vient lorsque je déconnecte du Wi-Fi et de partir en 4G, mon téléphone est maintenant incapable de terminer la poignée de main avec mon serveur.
Sur mon routeur, j'ai un port UDP 51820 envoyé à mon serveur Wireguard. Sur mon téléphone, je me connecte au VPN en utilisant le nom DNS (VPN.MYDOMAIN.TLD: 51820)
J'ai activé la journalisation du noyau pour WiderGuard pour m'aider à résoudre ce problème, mais je n'ai pas été capable de trouver ce qui ne va pas avec ma configuration.
Voici les journaux sur mon serveur qui apparaissent lorsque j'essaie de vous connecter de mon téléphone (via 4G)
Mar 23 17:49:36 wireguard kernel: [448095.663902] wireguard: wg0: Keypair 9893 created for peer 16
Mar 23 17:49:45 wireguard kernel: [448104.009541] wireguard: wg0: Receiving handshake initiation from peer 16 (xxx.xxx.xxx.xxx:40061)
Mar 23 17:49:45 wireguard kernel: [448104.009546] wireguard: wg0: Sending handshake response to peer 16 (xxx.xxx.xxx.xxx:40061)
Mar 23 17:49:45 wireguard kernel: [448104.010284] wireguard: wg0: Keypair 9893 destroyed for peer 16
Mar 23 17:49:45 wireguard kernel: [448104.010286] wireguard: wg0: Keypair 9894 created for peer 16
Mar 23 17:49:50 wireguard kernel: [448109.069901] wireguard: wg0: Receiving handshake initiation from peer 16 (xxx.xxx.xxx.xxx:40061)
Mar 23 17:49:50 wireguard kernel: [448109.069903] wireguard: wg0: Sending handshake response to peer 16 (xxx.xxx.xxx.xxx:40061)
Mar 23 17:49:50 wireguard kernel: [448109.070073] wireguard: wg0: Keypair 9894 destroyed for peer 16
Sur mon téléphone, je vois ce qui suit:
peer(...) - Sending handshake initiation
peer(...) - Handshake did not complete after 5 seconds, retrying (try 2)
peer(...) - Sending handshake initiation
peer(...) - Handshake did not complete after 5 seconds, retrying (try 2)
peer(...) - Sending handshake initiation
Comme cela fonctionne bien lorsque je suis connecté à mon Wi-Fi de mon domicile, je suis à perte de quoi rechercher un autre transfert de port, mais cela fonctionne bien autant que je puisse dire.
Voici le wg0.conf sur mon serveur:
[Interface]
Address = 10.10.10.3/32
SaveConfig = true
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -t nat -A POSTROUTING -d 10.10.10.0/24 -o eth0 -j MASQUERADE; iptables -t nat -A POSTROUTING ! -d 10.10.10.0/24 -o pia -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -t nat -D POSTROUTING -d 10.10.10.0/24 -o eth0 -j MASQUERADE; iptables -t nat -D POSTROUTING ! -d 10.10.10.0/24 -o pia -j MASQUERADE
ListenPort = 51820
PrivateKey = [removed]
[Peer]
PublicKey = [removed]
AllowedIPs = 10.10.10.245/32
Endpoint = 10.10.10.147:60743
Et le fichier de connexion sur mon téléphone (exécutant Android 11):
[Interface]
Address = 10.10.10.245/24
DNS = 10.10.10.2
PrivateKey = [removed]
[Peer]
AllowedIPs = 0.0.0.0/0
Endpoint = vpn.mydomain.tld:51820
PersistentKeepalive = 25
PublicKey = [removed]
Je me suis assuré que les clés correspondent mais que la connexion fonctionne bien lorsqu'elle est connectée à mon Wi-Fi, je ne pense pas que le fichier de configuration soit à blâmer.
J'ai installé UFW sur le serveur, avec la configuration suivante:
To Action From
-- ------ ----
51820/udp ALLOW Anywhere
22/tcp ALLOW Anywhere
10050 ALLOW Anywhere
51820/udp (v6) ALLOW Anywhere (v6)
22/tcp (v6) ALLOW Anywhere (v6)
10050 (v6) ALLOW Anywhere (v6)
Cependant, je l'ai désactivé pour s'assurer qu'il n'interfère pas, et cela n'a rien changé. À ce stade, je ne sais pas ce qui ne va pas, ni quoi de rechercher pour m'aider à comprendre cela de sorte que toute aide sera la bienvenue
éditer : I genre de figure où le problème vient de. Je suis mon wg0.conf, j'ai la partie suivante dans ma postun: iptables -t nat -A POSTROUTING ! -d 10.10.10.0/24 -o pia -j MASQUERADE Cette ligne est censée parcourir tout le trafic sortant à travers un autre tunnel, cependant, il a également l'effet secondaire de la réaction de mon serveur métallique à réagir à mon client externe via une autre adresse IP (c'est-à-dire que je me connecte à mon téléphone sur 4G à XXX. xxx.xxx.xxx, et à cause de cette ligne, il répond à la demande de connexion via yyy.yyy.yyyy.yyy), c'est pourquoi mon client ne se connecte pas. Lorsque je supplie cette règle de routage, je peux me connecter à l'extérieur de votre réseau, mais maintenant bien sûr, mon trafic n'est pas rétabli dans mon deuxième tunnel. Existe-t-il une façon de conserver cette règle ou d'au moins une règle similaire qui achèvera le trafic externe à travers l'autre VPN, tout en répondant à la demande de connexion de mon téléphone via mon appareil Eth0? Étant donné que mon téléphone se connectera à partir de 4G, je ne peux pas m'attendre à ce que l'adresse IP ne se connecte pas, SP I ne peut pas ajouter une règle de routage similaire uniquement pour mon téléphone.
Sur votre Android Device Installez-la et définissez-le sur le mode WiderGuard, puis Connectez-vous. Maintenant, vérifiez les règles IPTABLES. Malheureusement, je ne suis pas bon chez IPTABLES, mais il y a quelque chose dans la table de mangle et marquez DNS
-A st_clear_caught_dns_accept -d 10.255.255.2/32 -p udp -m udp --dport 53 -j ACCEPT
-A st_clear_detect -m connmark --mark 0x2000000/0x2000000 -j REJECT --reject-with icmp-port-unreachable
-A st_clear_detect -m connmark --mark 0x1000000/0x1000000 -j RETURN
-A st_clear_detect -p tcp -m u32 --u32 "0x0>>0x16&0x3c@0xc>>0x1a&0x3c@0x0&0xffff0000=0x16030000&&0x0>>0x16&0x3c@0xc>>0x1a&0x3c@0x4&0xff0000=0x10000" -j CONNMARK --set-xmark 0x1000000/0x1000000
-A st_clear_detect -p udp -m u32 --u32 "0x0>>0x16&0x3c@0x8&0xffff0000=0x16fe0000&&0x0>>0x16&0x3c@0x14&0xff0000=0x10000" -j CONNMARK --set-xmark 0x1000000/0x1000000
-A st_clear_detect -m connmark --mark 0x1000000/0x1000000 -j RETURN
-A st_clear_detect -p tcp -m state --state ESTABLISHED -m u32 --u32 "0x0>>0x16&0x3c@0xc>>0x1a&0x3c@0x0&0x0=0x0" -j st_clear_caught
-A st_clear_detect -p udp -j st_clear_caught
-A st_penalty_log -j CONNMARK --set-xmark 0x1000000/0x1000000
-A st_penalty_log -j NFLOG
-A st_penalty_reject -j CONNMARK --set-xmark 0x2000000/0x2000000
-A st_penalty_reject -j NFLOG
-A st_penalty_reject -j REJECT --reject-with icmp-port-unreachable