vpn时如何自动区分国内国外-chnroutes-autoddvpn

0

针对这个需求，有专门的开源项目 chnroutes

最起源的代码仓库：https://code.google.com/p/chnroutes/

1. 与这个最接近的github上的代码:

https://github.com/fivesheep/chnroutes

2. 还有一个差异比较大的，从时间上看是比较旧的，但需要比较代码才能知道哪个更合适

https://github.com/jimmyxu/chnroutes

3. 还有一个改进版，提供 go python 以及window界面版本，从其文档连接看是以 fivesheep 的版本为基线版本。

https://github.com/sabersalv/freedom-routes 

本文验证了pptp windows 环境下的功能，工作OK。

其中python 使用 2.7.10 版，请安装完整版，因为可能需要其他关联库。

脚本执行要使用管理员权限。

1，2，3生成的路由数据略有差异，经简单测试，以 baidu.com 和weibo.com 为test case， 似乎3的效果好些，但因每人宽带出口不同，不作为唯一结论，使用者请自行测试。

如果要让路由器实现上述功能，提供用户透明的vpn体验，也有相应的项目  https://code.google.com/p/autoddvpn/

pptp的安全风险

0

原文已经无法访问了，特意搬运过来，英文吃力的同学，可以用google翻译，当然你要会科  学  上  网

总结起来最终的要的亮点

  • 明文传输
  • 采用简单的用户名和密码验证，方法过于简单

原文：

http://pptpclient.sourceforge.net/protocol-security.phtml

PPTP Client

Protocol Security

References

by James Cameron

Summary

by Peter Mueller

PPTP is known to be a faulty protocol. The designers of the protocol, Microsoft, recommend not to use it due to the inherent risks. Lots of people use PPTP anyway due to ease of use, but that doesn't mean it is any less hazardous. The maintainers of PPTP Client and Poptop recommend using OpenVPN (SSL based) or IPSec instead.

(Posted on 2005-08-10 to the mailing list)

Why not use PPTP?

by James Cameron

The point to point tunneling protocol (PPTP) is not secure enough for some information security policies.

It's the nature of the MSCHAP V2 authentication, how it can be broken trivially by capture of the datastream, and how MPPE depends on the MSCHAP tokens for cryptographic keys. MPPE is also only 128-bit, reasonably straightforward to attack, and the keys used at each end are the same, which lowers the effort required to succeed. The obvious lack of two-factor authentication, instead relying on a single username and password, is also a risk. The increasing use of domestic wireless systems makes information capture more likely.

However, that doesn't mean people don't accept the risks. There are many corporations and individuals using PPTP with full knowledge of these risks. Some use mitigating controls, and some don't.

Many people seem to judge the security of a protocol by the availability of the implementation, the ease of installation, or the level of documentation on our web site. Improving the documentation is the purpose of this web site, and we aren't doing that in order to say anything about the risks of the software! Any judgement of security should be rigorously applied to the design and implementation alone.

PPTP on Linux, and Microsoft's PPTP, both implement fixes for vulnerabilities that were detected years ago in Microsoft's PPTP. But there remain the design vulnerabilities that cannot be fixed without changing the design. The changes needed would break interoperability. We can't change the Linux PPTP design, because it would stop working with Microsoft PPTP. They can't change their design, because it would stop working with all the other components out there, such as Nortel and Cisco, embedded routers, ADSL modems and their own Windows installed base.

The only option then is to deprecate the product and promote the replacement. Microsoft promote something else. Our choice for Open Source systems is OpenVPN or IPsec.

Level of acceptance isn't a good indicator of risk either. Some have said that the shipping of MSCHAP V2, MPPE and PPTP in Linux distributions is an indication of design security, but that's not the reason. It's for interoperability. As an example, see how Linux distributions still ship telnet, ftp, and rsh, even though these components are insecure because they reveal the password in cleartext in the network packets. The same can be said of many other components and packages.

Our recommendations are;

  1. do not implement PPTP between open source systems, because there's no justification, better security can be had from OpenVPN or IPsec,
  2. do not implement PPTP servers unless the justification is that the clients must not have to install anything to get going (Microsoft PPTP is included already), and be aware of the risks of information interception,
  3. do not implement PPTP clients unless the justification is that the server only provides PPTP, and there's nothing better that can be used, and again be aware of the risks of information interception.

