YSC 的频道
今天把msys2的shell换成了zsh,安装了Oh My Zsh以及zsh-autosuggestions和zsh-syntax-highlighting这两个插件,主题使用的是powerlevel10k 个人不推荐使用其他主题,因为其他主题读取git信息时是启动新进程获取的,在Windows下很慢。而powerlevel10k是在后台运行gitstatusd进程,速度极快!而且powerlevel10k还有异步加载插件的功能,可以缩短启动到可输入命令的时间。 这套配置在Windows下速度也是挺快的,感觉上比我多年前…
顺带一提,刚刚简单试了下最新的Oh My Posh,感觉变快了很多,喜欢PowerShell的朋友也可以试试。
start-ssh-pageant.sh
567 B
刚刚写了个msys2启动ssh-pageant的脚本,主要是因为两个问题:
一是ConEmu会等待当前控制台下所有进程退出了才关闭标签页。因此直接启动的话,在退出shell时因为ssh-pageant没有退出,标签页就不会关闭,只有脱离当前控制台才能实现真正的后台运行。
二是ssh-pageant在sock file存在时会尝试连接,如果此时进程不存在了就要等几秒超时,通过脚本提前检测PID对应的进程是否存在可以缓解此问题。(不能100%解决,因为PID可能被复用了)
使用方法:在
一是ConEmu会等待当前控制台下所有进程退出了才关闭标签页。因此直接启动的话,在退出shell时因为ssh-pageant没有退出,标签页就不会关闭,只有脱离当前控制台才能实现真正的后台运行。
二是ssh-pageant在sock file存在时会尝试连接,如果此时进程不存在了就要等几秒超时,通过脚本提前检测PID对应的进程是否存在可以缓解此问题。(不能100%解决,因为PID可能被复用了)
使用方法:在
~/.bashrc (Bash) 或 ~/.zshrc (Zsh) 中加入 source /path/to/start-ssh-pageant.sh (/path/to为start-ssh-pageant.sh所在位置)在试用了一下Windows Terminal之后,我打算扔掉ConEmu了。
后者在配合msys2/wsl使用时问题很多。按照ConEmu官方推荐的做法,msys2/wsl应该使用其提供的connector,但是使用connector并连接ssh时会出现终端尺寸锁死在80x24(打开nano之类的程序,终端右半部分是黑的,只有左上角80x24有显示东西),滚动条buffer不可用(输出的东西超过屏幕buffer就被截断了,滚动条一直不变长),不支持24bit color,以及性能很差(执行curl --help all等一次性输出很长文本的情况,可以明显地看到它在那滚呀滚,Windows Terminal是瞬间显示完)。
如果不使用connector,情况反而有好转(不过估计是Windows10的控制台有改进,Win7下可能还是得用connector),除了不支持24bit、性能差的问题还在,其他问题都没了,但是在使用tmux等支持鼠标控制的程序时,鼠标进行操作就会卡死。
不过Windows Terminal还是缺少一些细节功能,比如在msys2中粘贴本地路径时自动转换成Unix风格。
后者在配合msys2/wsl使用时问题很多。按照ConEmu官方推荐的做法,msys2/wsl应该使用其提供的connector,但是使用connector并连接ssh时会出现终端尺寸锁死在80x24(打开nano之类的程序,终端右半部分是黑的,只有左上角80x24有显示东西),滚动条buffer不可用(输出的东西超过屏幕buffer就被截断了,滚动条一直不变长),不支持24bit color,以及性能很差(执行curl --help all等一次性输出很长文本的情况,可以明显地看到它在那滚呀滚,Windows Terminal是瞬间显示完)。
如果不使用connector,情况反而有好转(不过估计是Windows10的控制台有改进,Win7下可能还是得用connector),除了不支持24bit、性能差的问题还在,其他问题都没了,但是在使用tmux等支持鼠标控制的程序时,鼠标进行操作就会卡死。
不过Windows Terminal还是缺少一些细节功能,比如在msys2中粘贴本地路径时自动转换成Unix风格。
YSC 的频道
在试用了一下Windows Terminal之后,我打算扔掉ConEmu了。 后者在配合msys2/wsl使用时问题很多。按照ConEmu官方推荐的做法,msys2/wsl应该使用其提供的connector,但是使用connector并连接ssh时会出现终端尺寸锁死在80x24(打开nano之类的程序,终端右半部分是黑的,只有左上角80x24有显示东西),滚动条buffer不可用(输出的东西超过屏幕buffer就被截断了,滚动条一直不变长),不支持24bit color,以及性能很差(执行curl --help…
才夸了没多久,最近又遇到bug了,连接ssh后,按Ctrl+C会停掉ssh进程,而不是传递给目标机器。去搜索了下,似乎除了mintty,其他终端都是走Console Host的,就会遇到许多问题。现在还是先用着mintty吧……
小米平板5底下会显示全面屏手势提示线,然后设置里没有开关关闭。按照网上的方法,可以跟小爱同学说“全面屏”打开另一个全面屏设置页面,然后就有“隐藏手势提示线”的开关了。
然而重启后又会显示出手势提示线,经过测试发现“隐藏手势提示线”开关控制的是 global settings 下的
我的解决方法是加一个 Magisk script,等待 boot completed 然后
具体代码如下:
没有 Magisk 的用户,可以考虑用 Tasker 等工具,开机时修改一下
然而重启后又会显示出手势提示线,经过测试发现“隐藏手势提示线”开关控制的是 global settings 下的
hide_gesture_line,进一步反编译发现系统桌面会在启动时检查一下设备是不是平板,是的话会把 hide_gesture_line 设置成0。我的解决方法是加一个 Magisk script,等待 boot completed 然后
settings put global hide_gesture_line 1 。具体代码如下:
#!/system/bin/sh可以做成模块,也可以直接放到
{
until [[ "$(getprop sys.boot_completed)" == "1" ]]; do
sleep 1
done
settings put global hide_gesture_line 1
}&
/data/adb/service.d,记得加上执行权限。没有 Magisk 的用户,可以考虑用 Tasker 等工具,开机时修改一下
hide_gesture_line。Node.js的QUIC支持有了新的动静
https://github.com/nodejs/node/pull/44325
https://github.com/nodejs/node/pull/44325
GitHub
src: quic by jasnell · Pull Request #44325 · nodejs/node
Updated alternatiive to #38233 ...
Significant changes here. This focuses entirely on the internal API surface and does not expose any public API yet. That is intentional to allow us to work throug...
Significant changes here. This focuses entirely on the internal API surface and does not expose any public API yet. That is intentional to allow us to work throug...
之前搬家了,昨天把联通宽带迁移了过来,又被强制花钱买了个新光猫(联通不给在我有光猫的情况下不买然后减钱),光猫是华为的HG8120C。
光猫背面写着用户名密码是root和admin,但是通过网页登录进去缺少很多选项。按照网上的方法用telnet备份配置文件后得知超级管理员用户名和密码是telecomadmin和admintelecom,也是挺搞笑的。
telnet里的shell是假的,搜索了一圈居然发现有获得root shell的方法!整个过程很精彩,推荐阅读:
https://blog.leexiaolan.tk/pwn-huawei-hg8120c-ont-via-uart-part-1.html
光猫背面写着用户名密码是root和admin,但是通过网页登录进去缺少很多选项。按照网上的方法用telnet备份配置文件后得知超级管理员用户名和密码是telecomadmin和admintelecom,也是挺搞笑的。
telnet里的shell是假的,搜索了一圈居然发现有获得root shell的方法!整个过程很精彩,推荐阅读:
https://blog.leexiaolan.tk/pwn-huawei-hg8120c-ont-via-uart-part-1.html
因为有透明代理的需求,但又不想折腾路由器全局代理,于是调查了一下 sniproxy (C语言实现的那个) 的方案。sniproxy 本身不支持走 SOCKS 代理,需要套一层 proxychains,然后由于 sniproxy 是用 UDP 解析域名,proxychains 又不支持 UDP 代理,于是再加上 https-dns-proxy 走代理使用 DoH 解析 DNS。最终方案是基于Alpine Linux,可以运行在 Docker 或 WSL1 中。WSL2 未测试,建议使用 WSL1,因为可以和主机共享网络。
GitHub 地址 https://github.com/ysc3839/sniproxy-socks
Docker Hub 地址 https://hub.docker.com/r/ysc3839/sniproxy-socks
在 WSL 中使用,需要手动下载 releases 中的 sniproxy-socks-rootfs.tar.gz,然后在 cmd 中执行:
然后执行
启动后在文件管理器中打开
执行
执行
后续会考虑写个脚本自动下载并安装到 WSL 中。(已取消)
要登录时自动运行,可以运行
GitHub 地址 https://github.com/ysc3839/sniproxy-socks
Docker Hub 地址 https://hub.docker.com/r/ysc3839/sniproxy-socks
在 WSL 中使用,需要手动下载 releases 中的 sniproxy-socks-rootfs.tar.gz,然后在 cmd 中执行:
mkdir %localappdata%\wsl\sniproxy-socks其中
wsl --import sniproxy-socks %localappdata%\wsl\sniproxy-socks sniproxy-socks-rootfs.tar.gz
sniproxy-socks 是 WSL 的 distro name (或者叫容器名更加贴切),%localappdata%\wsl\sniproxy-socks 是安装位置,这两个选项都可以随意设置。然后执行
wsl -d sniproxy-socks /entrypoint.sh 会自动在后台运行。启动后在文件管理器中打开
\\wsl$\sniproxy-socks 可修改配置文件。执行
wsl -t sniproxy-socks 停止运行。执行
wsl --unregister sniproxy-socks 卸载。要登录时自动运行,可以运行
shell:startup 打开“启动”文件夹,新建 start-sniproxy.jse 并写入:new ActiveXObject('WScript.Shell').Run('wsl -d sniproxy-socks /entrypoint.sh',0)GitHub
GitHub - dlundquist/sniproxy: Proxies incoming HTTP and TLS connections based on the hostname contained in the initial request…
Proxies incoming HTTP and TLS connections based on the hostname contained in the initial request of the TCP session. - dlundquist/sniproxy
YSC 的频道
因为有透明代理的需求,但又不想折腾路由器全局代理,于是调查了一下 sniproxy (C语言实现的那个) 的方案。sniproxy 本身不支持走 SOCKS 代理,需要套一层 proxychains,然后由于 sniproxy 是用 UDP 解析域名,proxychains 又不支持 UDP 代理,于是再加上 https-dns-proxy 走代理使用 DoH 解析 DNS。最终方案是基于Alpine Linux,可以运行在 Docker 或 WSL1 中。WSL2 未测试,建议使用 WSL1,因为可以和主机共享网络。…
朋友推荐了一个 Golang 实现的 sniproxy,直接支持 SOCKS,就不需要这么麻烦了,也能原生支持 Windows。
https://github.com/NiceLabs/go-sniproxy
我的项目在补全剩下的脚本及说明后可能就不继续维护了,就当多一个选择吧。
https://github.com/NiceLabs/go-sniproxy
我的项目在补全剩下的脚本及说明后可能就不继续维护了,就当多一个选择吧。
GitHub
GitHub - NiceLabs/go-sniproxy: Proxies incoming HTTP and TLS connections based on the hostname contained in the initial request…
Proxies incoming HTTP and TLS connections based on the hostname contained in the initial request of the TCP session. - NiceLabs/go-sniproxy
YSC 的频道
因为有透明代理的需求,但又不想折腾路由器全局代理,于是调查了一下 sniproxy (C语言实现的那个) 的方案。sniproxy 本身不支持走 SOCKS 代理,需要套一层 proxychains,然后由于 sniproxy 是用 UDP 解析域名,proxychains 又不支持 UDP 代理,于是再加上 https-dns-proxy 走代理使用 DoH 解析 DNS。最终方案是基于Alpine Linux,可以运行在 Docker 或 WSL1 中。WSL2 未测试,建议使用 WSL1,因为可以和主机共享网络。…
GitHub
Release v2 · ysc3839/sniproxy-socks
Contribute to ysc3839/sniproxy-socks development by creating an account on GitHub.
YSC 的频道
因为有透明代理的需求,但又不想折腾路由器全局代理,于是调查了一下 sniproxy (C语言实现的那个) 的方案。sniproxy 本身不支持走 SOCKS 代理,需要套一层 proxychains,然后由于 sniproxy 是用 UDP 解析域名,proxychains 又不支持 UDP 代理,于是再加上 https-dns-proxy 走代理使用 DoH 解析 DNS。最终方案是基于Alpine Linux,可以运行在 Docker 或 WSL1 中。WSL2 未测试,建议使用 WSL1,因为可以和主机共享网络。…
又发现问题了,wsl后台运行的进程好像会被停止,必须要有一个前台的进程……
可以临时把前面提到的
可以临时把前面提到的
start-sniproxy.jse 改成:new ActiveXObject('WScript.Shell').Run('wsl -d sniproxy-socks /entrypoint.sh -f',0)我编写了个编译 nft-fullcone 内核模块的脚本,可编译适用于 OpenWrt 官方内核的模块。
编译出的模块的内核 vermagic 和 OpenWrt 官方内核是一致的,因此可以直接在 OpenWrt 官方镜像中安装。
编译流程参考了 https://hamy.io/post/0015/how-to-compile-openwrt-and-still-use-the-official-repository/
patch 文件修改自 https://github.com/wongsyrone/lede-1
使用 GitHub Actions 自动编译 https://github.com/ysc3839/openwrt-official-builds-fullcone/actions
https://github.com/ysc3839/openwrt-official-builds-fullcone
编译出的模块的内核 vermagic 和 OpenWrt 官方内核是一致的,因此可以直接在 OpenWrt 官方镜像中安装。
编译流程参考了 https://hamy.io/post/0015/how-to-compile-openwrt-and-still-use-the-official-repository/
patch 文件修改自 https://github.com/wongsyrone/lede-1
使用 GitHub Actions 自动编译 https://github.com/ysc3839/openwrt-official-builds-fullcone/actions
https://github.com/ysc3839/openwrt-official-builds-fullcone
YSC 的频道
我编写了个编译 nft-fullcone 内核模块的脚本,可编译适用于 OpenWrt 官方内核的模块。 编译出的模块的内核 vermagic 和 OpenWrt 官方内核是一致的,因此可以直接在 OpenWrt 官方镜像中安装。 编译流程参考了 https://hamy.io/post/0015/how-to-compile-openwrt-and-still-use-the-official-repository/ patch 文件修改自 https://github.com/wongsyrone/lede…
已更新,加入了修改过的 luci-app-firewall
https://github.com/ysc3839/openwrt-official-builds-fullcone/releases/tag/v22.03.2-2
https://github.com/ysc3839/openwrt-official-builds-fullcone/releases/tag/v22.03.2-2
GitHub
Release v22.03.2-2 · ysc3839/openwrt-official-builds-fullcone
Contribute to ysc3839/openwrt-official-builds-fullcone development by creating an account on GitHub.
阿里云的云服务器要安装自定义系统,只能传一个系统盘镜像上去,假如手头上只有iso怎么办呢?
实测可以把iso作为系统盘镜像传上去,再添加一个数据盘,启动后把系统安装到数据盘里,再开一台机子,挂载刚才的系统盘和数据盘,把数据盘的内容dd回系统盘,就能正常使用了。
原理是绝大多数Linux的iso镜像都是混合镜像,能当成硬盘镜像来用,包含MBR,在传统BIOS模式下能直接启动。即使遇到了一些不是混合镜像的系统(比如银河麒麟),使用UEFI模式也能启动,具体原理不明,猜测是UEFI也能认硬盘里面的光盘文件系统。
实测可以把iso作为系统盘镜像传上去,再添加一个数据盘,启动后把系统安装到数据盘里,再开一台机子,挂载刚才的系统盘和数据盘,把数据盘的内容dd回系统盘,就能正常使用了。
原理是绝大多数Linux的iso镜像都是混合镜像,能当成硬盘镜像来用,包含MBR,在传统BIOS模式下能直接启动。即使遇到了一些不是混合镜像的系统(比如银河麒麟),使用UEFI模式也能启动,具体原理不明,猜测是UEFI也能认硬盘里面的光盘文件系统。
nginx 的默认服务器这么写,可以实现 http 无 Host 时直接断开连接,https 无 SNI 时返回
ERR_SSL_UNRECOGNIZED_NAME_ALERT,同时 http 请求错误地发到 https 端口时也会直接断开连接。server {
server_name _;
listen 80 default_server;
listen 443 ssl http2 default_server;
ssl_reject_handshake on;
error_page 497 =444 /;
return 444;
}
YSC 的频道
nginx 的默认服务器这么写,可以实现 http 无 Host 时直接断开连接,https 无 SNI 时返回 ERR_SSL_UNRECOGNIZED_NAME_ALERT,同时 http 请求错误地发到 https 端口时也会直接断开连接。 server { server_name _; listen 80 default_server; listen 443 ssl http2 default_server; ssl_reject_handshake on; error_page…
nginx 内部的错误码 497 代表 http 请求错误地发到 https 端口。还可以利用这个错误码实现重定向到 https:
444也是 nginx 的内部错误码,代表直接断开连接,仅适用于 http 请求,不能用于 https 请求。
error_page 497 =301 https://$server_name$request_uri;444也是 nginx 的内部错误码,代表直接断开连接,仅适用于 http 请求,不能用于 https 请求。
Debian 系的 nginx 版本十分落后 (Ubuntu 23.04 的 nginx 版本只有 1.22.0),且缺少 brotli 插件。而 nginx 官方提供的包版本虽然新,但是 brotli 插件属于 NGINX Plus 付费功能,并没有提供。
因此看上去要用上新版 nginx+brotli,似乎都免不了要编译。然而 Alpine Linux 的官方源里面正好就有新版 nginx 和 brotli 插件。
于是就写了个 Docker Compose 配置,把 PID 和网络等设为不隔离,以主系统上的
同时我在使用 go-acme/lego 来获取 SSL 证书,配合 systemd timer 定时执行,同样以
相关配置文件将会在后续整理后发布到 GitHub。
因此看上去要用上新版 nginx+brotli,似乎都免不了要编译。然而 Alpine Linux 的官方源里面正好就有新版 nginx 和 brotli 插件。
于是就写了个 Docker Compose 配置,把 PID 和网络等设为不隔离,以主系统上的
www-data 用户运行。同时我在使用 go-acme/lego 来获取 SSL 证书,配合 systemd timer 定时执行,同样以
www-data 用户运行,这样可以直接发送信号 reload nginx。相关配置文件将会在后续整理后发布到 GitHub。
YSC 的频道
Debian 系的 nginx 版本十分落后 (Ubuntu 23.04 的 nginx 版本只有 1.22.0),且缺少 brotli 插件。而 nginx 官方提供的包版本虽然新,但是 brotli 插件属于 NGINX Plus 付费功能,并没有提供。 因此看上去要用上新版 nginx+brotli,似乎都免不了要编译。然而 Alpine Linux 的官方源里面正好就有新版 nginx 和 brotli 插件。 于是就写了个 Docker Compose 配置,把 PID 和网络等设为不隔离,以主系统上的…
顺带一提,Alpine Linux 中 nginx 的默认配置结构很清晰,子配置文件都放在
http.d 目录内,不像 Debian 系搞什么 sites-available,太麻烦了nginx 配置了 brotli 插件后并作为反向代理时,可能会发现浏览器收到的响应仍然是使用 gzip 压缩。这个问题有两种情况:
一种是没有使用 https,Chrome 浏览器只会对 https 请求启用 brotli 压缩,因为中间可能有某些透明代理服务器不支持。
另一种是 nginx 反向代理的上级服务器支持且只支持 gzip 压缩,nginx 把客户端请求发上去后,上级服务器发现客户端支持 gzip 就返回了 gzip 压缩后的数据,于是 nginx 就没法使用 brotli 压缩了。
解决办法是在 nginx 配置中加上
一种是没有使用 https,Chrome 浏览器只会对 https 请求启用 brotli 压缩,因为中间可能有某些透明代理服务器不支持。
另一种是 nginx 反向代理的上级服务器支持且只支持 gzip 压缩,nginx 把客户端请求发上去后,上级服务器发现客户端支持 gzip 就返回了 gzip 压缩后的数据,于是 nginx 就没法使用 brotli 压缩了。
解决办法是在 nginx 配置中加上
proxy_set_header Accept-Encoding ""; 让上级服务器以为客户端不支持压缩,直接返回未压缩的数据,然后 nginx 就会自动压缩了。Linux 使用 WireGuard 进行内网穿透,可以在公网机子上不开启 NAT,把内网机子上 WireGuard 的 allowed ips 设置成
这样设置后内网机子能拿到外部访问者的 IP 地址,同时沿原路发回数据包。这个方案也可以用于其他多网络的情况。
0.0.0.0/0,然后按如下设置 ip rule:ip route add default via $GW dev wg0 table 20其中
ip rule add from $IP table 20
$IP 是 WireGuard 接口的 IP,因为 WireGuard 是隧道协议,不需要 gateway,$GW 可以写 0.0.0.0,或者直接去掉 via $GW。20 是 table id,可以写任意整数。这样设置后内网机子能拿到外部访问者的 IP 地址,同时沿原路发回数据包。这个方案也可以用于其他多网络的情况。
YSC 的频道
Linux 使用 WireGuard 进行内网穿透,可以在公网机子上不开启 NAT,把内网机子上 WireGuard 的 allowed ips 设置成 0.0.0.0/0,然后按如下设置 ip rule: ip route add default via $GW dev wg0 table 20 ip rule add from $IP table 20 其中 $IP 是 WireGuard 接口的 IP,因为 WireGuard 是隧道协议,不需要 gateway,$GW 可以写 0.0.0.0,或者直接去掉…
如果使用 NetworkManager,可以把以下脚本放到
请按需要修改其中的
/etc/NetworkManager/dispatcher.d/ 并加上执行权限,实现自动设置 ip rule:#!/bin/bash
[ "$1" == "wg0" ] || exit
TABLE_ID=20
function update_routing_table() {
IP_ADDR="${IP4_ADDRESS_0%/*}"
ip route add default via ${IP4_GATEWAY} dev ${DEVICE_IP_IFACE} table ${TABLE_ID}
ip rule add from ${IP_ADDR} table ${TABLE_ID}
}
function clear_routing_table() {
ip rule del lookup ${TABLE_ID}
ip route flush table ${TABLE_ID}
}
case "$2" in
up)
update_routing_table
;;
down)
clear_routing_table
;;
*)
;;
esac
请按需要修改其中的
[ "$1" == "wg0" ]。这个脚本修改自 https://gist.github.com/dcode/bbf990ea781bed1e42d39e2351b6c432