Nie można połączyć się z portami w systemie Linux, ale może w systemie Windows

Moja firma niedawno przeniosła dostawców i dzięki temu komputery wymagają teraz certyfikatu, aby uzyskać dostęp do witryn internetowych. Nie jestem pewien, czy to jest powód, ale pomyślałem, że i tak powinienem o tym wspomnieć. Przed przeprowadzką mogłem bez problemu połączyć się z moim serwerem przez SSH z dowolnego systemu operacyjnego. Teraz mogę używać SSH tylko za pośrednictwem mojej maszyny wirtualnej z systemem Windows 10 (oba komputery znajdują się w sieci biurowej), ale nie mogę z mojego komputera Arch. Wygląda na to, że mogę pingować porty 443 i 80 przez terminal Linux, ale nie mogę pingować żadnych innych otwartych portów, o których wiem, że są otwarte, ponieważ mogę pingować je z wiersza poleceń w systemie Windows.
Plik certyfikatu, który moim zdaniem może być przyczyną, jest przedstawiony jako plik PKCS12, z którego wyodrębniłem dane i umieściłem je w

/etc/ca-certificates/extracted/tls-ca-bundle.pem

     

jak również

/etc/ssl/certs/ca-certificates.crt

     

.
Mając to na uwadze, jeśli ten certyfikat nie jest poprawnie zainstalowany, powinien działać, prawda? Próbowałem śledzić zarówno z mojego komputera Arch, jak i komputera z systemem Windows i otrzymałem następujące wyniki.
Linux

hayden@workbox ~ sudo nmap -Pn --traceroute -p 22 aa.aa.aa.aaStarting 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 sshTRACEROUTE (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   ... 30Nmap done: 1 IP address (1 host up) scanned in 16.27 seconds

Windows

C:\Windows\system32>nmap -Pn --traceroute -p 22 aa.aa.aa.aaStarting 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  sshTRACEROUTE (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.aaNmap done: 1 IP address (1 host up) scanned in 3.30 seconds

Zadzwoniłem do dostawcy, z którym współpracujemy, i są oni pewni, że nie jest to problem z zaporą; faktycznie widzą ruch wychodzący próbujący dostać się do portu 22 bez względu na używany system, co doprowadziło mnie do wniosku, że może to być serwer, z którym próbuję się połączyć, więc zarejestrowałem ruch próbujący połączyć się na porcie 22. Wiesz, żądania trafiają do serwera, ale z jakiegoś powodu nie wracają.

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

Wszystko na portach innych niż 443 i 80 utknie na dd.dd.dd.dd, jeśli zażądam od mojego komputera z systemem Linux, co sprawia, że ​​myślę, że być może naprawdę nie zainstalowałem poprawnie tego certyfikatu. Moje pytanie brzmi: co robię źle? Firewall na moim serwerze jest w porządku - działał bezbłędnie, zanim zmieniliśmy dostawców. Dostawca, do którego się przenieśliśmy, nie pomoże, ponieważ nie jest to ich obszar specjalizacji, ale i tak byli na tyle uprzejmi, aby przeprowadzić trochę badań i ostatecznie doszli do wniosku, że to nie ich problem z zaporą ogniową. Szczerze mówiąc, nie mam dużego doświadczenia w tworzeniu sieci, więc przydałoby się kilka wskaźników/wskazówek, jak dalej to zbadać, jeśli nie ma tutaj odpowiedzi.
Trzy wymienione systemy to:

• Panel roboczy: Arch 4.14.10
• Maszyna wirtualna: Windows 10
• Serwer: Ubuntu 16.04 LTS (Xenial)