张成良:中国骨干传送网的现状及发展

随着电信市场的开放，国家骨干传输网 出现了巨大的变化。从过去单一的中国电信 一家建设和拥有国家骨干网，到现在几家运营公司分别建设长途传输网，正在形成竞争局面。并且各运营公司在网络拓扑，技术选择上也有着不同的考虑和选择，出现了技术方案的多元化趋势。在组网技术上也出现了一些新特点，比如超长复用段MS- Spring保护环和VC-4级联技术。本文力图对各运营商采用的骨干网方案进行简单的介绍，从几方面探讨传送网技术的最新进展和存在的问题。 1 中国电信 的传送网经济基础 ——中国电信国内光缆干线网的大规模建设是从“八五”开始的，其中“八五”建设光缆省际干线22条 ，“九五”期间除新建光缆28条外，还对“八五”期间建造的光缆进行了扩容改造。目前，全国干线传送网光缆总长度达20万公里 ，省际干线光缆网的总长度达8万公里 。已基本形成贯穿南北，横跨东西的“八横八纵”光缆网格局。省际干线已经覆盖全国85％以上的地区城市。 ——从网上应用的系统看，“九五“期间的干线建设全部采用了SDH STM-16系统 ，1998、1999年建设的WDM系统承载的也全是SDH STM-16系统。这标志着SDH系统和承载SDH系统的WDM系统已成为省际干线传输的主力军。 1.1 SDH网络 ——中国电信是1994年 开始引入SDH系统的。第一条是南京-武汉 的 622Mbit／s SDH系统（ECI设备）。在以后的干线网建设中，由于实行了“超前，高起点，加速”的发展战略，所采用的系统从开始的 34Mbit／s、140Mbit／s的PDH系统迅速转移到高速率大容量的2.5 Gbit／s SDH系统，大大提高了系统容量。同时利用SDH丰富的开销和强大的网络管理功能，可进行同步信息传输、复用，分插，使传送网的整体水平上了一个台阶。并初步形成“八横八纵”的省际干线传输网。省际干线传输网光缆已连通包括拉萨在内的所有省会城市，网路结构由树形网向格形网（网孔网）为主的复合同结构演进基本完成。 ——从网络拓扑上看，由于中国地域广大，比照北美AT＆T网络，当时的电信主管部门决定采用“Mesh”网状网＋DXC的结构，准备在全国60多个城市设立DXC节点，各条干线在DXC节点处将需要转接的电路接入到DXC，由DXC完成电路的调度和保护恢复。但是由于当时DXC4／4技术不够成熟，后来又因为种种原因，DXC的引进工作一直没有展开。目前干线上基本是点到点 2.5 Gbit／s SDH系统，统一的传送网并没有形成。     由于建设周期短，而且大部分设备都是从国外引进的，局限于当时的技术和人们对问题的认识水平，中国电信的SDH传送网络存在着两个急待解决的问题：一是多厂家的上层网络管理问题，二是网络的保护和恢复问题 。     从SDH设备供应商看，中国电信设备主要来自Siemens、Lucent、Ericsson、NEC、Futijsu、Alcatel和Nortel等7个厂家 。多厂家虽然增加了设备选型的灵活性，但是也带来网络管理的复杂性。当前我国的SDH网络维护管理水平无法与世界第二的网络规模相适应，传输网维护管理仍处于较低水平，在网络维护体制、管理手段上存在许多问题，主要表现在：（1）网管系统的多厂商问题严重，网络管理仍停留在对单一厂家、单一干线网元设备的维护上，没有建成综合多厂家设备的网络管理系统。（2）网管系统的运行质量和稳定度不高。（3）没有统一的管理网，难以实现对整个省际干线网有效的管理，传送网使用效率低。在网络的安全性和保护恢复方面，由于DXC迟迟没有引入，严重影响了网络的灵活性和安全性。其主要缺陷表现在：（1）没有传送网自身的交换节点，不能支持交叉连接功能，无法实现灵活的端到端调度，及时满足各种业务网和租用专线的动态要求。不同干线之间不能通过网管系统进行调度，只能进行人工配线。在国家省际干线网地图上，我们看到的只是一条条不相关联的线和孤立的点，这些点是没有自动交换能力的死节点，必须采取人工的手段才能将一段段线路连通。（2）没有足够的空闲（备用）容量支持自愈功能，对断缆等全阻障碍没有恢复能力。业务没有足够的保护和恢复，基本上都是1＋0的系统。 ——中国电信已经意识到目前网络存在的问题，已经着手解决网管和网络恢复保护这两大难题。在网络管理方面，已经决定在目前的网元管理系统之上先建立各主要供应商子网管理系统，力争将全国范围内的同一家产品管理起来，然后在于网管理系统之上再考虑建立网络级管理系统。具体是在北京建立Lucent、Siemens的子网管理系统，成都建立Nortel的子网管理中心，石家庄建立Futijsu子网管理系统，杭州建立Ericsson子网管理系统。另外，沉寂了几年的DXC引进也被摆上了议事日程，中国电信将在全国卫个重要节点城市建设DSC4／4恢复网络。 1.2 WDM网络 ——第一条WDM省际干线西安-武汉 工程是1997年引进的（8×2.5Gbit／s系统，Lucent设备），到目前为止，至少有16条干线已经采用了WDM系统。如京—九—广 、京—太—西 等。截至1999年底，WDM系统链路总长度超过25000km，大约占中国电信省际骨干网长度的40％。 ——近两年引进的WDM系统都是16×2.5GKbit／s系统，由于目前还没有那么大需求，系统多未配满。从承载的信号格式看，都是SDH STM-16信号。WDM系统可以承载多种格式信号的特点并没有得到发挥，主要原因在于目前的绝大部分业务仍是话音业务 。 ——1999年开始，中国电信的省际干线不再引进单波长的SDH系统，全面转向承载多个 SDH的开放式WDM系统。开放式WDM系统（带有波长转换单元OTU）由于其可以实现多厂商互连的优点，得到运营商和制造厂商的普遍欢迎，现在的多数产品都采用了开放方式，而且在发送端和接收端都采用了OTU波长变换器，从而更清楚地界定SDH和WDM的物理分界点。 ——从网络拓扑上看，当前建设的WDM全是点到点的线性系统，没有采用OADM（光分插复用设备）。在有业务上下的节点上，采用了复用器/解复用器的背对背方式。世界上大规模建设的WDM系统基本上都是这种系统，环型或其他结构的WDM网络在技术成熟后才会应用。 ——在WDM网管系统建设上，考虑到WDM网络是其他客户信号的传送平台（包括SDH信号），可以承载各种格式的信号，既可以承载标准的SDH信号，也可以承载其它任何不受限的数字信号或模拟信号。因而WDM的网络管理系统也应与其传送的信号的网管分离。对现在的干线工程来讲，就是独立于SDH的网管系统。WDM系统的网管系统只负责对光线路系统的管理，这包括波分复用器、光放大器等。SDH网管系统负责管理ADM、中继器等设备，而不涉及光传输系统。 ——目前引进的WDM系统中，只有4个设备供应商（即Lucent、NEC、Alcatel和Nortel ，其中Lucent的产品占绝大部分），比SDH供货商要少。相对于SDH系统，现在点到点WDM线路系统网管信息较少，基本上没有配置管理信息。在厂商不多，网管信息较少的情况下，比较容易建设WDM系统的网络层管理系统。目前我国采用的WDM系统只能实现告警管理和性能管理，只有“监视”功能，没有“控制”功能。中国电信已经委托国信朗讯公司在各厂家的网元管理系统（EM）层以上开发WDM网络层的网管系统，年内可以完成。 ——另外随着G.655光纤的建设和业务的强烈需求，中国电信传送网络已经开始从基于2.5 Gbit／s WDM系统向基于10 Gbit／s WDM系统过渡。 2 中国联通 的传送网 ——相对于中国电信，成立于1994年中国联通的网络建设较晚，目前中国联通光缆达到2.9万公里，其中干线光缆达到1.4万公里。从世界电信市场开放的形势看，第二运营商总是采用最先进的技术，以使自己处于有利的竞争地位。作为中国的主要电信运营商之一，中国联通在网络拓扑上与中国电信有着显著不同：中国电信采用的是网状网Mesh＋DXC4／4恢复网，而联通采用的是自愈环+DXC4／1策略，即采用复用段保护环来组建全国性的骨干传输网。在欧洲和北美的网络中，尤其是新运营商也大多使用环网结构组建国家骨干网，如北美Qwest使用复用段保护环技术组建了覆盖美国的长途传输网。 ——联通的长途光缆网工程分为两个阶段，其中第一阶段采用的是2纤2.5Gbit／s 单向通道保护环（全部采用Lucent设备），已经在1999年12月开通。第二期工程总投资6000万美元左右，一共5个自愈环工程。2个环网采用常规 2.5 Gbit／s 2纤复用段保护环，2个环网采用2.5 Gbit／s SDH 2纤复用段保护环MS-Spring+16WDM系统，1个大环采用10Gbit／s SDH 4纤复用段保护环MS-Spring+16波WDM系统。网间相连的7个重要节点采用了等效256×256 155Mbit／s交叉能力的DXC4／4／1设备，以疏通环间的业务。 ——联通的一些环的长度超过了4000km，引起人们对保护时间的担心。ITU-T在 G.841确定50ms的保护时间时，假设的是1200km周长、16个节点的自愈环。因此超长复用段环网的保护时间会突破50 ms，这主要来自信号在环路上的传输时延。对于5000km的自愈环，仅信号的传输时延就达50ms，如果再加上传输节点对K字节的判断和贯通时间，一般保护倒换时间会增长到 100ms左右。过去国内MS-Spring主要在省网和长长中继网上应用，保护倒换时间矛盾不突出。现在几千公里的超长复用段保护环，引起人们对保护倒换时间的担心。根据国外相关论文和现场网络测试结果，周长为5800km超长SDH 10Gbit／s 4 纤复用段环，环上共有16个节点，实际测试平均保护倒换时间为100ms，最大不超过为110ms。中国联通的复用段虽然比较长，但因节点数较少，复用段环的保护倒换时间不会因环的周长增加而增加很多，主要增加的是传输时延，而节点数少也会相应地使保护倒换时间缩短，一般相信倒换时间会小于100ms，对业务不会造成很大影响。联通网络的另一个突出特点是10Gbit／s复用段保护环的应用。TDM 10 Gbit／s作为一种新技术在电信网上的应用是迟早的事情，中国电信在上海—南京 采用了点到点10Gbit／ s WDM的线性系统，但并没有环型网的应用。联通在华东业务量大的地区采用了10 Gbit／s 4纤超长复用段保护技术（环长度在3000km左右），这种技术选择有着较大的挑战性。 ——在供应商的选择上，联通吸取了中国电信传输网设备选型“七国八制”的教训。已经注意把供货商限制在二三家以内，既有利于开展竞争，不至于在设备价格上被供应商左右，另一方面也尽力保持设备的统一性，有利于建立统一的网络管理系统。 3 中国网通 的传送网 ——中国网络通信有限责任公司（CNC）是1999年8月才注册成立的一家新运营者，主要从事与IP相关的业务，例如IP电话、数据。中国网通将在明年中期建设完成一个全国性的高速宽带IP互联骨干网络，该网络将采用先进的 IP over DWDM 传输技术，建立全国规模的“IP over WDM”网络，一期工程涵盖15个主要城市，包括北京、上海、广州等，总长度达 7000km。传输上采用16 ×2.5Gbit／s WDM技术，物理上为2纤环，路由器直接与WDM设备相连。但在物理层并没有保护措施，所有的业务保护都在IP层实施。 ——在CNC的网络论证初期，对于“IP over WDM”技术进行长途传输时是采用 “IP／SDH／WDM”还是“Gbit／s Ethernet over WDM”进行了激烈的争论。开始人们认为吉比特以太网的价格低，其帧结构可以直接在计算机运载，不存在SDH或ATM那样的再映射协议，而且以太网是非同步的，对同步和时钟不敏感，能容忍各种时延和抖动问题。采用“Gbit／s Ethernet over WDM”可以进 行长途传输，但是实验室结果却证明了此方案的不可行。其原因主要如下：其一目前WDM厂家只开发了2.5Gbit／s的3R光转换单元OTU，对于吉比特以太网（GE）接口却只有2R中继，不能对信号的抖动进行有效抑制，从而系统的输出抖动超标造成传输距离受限；其二由于GE为异步信号，异步传输系统目前无法解决线路传输带来的抖动累积问题，无法实现长距离传输，两路由器采用不同的时钟时，如果路由器的缓存器（buffer）不是足够大，将会引起丢包；其三是因为GE信号在长途传输时，无法实现故障定位，对于信号劣化，也缺乏有效的监测手段，不能提供一定的OAM&P功能。 ——而反观采用SDH帧结构的POS信号效果则好得多。因为一方面IP信号借助于SDH的同步传输技术能充分保证网络的传输性能，且2.5Gbit／s 3R OTU器件技术非常成熟；另一方面IP业务层网管系统可利用SDH帧结构中提供的强大的开销和维护信号实现OAM＆P功能，使传输网络具有较好的可靠性。 ——现在，中国网通公司（CNC）已经决定采用“IP／SDH／WDM”方式建设全国范围内“IP over WDM”传输网络。该WDM网络的客户信号虽然还是SDH帧格式，但帧结构为VC-4-16C，承载的是IP信号，而中国电信的 WDM网络上的SDH客户信号帧结构则不是W-4的级联，业务上基本上都是电话信号 。 ——网通公司在组建骨干网时，除了采取租赁光纤 方式外，还开始建设自己的光缆骨干网。值得一提的是目前开始建设的两条光缆干线：北京—武汉 和北京—济南 ，首次采用1800km的G.655光纤，这显示了新公司的不同凡响和技术选择的前瞻性。虽然G.655光纤国内专家已经论证多次，但国内应用进展缓慢。另外，考虑到光缆线路扩容的难度，网通公司也首先采用管道光缆技术，采用气吹缆技术，本次工程一次敷设8个管道，以方便将来的光缆扩容。 4 总  结 ——当前，传送网络正在发生深刻的变化，目前至少中国电信、中国联通、中国网通、广电总局 4个运营商都在建设自己的国内长途光缆干线网。各个运营公司采取了不同的网络拓扑或技术，出现了技术方案的多元化趋势。国家骨干传送网将出现激烈的竞争，各运营商纷纷投资长途网络的主要原因在于更容易、更快地收回投资。多运营者环境下网间互通也成了大家关心的一个问题，国家标准也变得更加重要。如何在新形势下建设国家骨干光缆传送网是值得每一个运营者和从事传输研究的人们深入研究的问题。

