Impossible de se connecter aux ports via Linux, Mais peut S. Windows
Mon entreprise a récemment déplacé les fournisseurs et, en même temps, les machines nécessitent désormais un certificat pour accéder aux sites Web. Je ne suis pas sûr que c'est la raison, mais j'ai décidé de le mentionner. Avant de déménager, je pourrais facilement me connecter à mon serveur par SSH de tout système d'exploitation. Maintenant je peux utiliser SSH Seulement via votre machine virtuelle avec Windows 10 (Les deux voitures sont dans le réseau de bureau), Mais je ne peux pas avec ma voiture Arch. Il semble que je puisse ping ports 443 et 80 à travers le terminal Linux, Mais je ne peux pas ping d'autres ports ouverts qui, comme je le sais, sont ouverts, car je peux les ping de la ligne de commande dans Windows.
Un fichier de certificat qui, comme je pense, peut être la cause, est représenté comme un fichier PKCS12, À partir de laquelle j'ai appris les données et placée dans
ainsi que
.
Compte tenu de ce qui précède, si ce certificat n'est pas défini correctement, cela devrait fonctionner, non? J'ai essayé de tracer à la fois avec ma machine d'arc et d'une machine Windows et reçu les résultats suivants.
Linux
Windows
J'ai appelé le fournisseur avec qui nous travaillons et ils sont convaincus que ce n'est pas un problème de pare-feu; ils peuvent vraiment voir le trafic sortant en essayant d'aller au port 22, Peu importe quel système j'utilise qui m'a conduit à la pensée qu'il peut s'agir d'un serveur auquel j'essaie de vous connecter, donc j'ai enregistré le trafic essayant de vous connecter via le port 22. Qu'est-ce que tu sais , Les demandes de renseignements entrent sur le serveur, mais pour une raison quelconque, elles ne sont pas retournées.
Tout ce qui est sur des ports autres que 443 et 80, collé sur dd.dd.dd.dd, Si je demande de ma voiture Linux, Ce qui me fait penser que, peut-être, je n'ai vraiment pas installé ce certificat correctement. J'ai une question: qu'est-ce que je fais mal? Pare-feu sur mon serveur dans l'ordre - Il a travaillé parfaitement avant de changer le fournisseur. Le fournisseur à qui nous avons déménagé ne vous aidera pas, car il n'est pas inclus dans leur compétence, mais ils ont toujours été suffisamment gentils à explorer un peu, finalement parvenus à la conclusion que ce n'est pas le problème de leur pare-feu. Je n'ai pas beaucoup d'expérience dans le réseau, pour être honnête, il serait donc utile pour certains indicateurs / Pointeurs sur la façon d'explorer plus loin cela s'il n'y a pas de réponses ici.
Trois systèmes mentionnés:
Panneau de travail: Arch 4.14.10
Machine virtuelle: Windows 10
Boîte de serveur: Ubuntu 16.04 LTS (Xenial)
Un fichier de certificat qui, comme je pense, peut être la cause, est représenté comme un fichier PKCS12, À partir de laquelle j'ai appris les données et placée dans
/etc/ca-certificates/extracted/tls-ca-bundle.pem
ainsi que
/etc/ssl/certs/ca-certificates.crt
.
Compte tenu de ce qui précède, si ce certificat n'est pas défini correctement, cela devrait fonctionner, non? J'ai essayé de tracer à la fois avec ma machine d'arc et d'une machine Windows et reçu les résultats suivants.
Linux
hayden@workbox ~ sudo nmap -Pn --traceroute -p 22 aa.aa.aa.aa
Starting Nmap 7.60 ( [url=https://nmap.org]https://nmap.org[/url] ) at 2018-02-05 11:57 GMT
Nmap scan report for aa.aa.aa.aa
Host is up.
PORT STATE SERVICE
22/tcp filtered ssh
TRACEROUTE (using proto 1/icmp)
HOP RTT ADDRESS
1 0.46 ms bb.bb.bb.bb
2 1.40 ms cc.cc.cc.cc
3 2.24 ms dd.dd.dd.dd
4 ... 30
Nmap done: 1 IP address (1 host up) scanned in 16.27 seconds
Windows
C:\Windows\system32>nmap -Pn --traceroute -p 22 aa.aa.aa.aa
Starting Nmap 7.60 ( [url=https://nmap.org]https://nmap.org[/url] ) at 2018-02-05 12:02 GMT Standard Time
Nmap scan report for aa.aa.aa.aa
Host is up (0.025s latency).
PORT STATE SERVICE
22/tcp open ssh
TRACEROUTE (using port 22/tcp)
HOP RTT ADDRESS
1 0.00 ms bb.bb.bb.bb
2 2.00 ms cc.cc.cc.cc
3 2.00 ms dd.dd.dd.dd
4 ... 13
14 28.00 ms aa.aa.aa.aa
Nmap done: 1 IP address (1 host up) scanned in 3.30 seconds
J'ai appelé le fournisseur avec qui nous travaillons et ils sont convaincus que ce n'est pas un problème de pare-feu; ils peuvent vraiment voir le trafic sortant en essayant d'aller au port 22, Peu importe quel système j'utilise qui m'a conduit à la pensée qu'il peut s'agir d'un serveur auquel j'essaie de vous connecter, donc j'ai enregistré le trafic essayant de vous connecter via le port 22. Qu'est-ce que tu sais , Les demandes de renseignements entrent sur le serveur, mais pour une raison quelconque, elles ne sont pas retournées.
hayden@serverbox:~$ sudo tail -1 /var/log/syslog
Feb 5 12:08:34 localhost kernel: [936377.791850] New ConnectionIN=ens192 OUT= MAC=00:50:56:37:1b:25:00:50:56:8e:7f:8f:08:00 SRC=ee.ee.ee.ee DST=aa.aa.aa.aa LEN=60 TOS=0x00 PREC=0x00 TTL=51 ID=13193 DF PROTO=TCP SPT=54482 DPT=22 WINDOW=29200 RES=0x00 SYN URGP=0
Tout ce qui est sur des ports autres que 443 et 80, collé sur dd.dd.dd.dd, Si je demande de ma voiture Linux, Ce qui me fait penser que, peut-être, je n'ai vraiment pas installé ce certificat correctement. J'ai une question: qu'est-ce que je fais mal? Pare-feu sur mon serveur dans l'ordre - Il a travaillé parfaitement avant de changer le fournisseur. Le fournisseur à qui nous avons déménagé ne vous aidera pas, car il n'est pas inclus dans leur compétence, mais ils ont toujours été suffisamment gentils à explorer un peu, finalement parvenus à la conclusion que ce n'est pas le problème de leur pare-feu. Je n'ai pas beaucoup d'expérience dans le réseau, pour être honnête, il serait donc utile pour certains indicateurs / Pointeurs sur la façon d'explorer plus loin cela s'il n'y a pas de réponses ici.
Trois systèmes mentionnés:
Panneau de travail: Arch 4.14.10
Machine virtuelle: Windows 10
Boîte de serveur: Ubuntu 16.04 LTS (Xenial)
Aucun résultat connexe trouvé
Invité:
Pour répondre aux questions, connectez-vous ou registre
0 réponses