V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  yaocf  ›  全部回复第 1 页 / 共 2 页
回复总数  23
1  2  
2 小时 17 分钟前
回复了 yaocf 创建的主题 Linux Traefik 代理 smtps 和 imaps 等邮箱协议
按照官方的配置: https://mailu.io/master/reverse.html
它可能还缺少了一个 tls.passthrough=true

也就是 traefik 只负责路由,并不负责解析 tls 。

不知道是不是能:client->traefik 代理的 smtps ( sni:mail.real.domain )->traefik 去掉 tls 层->mailu 上的 smtp (最好是 traefik 能把主机名改成 mail.cdn.domain ,类似 nginx 代理的时候的`proxy_set_header Host $host;`)
2 小时 26 分钟前
回复了 yaocf 创建的主题 Linux Traefik 代理 smtps 和 imaps 等邮箱协议
@terrytw 确实说漏了,这里说的反代所有的 https 服务是反代的 traefik 的 dashboard 、mailu 的 front 界面,他们都是 https 的服务。并没有反代其它协议。
real.domain 没有反代是说的 smtp 、imap 之类的服务。

但是实际上,通过 real.domain 域名对应的子域名也可以访问这些 https 服务,real.domain 上有一个总的 nginx 做了这些 https 服务的 sni 分流。

比如 mailu-front.real.domain ( nginx->mailu 前端) 和 mailu-front.cdn.domain ( cloudflare->nginx->mailu 前端),访问的都是同一个内容。
2 小时 32 分钟前
回复了 yaocf 创建的主题 Linux Traefik 代理 smtps 和 imaps 等邮箱协议
邮箱地址的域名用的是 cdn.domain (它比较短,也比较好记)。按照 mailu 的配置,邮箱服务器的地址默认是 mail.cdn.domain 。但是这个地址属于 cdn.domain ,cdn.domain 域名是整个托管给了 cloudflar 的(它不处理 smtp 和 imap 等服务)。为了保护 real.domain 主机,并不希望 cdn.domain 的任何地址被指向 real.domain 。

但是又需要在公网连接到邮箱服务。所以想知道这么做是不是可以行。

按理说应该是没问题的,更多公共邮箱的邮件服务器和邮箱地址域名都是不一致的。
2 小时 37 分钟前
回复了 yaocf 创建的主题 Linux Traefik 代理 smtps 和 imaps 等邮箱协议
@terrytw 对,`cdn.domain`是被 cloudflare 托管并开启了小云朵的,`real.domain`是对应的真实的主机。mailu 和 traefik 以及 nginx 都是 real.domain 的真实主机中的 docker 服务。
2 小时 41 分钟前
回复了 yaocf 创建的主题 Linux Traefik 代理 smtps 和 imaps 等邮箱协议
@yinmin
抱歉,没考虑到这种情况。

`cdn.domain`和`real.domain`不是同一个根域名。
写成`mail.real_domain`和`mail.real_domain`可能会容易理解一点。
3 小时 11 分钟前
回复了 yaocf 创建的主题 Linux Traefik 代理 smtps 和 imaps 等邮箱协议
也就是,如果使用 mail.cdn.domain 在公网连接邮件服务,还是会走到 cloudflare 的然后无响应(不用管收信。cloudflare 的邮件路由会把邮件转给指定邮箱)。
但是用 mail.real.domain 是可以正常连接到邮件服务的。

发信也是配置了中继( Brevo ),所以,除非是知道 real.domain ,以及 mail.real.domain ,否则,是无法对 real.domain 发起攻击的。
3 小时 16 分钟前
回复了 yaocf 创建的主题 Linux Traefik 代理 smtps 和 imaps 等邮箱协议
@terrytw 就是因为这个原因,所以,希望通过 real.domain 去公网访问邮件服务。
也就是按照正常流程,登录邮件客户端填写如下:

地址: [email protected]
服务器地址:mail.cdn.domain
端口:。。。。。。


希望可以是:
地址 [email protected]
服务器地址:mail.real.domain
端口:。。。。。。
6 小时 52 分钟前
回复了 yaocf 创建的主题 Linux Traefik 代理 smtps 和 imaps 等邮箱协议
另外,有没有啥好的工具可以 debug 或者显示 imap/imaps 协议协商和验证的全过程的?也希望各位大大不吝分享。
折腾了昨天一个下午加今天半个上午,总结一下:
- DNSSEC 导致 admin 起不来的问题。问题原因在于国内的公共 dns 都不支持解析 dnssec 的请求。并且,如果是直接用 udp 53 请求 dns ,还会被劫持到运营商的 dns 服务器,就更惨了。
- 通过抓包,mailu 的 admin 容器只验证了 example.org 的 dnssec ,总共请求了两个域名:redis ,example.org 。理论上来说应该是可以单独转发这个 example.org 域名到一个支持 dnssec 的服务器的( Dnsmasq 设置转发 example.org 域名,然后 docker 开个 dns-over-https 容器作为转发)。