(Posted on 2005-08-10 to the mailing list)

密码管理app体验

0
  1. CODE： 密码工具。进去后，每条密码是明文，特点是每条记录按用户名和密码分开存储显示     评价 ：一般
  2. keeper：密码工具。记录是明文存储，支持  faastfill ，支持 keeper DNA    评价：中
  3. 隐私卫士：app隐私锁 评价：高
  4. 私密锁：app锁，评价：一般
  5. 应用程序锁：评价：一般
  6. 隐私应用锁：app锁。评价低
  7. 密码本：密码工具，每个字段分开存储。 评价 ：中
  8. NS Wallet ：分文件夹-item 对字段做了详细的分类。 ：一般
  9. safeincloud ：有详细的模板 ，支持云同步 评价：高
  10. SSE  功能强大，支持密码管理 ，文件本加密 ，文件加密  评价 ：高
  11. password keepox： 简单的字段记录，支持同步到dropbox ，评价：低
  12. 秘密管理器：简单的字段记录：评价：极低
  13. sis密码管理：同上

nginx设置后端保持长连接

0

nginx 做反向代理分发时，为了提高效率，最好使用长连接，以下是nginx 支持的几种后端长连接配置方案：

Nginx从 1.1.4 开始，实现了对后端机器的长连接支持，这是一个激动人心的改进，这意味着 Nginx 与后端机器的通信效率更高，后端机器的负担更低。

例如，对一个没有长连接支持的后端机器，会出现大量TIME_WAIT 状态的连接，使用以下命令验证之：

netstat -n | grep TIME_WAIT

经过查阅官方文档，其目前已经实现了http, fastcgi, memcache 协议的长连接支持。而之前的版本中仅支持memcache 协议。

memcache

启用到 memcache 服务器的长连接 在upstream 配置段中增加 keepalive N 指令即可：

upstream memcached_backend {
     server 127.0.0.1:11211;
     server 10.0.0.2:11211;
     keepalive 32;
}

server {
    ...
     location /memcached/ {
         set $memcached_key $uri;
         memcached_pass memcached_backend;
     }
}

fastcgi

启用fastcgi 长连接支持 除了需要在upstream 中配置 keepalive N 外，还需要在 location 中增加

fastcgi_keep_conn on;

upstream fastcgi_backend {
    server 127.0.0.1:9000;
    keepalive 8;
}

server {
     ...
     location /fastcgi/ {
         fastcgi_pass fastcgi_backend;
         fastcgi_keep_conn on;
         ...
     }
}

HTTP

启用对后端机器HTTP 长连接支持

upstream http_backend {
    server 127.0.0.1:8080; 
    keepalive 16;
}

server {
     ...
     location /http/ {
         proxy_pass http://http_backend;
         proxy_http_version 1.1;
         proxy_set_header Connection \;
         ...
     }
}

注意：需要设置nginx 代理请求的 http 协议版本号为 1.1, 以及清除掉 Connection 请求header, 官方文档描述：

For HTTP, the proxy_http_version directive should be set to “ 1.1 ” and the “ Connection ” header field should be cleared .

The connections parameter should be set low enough to allow upstream servers to process additional new incoming connections as well.

即是说：keepalive N 指令中 , N 的值应该尽可能设置小一些，以便后端机器可以同时接受新的连接。

Too many connections

0

在php的日志里我们看到了如下的告警日志：
mysql_connect(): Too many connections

查看默认参数：
mysql> show variables;

实时修改：
mysql> set global wait_timeout=10;
Query OK, 0 rows affected (0.01 sec)

mysql> set GLOBAL max_connections=1024;
Query OK, 0 rows affected (0.00 sec)

注意 interactive_timeout  和 wait_timeout，根据不同场景，修改不同的参数。

还可以修改 my.cnf , 然后 重启 mysqld 服务。

还需要关注查询慢的本质原因：

1）DB是innodb 还是myisam

2)  高频查询的表的index创建是否合理

3）业务的mysql 语句写的是否合理

如果以上还搞不定，就需要考虑 分库分表 ， 加proxy 做集群来分流了。