服务器 Gind.cn

服务器问题集锦,包括 Linux(Ubuntu, Centos,Debian等)和Windows Server服务器

Openswan / IPtables:通过VPN隧道伪造一个唯一的IP地址

语境: 我正在Google Compute环境中运行一组实例。 每个主机在10.0.0.0私有范围内都有单个IP地址。 我有外部客户需要通过VPN连接连接到这些实例。 但是,由于它们的大小,这些客户需要一个独特的“真实”IP地址作为目标。 (为了避免多个客户端拥有相同的私有地址的风险)。在迁移到Google之前,我们可以使用思科ASA和虚拟公共接口将这些连接发送到我们的内部networking,但是附加到GCE实例的静态外部地址可以使用谷歌VPN /路由工具不会被发夹,所以这不是一个选项。 (我已经通过Google支持确认了这一点。) build议的解决scheme: 我已经在GCE环境中保留了一个静态地址(我们称之为5.xxx) 在GCE环境中,我有一个Openswan框,可以通过来自远程ASA的ipsec连接路由到内部networking。 我能够从该远程networking在专用GCEnetworking内ping主机。 (当10.0.0.0/16被configuration为目标时) 现在的目标是将VPNconfiguration的目标更改为5.xxx地址,然后让GCE Openswan框中的iptables翻译该目标以指向专用networking上的特定IP地址(10.xxx)。 我已经configuration了iptables,使得ping到5.xxx的地址在Openswan框本身上正确转换,但到目前为止,我还没有任何运气为ASA背后的主机做这项工作。 Iptables看起来像这样: # iptables -L -t nat Chain PREROUTING (policy ACCEPT) target prot opt source destination DNAT all — anywhere xxx5.bc.googleusercontent.com to:10.xxx Chain INPUT (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source […]

BIND – 缓慢查询响应隔离到单一接口

目前在我的域名服务器上的特定接口上遇到缓慢的查询响应。 我正在一个网卡的物理服务器上运行BIND。 这个网卡被eth0接口和eth0:1虚拟接口所利用。 他们都在同一个子网中有一个地址。 BIND正在监听所有IPv4接口,并且有一些非常基本的选项。 在其他包含的configuration文件中没有设置其他性能/networking相关的选项。 listen-on { any;}; listen-on-v6 port 53 { ::1; }; directory "/var/named"; dump-file "/var/named/data/cache_dump.db"; statistics-file "/var/log/named/named.stats"; memstatistics-file "/var/named/data/named_mem_stats.txt"; 当我查询主接口eth0上的地址时,通常会得到大约三秒钟或更长时间的延迟响应。 这甚至适用于从盒子本身查询地址(而不是回送)的情况。 当查询分配给虚拟接口eth0:1的其他私有IP地址时,不会遇到性能问题,并且响应总是在一秒钟之内。 分析性能统计,看起来这个盒子没有负载,内存没有被刷新。 我也有另一个名称服务器作为这个从属的设置,在同一networking上几乎相同的networking设置栏寻址,并没有性能问题查询它的主界面(它也有一个虚拟接口具有相同的configuration) 。 我查询的区域是权威性的,所以在其他地方查询logging是不会有任何延误的。 我也能够确认服务器几乎立即收到查询,而不pipe它是从哪里发出的,并且在收到的查询和正在发送的响应(通过tcpdump标识)之间发生延迟。 如果有任何有用的信息,请不要低估我在文章中遗漏的信息,请在下面留言,我很乐意提供任何有用的信息。 任何关于如何最好地解决这种性质的问题的build议,或者关于潜在原因的想法都可能是非常值得赞赏的。 BIND版本是9.3.6-P1-RedHat-9.3.6-25.P1.el5_11.11。 我最近更新了这个,但是我不能确定这些性能问题是在升级之后产生的,还是在它之前存在。 编辑:挖掘输出按要求。 删除了被查询的域名和目标服务器。 另外值得注意的是,有时这些请求只是完全超时。 这是非常间歇性的,偶尔在两秒钟内回复,但大多超过三个偶尔超时提到。 [root@hugh-host-01 ~]# dig REMOVED @REMOVED ; <<>> DiG 9.9.4-RedHat-9.9.4-38.el7_3 <<>> REMOVED @REMOVED ;; global options: +cmd […]