作者:张成良  （信息产业部电信传输研究所   北京100045） 来源: 光纤日报

SNC-LAVALIN 被沈阳副市长诈骗500万美元 深受伤害

本地化运营非常重要 与政要绑定也有政治风险 中国司法制度无有效陪审员制度，量刑过程不公开，给司法腐败留下祸根。

兰万灵(中国)有限公司与中国银行沈阳分行合同纠纷案    　　原告兰万灵（中国）有限公司（SNC-LAVALIN （CHINA） ENGINEERING INC.），住所地加拿大不列颠哥伦比亚省温哥华市乔治西街1800-1075号（1800-1075， WEST GEORGIA STREET， VANCOUVER， BRITISH COLUMBIA， CANADA V6E 3C9）。 　　法定代表人罗伯特·特伯（ROBERT TRIBE），系该公司董事长。 　　委托代理人李金生，系北京市首创律师事务所律师。 　　被告中国银行沈阳分行，住所地沈阳市沈河区市府大路253号。 　　法定代表人黄克彬，系该分行行长。 　　委托代理人杨柳，系该分行职员。 　　委托代理人张凯，系该分行职员。 　　第三人沈阳路通-兰万灵建设工程有限公司，住所地沈阳经济技术开发区。 　　法定代表人翟力，系该公司董事长，已因刑事犯罪被追究责任 。 　　委托代理人谢洛德（ROD SCRIBAN），系该公司副董事长。 　　委托代理人柯建民，系该公司副总经理。 　　原告兰万灵（中国）有限公司与被告中国银行沈阳分行、第三人沈阳路通-兰万灵建设工程有限公司存款合同纠纷一案，本院于2001年12月 18日受理。本院民四庭副庭长宋坤赤担任审判长，与代理审判员白丽萍、代理审判员金蔓莉（主审人）共同组成合议庭，于2002年4月3日公开开庭审理了本案。原告兰万灵（中国）有限公司委托代理人李金生，被告中国银行沈阳分行委托代理人杨柳、张凯，第三人沈阳路通-兰万灵建设工程有限公司委托代理人谢洛德、柯建民到庭参加了诉讼。本案现已审理终结。 　　原告兰万灵（中国）有限公司诉称，1999年5月，经沈阳市人民政府批准，原告与沈阳富通房屋开发有限责任公司、新加坡福克斯国际发展私人有限公司 合资成立了沈阳路通-兰万灵建设工程有限公司 ，即本案第三人。1999年9月28日，第三人在被告中国银行沈阳分行开立资本金帐户，并用该公司公章及其法定代表人签字作为预留印鉴；同时，原告也为该帐户预留了原告代表埃伦拉麦的英文签字。后原告陆续向该资本金帐户汇入250万美元。2000年 11月22日，在第三人企业仅有原告一家出资、原告汇入的资本金未经验资、原告代表不知道的情况下，被告将原告汇入的资本金及利息共计252万美元取出，并转存为一年定期存款，又用该笔定期存款与第三人签订了质押贷款合同 。原告认为被告的行为违反我国法律及金融法规，因此起诉至法院，要求判令被告： 1、将原告汇入第三人资本金帐户的252万美元恢复原状； 2、承担本案诉讼费用。 　　原告主要提交了以下证据证明其主张：1、1999年9月28日，第三人在被告开立资本金帐户的“开户登记表”，上面记录客户名称为第三人，预留印鉴为第三人的公章、印有“翟力之印”的印章，翟力个人签字和埃伦拉麦的个人签字，并注明“两印鉴，两签字同时出现有效”。2、第三人企业法人营业执照，正本有效期为1999年5月7日至2001年3月1日。被告中国银行沈阳分行及第三人对上述证据无异议。 　　被告中国银行沈阳分行辨称：1、原告所称的资本金帐户是以第三人名义开立，因此该帐户内款项应归第三人所有，原告无权要求将该笔款项恢复原状；2、被告将第三人资本金帐户资金转存的行为，系在审核了第三人董事会决议、法定代表人签字、关于原告代表取消预留印鉴的传真件等材料后做出的，该行为符合法律规定。因此，应驳回原告的诉讼请求。 　　被告向法院提交了以下证据证明其主张：1、第三人董事会决议，决定向被告申请贷款2050万元并转存资本金帐户款项作为质押。2、第三人要求被告贷款2050万元及转存资本金帐户款项作为质押的申请，上面有第三人法定代表人翟力签字并加盖了第三人公章；3、第三人与被告签订的贷款合同和质押合同；4、沈阳盛达会计师事务所于1999年8月27日作出的验资报告；5、第三人要求办理更换印鉴的介绍信；5、原告代表埃伦拉麦声明取消其在资本金帐户上签字权的“传真件”，该“传真件”使用的是第三人文头纸，以中文书写，页眉或页脚处无传真发送或接收时间、发送方及接收方电话号码等记载事项，署名为 ALAIN LAMAY（埃伦拉麦的英文原名，与其在银行预留印鉴签字表面相同），日期为2000年10月2日，被告称该“传真件”不是由原告代表直接传真给被告，而是由第三人提交给被告。原告及第三人对被告提供证据的真实性提出异议，认为上述材料系第三人法定代表人翟力伪造，对原告及第三人没有效力。 　　第三人沈阳路通-兰万灵建设工程有限公司同意原告诉讼主张，并做如下补充：1、被告在将第三人的资本金帐户上款项转存时，第三人还处于设立阶段，只有临时营业执照，且另两家股东的投资都没有到位，原告投入的该笔资金亦未经过验资，公司没有开始正常运做。因此，原告作为第三人的实际出资股东起诉是合法的；2、第三人在开立资本金帐户时，第三人和原告代表分别预留了印鉴。被告在不符合预留印鉴的情况下将资金转存，应承担相应的法律责任。 　　综合原、被告及第三人举证、质证情况，经审理查明，1999年5月，经沈阳市人民政府批准，原告兰万灵（中国）有限公司与沈阳富通房屋开发有限责任公司、新加坡福克斯国际发展私人有限公司合资成立沈阳路通-兰万灵建设工程有限公司，即本案第三人。1999年9月28日，第三人在被告中国银行沈阳分行开立资本金帐户，开户登记表上“预留印鉴式样”一栏加盖了第三人的公章和法定代表人翟力的名章，以及翟力个人签字和原告代表埃伦拉麦（ALAIN LAMAY）的英文签字，并注明“两印鉴，两签字同时出现有效”。此后，原告陆续向第三人的该资本金帐户汇入出资250万美元。 　　2000年11月9日，第三人向被告申请取消原告代表埃伦拉麦在其资本金帐户的签字权，被告称第三人在申请时向其提交了一份“传真件”，上面有埃伦拉麦的英文签字，内容是要求取消其在第三人资本金帐户的签字权。被告依据该“传真件”为第三人办理了取消原告代表签字权的手续。同年11 月20日，第三人向被告提出申请贷款2050万元人民币，同时要求将其资本金帐户余额252万美元转为定期存款并为贷款作质押担保。后被告将第三人资本金帐户余额252万美元转出，用于为第三人贷款做质押担保。 　　另经本院在沈阳经济技术开发区工商局查询，第三人沈阳路通-兰万灵建设工程有限公司的工商档案显示其投资总额为2500万美元，注册资本 2000万美元，实际认缴金额980万美元，执照有效期限为1999年5月7日至2001年3月1日。被告出示的验资报告没有在工商档案中备案，且工商档案中没有各方股东出资情况的记载，第三人营业执照于2001年3月1日到期后，没有办理新的营业执照。 　　本院认为，第三人沈阳路通-兰万灵建设工程有限公司在被告中国银行沈阳分行开立资本金帐户，双方形成存款合同关系。第三人将企业公章、法定代表人翟力的名章，及翟力和原告代表的签字作为预留印鉴，且开户申请书中已注明“两印鉴，两签字同时出现有效”字样，应视为双方已对其在存款合同中的权利义务作出了明确约定。在接受第三人取消印鉴的申请时，被告有义务依合同约定在“两印鉴，两签字同时出现”的前提下严格审核申请书上的印鉴原件。被告称第三人在申请取消原告代表签字权时，提交了原告代表关于取消签字权的“传真件”，现原告及第三人对“传真件”的真实性予以否认，认为系第三人法定代表人翟力伪造；且该“传真件”的页眉或页脚处无传真发送或接收时间、发送方及接收方电话号码等记载事项，使用的不是原告而是第三人为名头的文头纸，且正文以中文书写，被告未提供正文为英文的文本，亦未举证证明该文书系原告传真给第三人，故只能认定该文书为复印件而非传真件。尽管该复印件上显示的原告代表埃伦拉麦签字与其在银行预留签字表面相同，但因复印件可繁殖复印，被告又未能提供该复印件的原本以证明确系原告代表所写，因此对该复印件的真实性不能确认。被告在审核第三人取消原告代表签字的申请时，疏于审核原告代表签字原件，亦未采取措施向原告代表核实该复印件的真实性，主观上存在过失，应对由此产生的后果承担相应的法律责任；第三人明知转存资本金帐户款项须有原告代表签字，却持复印件要求取消原告代表的签字权，并随后向被告申请转存其资本金帐户款项，造成该款从第三人资本金帐户转出，第三人也负有责任。原告兰万灵（中国）有限公司要求被告将转存款项恢复原状的请求，理由正当，应予支持。另外，第三人作为合同一方，有权就其帐户款项事宜向被告主张权利。同时，在本案立案时，第三人营业执照正本已过有效期，不能依法从事经营活动，且其各股东尚未依合资经营合同约定足额缴纳出资，应视为该企业处于歇业状态。第三人歇业后，既未办理注销登记，又未成立清算组，原告作为实际出资股东可以作为清算主体与第三人共同参加诉讼。综上，依照《中华人民共和国公司法》第一百九十一条，《中华人民共和国合同法》第六十条一款、第一百零七条之规定，判决如下： 　　一、被告中国银行沈阳分行于本判决生效后三十日内将其从第三人沈阳路通-兰万灵建设工程有限公司资本金帐户转存的款项252万美元转回第三人资本金帐户。 　　二、驳回原、被告及第三人其他诉讼请求。 　　本案案件受理费114，590元人民币，由被告中国银行沈阳分行承担。 　　如不服本判决，原告兰万灵（中国）有限公司可在本判决书送达之日起30日内，被告中国银行沈阳分行、第三人沈阳路通-兰万灵建设工程有限公司可在本判决书送达之日起15日内，向本院递交上诉状，并按对方当事人的人数提交副本，上诉于辽宁省高级人民法院。 　　审 判 长 宋 坤 赤 　　代理审判员 白 丽 萍 　　代理审判员 金 蔓 莉 　　二OO二年十一月八日 　　书 记 员 吴 松

