个人工具

“UbuntuHelp:SSH VPN”的版本间的差异

来自Ubuntu中文

跳转至： 导航, 搜索
小
小
第1行： 第1行：
−
{{From|https://help.ubuntu.com/community/SSH_VPN}}
+
{{From|https://help.ubuntu.com/community/SSH VPN}}
−
{{Languages|UbuntuHelp:SSH_VPN}}
+
{{Languages|UbuntuHelp:SSH VPN}}
 +
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
 +
<html>
 +
<head>
 +
<meta http-equiv="Content-Type" content="text/html;charset=utf-8">
 +
<meta name="robots" content="index,nofollow">
  
  
−
This page details how to set up an SSH VPN.
+
<title>SSH - Community Ubuntu Documentation</title>
  
−
NB: You MUST be using OpenSSH version 4.3 or better to do this-- this means that this will NOT work with Ubuntu 6.06 or less's default packages -- it will only work with the recently released Edgy, or with a locally compiled SSH version 4.3 or better.
+
<script type="text/javascript">
 +
<!--// common functions
  
−
== Introduction ==
+
// We keep here the state of the search box
 +
searchIsDisabled = false;
  
−
OpenSSH version 4.3 introduced a new feature: the ability to create on-the-fly "Virtual Private Networks" via the tunnel driver, or "tun" driver. This feature allows you to create a network interface that bridges two physically disparate network segments. A quick diagram:
+
function searchChange(e) {
−
<pre><nowiki>
+
// Update search buttons status according to search box content.
−
+---------------+            OpenSSH 4.3          +---------------+
+
// Ignore empty or whitespace search term.
−
|  Machine A  | tun0 -- Tunnel Interface -- tun0 |  Machine B  |
+
var value = e.value.replace(/\s+/, '');
−
|  Has a tunnel | <------------------------------->|  Has a tunnel | 
+
if (value == '' || searchIsDisabled) {
−
|  and ethernet | 10.0.0.100            10.0.0.200 |  and ethernet |
+
searchSetDisabled(true);
−
+-------+-------+    point to point connection    +-------+-------+
+
} else {
−
eth0 |                 creates a bridge                | eth0 
+
searchSetDisabled(false);
−
*0.0.100 |              that plugs machine B              | 192.168.0.100
+
}
−
port 22  |                  into network A                  |         
+
}
−
forwarded |                                                  |
+
−
here    |                                                  |
+
−
+-------+-------+          +-~-~-~-~-~-~-~-+      +-------+-------+
+
−
|  Network A  |          |              |      |  Network B  |
+
−
|  10.0.0.1/24  | 1.2.3.4  |  The Internet |      | 192.168.0.1/24|
+
−
|  Has internet |<-------->|              |<----->|  Has internet |
+
−
|  NAT gateway  | Routable |              |      |  NAT gateway  |
+
−
+---------------+ Address  +-~-~-~-~-~-~-~-+      +---------------+
+
−
</nowiki></pre>
+
−
What does this diagram represent? In this case, we have two machines, machine A and machine B. Machine A is connected to network A via ethernet, and machine B is connected to network B via ethernet. Machine A's IP address on Network A is 10.0.0.100, and Machine B's IP address on Network B is 192.168.0.100. Each network has an internet NAT gateway to allow for internet connectivity.
+
  
−
In this example, we are connecting machine B to network A via an ssh tunnel interface. Machine A already has an IP addresses on network A: its ethernet interface address (10.0.0.100). Machine B must also be allocated one IP address on network A: its tunnel interface address (10.0.0.200).
+
function searchSetDisabled(flag) {
 +
// Enable or disable search
 +
document.getElementById('fullsearch').disabled = flag;
 +
document.getElementById('titlesearch').disabled = flag;
 +
}
  
−
Also, Machine B must have some access to the ssh server on Machine A; the most direct way for this to happen is that Machine A must have either a globally routable address itself; or (as is diagramed), port 22 (or whatever port ssh is running on) must be forwarded to Machine A by the NAT system. There are other ways to allow Machine B access to Machine A's ssh server, but I will leave these as an exercise for the reader.
+
function searchFocus(e) {
 +
// Update search input content on focus
 +
if (e.value == 'Search') {
 +
e.value = '';
 +
e.style.color = 'black';
 +
searchIsDisabled = false;
 +
}
 +
}
  
−
Once the tunnel is set up, Machine B will be able to directly access Network A. In other words, Machine B would be "plugged in" to Network A via its tunnel with Machine A. Of couse, the devil's in the details: how do you set all this up?
+
function searchBlur(e) {
 +
// Update search input content on blur
 +
if (e.value == '') {
 +
e.value = 'Search';
 +
e.style.color = 'gray';
 +
searchIsDisabled = true;
 +
}
 +
}
  
−
== IP Forwarding ==
+
function actionsMenuInit(title) {
 +
// Initiliaze action menu
 +
for (i = 0; i < document.forms.length; i++) {
 +
var form = document.forms[i];
 +
if (form.className == 'actionsmenu') {
 +
// Check if this form needs update
 +
var div = form.getElementsByTagName('div')[0];
 +
var label = div.getElementsByTagName('label')[0];
 +
if (label) {
 +
// This is the first time: remove label and do buton.
 +
div.removeChild(label);
 +
var dobutton = div.getElementsByTagName('input')[0];
 +
div.removeChild(dobutton);
 +
// and add menu title
 +
var select = div.getElementsByTagName('select')[0];
 +
var item = document.createElement('option');
 +
item.appendChild(document.createTextNode(title));
 +
item.value = 'show';
 +
select.insertBefore(item, select.options[0]);
 +
select.selectedIndex = 0;
 +
}
 +
}
 +
}
 +
}
 +
//-->
 +
</script>
  
−
Of course the first and most obvious thing is that you'd better have IP forwarding enabled.
+
<link rel="stylesheet" type="text/css" charset="utf-8" media="all" href="/htdocs/ubuntu/css/common.css">
 +
<link rel="stylesheet" type="text/css" charset="utf-8" media="screen" href="/htdocs/ubuntu/css/screen.css">
 +
<link rel="stylesheet" type="text/css" charset="utf-8" media="print" href="/htdocs/ubuntu/css/print.css">
 +
<link rel="stylesheet" type="text/css" charset="utf-8" media="projection" href="/htdocs/ubuntu/css/projection.css">
  
−
on Machine A (and it wouldn't hurt on B), execute:
+
<link rel="Start" href="/community/UserDocumentation">
−
<pre><nowiki>
+
<link rel="Alternate" title="Wiki Markup" href="/community/SSH?action=raw">
−
# echo 1 > /proc/sys/net/ipv4/ip_forward
+
<link rel="Alternate" media="print" title="Print View" href="/community/SSH?action=print">
−
</nowiki></pre>
+
<link rel="Search" href="/community/FindPage">
−
(# is the root prompt, not a character to type)
+
<link rel="Index" href="/community/TitleIndex">
 +
<link rel="Glossary" href="/community/WordIndex">
 +
<link rel="Help" href="/community/HelpOnFormatting">
 +
</head>
  
−
== The SSH Command ==
+
<body  lang="en" dir="ltr">
  
−
The actual SSH command that gets the ball rolling is quite simple:
+
<script xmlns="" src="https://ssl.google-analytics.com/urchin.js" type="text/javascript"></script>
 +
<script xmlns="" type="text/javascript"><![CDATA[
 +
_uacct = "UA-737845-5";
 +
urchinTracker();
 +
]]></script>
 +
<div id="header">
 +
<div id="mastwrap"><div id="masthead">
 +
<div id="logo"><a href="/community/UserDocumentation">Community Ubuntu Documentation</a></div>
  
−
on Machine B, execute:
+
<form id="searchform" method="get" action="">
−
<pre><nowiki>
+
<div>
−
# ssh -w 0:0 1.2.3.4
+
<input type="hidden" name="action" value="fullsearch">
−
</nowiki></pre>
+
<input type="hidden" name="context" value="180">
 +
<label for="searchinput">Search:</label>
 +
<input id="searchinput" type="text" name="value" value="" size="20"
 +
onfocus="searchFocus(this)" onblur="searchBlur(this)"
 +
onkeyup="searchChange(this)" onchange="searchChange(this)" alt="Search">
 +
<input id="titlesearch" name="titlesearch" type="submit"
 +
value="Titles" alt="Search Titles">
 +
<input id="fullsearch" name="fullsearch" type="submit"
 +
value="Text" alt="Search Full Text">
 +
</div>
 +
</form>
 +
<script type="text/javascript">
 +
<!--// Initialize search form
 +
var f = document.getElementById('searchform');
 +
f.getElementsByTagName('label')[0].style.display = 'none';
 +
var e = document.getElementById('searchinput');
 +
searchChange(e);
 +
searchBlur(e);
 +
//-->
 +
</script>
  
−
This command creates a tunnel interface named tun0 on both the client and server systems. In keeping with our diagram above, the server is Machine A (with a globally routable IP address of 1.2.3.4), and the client is Machine B.
 
  
−
Note that you will more than likely need to be root on both systems in order for ssh to be able to create these interfaces. Additionally, you will need the following settings in your sshd_config on Machine A (the server):
+
<div id="sisternav">
 +
<ul>
 +
<li id="plain">
 +
<a href="https://help.ubuntu.com/6.06"
 +
accesskey="t">6.06 LTS</a>
 +
</li>
 +
<li id="plain">
 +
<a href="https://help.ubuntu.com/6.10"
 +
accesskey="t">6.10</a>
 +
</li>
 +
<li id="plain">
 +
<a href="https://help.ubuntu.com/7.04"
 +
accesskey="t">7.04</a>
 +
</li>
 +
<li id="current">
 +
<a href="https://help.ubuntu.com/community"
 +
accesskey="t">Community Docs</a>
 +
</li>
 +
</ul>
 +
</div>
  
−
<pre><nowiki>
+
</div></div>
−
PermitRootLogin yes
+
−
PermitTunnel yes
+
−
</nowiki></pre>
+
  
−
If no errors occur, then you should be able to see a tun0 interface on both systems as existing, but unconfigured:
+
<ul class="extranav">
−
Machine A:
+
<li><a href="/community/UserDocumentation">User Documentation</a></li>
−
<pre><nowiki>
+
</ul>
−
# ifconfig tun0
+
−
tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
+
−
POINTOPOINT NOARP MULTICAST  MTU:1500  Metric:1
+
−
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
+
−
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
+
−
collisions:0 txqueuelen:500
+
−
RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
+
−
</nowiki></pre>
+
  
−
Machine B:
+
</div>
−
<pre><nowiki>
+
−
# ifconfig tun0
+
−
tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
+
−
POINTOPOINT NOARP MULTICAST  MTU:1500  Metric:1
+
−
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
+
−
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
+
−
collisions:0 txqueuelen:500
+
−
RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
+
−
</nowiki></pre>
+
  
−
== Configuring the Interfaces ==
+
<div id="page" lang="en" dir="ltr"><!-- start page -->
  
−
At this point, we've got interfaces, but they're unconfigured. All we need to do to configure them is give them each an IP address:
 
  
−
Machine A:
+
<h1 id="title"><a title="Click to do a full-text search for this title" href="/community/SSH?action=fullsearch&amp;value=linkto%3A%22SSH%22&amp;context=180">SSH</a></h1>
−
<pre><nowiki>
+
<div lang="en" id="content" dir="ltr">
−
# ifconfig tun0 10.0.0.100 pointopoint 10.0.0.200
+
<a id="top"></a>
−
</nowiki></pre>
+
<div lang="en" id="content" dir="ltr">
 +
<a id="top"></a>
 +
<p><strong>This page does not exist yet. You can create a new empty page, or use one of the page templates. Before creating the page, please check if a similar page already exists.</strong> </p>
 +
<a href="/community/SSH?action=edit">Create new empty page</a><p> </p>
 +
<div>
 +
<table>
 +
<tr>
 +
<td>
 +
<p> <strong>Page templates:</strong> </p>
 +
</td>
 +
<td>
 +
<p> <strong>Existing pages with similar names:</strong> </p>
 +
</td>
 +
</tr>
 +
<tr>
 +
<td style="vertical-align: top;">
 +
<p> <ul>
 +
<li><a href="/community/SSH?action=edit&amp;template=AideTemplate">AideTemplate</a></li>
 +
<li><a href="/community/SSH?action=edit&amp;template=[[category:CategoryTemplate">CategoryTemplate</a></li>]]
 +
<li><a href="/community/SSH?action=edit&amp;template=DocumentationTemplate">DocumentationTemplate</a></li>
 +
<li><a href="/community/SSH?action=edit&amp;template=HelpTemplate">HelpTemplate</a></li>
 +
<li><a href="/community/SSH?action=edit&amp;template=HilfeTemplate">HilfeTemplate</a></li>
 +
<li><a href="/community/SSH?action=edit&amp;template=HomepageTemplate">HomepageTemplate</a></li>
 +
<li><a href="/community/SSH?action=edit&amp;template=PagePersonnelleTemplate">PagePersonnelleTemplate</a></li>
 +
<li><a href="/community/SSH?action=edit&amp;template=Pr%c3%a9sentationTemplate">PrésentationTemplate</a></li>
 +
<li><a href="/community/SSH?action=edit&amp;template=SlideShowHandOutTemplate">SlideShowHandOutTemplate</a></li>
 +
<li><a href="/community/SSH?action=edit&amp;template=SlideShowTemplate">SlideShowTemplate</a></li>
 +
<li><a href="/community/SSH?action=edit&amp;template=SlideTemplate">SlideTemplate</a></li>
 +
<li><a href="/community/SSH?action=edit&amp;template=SupportPapierD'UnePr%c3%a9sentationTemplate">SupportPapierD'UnePrésentationTemplate</a></li>
 +
<li><a href="/community/SSH?action=edit&amp;template=ThuisbladTemplate">ThuisbladTemplate</a></li>
 +
<li><a href="/community/SSH?action=edit&amp;template=TransparentTemplate">TransparentTemplate</a></li>
 +
</ul>
 +
</p>
 +
</td>
 +
<td style="vertical-align: top;">
 +
<p> <ul>
 +
<li><a href="/community/USplash">USplash</a></li>
 +
</ul>
 +
<ul>
 +
<li><a href="/community/SSH_VPN">SSH VPN</a></li>
 +
<li><a href="/community/SSHFS">SSHFS</a></li>
 +
<li><a href="/community/SSHHowto">SSHHowto</a></li>
 +
</ul>
 +
<ul>
 +
<li><a href="/community/AdvancedOpenSSH">AdvancedOpenSSH</a></li>
 +
<li><a href="/community/Installation/OverSSH">Installation/OverSSH</a></li>
 +
<li><a href="/community/MythTV/Install/Live/Feisty+/OpenSSH">MythTV/Install/Live/Feisty+/OpenSSH</a></li>
 +
<li><a href="/community/MythTV/Install/Live/OpenSSH">MythTV/Install/Live/OpenSSH</a></li>
 +
<li><a href="/community/MythTV/Install/Server/OpenSSH">MythTV/Install/Server/OpenSSH</a></li>
 +
<li><a href="/community/VNCOverSSH">VNCOverSSH</a></li>
 +
</ul>
 +
</p>
 +
</td>
 +
</tr>
 +
</table>
 +
</div>
 +
<a id="bottom"></a>
  
−
Machine B:
+
</div>
−
<pre><nowiki>
+
<a id="bottom"></a>
−
# ifconfig tun0 10.0.0.200 pointopoint 10.0.0.100
+
−
</nowiki></pre>
+
  
−
Once each interface is configured, we've essentially got the VPN set up; it's just minor details from here. In fact, we can now ping from Machine B to Machine A:
+
</div>
  
−
Machine B:
+
</div> <!-- end page -->
−
<pre><nowiki>
+
−
# ping 10.0.0.100
+
−
PING 10.0.0.100 (10.0.0.100) 56(84) bytes of data.
+
−
64 bytes from 10.0.0.100: icmp_seq=1 ttl=64 time=74.8 ms
+
−
64 bytes from 10.0.0.100: icmp_seq=2 ttl=64 time=73.6 ms
+
−
64 bytes from 10.0.0.100: icmp_seq=3 ttl=64 time=74.3 ms
+
  
−
--- 10.0.0.100 ping statistics ---
 
−
3 packets transmitted, 3 received, 0% packet loss, time 2001ms
 
−
rtt min/avg/max/mdev = 73.649/74.278/74.880/0.549 ms
 
−
</nowiki></pre>
 
  
−
And of course we can also ping from Machine A back to Machine B:
+
<div id="footer">
  
−
Machine A:
+
<div id="ubuntulinks">
−
<pre><nowiki>
+
&copy; 2007 <a href="http://www.canonical.com">Canonical Ltd</a>. Ubuntu, Kubuntu, Edubuntu and Canonical are registered trademarks of Canonical Ltd.<br />
−
# ping 10.0.0.200
+
<a href="http://www.ubuntu.com/feedback">Feedback</a> &mdash;
−
PING 10.0.0.200 (10.0.0.200) 56(84) bytes of data.
+
<a href="http://www.ubuntu.com/legal">Legal</a> &mdash;
−
64 bytes from 10.0.0.200: icmp_seq=1 ttl=64 time=75.2 ms
+
<a href="https://wiki.ubuntu.com/wiki/credits">Credits</a><!-- &mdash;
−
64 bytes from 10.0.0.200: icmp_seq=2 ttl=64 time=74.0 ms
+
<a href="http://www.ubuntu.com/sitemap">Site Map</a>-->
−
64 bytes from 10.0.0.200: icmp_seq=3 ttl=64 time=74.0 ms
+
</div>
  
−
--- 10.0.0.200 ping statistics ---
 
−
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
 
−
rtt min/avg/max/mdev = 74.029/74.424/75.208/0.554 ms
 
−
</nowiki></pre>
 
  
−
== Plugging Into the Network ==
+
</div>
−
 
+
</body>
−
At this point, we've created the actual link that allows Machine B to be plugged into Network A, but we haven't set up any routing information to actually get packets back and forth between Machine B and Network A. The first thing we need to do is to tell Machine B about Network A:
+
</html>
−
 
+
−
Machine B:
+
−
<pre><nowiki>
+
−
# route add -net 10.0.0.0 netmask 255.255.255.0 gw 10.0.0.200 tun0
+
−
</nowiki></pre>
+
−
 
+
−
This allows us to send packets from Machine B to any IP address on Network A, via Machine A. However, to ensure that packets have a route back to Machine B, we need to set some things up on Machine A.
+
−
 
+
−
Machine A:
+
−
<pre><nowiki>
+
−
# arp -sD 10.0.0.200 eth0 pub
+
−
</nowiki></pre>
+
−
 
+
−
This ensures that other machines plugged into Network A will know to send packets destined for 10.0.0.200 to Machine A (so that it can forward them back to Machine B).
+
−
 
+
−
At this point, we do have two way communication betweek Network A and Machine B. Therefore, we can ping another machine on Network A from Machine B:
+
−
 
+
−
Machine B:
+
−
<pre><nowiki>
+
−
# ping 10.0.0.123
+
−
PING 10.0.0.123 (10.0.0.123) 56(84) bytes of data.
+
−
64 bytes from 10.0.0.123: icmp_seq=1 ttl=127 time=74.3 ms
+
−
64 bytes from 10.0.0.123: icmp_seq=2 ttl=127 time=74.3 ms
+
−
64 bytes from 10.0.0.123: icmp_seq=3 ttl=127 time=74.5 ms
+
−
 
+
−
--- 10.0.0.123 ping statistics ---
+
−
3 packets transmitted, 3 received, 0% packet loss, time 2001ms
+
−
rtt min/avg/max/mdev = 74.307/74.416/74.577/0.335 ms
+
−
</nowiki></pre>
+
−
 
+
−
== Expanding the scope of the VPN ==
+
−
 
+
−
At this point, we have successfully plugged Machine B into Network A, and Machine B can access Network A's resources and vice versa. However, what if we want to expand the scope of this VPN-- what if we want to pretend that Machine B's only network connection is through network A?
+
−
 
+
−
If we did this, then all packets coming from or going to Machine B would route through Network A; this would complete Machine B's integration into the private network. So, how do we do this?
+
−
 
+
−
Simple: we just switch Machine B's default gateway.
+
−
 
+
−
However, first, we must create a host-based route to Machine A's globally routable IP address; all packets except for the packets that actually create the link must go through the tunnel, but of course the packets that create the tunnel cannot go through the tunnel.
+
−
 
+
−
Machine B:
+
−
<pre><nowiki>
+
−
# route add 1.2.3.4 gw 192.168.0.1 eth0
+
−
</nowiki></pre>
+
−
 
+
−
In this case, 192.168.0.1 is Machine B's current default gateway; it is the gateway on Network B that provides internet connectivity. Before we switch Machine B's default gateway away from Network B, we must set up this explicit route so that tunnel packets will continue to flow.
+
−
 
+
−
After that route is in place, we can switch Machine B's default gateway:
+
−
 
+
−
Machine B:
+
−
<pre><nowiki>
+
−
# route add default gw 10.0.0.1 tun0
+
−
# route del default gw 192.168.0.1 eth0
+
−
</nowiki></pre>
+
−
 
+
−
In this case, again, 192.168.0.1 is Network B's default gateway, and 10.0.0.1 is Network A's default gateway. Since Machine B is now connected to Network A, we are telling it to use Network A's default gateway instead of its usual default gateway on Network B. At this point, the conversion is complete, and Machine B is now completely on Network A and has all the resources available to Network A, through the SSH tunnel. We can verify this by looking at the output of a tracepath:
+
−
 
+
−
Machine B:
+
−
<pre><nowiki>
+
−
# tracepath example.com
+
−
1:  10.0.0.200 (10.0.0.200)                                0.291ms pmtu 1500
+
−
1:  10.0.0.100 (10.0.0.100)                              168.589ms
+
−
2:  10.0.0.1 (10.0.0.1)                                  asymm  3  87.542ms
+
−
3:  1.2.3.4 (1.2.3.4)                                    157.360ms
+
−
</nowiki></pre>
+
−
 
+
−
== Automating it all with ifup/down ==
+
−
 
+
−
At this point, we have successfully created a virtual private network using SSH 4.3's tunnels. Can we automate this process with ifup/down? The answer is: yes!
+
−
 
+
−
Machine A:
+
−
<pre><nowiki>
+
−
iface tun0 inet static
+
−
pre-up sleep 5
+
−
address 10.0.0.100
+
−
pointopoint 10.0.0.200
+
−
netmask 255.255.255.0
+
−
up arp -sD 10.0.0.200 eth0 pub
+
−
</nowiki></pre>
+
−
 
+
−
Machine B:
+
−
<pre><nowiki>
+
−
iface tun0 inet static
+
−
pre-up ssh -f -w 0:0 1.2.3.4 'ifdown tun0; ifup tun0'
+
−
pre-up sleep 5
+
−
address 10.0.0.200
+
−
pointopoint 10.0.0.100
+
−
netmask 255.255.255.0
+
−
up route add -net 10.0.0.0 netmask 255.255.255.0 gw 10.0.0.200 tun0
+
−
up route add 1.2.3.4 gw 192.168.0.1 eth0
+
−
up route add default gw 10.0.0.1 tun0
+
−
up route del default gw 192.168.0.1 eth0
+
−
down route add default gw 192.168.0.1 eth0
+
−
down route del default gw 10.0.0.1 tun0
+
−
down route del -net 10.0.0.0 netmask 255.255.255.0 gw 10.0.0.200 tun0
+
−
down route del 1.2.3.4 gw 192.168.0.1 eth0
+
−
</nowiki></pre>
+
−
 
+
−
These example /etc/network/interface snippets show how you would, on Machine B, simply have to execute:
+
−
 
+
−
Machine B:
+
−
<pre><nowiki>
+
−
# ifup tun0
+
−
</nowiki></pre>
+
−
 
+
−
And the system would automatically make the ssh connection, set up the tunnel, and turn on the VPN. Additionally, the ifdown command can be used to put the routes back to normal, or turn off the VPN.
+
−
 
+
−
Note that the sleep commands in the snippet are there to allow ssh time to set the tunnel interface up, as it will not be instantaneous.
+
−
 
+
−
== Where do I go from here? ==
+
−
 
+
−
There are many other possible ways to use SSH 4.3's tunnels besides creating a VPN to connect machine B to network A. For example, you could connect machine B to network A, and then route back on machine A to network B, creating a sort-of reverse VPN. Or you could connect machine B to network A, and then redirect traffic from network A to machine B to another system on network B. The possibilities are only limited by the amount of root access you have.
+
−
 
+
−
----
+
−
[[category:CategoryDocumentation]]
+
  
 
[[category:UbuntuHelp]]
 
[[category:UbuntuHelp]]

2007年5月24日 (四) 17:58的版本

Geographylogo.png 文章出处: 

https://help.ubuntu.com/community/SSH VPN

Geographylogo.png 点击翻译: 

English

请不要直接编辑翻译本页，本页将定期与来源同步。

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> SSH - Community Ubuntu Documentation

SSH

This page does not exist yet. You can create a new empty page, or use one of the page templates. Before creating the page, please check if a similar page already exists.

Create new empty page

取自“https://wiki.ubuntu.org.cn/index.php?title=UbuntuHelp:SSH_VPN&oldid=20648”