※ 引述《HuangJC (吹笛牧童)》之铭言： : 标题: Re: [问答] 请问私网/公网的问题 : 时间: Thu May 7 02:51:21 2020 : : : 谢谢，真的很有细节！ : 独学不能无友 : 书我都不知道看几次了，但始终看不通 : 最後的结果是书都快被我当国文课本背起来了 : 但还是不懂 XDDDD （不知有没有人懂这种无奈） : : : ※ 引述《blackbox (黑盒子)》之铭言： : : : 比如这个例子，指令在 Mac 上面下 : : : 是不是说，封包进来後是由 Mac 充当 NAT? : : ssh指令是在MAC这台机器下的没错，应该形容成Port Forwarding比较接近 : : IP分享器建立个PORT FWD，就是把WAN IP的一个PORT对应到LAN的某个地方 : : 我们在远端的RPI开了Port FWD功能，但是这FWD却是由MAC去处理 : : 1.1.1.1:2345 <=> 10.1.1.11:xxxxx <=> 10.1.1.12:1234 : ^^^ : : 就这个，内网往外网我不怀疑其能力 : 但外网往内网有问题，所以我想 NAT 这时也还是有在做转发 : 但这次是自动设的，和我要去 AP 的 NAT 功能表手动设不同 : : 其实要讲解这细节，就连 NAT 都得给一个 IP 来讲了 : 而我一直很搞不懂的是，NAT 是有一个 IP，还是两个 IP？ : 似乎是两个，一个公网对外，一个私网对内， : NAT 就是电子交换机，将这两个直接短路起来 : 对不起我偷懒了，因为我不想转去提路由 的确分享器拿到的是两个IP，一般显示为WAN IP跟LAN IP 所以内网实际上是对LAN IP，然後在分享器内部转为WAN IP 多WAN多LAN啥的又是另一段，整个聊起来就是超零碎超好睡的 : 私网对内那个似乎和我们其他私网电脑是同一个网段的，所以才符合 netmask 的规则 : 也才有法子填 gateway 这个栏位 : （这带出另一个问题，现在的 NAT 都一插上就能用，不用自己设 route : 我以前是 modem 工程师，厂商有时送来的机器不会自己产生 route，我要先设才能用 : N 年前的产品比现在阳春吧！ : 可是我都不知道要怎样设，我不知道 gateway 是多少，怎麽查 : gateway 有一定的规则吗？比如 netmask 所规范范围内，所有可变 bit 都设 0? : 可变都设 1 是广播位址嘛；因为我常看 default gateway 是设往 0,0,0,0 : 也或者其实要看硬体设定，厂商应该提供给我但没提供） : gateway规则很简单，你怎麽写他怎麽走，反正大不了迷路被下一级丢包 比如说你可以指定10.2.0.0/16 全丢往 10.1.1.2 这样的话这台机器看到所有往10.2.x.x的封包就往10.1.1.2塞 如果10.1.1.2没有开启路由转发功能就丢包，有开启就照10.1.1.2的路由处理 0.0.0.0是关键字，表示上面没有的就丢给这个机器 : : 对远端的客户而言，他是连到RPI，他不认识MAC跟SRV : : 对SRV而言，是MAC连到他，他不认识客户跟RPI : : : 也就是说，我学过把 AP 设成 NAT : : : 而 ssh tunnal, 就是由下指令的那台电脑充当 NAT？ : : : 至於 cgnet 会有什麽问题，我还不懂 : : : 毕竟 email 的 request 已经突破层层内网穿出去了 : : : 而 mail server 的回传资料也突破层层内网穿回来了 : : 层层穿"出去"的request就是我说的主动连接 : : IP分享器可以在WAN IP做NAT功能对LAN提供服务。假设WAN IP: 2.2.2.2 : : 就这个，不把 IP 分享器也给一个 IP，根本讲解不清这段 : 但我觉得有两个 ip,私网 IP 就是 gateway : : : 当你用10.1.1.11连1.1.1.1:22时，他会建立纪录： : : 1.1.1.1:22 <=> 2.2.2.2:xxxxx <=> 10.1.1.11:34567 : 1.1.1.1:22 <=> 2.2.2.2:xxxxx <=> 10.1.1.1:xxxxx <=> 10.1.1.11:34567 加入LAN IP这一段应该就可以理解了 : 是，我印象中读过一句话：每个服务都要开 port : 而 NAT 被不定数量的私网 IP 动态连上时，也会动态开 port : 有还没用的就开～ : : : (:xxxxx表示任意Port，下同) : : 对1.1.1.1而言是2.2.2.2去连接他，他不认识10.1.1.11 : : 层层穿"进来"的NAT就没有对应表了 : : 今天你的IP分享器不会知道你在10.1.1.12:1234开了服务 : : 所以除非你在Port Forwarding下手动设定 2.2.2.2:3456 <=> 10.1.1.12:1234 : : 分享器不会也不应该主动让2.2.2.2:xxxxx对应到10.1.1.12:1234 : : (不谈DMZ, UPNP, Port Trigger啥的) : : 好吧，先不谈 Port Trigger : 我有去信问 tp-link, 他们回信後我还是不懂 : 我认为是我没用到，所以不懂；那先别勉强学 : : : 而这时外面的客户端要连线的是2.2.2.2:3456而不是10.1.1.12:1234 : : CGNAT的问题是你的WAN IP不是公网IP : : ISP发给你的是100.64.1.2这种类似私网的IP，对外变成ISP的3.3.3.3 : : 一样的连接变成 : : 1.1.1.1:22 <=> 3.3.3.3:xxxxx <=> 100.64.1.2:xxxxx <=> 10.1.1.11:xxxxx : : 对於公网上的机器，只知道3.3.3.3，不知道後面的100跟10这段 : : 此时你的Port fwd只能开在100.64.1.2，外面的人看不到的 : : : 可以想见的是，如果我要留着一个 ssh 通道做我想做的事 : : : 那便是一种资源占用，所以会被设限？ : : 手机要挂着登入远端的SSH以便开启通道，少了一个手机，好麻烦 : : 除了所有封包都要经过手机外，大致上没有其他问题 : : 这不是麻烦 XD : 我老板丢给我一个使用情境 : 他说：牵一个固网很贵，客户舍不得牵给 RPI : （我们 RPI 是用来做自动控制的微电脑，在工厂里控制机台的） : 平时 RPI 都独立运作 : : 但偶尔还是会想上网，这时客户会拿着手机接近 : RPI 可不可以设成临时连上手机并且马上上网 : 实际上应该是有模糊空间，可以也不可以 手机分享网路要在手机上开启WIFI AP功能 然後这功能会设定SSID跟加密等内容 然後再由RPI去"指定"连上这个AP 如果手机开启WIFI AP接近，然後在RPI上手动选SSID那就可以 如果想要自动连上，虽然有可能可以，以资安角度太危险 : 我答：可 : 他又问：那这时可不可由外界控制 RPI : 我当场就想把客户干到外翻了 XD : 好好牵个固网是会死吗？是有多贵.. : 牵个固网，你去美国都可以摇控你心爱的工厂 : : 然後老板就说：可是人家物联网都可以，都是内网，一样可以控制工厂的灯泡 : 应该可以把灯泡注册到云端，以後就可以控制 : : 那时我就很想不通 : 以注册来说是可以分辨出这颗灯泡没错 : 但以 IP 来说，内网 IP 没什麽好注册的，没分辨力 : 如果牵固网，我就会在 IP 分享器上面设好固定式 NAT : 大方的说当然连得进来 : 但如果是手机网路，我突然想到，要在手机上设 NAT？手机根本没这栏位！ : 这样知道我为什麽开始思考这些机车问题了吧.. : : 那就去用人家的服务啊！ : 这句回答等於是：我回家吃自己，你找那家替你做去 : 老板就是要我做 : 他就是说：team viewer 那种 server，我们自己架一个，程式自己写 : 忽然想到...上面问P2P的应该不是你们吧 : 所以我才评估这些 : 其实不是一定要做 : 而是只要可以评估出来，很难，很贵，别人不可能做出来，那也可以不做 XD : 但我天天最不爽听到的就是：别家那个谁谁谁做出来了耶，他为什麽可以 : : 靠北咧，别人可以！ : : 所以我才得研究一下 : 最近我有新的藉口了：team viewer 可以没错，但试用期过後就要钱了，要代价啦 : （要钱他就不会逼我做了 XDDDD） : : 好啦，现在我终於搞懂了 : 只要你舍得手机丢在那边 : 那你手机丢着的期间，我也承诺你做得到 : : 至於未来老板会想通，改去逼客户一定要牵固网 : 那是未来的事了，至少现阶段我不输别人 :P : : 放弃云端控制的话有个解法 换成RPI开WIFI AP，手机去连他 要云端的话就是要先投资云端SERVER 然後解决上面说的RPI手动连入AP的问题 再来还要考虑NAT各种撞墙，最後通常会变成靠云端主机中介流量 : : : : 所以跨过手机的 ssh 通道将会无法服务吗？ : : : 内网 ssh 外网应该是没问题 : : : 但 ssh tunnel 让外网反钻回内网，会有问题吗？ : : 有可能造成资安问题，但是技术问题应该没有 : : 你让一个本来被关在内网的服务可以被其他人使用 : : 我也觉得资安有问题，一直在想有没有地方可以上课 : 有些钱是得花的，坐着听两小时会懂，就去听.. : : 在 PTT 问免钱的有时会被酸 : 在这板到现在还没被酸是太好运了 : （至於上了课还不懂，就好像巨匠那种水准，那也不行 : 所以有时为了五斗米还是得来挨骂 : 我挨的很多骂都是主管要求做的，主管都觉得可以，然後我就来问，来挨骂 : 主管自己也不会 XD） : : : : 我昨天做了两个设定，一个是 A 往 B 连，一个是 B 往 A 连 : : : 如果没有方向性，都是短路在一起的概念 : : : 则效果应该一样 : : : 但效果就是不一样 : : : socket是双向的，我们在处理的是建立之前的步骤 : : 等等来修文附上我的案例，因为都看你的数字，我已经眼花了 : 必需实体化一下 : : ------------------- : : 有了，我们用 shell 的变数功能 : 我都这样做的，因为我背不起 IP : : RPi='169.254.161.158' : echo $RPi : 169.254.161.158 : : 其实像这样，所以根本不用直接给 IP : 现在我有一台 Mac, IP 是 $MAC : 有一台 RPi, IP 是 $RPi : : 在开发 RPi 时，我是用 VNC 的 : 开 port 是 5900 : 所以，在 Mac 上以 VNC Viewer 连向 $RPi 就可以看到 RPi : : 然後我下 ssh tunnel 指令 : : ssh -R 5901:localhost:5900 myname@$MAC : 下在 RPi，打完 MAC 上的密码後，shell 提示号会显示我登入 MAC 了 : 然後这时我在 MAC 上，用 VNC Viewer 连向 localhost 的 port 5901，就可以看到 RPi : : 这边是懂的 : 而我的理解是 RPi:5900 和 Mac:5901 短路在一起 : 去看 RPi:5900 就和去看 Mac:5901 一模一样 : 看来一定有细节不一样，因为若说短路，没有方向性，那反过来设却不会动 : : 在 MAC 上面下 : ssh -R 5900:localhost:5901 pi@$RPi : 然後在 MAC 用 VNC Viewer 看向 localhost 的 port 5901，没用，不能看 : 那请问这个方向性是怎麽造成的，细微差异在哪？ : 喔，这时若丢讯息进入 RPi 的 5900，就会由 MAC 的 5901 接收， : 看有没有什麽服务在监听 5901 就会动作 : 但反之丢讯息进入 MAC 的 5901，不会主动跑向 RPi 的 5900？ : （我以为是双向啊～ 不是虫洞吗？ XD） : Port redirect一样有端口绑定的问题 印象中通道开启失败还是会继续进行SSH登入，不会报错退出 初始状况： $RPI:5900 被VNC占用(监听中) $MAC:5901 闲置 在$RPI下指令ssh -R 5901:localhost:5900 myname@$MAC $MAC:5901 要求让SSH占用，指向$MAC端的localhost:5900 ($RPI:5900) 此时状况： $RPI:5900 被VNC占用(监听中) $MAC:5901 被SSH占用(自动指向$RPI:5900) 在$MAC下指令ssh -R 5900:localhost:5901 pi@$RPi $RPI:5900 要求让SSH占用，指向$MAC端的localhost:5901 ($MAC:5901) 冲突发生，$RPI:5900已被占用，通道开启失败 此时状况： $RPI:5900 被VNC占用(监听中) $MAC:5901 闲置 你想达到的功能应该是-L，然後注意解析方向不同 在$MAC下指令ssh -L 5901:localhost:5900 pi@$RPi $MAC:5901 要求让SSH占用，指向$RPI端的localhost:5900 ($RPI:5900) 此时状况： $RPI:5900 被VNC占用(监听中) $MAC:5901 被SSH占用(自动指向$RPI:5900) : : : （咦，我来钻第三层看看，钻过去再钻回来） : : : -- :

※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 49.219.131.19 (台湾) : ※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Network/M.1588791084.A.7AE.html : ※ 编辑: HuangJC (49.219.131.19 台湾), 05/07/2020 02:53:23 : ※ 编辑: HuangJC (49.219.131.19 台湾), 05/07/2020 03:00:00 : ※ 编辑: HuangJC (49.219.131.19 台湾), 05/07/2020 03:17:56 --

※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 180.218.6.59 (台湾) ※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Network/M.1588814573.A.B70.html ※ 编辑: blackbox (180.218.6.59 台湾), 05/07/2020 09:33:41 ※ 编辑: blackbox (180.218.6.59 台湾), 05/07/2020 09:38:14