Closed Saleh-Mumtaz closed 1 week ago
Please describe what you are meaning with ping. The usual ping is sending out icmp-packets and that has nothing todo with sslh. Or, are you using a ping build in in one of your applications? In this case provide more information about that. In case you are using an tcp-based ping, you are walking right into a trap: I assume, that in this case a tcp-based ping is always opening new connections. In this case you are seeing the core sslh functionality: Sslh is listening for a connection. Once a packet is received, sslh is sending back the SYN-ACK and waiting for more data, as it needs this data to inspect and decide what to do next. Than sslh is opening a own connection to the final target, waiting for the SYN-ACK of this connection and than it sends the stored packet to the final application. After that sslh shovels all answers from the final target back to the client and all data coming from the client to the final target. So an application based tcp ping, which is only measuring connection starts, will tell you: Nonsense! To get real numbers, you have to analyze an tcpdump and the timing for the later packets. Here you will see (after my experience) 30ms-100ms more latency, usually all below 50ms, if the system has enough free ressources.
inreases from 500ms to 1000 or 2000 and more, so much lagging, a lot of the times even no response.
Hi, as I mentioned, it's not only ping, and usual internet surfing is affected too.
And the 2dust/v2rayng uses url delay test. It has tcp ping too, but we don't use it.
tcp ping won't show if our domain or ip got blocked by gfw or not, url ping do that.
Sorry, your picture doesn't tell me anything. Looks like parts of Pythoncode with line numbers.
Your setup seems to be very complicated, and your problem can be caused by many reasons.
To analyze such things, you need to go some steps back:
Just setup a plain sslh-Setup, which only has an ssh-server destination and nothing else.
Than open a ssh-Session to your server which creates a local Socks5 proxy, e.g. ssh -D 8080 -q -N -p SSLH-PORT username@servername
Start a Browser, which is using this Socks Proxy, or use it with curl/wget and look for your performance.
If you are running in problems, show logs, capture-files from such a connection.
Most people using sslh are familiar with this setup, so you may have a good chance to get much more help, compared to your current setup.
If however this setup is working, you know, that sslh is not your primary problem, and you need to dive deeper into the interaction between sslh and your other applications.
The purpose of the picture was to show you that The problem is not from the ICMP ping handling and the problem is from the configuration of SSLH or the nginx's or other configurations of the V. P. S My main question is that why I can't run the SSLH with the background switch Without setting the other protocols because I don't need them. And the second question is, if the increase in ping is from the SSL H or there is no wrong with my configuration, and is there any better way to do what i want to do with it?
--background
?
From the man page:
This overrides foreground if set in the configuration file
Which means, you need this only in that case, when you have foreground configured in a configuration file. If you have no foreground configured, running in background is the default behaviour.
My personal assumption however is, that you may get an systemd error message. Systemd's default configuration is running sslh in foreground, as that is needed to take control over it. When sslh detaches, systemd will lose control. /etc/default/sslh
if that exists on your systemHi, 1/ I don't receive any error, only logs are sni matching when I run jouranctl. 2/ I read in one of the repositories issues or files that foreground takes time to write what is happening and that may slow it down. I searched phrase background, no explanation came up. I will delete foreground switch in service file and there is no foreground or background switch in /etc/sslh.cgf and see what happens. 3/ I deleted /etc/default/sslh, i am giving sslh all configurations it needs in sslh.cfg, does it necessarily need default/sslh file? 4/ I will set a ssh and SSL simple congif and use tcpdump to capture connections. And at last, I want to know, what I described earlier, could it be implemented in a better way in sslh.cfg? Or any better options in service file?
[Unit]
Description=SSL/SSH multiplexer
After=network.target
Documentation=man:sslh(8)
[Service]
User=sslh
RuntimeDirectory=sslh
ExecStart=/usr/sbin/sslh --config /etc/sslh.cfg
PIDFile=/run/sslh/sslh.pid
KillMode=control-group
#Hardening
PrivateTmp=true
CapabilityBoundingSet=CAP_SETGID CAP_SETUID CAP_NET_BIND_SERVICE
AmbientCapabilities=CAP_NET_BIND_SERVICE
SecureBits=noroot-locked
ProtectSystem=strict
ProtectHome=true
ProtectKernelModules=true
ProtectKernelTunables=true
ProtectControlGroups=true
MountFlags=private
NoNewPrivileges=true
PrivateDevices=true
RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX
MemoryDenyWriteExecute=true
DynamicUser=true
[Install]
WantedBy=multi-user.target
timeout: 2;
pidfile: "/run/sslh/sslh.pid";
# Listen on public port 443 for incoming connections
listen:
(
{ host: "0.0.0.0"; port: "443"; }
);
# Protocol definitions
protocols:
(
# Forward SSH traffic to the local SSH server on port 22
{ name: "ssh"; host: "localhost"; port: "22"; keepalive: true; fork: true; },
# Forward HTTPS (TLS) traffic to Xray on localhost:4443
{ name: "tls"; host: "localhost"; port: "4443"; keepalive: true; },
# Forward anything else to 4443 xray
{ name: "anyprot"; host: "localhost"; port: "4443"; keepalive: true; }
);
○ sslh.service - SSL/SSH multiplexer
Loaded: loaded (/usr/lib/systemd/system/sslh.service; ena
bled; preset: enabled)
Active: inactive (dead) since Mon 2024-11-11 19:39:34 UTC; 3s ago
Duration: 69ms
Docs: man:sslh(8)
Process: 369689 ExecStart=/usr/sbin/sslh --config /etc/sslh.cfg (code=exited, status=0/SUCCESS)
Main PID: 369689 (code=exited, status=0/SUCCESS)
CPU: 49ms
Nov 11 19:39:34 juden-ir systemd[1]: Started sslh.service - SSL/SSH multiplexer.
Nov 11 19:39:34 juden-ir systemd[1]: sslh.service: Deactivated successfully.
You were right, without foreground, systemd will lose control. With foreground switch in service file:
root@juden-ir:~# sudo systemctl status sslh
● sslh.service - SSL/SSH multiplexer
Loaded: loaded (/usr/lib/systemd/system/sslh.service; ena
bled; preset: enabled)
Active: active (running) since Mon 2024-11-11 19:41:59 UTC; 2s ago
Docs: man:sslh(8)
Main PID: 370889 (sslh)
Tasks: 2 (limit: 2288)
Memory: 792.0K (peak: 1.0M)
CPU: 47ms
CGroup: /system.slice/sslh.service
├─370889 /usr/sbin/sslh --foreground --config /etc/sslh.cfg
└─370892 "sslh: listener 0.0.0.0:443"
Nov 11 19:41:59 juden-ir systemd[1]: Started sslh.service - SSL/SSH multiplexer.
Nov 11 19:50:07 juden-ir sslh[375159]: tls:connection from 164.52.0.92:46549 to 193.43.91.150:443 forwarded from localhost:36856
to localhost:4443
Nov 11 19:50:07 juden-ir sslh[375159]: tls:connection from 164.52.0.92:46549 to 193.43.91.150:443 forwarded from localhost:36856
to localhost:4443
Nov 11 19:50:08 juden-ir sslh[375166]: sprintaddr:getnameinfo: Temporary failure in name resolution
Nov 11 19:50:08 juden-ir sslh[375166]: sprintaddr:getnameinfo: Temporary failure in name resolution
Nov 11 19:50:08 juden-ir sslh[375166]: anyprot:connection from 164.52.0.92:34177 to 193.43.91.150:443 forwarded from localhost:36
858 to localhost:4443
Nov 11 19:50:08 juden-ir sslh[375166]: anyprot:connection from 164.52.0.92:34177 to 193.43.91.150:443 forwarded from localhost:36
858 to localhost:4443
Nov 11 19:50:10 juden-ir sslh[375167]: sprintaddr:getnameinfo: Temporary failure in name resolution
Nov 11 19:50:10 juden-ir sslh[375167]: sprintaddr:getnameinfo: Temporary failure in name resolution
Nov 11 19:50:10 juden-ir sslh[375167]: ssh:connection from 164.52.0.92:57475 to 193.43.91.150:443 forwarded from localhost:34068
to localhost:22
Nov 11 19:50:10 juden-ir sslh[375167]: ssh:connection from 164.52.0.92:57475 to 193.43.91.150:443 forwarded from localhost:34068
to localhost:22
root@juden-ir:~# journalctl -u sslh.service
Nov 11 19:21:14 juden-ir systemd[1]: /usr/l
ib/systemd/system/sslh.service:10: Unknown key name 'Backlog' in section 'Service', ignoring.
Nov 11 19:21:14 juden-ir systemd[1]: Started sslh.service - SSL/SSH multiplexer.
Nov 11 19:21:14 juden-ir sslh[360257]: /etc/sslh.cfg:21:syntax error
Nov 11 19:21:14 juden-ir systemd[1]: sslh.service: Main process exited, code=exited, status=6/NOTCONFIGUR
ED
Nov 11 19:21:14 juden-ir systemd[1]: sslh.service: Failed with result 'exit-code'.
Nov 11 19:21:53 juden-ir systemd[1]: /usr/l
ib/systemd/system/sslh.service:10: Unknown key name 'Backlog' in section 'Service', ignoring.
Nov 11 19:21:56 juden-ir systemd[1]: Started sslh.service - SSL/SSH multiplexer.
Nov 11 19:21:56 juden-ir sslh[360643]: /etc/sslh.cfg:21:syntax error
Nov 11 19:21:56 juden-ir systemd[1]: sslh.service: Main process exited, code=exited, status=6/NOTCONFIGUR
ED
Nov 11 19:21:56 juden-ir systemd[1]: sslh.service: Failed with result 'exit-code'.
Nov 11 19:23:32 juden-ir systemd[1]: /usr/l
ib/systemd/system/sslh.service:10: Unknown key name 'Backlog' in section 'Service', ignoring.
Nov 11 19:23:35 juden-ir systemd[1]: Started sslh.service - SSL/SSH multiplexer.
Nov 11 19:23:36 juden-ir sslh[361524]: write_pid_file: /var/run/sslh.pid: Permission denied
Nov 11 19:23:36 juden-ir systemd[1]: sslh.service: Deactivated successfully.
Nov 11 19:23:39 juden-ir systemd[1]: /usr/l
ib/systemd/system/sslh.service:10: Unknown key name 'Backlog' in section 'Service', ignoring.
Nov 11 19:27:47 juden-ir systemd[1]: Started sslh.service - SSL/SSH multiplexer.
Nov 11 19:27:47 juden-ir sslh[363592]: write_pid_file: /var/run/sslh.pid: Permission denied
Nov 11 19:27:47 juden-ir systemd[1]: sslh.service: Deactivated successfully.
Nov 11 19:33:01 juden-ir systemd[1]: Started sslh.service - SSL/SSH multiplexer.
Nov 11 19:33:01 juden-ir systemd[1]: sslh.service: Deactivated successfully.
Nov 11 19:35:27 juden-ir systemd[1]: Started sslh.service - SSL/SSH multiplexer.
Nov 11 19:35:27 juden-ir systemd[1]: sslh.service: Deactivated successfully.
Nov 11 19:36:59 juden-ir systemd[1]: Started sslh.service - SSL/SSH multiplexer.
Nov 11 19:39:34 juden-ir systemd[1]: Stopping sslh.service - SSL/SSH multiplexer...
Nov 11 19:39:34 juden-ir systemd[1]: sslh.service: Deactivated successfully.
Nov 11 19:39:34 juden-ir systemd[1]: Stopped sslh.service - SSL/SSH multiplexer.
Nov 11 19:39:34 juden-ir systemd[1]: Started sslh.service - SSL/SSH multiplexer.
Nov 11 19:39:34 juden-ir systemd[1]: sslh.service: Deactivated successfully.
Nov 11 19:41:59 juden-ir systemd[1]: Started sslh.service - SSL/SSH multiplexer.
Nov 11 19:43:24 juden-ir sslh[371583]: tls:connection from 37.156.156.139:56669 to 193.43.91.150:443 forwarded from localhost:352
72 to localhost:4443
Nov 11 19:43:24 juden-ir sslh[371583]: tls:connection from 37.156.156.139:56669 to 193.43.91.150:443 forwarded from localhost:352
72 to localhost:4443
Nov 11 19:43:45 juden-ir sslh[371746]: ssh:connection from 162.142.125.32:37654 to 193.43.91.150:443 forwarded from localhost:343
98 to localhost:22
Nov 11 19:43:45 juden-ir sslh[371746]: ssh:connection from 162.142.125.32:37654 to 193.43.91.150:443 forwarded from localhost:343
98 to localhost:22
Nov 11 19:43:51 juden-ir sslh[371838]: ssh:connection from 162.142.125.32:51394 to 193.43.91.150:443 forwarded from localhost:333
02 to localhost:22
Nov 11 19:43:51 juden-ir sslh[371838]: ssh:connection from 162.142.125.32:51394 to 193.43.91.150:443 forwarded from localhost:333
02 to localhost:22
Nov 11 19:45:07 juden-ir sslh[372473]: tls:connection from 37.156.156.139:51875 to 193.43.91.150:443 forwarded from localhost:404
92 to localhost:4443
Nov 11 19:45:07 juden-ir sslh[372473]: tls:connection from 37.156.156.139:51875 to 193.43.91.150:443 forwarded from localhost:404
92 to localhost:4443
Nov 11 19:46:19 juden-ir sslh[373067]: ssh:connection from wille.ir:56846 to 193.43.91.150:443 forwarded from localhost:54508 to
localhost:22
Nov 11 19:46:19 juden-ir sslh[373067]: ssh:connection from wille.ir:56846 to 193.43.91.150:443 forwarded from localhost:54508 to
localhost:22
Nov 11 19:49:59 juden-ir sslh[375070]: sprintaddr:getnameinfo: Temporary failure in name resolution
Nov 11 19:49:59 juden-ir sslh[375070]: sprintaddr:getnameinfo: Temporary failure in name resolution
Nov 11 19:49:59 juden-ir sslh[375070]: tls:connection from 164.52.0.92:36389 to 193.43.91.150:443 forwarded from localhost:56326
to localhost:4443
Nov 11 19:49:59 juden-ir sslh[375070]: tls:connection from 164.52.0.92:36389 to 193.43.91.150:443 forwarded from localhost:56326
to localhost:4443
Nov 11 19:50:00 juden-ir sslh[375089]: sprintaddr:getnameinfo: Temporary failure in name resolution
Nov 11 19:50:00 juden-ir sslh[375089]: sprintaddr:getnameinfo: Temporary failure in name resolution
Nov 11 19:50:00 juden-ir sslh[375089]: anyprot:connection from 164.52.0.92:37627 to 193.43.91.150:443 forwarded from localhost:56
328 to localhost:4443
Nov 11 19:50:00 juden-ir sslh[375089]: anyprot:connection from 164.52.0.92:37627 to 193.43.91.150:443 forwarded from localhost:56
328 to localhost:4443
Nov 11 19:50:00 juden-ir sslh[375108]: sprintaddr:getnameinfo: Temporary failure in name resolution
Nov 11 19:50:00 juden-ir sslh[375108]: sprintaddr:getnameinfo: Temporary failure in name resolution
Nov 11 19:50:00 juden-ir sslh[375108]: tls:connection from 164.52.0.92:37545 to 193.43.91.150:443 forwarded from localhost:36788
to localhost:4443
Nov 11 19:50:00 juden-ir sslh[375108]: tls:connection from 164.52.0.92:37545 to 193.43.91.150:443 forwarded from localhost:36788
to localhost:4443
Nov 11 19:50:01 juden-ir sslh[375115]: sprintaddr:getnameinfo: Temporary failure in name resolution
Nov 11 19:50:01 juden-ir sslh[375115]: sprintaddr:getnameinfo: Temporary failure in name resolution
Nov 11 19:50:01 juden-ir sslh[375115]: tls:connection from 164.52.0.92:42103 to 193.43.91.150:443 forwarded from localhost:36802
to localhost:4443
Nov 11 19:50:01 juden-ir sslh[375115]: tls:connection from 164.52.0.92:42103 to 193.43.91.150:443 forwarded from localhost:36802
to localhost:4443
Nov 11 19:50:01 juden-ir sslh[375116]: sprintaddr:getnameinfo: Temporary failure in name resolution
Nov 11 19:50:01 juden-ir sslh[375116]: sprintaddr:getnameinfo: Temporary failure in name resolution
Nov 11 19:50:01 juden-ir sslh[375116]: tls:connection from 164.52.0.92:43129 to 193.43.91.150:443 forwarded from localhost:36806
to localhost:4443
Nov 11 19:50:01 juden-ir sslh[375116]: tls:connection from 164.52.0.92:43129 to 193.43.91.150:443 forwarded from localhost:36806
to localhost:4443
Nov 11 19:50:02 juden-ir sslh[375123]: sprintaddr:getnameinfo: Temporary failure in name resolution
Nov 11 19:50:02 juden-ir sslh[375123]: sprintaddr:getnameinfo: Temporary failure in name resolution
Nov 11 19:50:02 juden-ir sslh[375123]: tls:connection from 164.52.0.92:56039 to 193.43.91.150:443 forwarded from localhost:36812
to localhost:4443
Nov 11 19:50:02 juden-ir sslh[375123]: tls:connection from 164.52.0.92:56039 to 193.43.91.150:443 forwarded from localhost:36812
to localhost:4443
Nov 11 19:50:02 juden-ir sslh[375124]: sprintaddr:getnameinfo: Temporary failure in name resolution
Nov 11 19:50:02 juden-ir sslh[375124]: sprintaddr:getnameinfo: Temporary failure in name resolution
Nov 11 19:50:02 juden-ir sslh[375124]: tls:connection from 164.52.0.92:49497 to 193.43.91.150:443 forwarded from localhost:36822
to localhost:4443
Nov 11 19:50:02 juden-ir sslh[375124]: tls:connection from 164.52.0.92:49497 to 193.43.91.150:443 forwarded from localhost:36822
to localhost:4443
Nov 11 19:50:03 juden-ir sslh[375131]: sprintaddr:getnameinfo: Temporary failure in name resolution
Nov 11 19:50:03 juden-ir sslh[375131]: sprintaddr:getnameinfo: Temporary failure in name resolution
Nov 11 19:50:03 juden-ir sslh[375131]: tls:connection from 164.52.0.92:43371 to 193.43.91.150:443 forwarded from localhost:36826
to localhost:4443
Nov 11 19:50:03 juden-ir sslh[375131]: tls:connection from 164.52.0.92:43371 to 193.43.91.150:443 forwarded from localhost:36826
to localhost:4443
Nov 11 19:50:04 juden-ir sslh[375138]: sprintaddr:getnameinfo: Temporary failure in name resolution
Nov 11 19:50:04 juden-ir sslh[375138]: sprintaddr:getnameinfo: Temporary failure in name resolution
Nov 11 19:50:05 juden-ir sslh[375138]: tls:connection from 164.52.0.92:58345 to 193.43.91.150:443 forwarded from localhost:36828
to localhost:4443
Nov 11 19:50:05 juden-ir sslh[375138]: tls:connection from 164.52.0.92:58345 to 193.43.91.150:443 forwarded from localhost:36828
to localhost:4443
Nov 11 19:50:06 juden-ir sslh[375151]: sprintaddr:getnameinfo: Temporary failure in name resolution
Nov 11 19:50:06 juden-ir sslh[375151]: sprintaddr:getnameinfo: Temporary failure in name resolution
Nov 11 19:50:06 juden-ir sslh[375151]: tls:connection from 164.52.0.92:33189 to 193.43.91.150:443 forwarded from localhost:36842
to localhost:4443
Nov 11 19:50:06 juden-ir sslh[375151]: tls:connection from 164.52.0.92:33189 to 193.43.91.150:443 forwarded from localhost:36842
to localhost:4443
Nov 11 19:50:07 juden-ir sslh[375158]: sprintaddr:getnameinfo: Temporary failure in name resolution
Nov 11 19:50:07 juden-ir sslh[375158]: sprintaddr:getnameinfo: Temporary failure in name resolution
Nov 11 19:50:07 juden-ir sslh[375158]: tls:connection from 164.52.0.92:50031 to 193.43.91.150:443 forwarded from localhost:36846
to localhost:4443
Nov 11 19:50:07 juden-ir sslh[375158]: tls:connection from 164.52.0.92:50031 to 193.43.91.150:443 forwarded from localhost:36846
to localhost:4443
Nov 11 19:50:07 juden-ir sslh[375159]: sprintaddr:getnameinfo: Temporary failure in name resolution
Nov 11 19:50:07 juden-ir sslh[375159]: sprintaddr:getnameinfo: Temporary failure in name resolution
Nov 11 19:50:07 juden-ir sslh[375159]: tls:connection from 164.52.0.92:46549 to 193.43.91.150:443 forwarded from localhost:36856
to localhost:4443
Nov 11 19:50:07 juden-ir sslh[375159]: tls:connection from 164.52.0.92:46549 to 193.43.91.150:443 forwarded from localhost:36856
to localhost:4443
Nov 11 19:50:08 juden-ir sslh[375166]: sprintaddr:getnameinfo: Temporary failure in name resolution
Nov 11 19:50:08 juden-ir sslh[375166]: sprintaddr:getnameinfo: Temporary failure in name resolution
Nov 11 19:50:08 juden-ir sslh[375166]: anyprot:connection from 164.52.0.92:34177 to 193.43.91.150:443 forwarded from localhost:36
858 to localhost:4443
Nov 11 19:50:08 juden-ir sslh[375166]: anyprot:connection from 164.52.0.92:34177 to 193.43.91.150:443 forwarded from localhost:36
858 to localhost:4443
Nov 11 19:50:10 juden-ir sslh[375167]: sprintaddr:getnameinfo: Temporary failure in name resolution
Nov 11 19:50:10 juden-ir sslh[375167]: sprintaddr:getnameinfo: Temporary failure in name resolution
Nov 11 19:50:10 juden-ir sslh[375167]: ssh:connection from 164.52.0.92:57475 to 193.43.91.150:443 forwarded from localhost:34068
to localhost:22
Nov 11 19:50:10 juden-ir sslh[375167]: ssh:connection from 164.52.0.92:57475 to 193.43.91.150:443 forwarded from localhost:34068
to localhost:22
Nov 11 19:50:20 juden-ir sslh[375290]: sprintaddr:getnameinfo: Temporary failure in name resolution
Nov 11 19:50:20 juden-ir sslh[375290]: sprintaddr:getnameinfo: Temporary failure in name resolution
Nov 11 19:50:20 juden-ir sslh[375290]: ssh:connection from 164.52.0.92:50786 to 193.43.91.150:443 forwarded from localhost:37714
to localhost:22
Nov 11 19:50:20 juden-ir sslh[375290]: ssh:connection from 164.52.0.92:50786 to 193.43.91.150:443 forwarded from localhost:37714
to localhost:22
Nov 11 19:50:36 juden-ir sslh[375436]: sprintaddr:getnameinfo: Temporary failure in name resolution
Nov 11 19:50:36 juden-ir sslh[375436]: sprintaddr:getnameinfo: Temporary failure in name resolution
Nov 11 19:50:36 juden-ir sslh[375436]: ssh:connection from 164.52.0.92:49596 to 193.43.91.150:443 forwarded from localhost:37352
to localhost:22
Nov 11 19:50:36 juden-ir sslh[375436]: ssh:connection from 164.52.0.92:49596 to 193.43.91.150:443 forwarded from localhost:37352
to localhost:22
Nov 11 19:50:38 juden-ir sslh[375445]: sprintaddr:getnameinfo: Temporary failure in name resolution
Nov 11 19:50:38 juden-ir sslh[375445]: sprintaddr:getnameinfo: Temporary failure in name resolution
Nov 11 19:50:38 juden-ir sslh[375445]: ssh:connection from 164.52.0.92:49606 to 193.43.91.150:443 forwarded from localhost:37354
to localhost:22
Nov 11 19:50:38 juden-ir sslh[375445]: ssh:connection from 164.52.0.92:49606 to 193.43.91.150:443 forwarded from localhost:37354
to localhost:22
Nov 11 19:51:01 juden-ir sslh[375633]: sprintaddr:getnameinfo: Temporary failure in name resolution
Nov 11 19:51:01 juden-ir sslh[375633]: sprintaddr:getnameinfo: Temporary failure in name resolution
Nov 11 19:51:01 juden-ir sslh[375633]: ssh:connection from 164.52.0.92:52636 to 193.43.91.150:443 forwarded from localhost:41768
to localhost:22
Nov 11 19:51:01 juden-ir sslh[375633]: ssh:connection from 164.52.0.92:52636 to 193.43.91.150:443 forwarded from localhost:41768
to localhost:22
Nov 11 19:51:19 juden-ir sslh[375791]: sprintaddr:getnameinfo: Temporary failure in name resolution
Nov 11 19:51:19 juden-ir sslh[375791]: sprintaddr:getnameinfo: Temporary failure in name resolution
Nov 11 19:51:19 juden-ir sslh[375791]: ssh:connection from 164.52.0.92:37734 to 193.43.91.150:443 forwarded from localhost:41038
to localhost:22
Nov 11 19:51:19 juden-ir sslh[375791]: ssh:connection from 164.52.0.92:37734 to 193.43.91.150:443 forwarded from localhost:41038
to localhost:22
Nov 11 19:51:37 juden-ir sslh[375943]: sprintaddr:getnameinfo: Temporary failure in name resolution
Nov 11 19:51:37 juden-ir sslh[375943]: sprintaddr:getnameinfo: Temporary failure in name resolution
Nov 11 19:51:37 juden-ir sslh[375943]: ssh:connection from 164.52.0.92:38912 to 193.43.91.150:443 forwarded from localhost:42492
to localhost:22
Nov 11 19:51:37 juden-ir sslh[375943]: ssh:connection from 164.52.0.92:38912 to 193.43.91.150:443 forwarded from localhost:42492
to localhost:22
Nov 11 19:51:38 juden-ir sslh[375952]: sprintaddr:getnameinfo: Temporary failure in name resolution
Nov 11 19:51:38 juden-ir sslh[375952]: sprintaddr:getnameinfo: Temporary failure in name resolution
Nov 11 19:51:38 juden-ir sslh[375952]: ssh:connection from 164.52.0.92:38926 to 193.43.91.150:443 forwarded from localhost:42504
to localhost:22
Nov 11 19:51:38 juden-ir sslh[375952]: ssh:connection from 164.52.0.92:38926 to 193.43.91.150:443 forwarded from localhost:42504
to localhost:22
Hi, 1/ I don't receive any error, only logs are sni matching when I run jouranctl.
You wrote in your opening post: "it says code=6/NOTCONGIGUR?", which seems beeing part of an error message; So I wanted to see the full message
2/ I read in one of the repositories issues or files that foreground takes time to write what is happening and that may slow it down. I searched phrase background, no explanation came up.
man sslh is your friend
3/ I deleted /etc/default/sslh, i am giving sslh all configurations it needs in sslh.cfg, does it necessarily need default/sslh file?
No, you don't need it. But if it is there, it has an influence on the configuration. So you need either to post content of that file or the information, that you deleted the file.
4/ I will set a ssh and SSL simple congif and use tcpdump to capture connections. And at last, I want to know, what I described earlier, could it be implemented in a better way in sslh.cfg?
As I don't know your other applications, and at least this XRAY stuff looks really weird. As my experience is, that sslh does not delay ssh connections in a noticable way, my recommendation is, setting up a configuration with only one ssh target and nothing else.
I should clarify my previous message, Notconfigure: I was looking to run it in background, Now I don't. Yes I don't like default/sslh I didn't like how we should write configuration in it, sslh.cfg is better. Xray, is a tls based VPN for China, Iran Russia and other dictatorship countries. It mimics the traffic of a real web surfing. We faced tls-in-tls, not a browser like traffic, and tls factors. Reality can eliminate server tls fingerprint characteristics. xtls-rprx-vision can eliminate tls-in-tls characteristics. utls can eliminate client tls fingerprint characteristics. Now when I said sslh previously increased ping and created so much lagging and disconnectings, I experienced it not only in Ssh to the vps, a lot of lags and commands left behind, but also in xray connections. For this new simple(no mtproto with anyprot , no sni matching), it gives 700 800ms URL ping, which is good. I should see how long it would remain stable. Then add the other stuff. If you did find a better way to write that configuration send it please.
journalctl output. Now I move to add mtprotoproxy.
New sslh.cfg
timeout: 2;
pidfile: "/run/sslh/sslh.pid";
# Listen on public port 443 for incoming connections
listen:
(
{ host: "0.0.0.0"; port: "443"; }
);
# Protocol definitions
protocols:
(
# Forward SSH traffic to the local SSH server on port 22
{ name: "ssh"; host: "localhost"; port: "22"; keepalive: true; fork: true; },
#MTProto Proxy
{ name: "tls"; host: "localhost"; port: "5443"; sni_hostnames: [ "google.com" ]; keepalive: true; },
# Forward HTTPS (TLS) traffic to Xray on localhost:4443
{ name: "tls"; host: "localhost"; port: "4443"; keepalive: true; },
# Forward anything else to 4443 xray
{ name: "anyprot"; host: "localhost"; port: "4443"; keepalive: true; }
);
I notice you have a lot of DNS failures ("Temporary failure in name resolution"): typically each of these failure may introduce delays, which would happen for each new incoming connection (but not for established connections): I am not sure if that fits your symptoms, it's not clear if you experience lagging at connection establishment or later on.
sslh
only uses DNS to revert IP addresses to names, so it can happily work without it: it is worth adding
numeric: true;
or -n
to the command line
@ftasnetamot tested new cfg for 6 hours: sslh-12-11-2024-2011.txt
@yrutschle I don't know if I should add numeric: true; to all protocols so that I will add it to the service file.
ExecStart=/usr/sbin/sslh --foreground -n --config /etc/sslh.cfg
I see these connection refused lines, and after that line, there is a connection forwarded to 5443, the mtproto proxy port. I don't know if they are invalid requests by GFW or if there is a wrong configuration. Despite these errors, the Telegram proxy is working very well. No errors in mtprotoproxy logs from six hours ago.
Ok, looking to your results, I see that my assumption is right.
The basic sslh function has no problems, you have problems with dns, where @yrutschle already told you, using the -n switch.
For those services, you are now seeing "connection refused" messages, you should tell more about the domain names: mydomain.com and a-tls1.3-domain.com are for example not domain names, which could be resolved. So I can only make assumptions, that those are fake domains, which are resolved via /etc/hosts or a special nameserver. If those names are used as targets for the sslh configuration, i think using names is overkill, just use ip addresses. But to tell, why you will receive those messages, i can only read tea leaves.
Those are fake domains I replaced using notepad. I am using my own domains, I didn't want them to be in log file. That "connection refused" I think is no longer related to SSLH, which is working perfectly. If you think it can be from SSLH tell me please. Also I enabled tfo for all protocols, inculding ssh. I would like to keep this issue open for a while, since problems with sslh are solved, I will leave it under test for a while and report here if I faced any problem. Thank you both for your help.
I solved that problem, mtprotoproxy doesn't accept connections from ::1 , only 127.0.0.1. Still, if you had any suggestions that I could use this tool better or with other useful services I would appreciate it.
sslh-13-11-2024-2120.txt No error. 16 hours of running. Closing the issue.
Hi, I want to thank you @yrutschle for your great project, this tool really comes in handy for beginners and newibies. I am using sslh to have a https website, another https website hidden and only accessed by special path(vpn control pannel), xray REALITY vpn, xray CDN vpn, telegram mtproto proxy, and also ssh on 443. I have compiled sslh on my server, an i am using sslh-ev executable. ubuntu 24.04. 1vcore 3.6GHz and 4gb ram. I am running it as a service.
1/I wanted to know why when I use --background switch in service file or manual running, it says code=6/NOTCONGIGUR? I don't want to configure other protocols, i don't need them.
2/And, when I use this setup, my ping(in v2rayng, xray client) inreases from 500ms to 1000 or 2000 and more, so much lagging, a lot of the times even no response. Is it natural and I can't do anything about it or my configuration is wrong?
For now, I placed xray as 443 manager, lost mtproxy and ssh on 443. ping is 400 to 600ms.
XRAY is on 4443 NGINX is on 8443 MTProxy is on 5443 SSH is on 6443
xray receives REALITY and CDN domains, handle the REALITY by it self, if it has a special path(xray can detect non-Reality and forward to specified local port or other websites) it will be redirected to local 8443, NGINX. If it is the CDN sni it will be redirected to NGINX(these are websocket connections).
Real REALITY connections are going through sslh-xray way. [ client <--> sslh:443 <--> xray:4443 | check if it is authentic REALITY request ]
NGINX will perform path based routing, decipher and return connections to xray local ports opened by it's inbounds. [ client <--> sslh:443 <--> xray:4443 <--> nginx:8443 <--> xray:inbound's_local_port ]
NGINX will show vpn control pannel by getting /special-path/ in url. [ client <--> sslh:443 <--> xray:4443 <--> nginx:8443 <--> x-ui:panel_port ]
MTProxy [ client <--> sslh:443 | check if sni == zula.ir <--> mtproxy:5443 ]
My /etc/sslh.cfg:
P.S I used the commented lines without third and fourth lines, it was okay but tested this new one. **** domains are REALITY(CDN-OFF) domain and CDN-ON domain. zula.ir is the fake-tls handshake site of mtproxy.