WPE|52wpe|我爱WPE

 找回密码
 注册会员
搜索
  • 2122查看
  • 0回复

主题

好友

1172

积分

禁止发言

发表于 2010-2-2 16:36:09 |显示全部楼层
【慧聪安防网】2009年12月20日,**电信发布公告,称“应工信部要求从12月20号开始,**电信ADSL宽带业务只提供普通的宽带上网,其用户不能对外提供其他服务,并且工信部没有给出相应的解封时间。”

    所谓80端口是为HTTP(HyperTextTransportProtocol,超文本传输协议)开放的,这是上网冲浪使用最多的协议,主要用于在WWW(WorldWideWeb,万维网)服务上传输信息的协议。

    至于电信关闭80端口的原因,电信方面这样解释:“许多宽带用户的ADSL路由器都没有修改默认的密码,使得黑客很容易就盗取到ADSL拨号的帐号密码用并来消费,给用户带来很大的损失。例如,TP-LINK路由器的默认密码一般是‘admin’,黑客可以使用它登陆到没有修改默认密码的TP-LINK路由器上,盗取用户的ADSL帐户和密码,然后到互连星空进行买Q币、看收费电影等消费。为此,我们开始在接入服务路由器上封闭互联网访问接入线路的80端口,作为解决问题的方法。”

    **电信封了ADSL用户的80端口后,ADSL用户将无法使用家里的电脑对外发布网站,将域名的IP解析到自己家里电脑的IP,默认http端口也无法打开网站。电信的端口屏蔽对于远程监控等来说,是个严重的打击。

    对于vps、自己的服务器等有管理权限的系统来说,可以用以下几个方法解决。

    1.换访问端口

    80端口用不了换个别的端口,这个最简单,对主机设置下,没什么技术含量。同样效果也不好,相当于换了域名。

    2.域名转发

    如你的域名为www.aaa.com,被封了80端口,你可以启用别的端口,如800端口,把www.aaa.com跳转到www.aaa.com:800,可以选择隐藏转发和不隐藏。

    这个方案可行性较小,国内注册的域名大都不提供域名转发,或者转发或隐藏转发又要审核。国外注册的域名,所提供的转发服务器也封得差不多了。而且转发的域名影响搜索引擎收录。只是一种应急的办法。

    3.域名跳转

    把域名解析到一个没有封80端口的主机上面,封了80的换成另一个域名如a.aaa.com。在可用的主机上写一个html、php或asp(看主机支持)做跳转代码。如下:

    asp方式



asp方式

点击此处查看全部新闻图片


    html方式(不隐藏)



html方式(不隐藏)

点击此处查看全部新闻图片

    Html方式(隐藏转向代码):

      



html方式(隐藏)

点击此处查看全部新闻图片

    PHP方式就不再详述,也大同小异,大家也可以去网上搜索。

    这个方案的优点是在目前条件下方便操作。也实际使用不复杂。

    这个方案的缺点也很明显,因为这个方案相当于重新换了个域名,论坛类的网站可以使用这个,但是对于资料类的网站的最大来源——搜索引擎来源就没了。所以方案不适于长期,这种情况赶紧换idc为上策。

    4.301转向

    这个效果与域名转发差不多。主要区别是一个在域名上设置,一个在服务器上设置。应用IIS、Apache很容易做到。

    5.反向代理

    这个是个用得比较少的技术,指以代理服务器来接受internet上的连接请求,然后将请求转发给内部网络上的服务器,并将从服务器上得到的结果返回给internet上请求连接的客户端,此时代理服务器对外就表现为一个服务器。

    反向代理服务器可以使用一个vps就可以。由反向服务器转发请求。把域名解析到反向服务器上。对反向服务器配置要求不高,但是对带宽要求高,相当于以前访问带宽全部转移到代理的上面。Nginx、squid等都可以做反向代理。这个的优点是用户完全不会感觉到区别。不需要改变域名,对搜索引擎也没有影响。

    缺点也有除了前面所说的带宽外,由于反向服务器IP地址一样,一个人输错密码,所有人都无法登陆。如果论坛限制了同一IP的注册周期,那么一个人注册成功后,所有人都无法注册,除非你关闭注册限制。验证码会出现问题。等等这些,都是由于访客IP全部一样造成的。

    这些只是局限于论坛等交互式的,同样也可以通过代理的配置连ip都转发,配置就复杂了。别的类型网站影响不大。目前这个是最好的解决方案。

快速发帖

您需要登录后才可以回帖 登录 | 注册会员

手机版|Archiver|WPE|52wpe|我爱WPE ( 闽ICP备15009081号 )

GMT+8, 2024-5-3 11:02 , Processed in 0.056423 second(s), 16 queries .

返回顶部