-
Notifications
You must be signed in to change notification settings - Fork 209
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Feature Request] Connect to company network #565
Comments
Thanks for opening this issue! |
|
got it thanks! btw, some routing rules not effective can you help check?
I already add rule like:
but it seems not working, from the log it seems still go to direct, I tried to replace |
I even tried to put this rule at the top line of routing, still the same. For global settings I use the same as the example. so really confusing... |
@marsjane This is dns; its target is 223.5.5.5. |
emm it is a website... I did some more tests, can you help check the results?
but for the
it ignore the rule then go to the fallback group which is my HK proxy Could you help check which part is wrong here? Thank! |
This seems a known problem fixed in #542. |
Thanks, but I just checked my version is 0.7.0rc1, and I also tried the git version:
so key is why the |
I'll look into it. |
Thanks, because seems the |
试试加个空格 domain(keyword: company) -> CM |
这个看起来是 sniffed 为空,所以 routing 没有生效 |
刚刚试了一下加了空格:
但是好像还是不行,我用curl -I 测试了一下,log更干净一些,发现了一些问题,这是完整的相关log对比:
对 gitlab.com, 有三行很不一样:
这之后就成功应用到了那个CM了:
但是 gitlab.company,没有 TRACE Update相关的 log, 能看出来什么问题么? |
哦哦哦那这个应该怎么弄啊? |
看起来并没有“Update DNS record cache _qname=gitlab.company” 相关的字样,猜测这个域名应该交给一个内网 dns 才能解析出结果,你可以添加一个可以解析该域名的 dns upstream,对这个域名转发到该 dns 进行查询 |
感觉是这样了!以前在别的工具里面我用的这个是没问题的:
这个不知道怎么转换过来呢 我看tls和https似乎都还不支持?我试了一下用tcp+udp://223.5.5.5:53,然后加了个条件,确实走了这个DNS,但是好像也没解析出来:
这方面我着实不太懂,有没有什么建议的dns upstream呀? |
@marsjane dns routing 里用 qname(suffix:gitlab.company)->asis |
asis需要定义么?我目前加的是 |
@marsjane 不用定义。asis就是请求的时候用什么就用什么,上述就是去用 192.168.50.1:53,你可以验证 dig gitlab.company @192.168.50.1 看看有没有结果 |
@marsjane 在 dae 关闭的情况下 dig 测试 |
这个dig确实没问题,我按照你说的试了,确实它走的是192.168.50.1:53,但是好像依旧没有结果==
为啥dig可以这里又不可以了呢 |
好像是update DNS record cache有了但是还是没有 |
这个update DNS record cache里面没有answer,所以问题应该在192.168.50.1上? |
那还有什么方式可以不用这个192.168.50.1么?为啥我上面提到的别的软件的那种设置是可以的?不知道那个是通过什么dns完成的 |
This comment was marked as outdated.
This comment was marked as outdated.
我收到了你的邮件,看起来手动 dig 也是没有 a/aaaa 记录的,http 代理可以是因为直接发送了域名到远端。
|
好的,多谢两位,我试一下!话说如何看公司dns ip啊,我去内部机器上看了 |
@marsjane 直接 tcpdump -i any dst port 53 -n 然后新开个终端 nslookup 看看目标地址是多少(有可能有缓存,等缓存结束之后再测) |
@marsjane 另一个方法是 lsof -i:53 看看监听 53 的进程是谁,找到对应的配置文件看看上游 dns 是多少 |
tcpdump我似乎没有权限执行 我不是管理员,那个lsod -i :53我跑了一下 啥输出也没有,感觉不知道是不是也是权限不足所以看不到 |
@marsjane 1. 问问公司 dns 服务器是多少
|
@marsjane 哦对了,127.0.0.53也没关系,可以直接当成 upstream |
|
@marsjane 你要按照上面我说的那几个步骤,不能单加个 upstream。 |
我目前这么设置的对不:
然后它的报错是:
不过我也确实没看到127.0.0.53走我这个CM节点的log,好像 |
@mzz2017 所以为啥 |
发一下比较全的配置? |
|
pname(NetworkManager) -> direct 改成 pname(NetworkManager,systemd-resolved) -> direct 试试 因为127.0.0.53:53是systemd-resolved |
啊试了一下,还是一样的报错 |
@marsjane 感觉没什么问题,我得抽空复现一下 |
谢谢! |
@marsjane 你的 node 是 http 的,不支持 udp,有两个解决方案:
|
啊tcp可以了!多谢!! |
好巧,我也是遇到了节点为 https proxy 时,dns 设置 udp 会报错的情况,没想到刚过来搜 issue 就找到解决方案了哈哈 |
hi @mzz2017 , 这个办法确实我可以上内部网站了 但是似乎还是会遇到一些问题 就是一些操作的话发送回网站好像会有问题,不知道这个log是什么意思,大概就是我在网站上进行一个提交 就会卡住,也不太清楚是卡在哪里了
|
现在发现一些诸如上传文件之类的操作也一样是报上面这个错,正常的浏览都没问题 |
|
emm这个看不到服务端的日志要是无法debug的话那也没事,我现在暂时先用其他软件代替着用吧,感觉确实是特殊需求 |
Greetings
No response
Feature Request
Hi,thanks for this great work, I've been going through most of the documentation and plan to migrate to dae. However, I have several questions:
/etc/dae
? Is it possible to put it under other place, like~/.config/dae
?/etc/dae
, which permission should it be? As I want to add several new files to use the separated configuration as shown in Config Examples #81 (comment)Is it necessary to do
sudo chmod -R 0640 /etc/dae
? I just wonder is there any config file permission requirement for dae to run.Can you help clarify these?
Use Cases
other places for config files
separated configuration
Potential Benefits
clear understanding about config location and permission requirements
The text was updated successfully, but these errors were encountered: