[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Documentation/network/ipsec/rasvpn.xml: 1.7 -> 1.12
以下のページの更新をしました。ツッコミをお願いします。
Documentation/network/ipsec/rasvpn.xml: 1.7 -> 1.12
水曜日までに異議がなければ、 commit します。
> revision 1.12
> date: 2006/04/10 15:46:38; author: kano; state: Exp; lines: +5 -5
> fix typo
> ----------------------------
> revision 1.11
> date: 2006/03/27 16:07:06; author: kano; state: Exp; lines: +3 -3
> fix typo
> ----------------------------
> revision 1.10
> date: 2006/03/21 04:08:31; author: kano; state: Exp; lines: +3 -3
> fix typo
> ----------------------------
> revision 1.9
> date: 2006/03/18 03:34:47; author: kano; state: Exp; lines: +4 -4
> fix typo
> ----------------------------
> revision 1.8
> date: 2005/12/25 16:15:18; author: jschauma; state: Exp; lines: +10 -10
> some spelling fixes from Wouter Schoot
すべて typo 等の修正で、
訳に影響するのは 1 箇所のみです。
以下、訳と原文の差分です。
--- Documentation/network/ipsec/rasvpn.xml.orig 2006-04-11 00:50:25.000000000 +0900
+++ Documentation/network/ipsec/rasvpn.xml 2006-04-11 00:50:25.000000000 +0900
@@ -5,10 +5,10 @@
<webpage id="ja-Documentation-network-ipsec-rasvpn">
<config param="desc" value="リモートユーザーアクセス VPN の構築方法"/>
-<config param="cvstag" value="$NetBSD: rasvpn.xml,v 1.7 2005/06/13 11:13:24 rpaulo Exp $"/>
+<config param="cvstag" value="$NetBSD: rasvpn.xml,v 1.12 2006/04/10 15:46:38 kano Exp $"/>
<!-- Based on english version: -->
-<!-- NetBSD: rasvpn.xml,v 1.7 2005/06/13 11:13:24 rpaulo Exp -->
-<config param="rcsdate" value="$Date: 2005/06/13 11:13:24 $"/>
+<!-- NetBSD: rasvpn.xml,v 1.12 2006/04/10 15:46:38 kano Exp -->
+<config param="rcsdate" value="$Date: 2006/04/10 15:46:38 $"/>
<head>
<!-- Copyright (c) 2005 Emmanuel Dreyfus. ALL RIGHTS RESERVED. -->
@@ -504,7 +504,7 @@
ログイン名を <code>-u</code> オプションで指定します。
パスワードは端末上で入力を促されます。
<programlisting>$ racoonctl vc -u username 192.0.2.50
-Pasword: password
+Password: password
Bound to address 10.99.99.3
==========================================================
Flying pigs LTD
Index: Documentation/network/ipsec/rasvpn.xml
===================================================================
RCS file: /cvsroot/htdocs/Documentation/network/ipsec/rasvpn.xml,v
retrieving revision 1.7
retrieving revision 1.12
diff -u -r1.7 -r1.12
--- Documentation/network/ipsec/rasvpn.xml 13 Jun 2005 11:13:24 -0000 1.7
+++ Documentation/network/ipsec/rasvpn.xml 10 Apr 2006 15:46:38 -0000 1.12
@@ -5,8 +5,8 @@
<webpage id="Documentation-network-ipsec-rasvpn">
<config param="desc" value="How to build a remote user access VPN"/>
-<config param="cvstag" value="$NetBSD: rasvpn.xml,v 1.7 2005/06/13 11:13:24 rpaulo Exp $"/>
-<config param="rcsdate" value="$Date: 2005/06/13 11:13:24 $"/>
+<config param="cvstag" value="$NetBSD: rasvpn.xml,v 1.12 2006/04/10 15:46:38 kano Exp $"/>
+<config param="rcsdate" value="$Date: 2006/04/10 15:46:38 $"/>
<head>
<!-- Copyright (c) 2005 Emmanuel Dreyfus. ALL RIGHTS RESERVED. -->
@@ -65,7 +65,7 @@
<para>User authentication for VPN access can be done by different
methods:
<itemizedlist>
- <listitem>Group password (every users have the same
+ <listitem>Group password (all users have the same
password)</listitem>
<listitem>Login and password</listitem>
<listitem>x509 certificate</listitem>
@@ -94,7 +94,7 @@
authenticate to the VPN gateway, and the VPN gateway must authenticate
to the remote user. If the mutual authentication is not performed,
then there is a loophole open for Man in the Middle (MiM) attacks,
- where an attacker can masquerade as athe VPN gateway and collect
+ where an attacker can masquerade as the VPN gateway and collect
user passwords.</para>
<para>We said the remote user will authenticate using login and
@@ -129,7 +129,7 @@
<para>IPsec phase 1 is part of the IPsec Key Exchange (IKE) operations
performed by the IKE daemon, also known as &man.racoon.8; in NetBSD.
- It's goal is to authenticate the peers and set up master keys for
+ Its goal is to authenticate the peers and set up master keys for
performing a secured IPsec phase 2. The goal of phase 2 is to derive
the keys used for exchanging IPsec traffic. Phase 2 rekeying can
occur regularly while IPsec traffic is exchanged.</para>
@@ -139,9 +139,9 @@
<itemizedlist>
<listitem>pre-shared keys are not bound to logins. We have no
management tools to handle them properly, leaving a group
- password as the only managable option.</listitem>
+ password as the only manageable option.</listitem>
<listitem>IPsec phase 1 authentication is supposed to be
- symetric: pre-shared keys on both endpoints or certificates on
+ symmetric: pre-shared keys on both endpoints or certificates on
both endpoints. This is not what we are looking for.</listitem>
</itemizedlist>
</para>
@@ -163,7 +163,7 @@
<title>Hybrid auth</title>
<para>Hybrid auth is another IKE extension, that makes phase 1
- asymetric. During phase 1, the VPN gateway can use a certificate,
+ asymmetric. During phase 1, the VPN gateway can use a certificate,
while the remote user does not have to authenticate. After phase
1 we are in a situation where:
<itemizedlist>
@@ -215,7 +215,7 @@
<title>IKE fragmentation and ESP fragmentation</title>
<para>Remote users will often connect from behind DSL modem-router
- appliances. Most of these devices are uterly broken when dealing
+ appliances. Most of these devices are utterly broken when dealing
with big UDP packets: they assume UDP can only be used for DNS
requests and will drop bigger or fragmented UDP packets. IKE
transactions and ESP over UDP will tend to use big UDP packets,
@@ -234,7 +234,7 @@
<title>Dead Peer Detection</title>
<para>Last problem: the remote user Internet connection can be
- unstable, leading to spurious deconnections. The only built-in
+ unstable, leading to spurious disconnections. The only built-in
mechanism IPsec has to handle that is to force IKE phase 2 rekeying
after some time. If the peer is not on-line anymore, it will fail,
thus causing the VPN tunnel to be destroyed.</para>
@@ -366,7 +366,7 @@
For now only IPv4 configuration is supported. The VPN address pool
is defined there, by a base address (<code>network4</code>) and a
pool size (<code>pool_size</code>). <code>auth_source</code>
- explains how the login and passwrod are validated. Possible values
+ explains how the login and password are validated. Possible values
are <code>system</code>, to validate against the system user
database, <code>pam</code> to use the Pluggable Authentication
Module (PAM) system (<filename>/etc/pam.d/racoon</filename> will be
@@ -394,7 +394,7 @@
<para>Using ESP fragmentation, it is possible to exchange IP packets
of any size through the tunnel. However, there is a special case
for TCP, which may have trouble with Path Maximum Transmission
- nit (PMTU) discovery. The solution is to use Maximum Segment Size
+ Unit (PMTU) discovery. The solution is to use Maximum Segment Size
(MSS) clamping. This can be done in
<filename>/etc/ipnat.conf</filename>, assuming your VPN internal
address pool is 10.99.99.0/24:
@@ -412,11 +412,11 @@
</sect3>
<sect3 id="firewall">
- <title>Interraction with firewalls</title>
+ <title>Interaction with firewalls</title>
<para>In this VPN solution, the client needs to send UDP packets
to ports 500 and 4500 of the VPN gateway. The first packets
- are exchanged on port 500, then NAT-T negociation moves the
+ are exchanged on port 500, then NAT-T negotiation moves the
transaction to port 4500.</para>
<para>Firewalls in front of the VPN gateway must be configured
@@ -443,7 +443,7 @@
pfs_group 2;
}</programlisting></para>
- <para>Additionnaly, you need to create a
+ <para>Additionally, you need to create a
<filename>/etc/radius.conf</filename> file that contains the
RADIUS server address and the secret shared with the RADIUS server.
This file must be owned by root and mode 0600 in order to keep
@@ -538,7 +538,7 @@
<code>-u</code> option and the password is prompted on the
terminal:
<programlisting>$ racoonctl vc -u username 192.0.2.50
-Pasword: password
+Password: password
Bound to address 10.99.99.3
==========================================================
Flying pigs LTD