V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  Austing  ›  全部回复第 1 页 / 共 7 页
回复总数  132
1  2  3  4  5  6  7  
2018-08-10 08:00:12 +08:00
回复了 yingtl 创建的主题 宽带症候群 用 iptable 做这样的转发能实现么
@ShadowStar
您真的了解 TCP/IP 和 netfilter?

没有任何操作的下 Client_1 和 VPS_2 当然不知道, 但是这和我说的有什么关系吗?

题主所说的不就是三台主机的固定关系? 即便不固定, Client 的处理也不会说只能针对一个地址.
即便不针对地址, 同样可以 connmark 一个特定状态或者数据包标识来标记用来匹配.


@yingtl 如果可以伪装 src 确实可以达到此目的, 但是你要想要比较满意的达到这个目的, 成本不会亚于你多买几台机器的.
2018-08-09 08:58:57 +08:00
回复了 yingtl 创建的主题 宽带症候群 用 iptable 做这样的转发能实现么
@yingtl 一般来讲是不行的, 因为一般 VPS 服务商是在宿主机就过滤, 现在 VPS 商家常用的 solusvm openstack 之类的默认防止欺骗什么的都是最基本的- -
如果它是租用的其他服务商的服务器, 那么他的上游服务商很可能也会有过滤.
所以很多时候可能会有很多层的...
不过你可以自己试试啊, 随便用 hping 什么的发包然后抓包看看, 能收到就是能发呗.
但是你要是同机房同网络的话, IPIP 隧道正常应该也没多少性能衰减吧.
2018-08-09 06:22:33 +08:00
回复了 yingtl 创建的主题 宽带症候群 用 iptable 做这样的转发能实现么
@ShadowStar 双向无法通信的前提是, 只是在客户端不进行任何操作的前提下, 当然无法通信, 你大可客户端 hook 再进行一次包修改.
没有任何问题, 而且使用情况也很多, 各大云的 LB 几乎全是如此.
2018-08-09 03:18:17 +08:00
回复了 yingtl 创建的主题 宽带症候群 用 iptable 做这样的转发能实现么
如果你想做到不改变发送源, 那你可以在 VPS_A 和 VPS_B 之间另外建立一条隧道来实现.
纯公网基本不太可能, 如果你不缺钱, 那你可以找没有开 uRPF 的机房或者自己买条 transit 做 bgp 吧 :)
2018-08-09 03:15:28 +08:00
回复了 yingtl 创建的主题 宽带症候群 用 iptable 做这样的转发能实现么
@ShadowStar
@yingtl
和发送回复对不对的上以及 UDP 无关.
了解一下 BCP 38/RFC 2827.
如果 VPS_A 直接 DNAT 到 VPS_B 不不改变 SRC, 那么理论上就是伪造发送源进行 IP 欺骗, 99% 的 VPS 都不可能没开启 uRPF 和 ACL 来防止伪造的.
并且很多不是自有 transit 的服务商在其上游就已经被开启了 uRPF, 你可以直接在 VPS_A 尝试用 client 或其他任意 IP 直接向 B/其他服务器发包看一下, 然后接受 server tcpdump 抓包一下, 我相信对面是根本收不到的.
別的不說了,IP 比頻寬貴,你是在局限於向 ISP 租用 IP ???這些廠有哪家 BGP 是租的 ISP 的而不是自己做的嗎?
你在開玩笑嗎,我租一個 /24 行情目前基本都在 60-70 歐,更別提買的了,那基本上算是一次性費用了,年費根本可以不計,三年前 IP 都還是成堆的給好吧。
2017-03-28 12:14:13 +08:00
回复了 Quaintjade 创建的主题 宽带症候群 上海联通的国际出口是炸了吗……
@bclerdx 你沒接聯通直連,也就是沒有和聯通 PEER ,那肯定會選擇其他的路徑過去啊,如果不選擇那就目標不可達,就這麼簡單。

@Quaintjade 要是聯通 4G 的話,大概也好不到哪去,電信 4G 還可以找個 AliHK 或者 Dediserve 的 Vienna 中轉過去,說實話聯通現在到歐洲除了 IPLC/MPLS 這些之外真的是加錢也不可及,老 CNC 出口也只有一條 DTAG 的歐洲直連,而且到晚上也是炸 30-60+的延遲。 。