整体步骤:开启 Openwrt 中 Dnsmasq 的 dnssec ,在代理工具中将所有 dns 请求全部通过 DOH 转发出去,是可以正常让 admin 起来并且正常打开 mailu 完全启动后的 web 页面,以及正常登录的。
@bettercallbalds 期待不重复题库。
Veruca Salt paused, her eyes locking with the assembly before her. A moment of silence hung in the air, thick with anticipation. Then, her attention shifted, drawn to a diminutive squirrel perched at the table's edge, its paws delicately clutching a walnut.

"Very well," Veruca declared, a mischievous glint in her eye, "you shall be mine!"

With a swift motion, she extended her arms towards the unsuspecting creature. But in that infinitesimal instant, as her fingers splayed to ensnare her prize, the room erupted into a frenzy. It was as if a bolt of brown lightning had struck, electrifying the space with sudden movement. Each squirrel, previously still as a statue, sprang into action. They launched themselves from their seats, a coordinated battalion of fur and claws, converging upon her with astonishing agility.

Veruca, caught off guard by the unexpected assault, could only gasp as the furry horde descended upon her. They clambered over her arms, shoulders, and head, their tiny feet pattering against her skin, their tails flicking in her face. The room, once filled with the quiet murmur of the gentle creatures, now resounded with the chaos of chittering and scolding.

In the midst of the pandemonium, the little squirrel with the walnut remained poised, its bright eyes watching the scene unfold with a wisdom beyond its years. It seemed to understand the folly of Veruca's greed, the consequence of underestimating those deemed insignificant.

As the squirrels retreated, leaving a disheveled Veruca in their wake, the room settled once more into tranquility. The little squirrel turned away, its walnut still secure in its grasp, a silent testament to the day's unexpected lesson. Veruca, now humbled, sat amidst the calm, a newfound respect dawning within her for the creatures she had so carelessly sought to claim

Why did the squirrels swarm and scramble over Veruca?
They were trying to play a friendly game with her.
They were angry that she tried to take one of them.
They wanted to show her a new dance they learned.

这个是不是该选择`They were angry that she tried to take one of them.`
而不是答案给的`They wanted to show her a new dance they learned.`

判据:
```
"Very well," Veruca declared, a mischievous glint in her eye, "you shall be mine!"

With a swift motion, she extended her arms towards the unsuspecting creature
```
200 天前
回复了 panda7456 创建的主题 宽带症候群 IPV6 ping 通但无法访问网页
请问楼主解决了吗?
@TcDhl 大佬,这个是完全自己写的平台吗?
@yaocf pyrogram 的代码注释对这个方法的说明就是:This is the equivalent of clicking an inline button containing callback data.
找到了,可能是算是新手吧,api 文档中的 tg 专业名词太多了。
https://docs.pyrogram.org/api/methods/request_callback_answer

如题示例:
```python
await app.request_callback_answer(_id, message.id, "checkin", 0)
```
最后的 timeout 参数不知道该怎么填,不过效果已经达到了。
dart 是有反射的,只是 flutter 没有,可能是谷歌被 java 时代的反射搞怕了,flutter 禁用 dart 之后,世界一下子就安静了。
354 天前
回复了 yaocf 创建的主题 OpenWrt Openwrt/ Linux 定长 日志文件
嗯,之前理解错了,unix 可以设置的是缓冲长度(-I length TCP receive buffer length )。

至于为啥要一个定长日志,原因如下:那个进程的输出文本产生的特别快,如果直接怼到系统 log ,会导致其他进程的 log 被冲掉,但是,如果在 procd 中将输出信息重定向到文件,又担心那个文件会无限制增长。用 cron 倒是可以做到效果,但是总感觉不是很完善。
2022-07-19 16:31:02 +08:00
回复了 lxr760 创建的主题 宽带症候群 dynv6 挂掉超过 24h 了
dynv6 恢复了。

while [ `/usr/bin/curl -s -o /dev/null -w "%{http_code}" "https://dynv6.com"` -ne 200 ];
do
echo -e "$(date) \t Still down! waiting..."
sleep 300s
done
echo -e "service was online!"
/usr/lib/mylibs/noticeMeByMail "service was online!"

自动检测。
2022-07-19 11:07:30 +08:00
回复了 lxr760 创建的主题 宽带症候群 dynv6 挂掉超过 24h 了
已经 72 小时了。从周六那天就开始 500 了。
找到原因了,是防火墙区域设置里的 nat ( Ip 动态伪装)没开。
但是现象很奇怪,按理说,请求包的目的地址是 172.16.0.9 ,根据路由表它是可以正常找到路由,发到 wg0 的,wg0 应该也是可以从设置的 AllowIps 找到中继网络 B 的,中继网络 B 可以很容易地找到正确的对端 172.16.0.9 ,顶多是回来的时候,因为请求源地址(响应的目的地址) 10.0.0.106 不在 wg0 接口的网段,所以响应包会被丢弃。可为什么,我从 172.16.0.1 那台中继网络 B 中,并没有看到任何数据包???
1  2  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   5642 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 24ms · UTC 06:34 · PVG 14:34 · LAX 23:34 · JFK 02:34
Developed with CodeLauncher
♥ Do have faith in what you're doing.