搜索到
289
篇与
的结果
-
-
truenas scale 之容器桥接不成功的问题 0x1 为什么桥接 其实如果是使用普通的http服务，单个ip足够使用了，那么就使用 nginx、treafik等服务直接放在前端做代理即可，通过不通端口或者不通域名定位到后端。 但是这里有一个多nfs服务端的需求，首先nfs服务端端口不好修改，再就是客户端又需要修改挂载端口，如果使用端口映射的方式那显然比较难以使用，所以多个公开ip是最好的方式。而实现用户直接访问（容器直接配置公众ip）的网络方式就是桥接，后续也可以使用到虚拟机上 0x2 如何配置 TrueNas版本：TrueNAS-SCALE-23.10.0.1 truenas网络接口这块的功能上其实做的非常好了，不过如果网络这块使用不多的人，一开始看的时候比较难以接收。比如上面已经有一个我的网卡了，那我继续add还做什么呢？以及展开的一些选项又能做什么用途呢？其实这些都是一些需要自己定制的功能，如果会，那么比较有用，如果不会，则一头雾水。 桥接配置方式 其实也不复杂，主要流程如下： 把目前的主接口ip拿掉，如果设置的dhcp，则关闭，之后保存（退出到外层后不要点测试） 创建（add）一个桥接类型的网络，设置名称，需要以br开头后面直接接数字，然后成员选择主接口，再设置之前主接口的ip，保存 现在可以点击测试了，如果没有问题，则会在60秒内生效，然后出现保存按钮，点击即可 第三步没有问题，则图标会变成链接状态，并且基本上跟主接口同步 但就是在这短短的几步出现了问题，点击测试后页面一直没有刷新，并且不再能够ping通ip，一直等到超时回滚后才刷新出页面，接下来查阅了大量资料后做了如下方法的尝试： 分别在web和终端中强制设置并且保存，无法访问web ui，无法ping通地址，最终无效 怀疑是mac地址不同导致无法访问，于是配置后在同网段的机器中访问，仍然不行 查阅资料后发现官方人员说启动的虚拟机或者app会影响，又关闭了整个app服务，取消了池，但重新配置仍失败 在这个过程中重启了很多次truenas，一步一步对比官方提供的操作创建了很多次接口，甚至顺序上也做了一些微小的调整，也咨询了一些使用的人，都没有给出有用的答案，最后都怀疑是truenas的bug了。 0x3 曙光 在查询了大量的类似问题之后，终于注意到了一段话。对方没有明确的说解决方案，但是说在虚拟化的平台中使用Truenas会有一些局限性。于是乎我恍然大悟，是否当前的 esxi 平台网络上有问题呢？ 登录到此esxi主机，依次找到 配置 -> 网络 -> 虚拟交换机，然后编辑，找到安全，可以看到当前的混杂模式是拒绝，修改为接收 再次返回 Truenas 配置桥接接口成功 0x4 其他 此次问题为虚拟机宿主机网络配置问题导致，如果后续实际迁移到物理机，应该是没有此问题的
-
h3c无线之雷达信道的影响 0x1 现象 部分区域的同事基本上同时断网（漫游到其他AP上），同时观察此AP，发现指示灯为绿色常亮，过一段时间（大概数十秒或数分钟）后恢复正常。 架构及型号： AC： MSG360-20 AP: WAP712c、WAP712C-LI AC接三层下，AC下联POE交换机，AP接入POE交换机，所有配置基本上都是型号模板配置，所以应该不是配置问题，因为目前基本上相同的配置，只收到此AP有故障现象。 0x2 初步排查 通过对比时间，AP指示灯状态，再检索日志，发现如下异常： Dec 4 20:10:15 2023 ac %%10APMGR/6/APMGR_LOG_CHANNELCHANGE: -DevIP=192.168.192.21; Channel of Radio 1 on AP 2f_yanfa_waibu changed from 161 to 60, Reason: Radar channel recover. Dec 4 20:10:16 2023 ac %%10STAMGR/6/STAMGR_CLIENT_OFFLINE: -DevIP=192.168.192.21; Client f46a-dd6e-2ced went offline from BSS 943b-b04d-3f20 with SSID Succez on AP 2f_yanfa_waibu Radio ID 1. State changed to Unauth. Reason:AP triggered (channel changed). Dec 4 20:10:16 2023 ac %%10STAMGR/6/STAMGR_CLIENT_OFFLINE: -DevIP=192.168.192.21; Client e00a-f671-e9f1 went offline from BSS 943b-b04d-3f20 with SSID Succez on AP 2f_yanfa_waibu Radio ID 1. State changed to Unauth. Reason:AP triggered (channel changed). Dec 4 20:10:16 2023 ac %%10STAMGR/6/STAMGR_CLIENT_OFFLINE: -DevIP=192.168.192.21; Client acbc-3278-d889 went offline from BSS 943b-b04d-3f20 with SSID Succez on AP 2f_yanfa_waibu Radio ID 1. State changed to Unauth. Reason:AP triggered (channel changed). Dec 4 20:10:16 2023 ac %%10STAMGR/6/STAMGR_CLIENT_OFFLINE: -DevIP=192.168.192.21; Client c889-f3ac-2271 went offline from BSS 943b-b04d-3f20 with SSID Succez on AP 2f_yanfa_waibu Radio ID 1. State changed to Unauth. Reason:AP triggered (channel changed). Dec 4 20:10:16 2023 ac %%10STAMGR/6/STAMGR_CLIENT_OFFLINE: -DevIP=192.168.192.21; Client bc03-5872-49fd went offline from BSS 943b-b04d-3f20 with SSID Succez on AP 2f_yanfa_waibu Radio ID 1. State changed to Unauth. Reason:AP triggered (channel changed). 可以看到先提示了信道改变，原因是: Radar channel recover ，然后下面就是客户端离线，原因是通道（信道）改变。 于是登录AC控制台查看了信道射频相关的配置，可以确定没有开启信道定时自动调优，但AP的信道设置是自动信道不锁定，结合信道会变化，怀疑是这里问题，于是修改为自动信道并锁定。 但设置后并没有恢复正常超过半天，又出现了同样的问题。所以可确定不是此配置影响，而目前最大的疑问在于，为什么锁定了信道仍然会自动变化，为什么其他AP不会变化，难倒是AP物理上存在故障了？ 0x3 radar? 在修改锁定信道也无法解决问题后，又尝试重启了AP，但后续也发现无法解决，所以目前为止比较怀疑的是AP硬件或者软件存在故障或BUG 不过仍然在百度和google查询了 Radar channel recover ，毕竟这里可能是唯一的错误信息了，但检索基本没有得到有效信息。 在一筹莫展的时候，我反复在想为什么配置了 锁定信道 但仍然会切换，这显然是软件行为，比锁定信道的优先级都高，于是我查询 H3C 中关于信道锁定的部分配置 auto lock ，这一查，终于发现了蹊跷： 【缺省用户角色】 network-admin 【参数】 channel-number：手动配置的射频工作信道。取值范围由区域码和射频模式决定。 auto lock：自动选择信道并加锁模式，由设备根据实际环境自动选择最优信道，并将该信道锁定。 auto unlock：自动选择信道并解锁模式。由设备根据实际环境自动选择最优信道，并将该信道设置为无锁模式。 【使用指导】 在手工指定工作信道模式时，如果在当前工作信道上发现雷达信号，则AP会立即将工作信道调整至其他信道。AP会在30分钟后将信道切换回手工指定的信道，并静默一段时间，如果在静默时间内没有发现雷达信号，则开始使用该信道；如果发现雷达信号，则再次切换信道。 在自动选择信道模式上，无论信道加锁与否，如果在当前工作信道上发现雷达信号，则AP会立即将工作信道调整至其他信道。 在只看参数的时候我觉得挺正常的， lock、unlock 在是意料之中的行为，不过在使用指导中发现了关键字 雷达，并且整体解释大意为，不论是手动设置、自动设置信道，不论是否加锁，只要检测到雷达信号，则会立即切换到其他信道，这和我遇到的现象是一模一样的。所以断网的原因终于找到了，那为什么会出现这个问题呢？ 0x4 原因 首先AP进行了信道切换，所以可以判断雷达也是有相关的信道，并且可能在当时发生冲突了。所以我们可以了解雷达信道的范围，检索的资料如下： 什么是雷达信道 信道52，56，60，64，100，104，108，112，116，120，124，128，132，136，140，144可作为雷达信道，如果某国家和地区支持的信道和雷达信道有重叠，则使用信道时请尽量避开雷达信道。当AP工作在5G射频频段时，AP通过DFS功能，进行雷达检测，当检测到雷达信道后会自动切换到其他工作信道，避免干扰雷达。 思科关于DFS和雷达信号的介绍 在了解了基本情况之后，我们大概可以知道，是因为AP检测到了相同信道的雷达信号，所以立即切换了信道，但这里仍然有疑点，室内真的存在雷达信号吗？并且一天中随机出现，这个我们无法验证，但解决办法是什么呢？ 既然雷达信道和wifi信道有一定重合，但wifi信道也较多，所以可以手动设置AP信道，在当前网络架构中完全不使用雷达信道 关闭雷达检测 `radar-detect disable` （不建议此方法） 此次问题是发生在室内，正常应该不存在雷达信号，所以基本上是误判，可以提交问题给厂家 或者 尝试升级 AC 固件版本。（本次升级后解决，如果升级后仍未解决可以采用更换非雷达信道办法） PS. 关于多个AP使用雷达信道 AP检测雷达信号使用的DFS技术，虽然是同一个信道，但能够判断具体是 WIFI 信号还是雷达信号，所以多个AP使用同一个雷达信道，也是不会发生切换的 其他 最后通过检索之前日志中的 radar ，发现不少 AP 其实是切换过信道的 Dec 4 09:20:44 2023 ac %%10APMGR/6/APMGR_LOG_CHANNELCHANGE: -DevIP=192.168.192.21; Channel of Radio 1 on AP 2f_yingkai_neibu changed from 40 to 60, Reason: Radar channel recover. Dec 4 09:21:21 2023 ac %%10APMGR/6/APMGR_LOG_CHANNELCHANGE: -DevIP=192.168.192.21; Channel of Radio 1 on AP 2f_huiyishi changed from 165 to 56, Reason: Radar channel recover. Dec 4 12:16:23 2023 ac %%10APMGR/6/APMGR_LOG_CHANNELCHANGE: -DevIP=192.168.192.21; Channel of Radio 1 on AP 2f_yingkai_waibu changed from 52 to 153, Reason: Avoid radar channel. Dec 4 12:16:24 2023 ac %%10APMGR/6/APMGR_LOG_CHANNELCHANGE: -DevIP=192.168.192.21; Channel of Radio 1 on AP 2f_huiyishi changed from 56 to 48, Reason: Avoid radar channel. Dec 4 12:46:23 2023 ac %%10APMGR/6/APMGR_LOG_CHANNELCHANGE: -DevIP=192.168.192.21; Channel of Radio 1 on AP 2f_yingkai_waibu changed from 153 to 52, Reason: Radar channel recover. Dec 4 12:46:24 2023 ac %%10APMGR/6/APMGR_LOG_CHANNELCHANGE: -DevIP=192.168.192.21; Channel of Radio 1 on AP 2f_huiyishi changed from 48 to 56, Reason: Radar channel recover. Dec 4 13:25:01 2023 ac %%10APMGR/6/APMGR_LOG_CHANNELCHANGE: -DevIP=192.168.192.21; Channel of Radio 1 on AP 2f_yingkai_neibu changed from 60 to 165, Reason: Avoid radar channel. Dec 4 13:55:01 2023 ac %%10APMGR/6/APMGR_LOG_CHANNELCHANGE: -DevIP=192.168.192.21; Channel of Radio 1 on AP 2f_yingkai_neibu changed from 165 to 60, Reason: Radar channel recover. Dec 4 15:21:36 2023 ac %%10APMGR/6/APMGR_LOG_CHANNELCHANGE: -DevIP=192.168.192.21; Channel of Radio 1 on AP 2f_yingkai_neibu changed from 60 to 52, Reason: Avoid radar channel. Dec 4 15:51:36 2023 ac %%10APMGR/6/APMGR_LOG_CHANNELCHANGE: -DevIP=192.168.192.21; Channel of Radio 1 on AP 2f_yingkai_neibu changed from 52 to 60, Reason: Radar channel recover. Dec 4 18:02:55 2023 ac %%10APMGR/6/APMGR_LOG_CHANNELCHANGE: -DevIP=192.168.192.21; Channel of Radio 1 on AP 2f_yingkai_waibu changed from 52 to 48, Reason: Avoid radar channel. Dec 4 18:32:55 2023 ac %%10APMGR/6/APMGR_LOG_CHANNELCHANGE: -DevIP=192.168.192.21; Channel of Radio 1 on AP 2f_yingkai_waibu changed from 48 to 52, Reason: Radar channel recover. Dec 4 18:34:14 2023 ac %%10APMGR/6/APMGR_LOG_CHANNELCHANGE: -DevIP=192.168.192.21; Channel of Radio 1 on AP 2f_huiyishi changed from 56 to 60, Reason: Avoid radar channel. Dec 4 19:04:14 2023 ac %%10APMGR/6/APMGR_LOG_CHANNELCHANGE: -DevIP=192.168.192.21; Channel of Radio 1 on AP 2f_huiyishi changed from 60 to 56, Reason: Radar channel recover. Dec 4 19:40:15 2023 ac %%10APMGR/6/APMGR_LOG_CHANNELCHANGE: -DevIP=192.168.192.21; Channel of Radio 1 on AP 2f_yanfa_waibu changed from 60 to 161, Reason: Avoid radar channel. Dec 4 19:54:24 2023 ac %%10APMGR/6/APMGR_LOG_CHANNELCHANGE: -DevIP=192.168.192.21; Channel of Radio 1 on AP 1f_renshi changed from 52 to 44, Reason: Avoid radar channel. Dec 4 20:10:15 2023 ac %%10APMGR/6/APMGR_LOG_CHANNELCHANGE: -DevIP=192.168.192.21; Channel of Radio 1 on AP 2f_yanfa_waibu changed from 161 to 60, Reason: Radar channel recover. Dec 4 20:24:24 2023 ac %%10APMGR/6/APMGR_LOG_CHANNELCHANGE: -DevIP=192.168.192.21; Channel of Radio 1 on AP 1f_renshi changed from 44 to 52, Reason: Radar channel recover.
-
nginx之同一个端口http跳转到https 0x1 场景 在 nginx 中一个监听端口只能有一种状态，如果监听了 http，那么不能再次监听 https，所以会出现一种需求： 如果环境使用了非标准的 https 端口，而用户如果没有手动输入前缀 https:// ，那么是无法正常访问环境的，通常返回的是 400，告诉用户在 https 上使用了 http 协议。但这样仍然不够，对于不熟悉技术的用户来说，也仍然不知道需要去手动处理前缀 0x2 常用解决办法 通常这问题有一个常用的解决办法。那就是增加一个 http 端口，在这个端口上做 301 跳转到 https即可。那这样就用到了两个端口，我们可以通过一个端口来解决问题吗？ 答案是可以的 0x3 一个端口497 参考如下的配置： error_page 497 https://$http_host$request_uri; error_page 指令也是我们常用的，就是把指定的错误响应状态码跳转到设定的页面上，所以这一句基本的含义就是把 497 的状态码跳转到其 https 地址上。再结合其能解决问题，我们可以知道，当 nginx为https环境时，如果接受到了 http 请求，那么其会响应 497。至此我们就解决了单个端口实现 https 环境，并且兼容 http 访问跳转的需求。 0x4 haproxy实现 发现 haproxy 也是有办法可以实现的，参考文档: https://discourse.haproxy.org/t/one-port-to-catch-http-and-https-requests-and-redirect-to-the-https-version/1703?u=elovin
-
java jar 的一次修改破解 0x1 准备工作 首先触发报错，看报错的内容 在服务器上查看堆栈，以确定对应的文件 可以确定是UserDaoImpl.java中，并且目录是com.farm.authority.dao.impl 但并没有在找到 authority 相关的目录，而是在 lib 中找到了可能相关的jar，那么就需要破解看看了 0x2 反编译工具选择 使用 cfr 直接反编译出源码，推荐 使用 jar 命令解压出 class，再使用其他工具反编译出java源码，如 eclipse 的 Class Decompiler viewer，或者其他各种工具 其实如果代码没有加密等情况，有了源码就很好解决了，修改下判断就能达到我们的目的，但是如何编译回去又成了最大的问题 0x3 编译 因为我们没有整套的源码，如何把修改后的java文件编译成class是个大问题，大概尝试了有如下办法： 使用 javac 命令，但是一直提示有两个类型转换错误，而且 javac 没有办法跳过错误 听闻 eclipse 有跳过错误的功能，但是实际使用很复杂，保存后自动编译貌似也没通过 最后使用了 idea，它在源码中显示出了这两个错误的行，然后点击后还自动给修复了（貌似就增加了一个声明），最后编译成功。总体尝试下来推荐使用 idea
