發佈於?2020-11-12
本篇内容,主要记录日常工作生活中遇到的一些问题思考以及一些常见技巧。
之所以会出现无法在 NAT 的内部网络通过 NAT 服务的外部 IP 地址来访问的情况,是因为如果服务从内部请求,那么经过 DNAT 转换后,将目标 IP 改写成内网 IP,如 192.168.1.3,而发送请求的机器 IP 是 192.168.1.4,数据包被网关 192.168.1.1 顺利的重定向到 192.168.1.3 的服务端口,然后 192.168.1.3 根据请求发送响应给目的 IP 地址,也就是 192.168.1.4,但是,问题出现了,因为 192.168.1.4 请求的地址是外部 IP 假设是 106.54.43.50,所以它等待着 106.54.43.50 的响应,但是由于是局域网,所以路由器不经过封装,直接转发,所以 192.168.1.3 的响应请求被看做是非法的,被丢弃了。这就是问题的所在了,该问题称为 NAT 回流,解决方案在此不再赘述。
## 查看被占用端口对应的 PID
netstat -aon | findstr "{port}"
## 查看指定 PID 的进程
tasklist | findstr "{pid}"
## 强制结束进程
taskkill /T /F /PID {pid}
certutil -hashfile {文件} [SHA1 | SHA256 | MD5]
# 查看所有连接过的 wifi 名称
netsh wlan show profile
# 关键内容即为密码
netsh wlan show profile key=clear name="[wifi名]"
tracert [域名/IP]
# 通过最多 30 个跃点跟踪
# 到 XiaoQiang [192.168.31.1] 的路由:
# 1 3 ms 1 ms 1 ms XiaoQiang [192.168.31.1]
# 2 9 ms 7 ms 16 ms 42.103.52.1
# 3 * * * 请求超时
# ...
# 14 88 ms 67 ms 67 ms 106.54.43.50
# 跟踪完成。
出现全是星号时间的,是该路由器禁止追踪。
ping [域名/IP]
# 正在 Ping 0xfee1dead.cn [106.54.43.50] 具有 32 字节的数据:
# 来自 106.54.43.50 的回复: 字节=32 时间=50ms TTL=50
# 来自 106.54.43.50 的回复: 字节=32 时间=49ms TTL=50
# 来自 106.54.43.50 的回复: 字节=32 时间=49ms TTL=50
# 来自 106.54.43.50 的回复: 字节=32 时间=49ms TTL=50
# 106.54.43.50 的 Ping 统计信息:
# 数据包: 已发送 = 4,已接收 = 4,丢失 = 0 (0% 丢失),
# 往返行程的估计时间(以毫秒为单位):
# 最短 = 49ms,最长 = 50ms,平均 = 49ms
# 检测域名/IP 及端口是否可达
telnet [域名/IP] [Port]
nslookup
# 默认服务器: UnKnown
# Address: 240e:30a:2e:6800::1
# 默认查询 A 记录
> 0xfee1dead.cn
# 服务器: UnKnown
# Address: 240e:30a:2e:6800::1
# 非权威应答:
# 名称: 0xfee1dead.cn
# Address: 106.54.43.50
# 设置查询 CNAME 记录
> set type=cname
# 设置查询 TXT 记录
> set type=txt
cpl 是 Control Panel extension 的缩写。在 C:\windows\system32 下面有一系列 cpl 文件,它们分别对应着控制面板中的项目。 常见 cpl 项目及对应功能:
如果免密登录失败,需检查:
jsDelivr 提供的全球 CDN 加速,CDN的分流作用不仅减少了用户的访问延时,也减少的源站的负载。但其缺点也很明显: 当网站更新时,如果 CDN 节点上数据没有及时更新,即便用户再浏览器使用 Ctrl + F5 的方式使浏览器端的缓存失效,也会因为 CDN 边缘节点没有同步最新数据而导致用户端未能及时更新。 对于 jsDelivr,缓存刷新的方式也很简单: 将希望刷新缓存的链接 https://cdn.jsdelivr.net/… 替换为 https://purge.jsdelivr.net/… 即可实时刷新。刷新成功后,浏览器会返回缓存刷新成功的 JSON 信息。