http://www.lawtime.cn/info/wenshu/pjmscpwsyishen/2006110942191.html

OpenVPN How-to 1.0

重要历史文献 有空再翻译整理

OpenVPN HOWTO 1.0 Introduction This HOWTO is mainly relevant for setting up single-client or static site-to-site VPNs and is oriented more towards OpenVPN 1.x than 2.0. To take advantage of the OpenVPN 2.0 client/server capability, see the OpenVPN 2.0 HOWTO . This document describes setting up OpenVPN in a typical Home to Office telecommuting configuration. While this HOWTO presents in-depth configuration examples, simpler examples are shown in the examples section of the man page. Additional Articles and Documentation Many excellent articles and HOWTOs exist for configuring OpenVPN in different environments. Basic Tunnel Types There are two basic types of tunnels that one can create with OpenVPN:     * Routed IP tunnel s -- best used to route point-to-point IP traffic without broadcasts. Slightly more efficient than bridged ethernet tunnels and easier to configure. This HOWTO (below) covers routed IP tunnels.     * Bridged Ethernet Tunnels -- can be used to tunnel both IP and non-IP protocols. This type of tunnel is appropriate for applications which communicate via broadcasts, such as Windows file and print sharing (without a WINS server) and LAN games. Slightly more complex to configure. A Mini-HOWTO for bridged ethernet tunnels. Routed IP tunnel HOWTO Given the interrelated issues involved in configuring firewalls, VPNs, and NAT, we will attempt to describe a complete system configuration rather than isolating the VPN component of the setup. In our example, both Home and Office private networks are linked to the internet via two gateway machines which each have a public IP address. Each gateway machine contains two NICs, one connected to the private network, the other connected to the internet. The gateway machines provide NAT, firewall, and VPN services for the machines on the private networks. The Home and Office sides of the configuration are roughly symmetrical except the Office gateway machine has a fixed IP address while the Home machine has a DHCP dynamic address. In the following examples, all configuration files shown are also available in the OpenVPN distribution. Home and Office IP Networking Parameters Home Office Local Ethernet Subnet (Private Address) 10.0.1.0/24 10.0.0.0/24 Tunnel Endpoint (Private Address) 10.1.0.2 10.1.0.1 OpenVPN Gateway (Public Address) DHCP client, need not be explicitly specified 1.2.3.4             Installing OpenVPN If your system doesn't have the OpenSSL Library , you should download and install it. If you want to take advantage of compression on the VPN link, or you want to install OpenVPN as an RPM package, install the LZO Library . If you are using Linux 2.2 or earlier, download the TUN/TAP driver . Users of Linux 2.4.7 or greater should find the TUN/TAP driver already bundled with their kernel. Users of Linux 2.4.0 -> 2.4.6 should note the caveat at the end of the INSTALL file. Now download the latest release of OpenVPN . Install from tarball Unzip the distribution:     gzip -dc openvpn-1.6.0.tar.gz | tar xvf - Build OpenVPN:     cd openvpn-1.6.0     ./configure     make     make install If you didn't download the LZO Library, add --disable-lzo to the configure command. Other options can be enabled such as pthread support (./configure --enable-pthread) to improve latency during SSL/TLS dynamic key exchanges. The command     ./configure --help will show all configuration options. Install from RPM First build the RPM file. This will require that the OpenSSL, pthread, and LZO libraries are present. Normally only the LZO library requires an explicit download and install; the other libraries are present by default on most Linux distributions.     rpmbuild -tb openvpn-1.6.0.tar.gz The RPM build process will generate a lot of output. If the build succeeds, there should be a note near the end of the output stating the name of the binary RPM file which was written. Install the binary RPM with the command:     rpm -Uvh binary-RPM-file Configuring the TUN/TAP driver One-time Configuration Steps If you are using Linux 2.4.7 or higher, chances are good that the TUN/TAP driver is already bundled with your kernel. You can confirm this with the command     locate if_tun.h which should show a file such as /usr/include/linux/if_tun.h. For Linux 2.4.7 or higher, if you installed from the tarball, enter the following command to configure the TUN/TAP device node (you can omit this step if you installed from RPM, as the RPM install will do it automatically for you):     mknod /dev/net/tun c 10 200 If you are using Linux 2.2, you should obtain Version 1.1 of the TUN/TAP kernel module and follow the installation instructions. Once-per-reboot Configuration Steps On Linux, prior to using OpenVPN or any other program which uses TUN/TAP devices, you should load the TUN/TAP kernel module:     modprobe tun and enable IP forwarding:     echo 1 > /proc/sys/net/ipv4/ip_forward Configure Firewall and NAT This section assumes you are using Linux 2.4 with an iptables firewall . Here is a sample firewall configuration that provides NAT for machines on a private network to access the internet, stateful outgoing connection tracking, and OpenVPN support: sample-config-files/firewall.sh     #!/bin/bash     # A Sample OpenVPN-aware firewall.     # eth0 is connected to the internet.     # eth1 is connected to a private subnet.     # Change this subnet to correspond to your private     # ethernet subnet.  Home will use 10.0.1.0/24 and     # Office will use 10.0.0.0/24.     PRIVATE=10.0.0.0/24     # Loopback address     LOOP=127.0.0.1     # Delete old iptables rules     # and temporarily block all traffic.     iptables -P OUTPUT DROP     iptables -P INPUT DROP     iptables -P FORWARD DROP     iptables -F     # Set default policies     iptables -P OUTPUT ACCEPT     iptables -P INPUT DROP     iptables -P FORWARD DROP     # Prevent external packets from using loopback addr     iptables -A INPUT -i eth0 -s $LOOP -j DROP     iptables -A FORWARD -i eth0 -s $LOOP -j DROP     iptables -A INPUT -i eth0 -d $LOOP -j DROP     iptables -A FORWARD -i eth0 -d $LOOP -j DROP     # Anything coming from the Internet should have a real Internet address     iptables -A FORWARD -i eth0 -s 192.168.0.0/16 -j DROP     iptables -A FORWARD -i eth0 -s 172.16.0.0/12 -j DROP     iptables -A FORWARD -i eth0 -s 10.0.0.0/8 -j DROP     iptables -A INPUT -i eth0 -s 192.168.0.0/16 -j DROP     iptables -A INPUT -i eth0 -s 172.16.0.0/12 -j DROP     iptables -A INPUT -i eth0 -s 10.0.0.0/8 -j DROP     # Block outgoing NetBios (if you have windows machines running     # on the private subnet).  This will not affect any NetBios     # traffic that flows over the VPN tunnel, but it will stop     # local windows machines from broadcasting themselves to     # the internet.     iptables -A FORWARD -p tcp --sport 137:139 -o eth0 -j DROP     iptables -A FORWARD -p udp --sport 137:139 -o eth0 -j DROP     iptables -A OUTPUT -p tcp --sport 137:139 -o eth0 -j DROP     iptables -A OUTPUT -p udp --sport 137:139 -o eth0 -j DROP     # Check source address validity on packets going out to internet     iptables -A FORWARD -s ! $PRIVATE -i eth1 -j DROP     # Allow local loopback     iptables -A INPUT -s $LOOP -j ACCEPT     iptables -A INPUT -d $LOOP -j ACCEPT     # Allow incoming pings (can be disabled)     iptables -A INPUT -p icmp --icmp-type echo-request -j ACCEPT     # Allow services such as www and ssh (can be disabled)     iptables -A INPUT -p tcp --dport http -j ACCEPT     iptables -A INPUT -p tcp --dport ssh -j ACCEPT     # Allow incoming OpenVPN packets     # Duplicate the line below for each     # OpenVPN tunnel, changing --dport n     # to match the OpenVPN UDP port.     #     # In OpenVPN, the port number is     # controlled by the --port n option.     # If you put this option in the config     # file, you can remove the leading '--'     #     # If you taking the stateful firewall     # approach (see the OpenVPN HOWTO),     # then comment out the line below.     iptables -A INPUT -p udp --dport 1194 -j ACCEPT     # Allow packets from TUN/TAP devices.     # When OpenVPN is run in a secure mode,     # it will authenticate packets prior     # to their arriving on a tun or tap     # interface.  Therefore, it is not     # necessary to add any filters here,     # unless you want to restrict the     # type of packets which can flow over     # the tunnel.     iptables -A INPUT -i tun+ -j ACCEPT     iptables -A FORWARD -i tun+ -j ACCEPT     iptables -A INPUT -i tap+ -j ACCEPT     iptables -A FORWARD -i tap+ -j ACCEPT     # Allow packets from private subnets     iptables -A INPUT -i eth1 -j ACCEPT     iptables -A FORWARD -i eth1 -j ACCEPT     # Keep state of connections from local machine and private subnets     iptables -A OUTPUT -m state --state NEW -o eth0 -j ACCEPT     iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT     iptables -A FORWARD -m state --state NEW -o eth0 -j ACCEPT     iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT     # Masquerade local subnet     iptables -t nat -A POSTROUTING -s $PRIVATE -o eth0 -j MASQUERADE OpenVPN offers a few additional options on firewall setup:     * If both OpenVPN peers reference the other with an explicit --remote option, and stateful firewalls that provide UDP connection tracking (such as iptables) exist between the peers, it is possible to run OpenVPN without any explicit firewall rules, if both peers originate regular pings to each other to keep the connection alive. To do this, simply run OpenVPN with the --remote peer option, and specify --ping 15 to ensure that packets flow over the tunnel at least once every 15 seconds.     * The above option is less convenient if one of the peers changes its IP address frequently such as a DHCP or a dial-in peer . For these cases, the sample firewall configuration above will allow incoming packets on UDP port 1194 (OpenVPN's default UDP port) from any IP address. This should be considered safe in any of OpenVPN's secure modes, since all incoming tunnel packets must pass an authentication test or they will be dropped.     * If you choose to fully open OpenVPN's incoming UDP port as in the sample firewall configuration above, you might want to take advantage of the --tls-auth option to do double authentication on the TLS control channel, using both the RSA key and a pre-shared secret passphrase as a second line of defense against DoS or active attacks . For more information on --tls-auth, see the openvpn man page. Build RSA Certificates and Keys OpenVPN has two secure modes, one based on SSL/TLS security using RSA certificates and keys, the other using a pre-shared static key. While SSL/TLS + RSA keys is arguably the most secure option, static keys have the benefit of simplicity. If you want to use RSA keys, read on. For static keys, jump forward to the Build Pre-Shared Static Key section. We will build RSA certificates and keys using the openssl command , included in the OpenSSL library distribution. RSA certificates are public keys that also have other secure fields embedded in them such as the Common Name or email address of the certificate holder. OpenVPN provides the ability to write scripts to test these fields prior to authentication. For more information, see the --tls-verify option in the openvpn man page. In our example we will follow the apache convention of using the .crt file extension to denote certificate files and the .key file extension to denote private key files. Private key files must always be kept secure . Certificate files can be freely published or shared. Select one machine such as Office to be the key management machine . First edit the /usr/share/ssl/openssl.cnf file (this file may exist in a different place, so use locate openssl.cnf to find it). You may want to make some changes to this file:     * Make a directory to serve as your key working area and change dir to point to it.     * Consider increasing default_days so your VPN doesn't mysteriously stop working after exactly one year.     * Set certificate and private_key to point to your master certificate authority certificate and private key files which we will presently generate. In the examples below, we will assume that your certificate authority certificate is named my-ca.crt and your certificate authority private key is named my-ca.key.     * Note the files index.txt and serial. Initialize index.txt to be empty and serial to contain an initial serial number such as 01.     * If you are paranoid about key sizes, increase default_bits to 2048. OpenVPN will have no problem handling a 2048 bit RSA key if you have built OpenVPN with pthread support, to enable background processing of RSA keys. You can still use large keys even without pthread support, but you will see some latency degradation on the tunnel during SSL/TLS key negotiations. For a good article on choosing an RSA key size, see the April 2002 issue of Bruce Schneier's Crypto-Gram Newsletter. After openssl.cnf has been edited, create your master certificate authority certificate/private-key pair:     openssl req -nodes -new -x509 -keyout my-ca.key -out my-ca.crt -days 3650 This will create a master certificate authority certificate/private-key pair valid for 10 years. Now create certificate/private-key pairs for both Home and Office. When prompted for the common name, make sure to use a different name for Home and Office.     openssl req -nodes -new -keyout office.key -out office.csr     openssl ca -out office.crt -in office.csr     openssl req -nodes -new -keyout home.key -out home.csr     openssl ca -out home.crt -in home.csr Now copy home.crt, home.key, and my-ca.crt to Home over a secure channel, though actually only .key files should be considered non-public. Now create Diffie Hellman parameters on Office with the following command:     openssl dhparam -out dh1024.pem 1024 Increase the bit size from 1024 to 2048 if you also increased it in openssl.cnf. For the paranoid, consider omitting the -nodes option on the openssl commands above. This will cause each private key to be encrypted with a password, making the keys secure even if someone broke onto your server and stole your private key files. The downside of this approach is that every time you run OpenVPN, you will need to type in the password. For more information see the --askpass option in the openvpn man page. If you find manual RSA key management confusing, note that OpenVPN will interoperate with any X509 certificate management tool or service including the commercial CAs such as Thawte or Verisign. Check out the OpenCA project for an example of what's being done with certificate/key management in the Open Source realm. In addition, the OpenVPN distribution contains a small set of scripts which can be used to simplify RSA certificate and key management. Important Note on the use of commercial certificate authorities (CAs) with OpenVPN It should be noted that OpenVPN's security model in SSL/TLS mode is oriented toward users who will generate their own root certificate, and hence be their own CA . In SSL/TLS mode, OpenVPN authenticates its peer by checking that the peer-supplied certificate was signed by the CA certificate specified in the --ca option. Like the SSL-based secure web, the security of OpenVPN's SSL/TLS mode rests on the infeasibility of forging a root certificate signature.   This authentication procedure works perfectly well if you have generated your own root certificate, but presents a problem if you wish to use the root certificate of a commercial CA such as Thawte. If, for example, you specified Thawte's root certificate in the --ca option, any certificate signed by Thawte would now be able to authenticate with your OpenVPN peer -- certainly not what you would want. Luckily there is a solution to this problem in the --tls-verify option. This option will allow you to execute a command to check the contents of a certificate, to fine-tune the selection of which certificate is allowed, and which is not. See the script verify-cn in the sample-scripts subdirectory for an example of how to do this, and also see the man page for the --tls-verify option. Important Note on possible "Man-in-the-Middle" attack if clients do not verify the certificate of the server they are connecting to. See discussion here. http://openvpn.net/index.php/open-source/documentation/howto.html#mitm Configuration file using SSL/TLS mode and RSA certificates/keys In our example, we will use OpenVPN configuration files. OpenVPN allows options to be passed on either the command line or in one or more configuration files. Options in configuration files can omit the leading "--" that is required for command line options. Set up the following configuration files: sample-config-files/tls-office.conf     #     # Sample OpenVPN configuration file for     # office using SSL/TLS mode and RSA certificates/keys.     #     # '#' or ';' may be used to delimit comments.     # Use a dynamic tun device.     # For Linux 2.2 or non-Linux OSes,     # you may want to use an explicit     # unit number such as "tun1".     # OpenVPN also supports virtual     # ethernet "tap" devices.     dev tun     # 10.1.0.1 is our local VPN endpoint (office).     # 10.1.0.2 is our remote VPN endpoint (home).     ifconfig 10.1.0.1 10.1.0.2     # Our up script will establish routes     # once the VPN is alive.     up ./office.up     # In SSL/TLS key exchange, Office will     # assume server role and Home     # will assume client role.     tls-server     # Diffie-Hellman Parameters (tls-server only)     dh dh1024.pem     # Certificate Authority file     ca my-ca.crt     # Our certificate/public key     cert office.crt     # Our private key     key office.key     # OpenVPN 2.0 uses UDP port 1194 by default     # (official port assignment by iana.org 11/04).     # OpenVPN 1.x uses UDP port 5000 by default.     # Each OpenVPN tunnel must use     # a different port number.     # lport or rport can be used     # to denote different ports     # for local and remote.     ; port 1194     # Downgrade UID and GID to     # "nobody" after initialization     # for extra security.     ; user nobody     ; group nobody     # If you built OpenVPN with     # LZO compression, uncomment     # out the following line.     ; comp-lzo     # Send a UDP ping to remote once     # every 15 seconds to keep     # stateful firewall connection     # alive.  Uncomment this     # out if you are using a stateful     # firewall.     ; ping 15     # Uncomment this section for a more reliable detection when a system     # loses its connection.  For example, dial-ups or laptops that     # travel to other locations.     ; ping 15     ; ping-restart 45     ; ping-timer-rem     ; persist-tun     ; persist-key     # Verbosity level.     # 0 -- quiet except for fatal errors.     # 1 -- mostly quiet, but display non-fatal network errors.     # 3 -- medium output, good for normal operation.     # 9 -- verbose, good for troubleshooting     verb 3 sample-config-files/office.up     #!/bin/sh     route add -net 10.0.1.0 netmask 255.255.255.0 gw $5 sample-config-files/tls-home.conf     #     # Sample OpenVPN configuration file for     # home using SSL/TLS mode and RSA certificates/keys.     #     # '#' or ';' may be used to delimit comments.     # Use a dynamic tun device.     # For Linux 2.2 or non-Linux OSes,     # you may want to use an explicit     # unit number such as "tun1".     # OpenVPN also supports virtual     # ethernet "tap" devices.     dev tun     # Our OpenVPN peer is the office gateway.     remote 1.2.3.4     # 10.1.0.2 is our local VPN endpoint (home).     # 10.1.0.1 is our remote VPN endpoint (office).     ifconfig 10.1.0.2 10.1.0.1     # Our up script will establish routes     # once the VPN is alive.     up ./home.up     # In SSL/TLS key exchange, Office will     # assume server role and Home     # will assume client role.     tls-client     # Certificate Authority file     ca my-ca.crt     # Our certificate/public key     cert home.crt     # Our private key     key home.key     # OpenVPN 2.0 uses UDP port 1194 by default     # (official port assignment by iana.org 11/04).     # OpenVPN 1.x uses UDP port 5000 by default.     # Each OpenVPN tunnel must use     # a different port number.     # lport or rport can be used     # to denote different ports     # for local and remote.     ; port 1194     # Downgrade UID and GID to     # "nobody" after initialization     # for extra security.     ; user nobody     ; group nobody     # If you built OpenVPN with     # LZO compression, uncomment     # out the following line.     ; comp-lzo     # Send a UDP ping to remote once     # every 15 seconds to keep     # stateful firewall connection     # alive.  Uncomment this     # out if you are using a stateful     # firewall.     ; ping 15     # Uncomment this section for a more reliable detection when a system     # loses its connection.  For example, dial-ups or laptops that     # travel to other locations.     ; ping 15     ; ping-restart 45     ; ping-timer-rem     ; persist-tun     ; persist-key     # Verbosity level.     # 0 -- quiet except for fatal errors.     # 1 -- mostly quiet, but display non-fatal network errors.     # 3 -- medium output, good for normal operation.     # 9 -- verbose, good for troubleshooting     verb 3 sample-config-files/home.up     #!/bin/sh     route add -net 10.0.0.0 netmask 255.255.255.0 gw $5 Build A Pre-Shared Static Key In contrast with RSA key management, using a pre-shared static key has the benefit of simplicity. The major downside of using static keys is that you give up the notion of perfect forward secrecy, meaning that if an attacker steals your static key, everything that was ever encrypted with it is compromised. Generate a static key with the following command:     openvpn --genkey --secret static.key The static key file is formatted in ascii and looks like this:     -----BEGIN OpenVPN Static key V1-----     e5e4d6af39289d53     171ecc237a8f996a     97743d146661405e     c724d5913c550a0c     30a48e52dfbeceb6     e2e7bd4a8357df78     4609fe35bbe99c32     bdf974952ade8fb9     71c204aaf4f256ba     eeda7aed4822ff98     fd66da2efa9bf8c5     e70996353e0f96a9     c94c9f9afb17637b     283da25cc99b37bf     6f7e15b38aedc3e8     e6adb40fca5c5463     -----END OpenVPN Static key V1----- An OpenVPN static key file contains enough entropy to key both a 512 bit cipher key and a 512 bit HMAC key for authentication. Copy static.key to the other peer via a secure medium such as scp or copy-paste in ssh. Configuration File using a Pre-Shared Static Key In our example, we will use OpenVPN configuration files. OpenVPN allows options to be passed on either the command line or in one or more configuration files. Options in configuration files can omit the leading "--" that is required for command line options. Set up the following configuration files: sample-config-files/static-office.conf     #     # Sample OpenVPN configuration file for     # office using a pre-shared static key.     #     # '#' or ';' may be used to delimit comments.     # Use a dynamic tun device.     # For Linux 2.2 or non-Linux OSes,     # you may want to use an explicit     # unit number such as "tun1".     # OpenVPN also supports virtual     # ethernet "tap" devices.     dev tun     # 10.1.0.1 is our local VPN endpoint (office).     # 10.1.0.2 is our remote VPN endpoint (home).     ifconfig 10.1.0.1 10.1.0.2     # Our up script will establish routes     # once the VPN is alive.     up ./office.up     # Our pre-shared static key     secret static.key     # OpenVPN 2.0 uses UDP port 1194 by default     # (official port assignment by iana.org 11/04).     # OpenVPN 1.x uses UDP port 5000 by default.     # Each OpenVPN tunnel must use     # a different port number.     # lport or rport can be used     # to denote different ports     # for local and remote.     ; port 1194     # Downgrade UID and GID to     # "nobody" after initialization     # for extra security.     ; user nobody     ; group nobody     # If you built OpenVPN with     # LZO compression, uncomment     # out the following line.     ; comp-lzo     # Send a UDP ping to remote once     # every 15 seconds to keep     # stateful firewall connection     # alive.  Uncomment this     # out if you are using a stateful     # firewall.     ; ping 15     # Uncomment this section for a more reliable detection when a system     # loses its connection.  For example, dial-ups or laptops that     # travel to other locations.     ; ping 15     ; ping-restart 45     ; ping-timer-rem     ; persist-tun     ; persist-key     # Verbosity level.     # 0 -- quiet except for fatal errors.     # 1 -- mostly quiet, but display non-fatal network errors.     # 3 -- medium output, good for normal operation.     # 9 -- verbose, good for troubleshooting     verb 3 sample-config-files/office.up     #!/bin/sh     route add -net 10.0.1.0 netmask 255.255.255.0 gw $5 sample-config-files/static-home.conf     #     # Sample OpenVPN configuration file for     # home using a pre-shared static key.     #     # '#' or ';' may be used to delimit comments.     # Use a dynamic tun device.     # For Linux 2.2 or non-Linux OSes,     # you may want to use an explicit     # unit number such as "tun1".     # OpenVPN also supports virtual     # ethernet "tap" devices.     dev tun     # Our OpenVPN peer is the office gateway.     remote 1.2.3.4     # 10.1.0.2 is our local VPN endpoint (home).     # 10.1.0.1 is our remote VPN endpoint (office).     ifconfig 10.1.0.2 10.1.0.1     # Our up script will establish routes     # once the VPN is alive.     up ./home.up     # Our pre-shared static key     secret static.key     # OpenVPN 2.0 uses UDP port 1194 by default     # (official port assignment by iana.org 11/04).     # OpenVPN 1.x uses UDP port 5000 by default.     # Each OpenVPN tunnel must use     # a different port number.     # lport or rport can be used     # to denote different ports     # for local and remote.     ; port 1194     # Downgrade UID and GID to     # "nobody" after initialization     # for extra security.     ; user nobody     ; group nobody     # If you built OpenVPN with     # LZO compression, uncomment     # out the following line.     ; comp-lzo     # Send a UDP ping to remote once     # every 15 seconds to keep     # stateful firewall connection     # alive.  Uncomment this     # out if you are using a stateful     # firewall.     ; ping 15     # Uncomment this section for a more reliable detection when a system     # loses its connection.  For example, dial-ups or laptops that     # travel to other locations.     ; ping 15     ; ping-restart 45     ; ping-timer-rem     ; persist-tun     ; persist-key     # Verbosity level.     # 0 -- quiet except for fatal errors.     # 1 -- mostly quiet, but display non-fatal network errors.     # 3 -- medium output, good for normal operation.     # 9 -- verbose, good for troubleshooting     verb 3 sample-config-files/home.up     #!/bin/sh     route add -net 10.0.0.0 netmask 255.255.255.0 gw $5 Starting the VPN in SSL/TLS mode On Home, start the VPN with the command:     openvpn --config tls-home.conf On Office, start the VPN with the command:     openvpn --config tls-office.conf Starting the VPN in Static Key mode On Home, start the VPN with the command:     openvpn --config static-home.conf On Office, start the VPN with the command:     openvpn --config static-office.conf Test the VPN On Home, test the VPN by pinging Office through the tunnel:     ping 10.1.0.1 On Office, test the VPN by pinging Home through the tunnel:     ping 10.1.0.2 If these tests silently fail, you may want to re-edit the configuration files and set the verbosity level to 8 which will produce much more detailed debugging output. Also consult the FAQ for more information on troubleshooting. If these tests succeed, now try pinging through the tunnel using machines on the private networks other than the OpenVPN gateway machines, to test the routing. Basically any machine on the 10.0.1.0/24 subnet should be able to access any machine on the 10.0.0.0/24 subnet and vice versa. If that works, congratulations! If not, you might want to check out the OpenVPN Mailing List archives to see if anyone else has had a similar problem. If you don't find a resolution to your problem there, consider posting to the openvpn-users list. Make the VPN DHCP-aware If you recall, in our example network configuration, Home has a dynamic IP address which could change without warning. If you are using dhcpcd as your client daemon, it is easy to construct a script which will be run anytime the client's IP address changes. This script will be named something like /etc/dhcpc/dhcpcd-eth0.exe. Basically, you should add a line to this script which will send a SIGUSR1 or SIGHUP signal to the OpenVPN daemon such as:     killall -HUP openvpn When OpenVPN receives this signal it will close and reopen the network connection to its peer, using the new IP address assigned by DHCP. You should also use the --float option if you are connecting to a peer which may change its IP address due to a DHCP reset. It is also possible to handle DHCP resets with the SIGUSR1 signal which is like SIGHUP except it offers more fine-grained control over which OpenVPN subsystems are reset. A SIGUSR1 signal can also be generated internally based on --ping and --ping-restart. The --persist-tun option allows a reset without closing and reopening the TUN device (which allows seamless connectivity through the tunnel across DHCP resets). The --persist-remote-ip option allows for preservation of remote IP address across DHCP resets. This allows both OpenVPN peers to be DHCP clients. The --persist-key option doesn't re-read key files on restart (which allows an OpenVPN daemon to be restarted even if its privileges were downgraded with --user or --group). For more information on using OpenVPN in a dynamic IP address context, see the FAQ. OpenVPN can also be used in cases where both ends of the connection are dynamic. Start the VPN automatically on reboot First make a directory to store OpenVPN keys and configuration files such as /etc/openvpn. Decide whether you want to use TLS or Static Key mode and copy appropriate .conf, .up, .key, .pem, and .crt files to /etc/openvpn. Protect your .key files:     chmod go-rwx /etc/openvpn/*.key If you are using Linux iptables, edit the firewall configuration file firewall.sh, making changes appropriate to your site and copy to /etc/openvpn. Make a startup script that looks something like this: sample-config-files/openvpn-startup.sh     #!/bin/sh     # A sample OpenVPN startup script     # for Linux.     # openvpn config file directory     dir=/etc/openvpn     # load the firewall     $dir/firewall.sh     # load TUN/TAP kernel module     modprobe tun     # enable IP forwarding     echo 1 > /proc/sys/net/ipv4/ip_forward     # Invoke openvpn for each VPN tunnel     # in daemon mode.  Alternatively,     # you could remove "--daemon" from     # the command line and add "daemon"     # to the config file.     #     # Each tunnel should run on a separate     # UDP port.  Use the "port" option     # to control this.  Like all of     # OpenVPN's options, you can     # specify "--port 8000" on the command     # line or "port 8000" in the config     # file.     openvpn --cd $dir --daemon --config vpn1.conf     openvpn --cd $dir --daemon --config vpn2.conf     openvpn --cd $dir --daemon --config vpn2.conf And make a shutdown script like this: sample-config-files/openvpn-shutdown.sh     #!/bin/sh     # stop all openvpn processes     killall -TERM openvpn Finally, add calls to openvpn-startup.sh and openvpn-shutdown.sh to your system startup and shutdown scripts or to your /etc/init.d directory. Managing startup and shutdown of multiple OpenVPN tunnels Here is a sample /etc/init.d script which will automatically create an OpenVPN tunnel for each .conf file in /etc/openvpn. This script is installed by default if you install OpenVPN from an RPM package. sample-scripts/openvpn.init     #!/bin/sh     #     # openvpn       This shell script takes care of starting and stopping     #               openvpn on RedHat or other chkconfig-based system.     #     # chkconfig: 345 24 76     #     # description: OpenVPN is a robust and highly flexible tunneling application that     #              uses all of the encryption, authentication, and certification features     #              of the OpenSSL library to securely tunnel IP networks over a single     #              UDP port.     #     # Contributed to the OpenVPN project by     # Douglas Keller <doug@voidstar.dyndns.org>     # 2002.05.15     # To install:     #   copy this file to /etc/rc.d/init.d/openvpn     #   shell> chkconfig --add openvpn     #   shell> mkdir /etc/openvpn     #   make .conf or .sh files in /etc/openvpn (see below)     # To uninstall:     #   run: chkconfig --del openvpn     # Author's Notes:     #     # I have created an /etc/init.d init script and enhanced openvpn.spec to     # automatically register the init script.  Once the RPM is installed you     # can start and stop OpenVPN with "service openvpn start" and "service     # openvpn stop".     #     # The init script does the following:     #     # - Starts an openvpn process for each .conf file it finds in     #   /etc/openvpn.     #     # - If /etc/openvpn/xxx.sh exists for a xxx.conf file then it executes     #   it before starting openvpn (useful for doing openvpn --mktun...).     #     # - In addition to start/stop you can do:     #     #   service openvpn reload - SIGHUP     #   service openvpn reopen - SIGUSR1     #   service openvpn status - SIGUSR2     #     # Modifications:     #     # 2003.05.02     #   * Changed == to = for sh compliance (Bishop Clark).     #   * If condrestart|reload|reopen|status, check that we were     #     actually started (James Yonan).     #   * Added lock, piddir, and work variables (James Yonan).     #   * If start is attempted twice, without an intervening stop, or     #     if start is attempted when previous start was not properly     #     shut down, then kill any previously started processes, before     #     commencing new start operation (James Yonan).     #   * Do a better job of flagging errors on start, and properly     #     returning success or failure status to caller (James Yonan).     #     # 2005.04.04     #   * Added openvpn-startup and openvpn-shutdown script calls     #     (James Yonan).     #     # Location of openvpn binary     openvpn=""     openvpn_locations="/usr/sbin/openvpn /usr/local/sbin/openvpn"     for location in $openvpn_locations     do       if [ -f "$location" ]       then         openvpn=$location       fi     done     # Lockfile     lock="/var/lock/subsys/openvpn"     # PID directory     piddir="/var/run/openvpn"     # Our working directory     work=/etc/openvpn     # Source function library.     . /etc/rc.d/init.d/functions     # Source networking configuration.     . /etc/sysconfig/network     # Check that networking is up.     if [ ${NETWORKING} = "no" ]     then       echo "Networking is down"       exit 0     fi     # Check that binary exists     if ! [ -f  $openvpn ]     then       echo "openvpn binary not found"       exit 0     fi     # See how we were called.     case "$1" in       start)         echo -n $"Starting openvpn: "         /sbin/modprobe tun >/dev/null 2>&1         # From a security perspective, I think it makes         # sense to remove this, and have users who need         # it explictly enable in their --up scripts or         # firewall setups.         #echo 1 > /proc/sys/net/ipv4/ip_forward         # Run startup script, if defined         if [ -f $work/openvpn-startup ]; then             $work/openvpn-startup         fi         if [ ! -d  $piddir ]; then             mkdir $piddir         fi         if [ -f $lock ]; then             # we were not shut down correctly             for pidf in `/bin/ls $piddir/*.pid 2>/dev/null`; do               if [ -s $pidf ]; then             kill `cat $pidf` >/dev/null 2>&1               fi               rm -f $pidf             done             rm -f $lock             sleep 2         fi         rm -f $piddir/*.pid         cd $work         # Start every .conf in $work and run .sh if exists         errors=0         successes=0         for c in `/bin/ls *.conf 2>/dev/null`; do             bn=${c%%.conf}             if [ -f "$bn.sh" ]; then             . $bn.sh             fi             rm -f $piddir/$bn.pid             $openvpn --daemon --writepid $piddir/$bn.pid --config $c --cd $work             if [ $? = 0 ]; then             successes=1             else             errors=1             fi         done         if [ $errors = 1 ]; then             failure; echo         else             success; echo         fi         if [ $successes = 1 ]; then             touch $lock         fi         ;;       stop)         echo -n $"Shutting down openvpn: "         for pidf in `/bin/ls $piddir/*.pid 2>/dev/null`; do           if [ -s $pidf ]; then             kill `cat $pidf` >/dev/null 2>&1           fi           rm -f $pidf         done         # Run shutdown script, if defined         if [ -f $work/openvpn-shutdown ]; then             $work/openvpn-shutdown         fi         success; echo         rm -f $lock         ;;       restart)         $0 stop         sleep 2         $0 start         ;;       reload)         if [ -f $lock ]; then             for pidf in `/bin/ls $piddir/*.pid 2>/dev/null`; do             if [ -s $pidf ]; then                 kill -HUP `cat $pidf` >/dev/null 2>&1             fi             done         else             echo "openvpn: service not started"             exit 1         fi         ;;       reopen)         if [ -f $lock ]; then             for pidf in `/bin/ls $piddir/*.pid 2>/dev/null`; do             if [ -s $pidf ]; then                 kill -USR1 `cat $pidf` >/dev/null 2>&1             fi             done         else             echo "openvpn: service not started"             exit 1         fi         ;;       condrestart)         if [ -f $lock ]; then             $0 stop             # avoid race             sleep 2             $0 start         fi         ;;       status)         if [ -f $lock ]; then             for pidf in `/bin/ls $piddir/*.pid 2>/dev/null`; do             if [ -s $pidf ]; then                 kill -USR2 `cat $pidf` >/dev/null 2>&1             fi             done             echo "Status written to /var/log/messages"         else             echo "openvpn: service not started"             exit 1         fi             ;;       *)         echo "Usage: openvpn {start|stop|restart|condrestart|reload|reopen|status}"         exit 1         ;;     esac     exit 0 Instantiate an OpenVPN daemon using inetd or xinetd The common xinetd service can be used to automatically instantiate an OpenVPN daemon upon receipt of an initial datagram from a remote peer. This xinetd configuration will cause xinetd to listen on UDP port 1194 for the first datagram of an incoming OpenVPN session (using a pre-shared key), at which time xinetd will automatically instantiate an OpenVPN daemon to handle the session. Note the use of the --inactive switch which will cause the OpenVPN daemon to time out and exit after 10 minutes of idle time. After the OpenVPN daemon exits for whatever reason, the xinetd service will resume listening on the port, and will again instantiate an OpenVPN daemon to handle additional incoming connections. Also note that xinetd will initially instantiate the OpenVPN daemon with root privileges, but OpenVPN will subsequently (after reading the protected key file) downgrade its privilege to nobody. The key file can be generated with the following command:     openvpn --genkey --secret key Note that each OpenVPN tunnel needs to run on its own separate port number, and needs its own xinetd configuration file. This is because OpenVPN needs specific information on each potential incoming connection, including key files, TUN/TAP devices, tunnel endpoints, and routing configuration. At this point in OpenVPN's development, it is not capable of handling any sort of incoming connection template that would allow a single configuration file to describe a large class of potential connecting clients. Since OpenVPN is implemented as a UDP server, it cannot take advantage of the infrastructure available to forking TCP servers which listen on a fixed port number, then dynamically fork off a new handling daemon for each client session. Nonetheless, incoming connection templates are on the wish list and may be implemented if there is sufficient interest and support from the developer and user community. sample-config-files/xinetd-server-config     # An xinetd configuration file for OpenVPN.     #     # This file should be renamed to openvpn or something suitably     # descriptive and copied to the /etc/xinetd.d directory.     # xinetd can then be made aware of this file by restarting     # it or sending it a SIGHUP signal.     #     # For each potential incoming client, create a separate version     # of this configuration file on a unique port number.  Also note     # that the key file and ifconfig endpoints should be unique for     # each client.  This configuration assumes that the OpenVPN     # executable and key live in /root/openvpn.  Change this to fit     # your environment.     service openvpn_1     {             type            = UNLISTED             port            = 1194             socket_type     = dgram             protocol        = udp             wait            = yes             user            = root             server          = /root/openvpn/openvpn             server_args     = --inetd --dev tun --ifconfig 10.4.0.2 10.4.0.1 --secret /root/openvpn/key --inactive 600 --user nobody     } sample-config-files/xinetd-client-config     # This OpenVPN config file     # is the client side counterpart     # of xinetd-server-config     dev tun     ifconfig 10.4.0.1 10.4.0.2     remote my-server     port 1194     user nobody     secret /root/openvpn/key     inactive 600

来源: http://openvpn.net/index.php/open-source/documentation/miscellaneous/88-1xhowto.html