@yexm0 interoute 晚上炸的飛起,白天 CU 延遲還算穩,但速度也完全不上去的,不過收郵件還是夠的。
2017-03-28 11:13:57 +08:00
回复了 Quaintjade 创建的主题 宽带症候群 上海联通的国际出口是炸了吗……
@bclerdx 是的。
2017-03-28 10:58:59 +08:00
回复了 Quaintjade 创建的主题 宽带症候群 上海联通的国际出口是炸了吗……
@Quaintjade

沒做宣告的話連 routing 都不會有,聯通客服這話在搞笑。
其實也就是在說對面的服務商沒買聯通直連,就算跟服務商講了肯定也不會花錢去接聯通的,而且歐洲的話就算接了也依然不會穩。
還是找個中轉出口吧。
2017-03-25 08:11:57 +08:00
回复了 fsgmhoward 创建的主题 宽带症候群 OVH + CN2 =?
穿 SJC 的話 CA 本地會多 40-80MS 延遲,而且穿了回程之後,被 attack 回程會漏流量進去。 。這有什麼意義麼。 。 。
2017-03-20 23:31:53 +08:00
回复了 xiaofami 创建的主题 宽带症候群 HICHINA ZHICHENG TECHNOLOGY LTD 是什么来历?
你能把域名註冊商看成註冊人也是可以的。 。 。
2017-03-17 17:15:44 +08:00
回复了 xiyangyang 创建的主题 编程 vipkid 是不是吹牛了。中美之间网络延迟不超过 200ms。。。。
@bear145

我回复你僅僅是為了告訴你科技網到 US 最低延遲是 160 ,你的 100 上下有錯誤而已,因為你這樣會誤導人的, PEK-SEA 最低時延的 IEPL 都需要 132MS 。
2017-03-17 15:25:23 +08:00
回复了 xiyangyang 创建的主题 编程 vipkid 是不是吹牛了。中美之间网络延迟不超过 200ms。。。。
@bear145
科技網目前上游基本就只有 PCCW 和 L3 好吧,而且還需要自己接 BGP 才能調出 L3 ,本身科技網 AS 上游連 L3 都沒,就一個 PCCW , PCCW 全繞 HK ,而且科技網只有北京出口,就算調出 L3 科技網極限也就是 160 ,科技網到 US 還不如教育網低= =。
2017-02-24 23:53:33 +08:00
回复了 terrancesiu 创建的主题 YouTube Youtube CDN 调度到其他国家去了问题
你可能是 MTU/MSS 的受害者,抓下包按情況改,或者直接點去 Azure 開個 GPU 實例然後連 Youtube 的捷克,你會發現並不慢 :)
2017-02-19 18:05:55 +08:00
回复了 nightwind 创建的主题 VPS 为什么国内的 VPS 都限制流量?
@tadtung 你把這些線路都接全了再來測算一下成本吧,光一個科技網和教育網就会超過 1W 了,機器價格比起來根本就不值一提。
2017-02-19 15:30:34 +08:00
回复了 nightwind 创建的主题 VPS 为什么国内的 VPS 都限制流量?
@tadtung 阿里企業認證的話最高可以自助開 300M ,然後也有 G 口,需要特殊申請,最大可以 2G ,然後 7K 百兆其實比託管划算多了,別的不說,就說阿里電信聯通移動鐵通教育網科技網鵬博士這麼多條 BGP ,而且還都在一線城市,別的地方想買還買不到呢- -
當然騰訊和百度也做了這麼多,除了這仨其他的服務商還真沒見過這麼接了這麼多的,那些雙線三線就賣 7-8K 的才叫真的貴。
2017-02-16 20:07:39 +08:00
回复了 maojy1989 创建的主题 宽带症候群 移动的国际出口发生了什么?
@hongxin 那就是改回去了吧,我這也沒一直監測著
2017-02-16 19:42:44 +08:00
回复了 maojy1989 创建的主题 宽带症候群 移动的国际出口发生了什么?
@hongxin 現在基本已經不丟包,但是所有出口仍然繞 HK 。
2017-02-16 13:11:00 +08:00
回复了 minsnia 创建的主题 宽带症候群 阿里云访问 google 不需要验证码了?
@ericbize 你可以選擇開 VPC 的,反正可以換 EIP 啊,沒開到就刪掉換一個。
1  2  3  4  5  6  7  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   918 人在线   最高记录 6543   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 34ms · UTC 20:34 · PVG 04:34 · LAX 13:34 · JFK 16:34
Developed with CodeLauncher
♥ Do have faith in what you're doing.