vpnc w Gentoo

1.  Wprowadzenie

Jeżeli czytamy ten dokument zapewne chcemy podłaczyć się do sieci w naszym biurze z domu czy w trakcie podróży. Wiele firm wykorzystuje koncentratory Cisco 3000 VPN do takich celów i jestem gotów się założyć, że wielu początkujących użytkowników Linuksa myśli, że są skazani na używanie systemu operacyjnego Windows, aby móc się łączyć z tymi urządzeniami. Dokument ten ma za zadanie zmienić ten pogląd i pokazać w jaki sposób stworzyć i skonfigurować działający tunel przy pomocy stacji roboczej Gentoo lub laptopa.

Co znajduje się w tym opracowaniu

• Przedownik po podstawach działania vpnc
• Dyskusje na temat problemów związanych z DNS oraz routingiem w VPN-ach
• Przykłady zarządzania sesjami VPN
• Przydatne sztuczki i kruczki

Czego nie zawiera to opracowanie

• Zaawansowanego przewodnika po technologiach VPN oraz szyfrowania
• Opisu każdej z funkcji vpnc

Założenia

W tym punkcie musimy przyjąć pewne założenia:

• Posiadamy zainstalowany system Gentoo
• Posiadamy dostęp do sieci Internet
• Chcemy się połączyć z koncenratorem Cisco 3000 VPN
• Potrafimy konfigurować, budować i instalować nowe jądro

2.  Konfiguracja jądra

Aby Linux mógł utworzyć połączenie VPN należy uaktywnić wsparcie Universal TUN/TAP device driver support w jądrze. Co to jest i dlaczego potrzebujemy tej opcji? Poniżej znajduje się dość proste wyjaśnienie tej opcji pochodzące z menu konfiguracyjnego jądra:

TUN/TAP provides packet reception and transmission for user space
programs. It can be viewed as a simple Point-to-Point or Ethernet
device, which instead of receiving packets from a physical media,
receives them from user space program and instead of sending packets
via physical media writes them to the user space program.

When a program opens /dev/net/tun, driver creates and registers
corresponding net device tunX or tapX. After a program closed above
devices, driver will automatically delete tunXX or tapXX device and
all routes corresponding to it.

Możemy sami sprawdzić czy jądro, którego używamy, posiada wsparcie dla TUN/TAP poprzez następujące polecenie:

#  grep "TUN" /usr/src/linux/.config
CONFIG_INET_TUNNEL=m
# CONFIG_INET6_TUNNEL is not set
# CONFIG_IPV6_TUNNEL is not set
(TUN/TAP jest uaktywnione jako moduł)
CONFIG_TUN=m
# CONFIG_8139TOO_TUNE_TWISTER is not set

Jak widzimy powyżej, opcja CONFIG_TUN=m skompilowana jest jako moduł. Jeżeli nie mamy wsparcia, musimy go uaktywnić w jądrze, przebudować, zainstalować, ponownie uruchomić komputer, a następnie wracamy do tego przewodnika, aby kontynuować pracę.

Device Drivers  --->
  Networking support  --->
    [*] Universal TUN/TAP device driver support

Jeżeli wbudowaliśmy wsparcie TUN/TAP bezpośrednio do jądra, po wydaniu polecenia dmesg powinniśmy zobaczyć następujący wynik:

# dmesg | grep TUN
Universal TUN/TAP device driver 1.5 (C)1999-2002 Maxim Krasnyansky

Jeżeli zbudowaliśmy wsparcie dla TUN/TAP jako moduł, najpierw powinniśmy załadować moduł tun:

# modprobe tun
# lsmod
Module                  Size  Used by
tun                     7296  0

Teraz, kiedy już załadowaliśmy moduł tun należy sprawdzić rezultat polecenia dmesg. Powinniśmy zobaczyć następujący wynik:

# dmesg | grep TUN
Universal TUN/TAP device driver 1.5 (C)1999-2002 Maxim Krasnyansky

3.  Instalacja potrzebnego oprogramowania

Po skonfigurowaniu jądra, należy zainstalować program net-misc/vpnc:

# emerge -av net-misc/vpnc

4.  Przykładowa konfiguracja

Aby ułatwić pracę można skorzystać z przykładowej konfiguracji. Dla potrzeb tego ćwiczenia, zakładamy, że posiadamy domową sieć składającą się z kilku komputerów. Wszystkie posiadają adresy sieci 192.168.0.0 / 255.255.255.0. Sieć zarządzana jest przez komputer z systemem Gentoo oraz firewallem iptables, DHCP, serwerem DNS itp. Dodatkowo na komputerze znajduje się maskarada. Posiadamy również stację roboczą w obrębie naszej sieci, z której chcemy się łączyć poprzez tunel VPN do komputera w naszym biurze.

Przykładowa konfiguracja stacji roboczej wygląda następująco:

(Konfiguracja serwera nazw)
# cat /etc/resolv.conf
nameserver      192.168.0.1

(Konfiguracja sieci)
# cat /etc/hosts
127.0.0.1       desktop localhost
192.168.0.1     router
192.168.2.2     mediacenter

(Konfiguracja interfejsów)
# ifconfig -a
eth0      Link encap:Ethernet  HWaddr 00:11:2F:8D:08:08
          inet addr:192.168.0.2  Bcast:192.168.0.255  Mask:255.255.255.0
          inet6 addr: fe80::211:2fff:fe8d:808/64 Scope:Link
          UP BROADCAST NOTRAILERS RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:3657889 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2305893 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:2193722103 (2092.0 Mb)  TX bytes:1415104432 (1349.5 Mb)
          Interrupt:185 Memory:fac00000-0

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:35510 errors:0 dropped:0 overruns:0 frame:0
          TX packets:35510 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:16023838 (15.2 Mb)  TX bytes:16023838 (15.2 Mb)

(Tablica routingu)
# netstat -r
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
192.168.0.0     *               255.255.255.0   U         0 0          0 eth0
loopback        desktop         255.0.0.0       UG        0 0          0 lo
default         router          0.0.0.0         UG        0 0          0 eth0

5.  Konfiguracja vpnc

Gdy posiadamy zainstalowany już program vpnc oraz przykładową konfigurację, z której możemy czerpać natchnienie możemy poznać podstawowe ustawienia vpnc. Plik konfiguracyjny vpnc dla ustawienia parametrów połączeń może znajdować się w kilku miejscach, w zależności od tego jak dużo profili chcemy stworzyć. Domyślnie vpnc szuka na początku pliku /etc/vpnc/default.conf. Jeśli nie znajdzie tego pliku, szuka konfiguracji w pliku /etc/vpnc.conf. W poniższym przykładzie posłużymy się jedynie przykładem z pojedynczym profilem, przez co potrzebować będziemy pliku konfiguracyjnego znajdującego się w /etc/vpnc.conf. Należy upewnić się, że nie posiadamy pliku /etc/vpnc/default.conf.

IPSec gateway vpngateway.domain.org
IPSec ID group_id
IPSec secret group_password
Xauth username network_signon
Xauth password network_password

Przykładowy plik konfiguracyjny zaprezentowany powyżej powinien zostać zmodyfikowany tak, aby argumenty dla danych zmiennych były odpowiednie do naszych potrzeb. W opcji gateway zamiast vpngateway.domain.org podać możemy nazwę domeny lub adres IP. Odpowiednie wartości dla opcji ID oraz secret powinniśmy dostać od administratora naszej sieci. Jeśli nie uzyskamy tych informacji, a posiadamy działającą konfigurację na komputerze z systemem Windows i oficjalnym klientem VPN Cisco, jedyne co musimy zrobić to wyeksportować nasz profil. Opcje username oraz password są wartościami, których używamy do logowania się do sieci, takich jak np. domena Windows NT.

Jeśli jesteśmy zmuszeni wyeksportować nasz profil z komputera z systemem Windows, będziemy w posiadaniu pliku zakończonego rozszerzeniem .pcf. W pliku tym znajdziemy wszystkie potrzebne nam informacje. Poniżej znajduje się przykładowy plik tego typu:

[main]
Description=
Host=VPNGATEWAY.DOMAIN.ORG
AuthType=1
GroupName=group_id
GroupPwd=
enc_GroupPwd=F3256220AA200A1D532556024F4F314B0388D48B0FBF2DB12
EnableISPConnect=0
ISPConnectType=0
ISPConnect=FOOBAR
ISPCommand=
Username=
SaveUserPassword=0
UserPassword=
enc_UserPassword=
NTDomain=
EnableBackup=0
BackupServer=
EnableMSLogon=1
MSLogonType=0
EnableNat=1
TunnelingMode=0
TcpTunnelingPort=10000
CertStore=0
CertName=
CertPath=
CertSubjectName=
CertSerialHash=00000000000000000000000000000000
SendCertChain=0
VerifyCertDN=
DHGroup=2
ForceKeepAlives=0
PeerTimeout=90
EnableLocalLAN=0
EnableSplitDNS=1
ForceNetLogin=0

W powyższym przykładzie widać wpisy dla Host, GroupName oraz enc_GroupPwd. Opcje Username i UserPassword w zależności od ustawień mogą, ale nie muszą zostać wyeksportowane. Aby wygenerować działającą konfigurację vpnc z pliku pcf powinniśmy użyć programu pcf2vpnc, który dostarczany jest z vpnc.

Testowanie konfiguracji

Gdy wszystko skonfigurujemy już poprawnie, pora na przetestowanie naszych ustawień. Aby uruchomić vpnc należy wykonać następujące czynności:

# vpnc
Enter password for username@vpngateway.domain.org:
VPNC started in background (pid: 14788)...

Jak widać w powyższym przykładzie po wpisaniu polecenia vpnc (jako root) jesteśmy poproszeni o wpisanie naszego hasła. Po zatwierdzeniu hasła, co odbędzie się bez żadnej odpowiedzi, proces vpnc zostanie przeniesiony automatycznie w tło.

#  ifconfig -a
eth1      Link encap:Ethernet  HWaddr 00:11:2F:8D:08:08
          inet addr:192.168.0.2  Bcast:192.168.0.255  Mask:255.255.255.0
          inet6 addr: fe80::211:2fff:fe8d:808/64 Scope:Link
          UP BROADCAST NOTRAILERS RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2101119 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1577559 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1757862627 (1676.4 Mb)  TX bytes:732200131 (698.2 Mb)
          Interrupt:177 Memory:faa00000-0

sit0      Link encap:IPv6-in-IPv4
          NOARP  MTU:1480  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:0
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:192.168.160.42  P-t-P:192.168.160.42  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1412  Metric:1
          RX packets:1 errors:0 dropped:0 overruns:0 frame:0
          TX packets:9 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:500
          RX bytes:60 (60.0 b)  TX bytes:616 (616.0 b)

# netstat -r
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
vpn01.domain.or router          255.255.255.255 UGH    1500 0          0 eth1
192.168.0.0     *               255.255.255.0   U         0 0          0 eth1
loopback        desktop         255.0.0.0       UG        0 0          0 lo
default         *               0.0.0.0         U         0 0          0 tun0

Jak widzimy wyżej, vpnc dokonał następujących zmian:

• Stworzony został wirtualny interfejs sieciowy tun0, który przekazuje ruch przez tunel VPN
• Uzyskano adres IP dla urządzenia tun0 od dostawcy VPN
• Ustawiono domyślną bramę na VPN

W tym momencie, nasza stacja robocza powinna być zdolna do komunikacji poprzez VPN jednak tylko przy użyciu adresu IP. Jak niektórzy zauważyli, vpnc nie zmodyfikował pliku /etc/resolv.conf, dlatego też nie ustanowił DNS-ów dla wirtualnego połączenia. Dodatkowo, ponieważ vpnc ustawia domyślną bramę na bramę VPN, cały ruch będzie kierowany przez VPN, nawet w przypadku gdy pochodzi on z Internetu lub z każdego innego miejsca nie określonego przez dodatkowe tablice routingu. Dla części użytkowników tak skonfigurowane podstawowe połączenie może wystarczyć, jednak większość podejmnie dodatkowe kroki.

Dodatkowe rzeczy, które mogą okazać się przydatne:

• DNS dla VPN
• Ustawienie tablicy routingu, które kierować będą ruch VPN przez wirtualny tunel. W ten sposób możemy przeglądać Internet, będąc jednocześnie połączonymi z VPN, bez obaw o wyciek naszych danych do tunelu.
• Skrypt zarządzający wszystkimi funkcjami, ponieważ vpnc nie robi tego wystarczająco dobrze w domyślnej konfiguracji.

Gdy chcemy zakończyć sesję VPN, należy wydać polecenie vpnc-disconnect. Przykład użycia pokazano poniżej.

# vpnc-disconnect
Terminating vpnc daemon (pid: 26250)

6.  Konfiguracja DNS

Niestety, vpnc nie radzi sobie z konfiguracją i zarządzaniem DNS dla nowo utworzonego tunelu. Sposób w jaki powinno się to odbywać wybiera użytkownik. Możemy po prostu nadpisać plik /etc/resolv.conf kiedy zostaniemy połączeni, jednak w ten sposób spowodujemy, że wszystkie dane, nie ważne czy przeznaczone dla naszego tunelu VPN czy nie, będą używały DNS dla VPN. Jest to bardzo funkcjonalne rozwiązanie i jeśli potrzebujemy się jedynie łączyć z tunelem, aby wykonać konkretną pracę, a następnie rozłączamy się, nie musimy czytać dalszej części tego rozdziału. Jednak, jeśli będziemy chcieli pozostawiać połączenie z naszym tunelem aktywne na długie okresy czasu, a nie życzymy sobie, aby robocze serwery DNS przechwytywały nasz lokalny ruch powinniśmy kontynuować lekturę.

Idealna konfiguracja pozwoli nam rozdzielić zapytania DNS na dwie grupy: związane z VPN oraz pozostały ruch. W takiej konfiguracji wszystkie zapytania DNS dotyczące VPN będą odbierane przez serwery DNS zlokalizowane na drugim końcu tunelu VPN. Wszystkie pozostałe zapytania będą przesyłane dalej do lokalnego serwera DNS lub do serwera DNS dostarczanego przez ISP. Konfiguracja taka zostanie zaprezentowana poniżej.

W jaki więc sposób skonfigurować wszystko tak, aby tylko zapytania skierowane do komputerów znajdujących się w domenie example.org kierowane były serwerów DNS dostarczonych z tunelem VPN? Przede wszystkim należy zainstalować lokalny serwer DNS. Nie należy jednak się przejmować tym, jest to zdecydowanie prostsze niż wydaje się na pierwszy rzut oka. W drzewie znajduje sie kilka pakietów, których możemy użyć. W poniższym przykładzie użyjemy programu dnsmasq. Należy go teraz zainstalować:

#  emerge dnsmasq

Następnie musimy dodać opcję do komendy startowej dnsmasq. Należy edytować poniższy przykład, aby dopasować go naszych potrzeb. Powinniśmy zastąpić .example.org odpowiednią nazwą domeny. Adresem IP będzie adres odpowiedniego serwera DNS, który należy do tunelu VPN.

Config file for /etc/init.d/dnsmasq

# See the dnsmasq(8) man page for possible options to put here.
DNSMASQ_OPTS="-S /.example.org/192.168.125.10"

Następnie należy się upewnić, że pierwszym wpisem w pliku /etc/resolv.conf będzie wpis definiujący nasz lokalny komputer 127.0.0.1. Po tym wpisie powinna znajdować się lokalizacja zapasowego serwer DNS, który powinien przejąć ruch w przypadku nieudanego uruchomienia programu dnsmasq lub gdy będzie musiał on przekazać ruch w przypadku braku odpowiednich danych we własnej pamięci podręcznej. Przykładowy plik /etc/resolv.conf znajduje się poniżej.

nameserver 127.0.0.1
nameserver 192.168.0.1

Po skonfigurowaniu reguł dla naszego tunelu VPN, powinniśmy uruchomić dnsmasq.

# /etc/init.d/dnsmasq start
# rc-update add dnsmasq default

7.  Konfiguracja tabeli routingu

Doskonałym przypadkiem będzie sytuacja, w której przez połączenie przesyłany jest wyłącznie ruch związany z VPN, chyba że dodamy dodatkowe trasy. Aby móc rozwiązać tę sytuację, musimy wiedzieć jakie sieci dostępne są dla naszego VPN. Najprostszym sposobem na uzyskanie tych danych będzie zasięgnięcie informacji u administratora sieci. Jednak czasami są oni niechętni do odpowiadania na tego typu pytania. W przypadku gdy nie dostaniemy tych danych, potrzeba będzie użyć metody prób i błędów.

Gdy uruchomiliśmy tunel VPN, vpnc ustawiło domyślną bramę. Musimy więc przywrócić wartość domyślną, aby wszystko działało tak jak tego oczekujemy.

# route add default gw 192.168.0.1

Wcześniej, gdy konfigurowaliśmy usługę DNS dla tunelu VPN, wpisaliśmy serwer DNS, który ma zajmować się domeną example.org. Musimy dodać trasę do podsieci 192.168.125.0 tak, aby zapytania DNS funkcjonowały poprawnie.

# route add -net 192.168.125.0 netmask 255.255.255.0 dev tun0

W tym momencie powinniśmy dodać wszystkie dodatkowe trasy dla znanych sieci (takie jak podsieć 192.168.160.0, w którym zawiera się adres otrzymany przez wirtualne urządzenie TUN/TAP). Jeśli dostaliśmy potrzebne nam informację od administratora sieci, świetnie. W przeciwnym wypadku, będziemy musieli spingować komputery do których będziemy się łączyć, aby mieć jakiekolwiek pojęcie o wyglądzie naszej tablicy routingu.

# ping intranet1.example.org
PING intranet1.example.org (172.25.230.29) 56(84) bytes of data.


--- intranet1.example.org ping statistics ---
18 packets transmitted, 0 received, 100% packet loss, time 16997ms

Jak widać z powyższego przykładu, polecenie ping do adresu intranet1.example.org nie powiodło się. Więc powinniśmy dodać trasę do tej podsieci.

# route add -net 172.25.230.0 netmask 255.255.255.0 dev tun0

Kilka poleceń ping dalej, powinniśmy być na dobrej drodze do stworzenia odpowiedniej tablicy routingu.

8.  Zarządzanie połączeniem

Wywoływanie vpnc w razie potrzeby

Kolejnym przykładem jest skrypt do zarządzania połączeniem VPN. Powinniśmy go uruchamiać (jako root) przy pomocy xterm, aby wystartować połączenie z naszym tunelem VPN. Wtedy jedyną czynnością potrzebną do rozłączenia się będzie wciśnięcie enter. Oczywiście skrypt ten musimy dostosować do naszych potrzeb, pamiętając o dodaniu dodatkowych tras do podsieci.

#!/bin/bash

source /sbin/functions.sh

ebegin "Connecting to the VPN"
vpnc
eend

ebegin "Modifying the routing table"
route add default gw 192.168.0.1
route add -net 172.25.230.0 netmask 255.255.255.0 dev tun0
route add -net 192.168.160.0 netmask 255.255.255.0 dev tun0
route add -net 192.168.125.0 netmask 255.255.255.0 dev tun0
eend

einfo "Press any key to disconnect ..."

read $disconnect

ebegin "Disconnecting from the VPN"
vpnc-disconnect
eend
ebegin "Reconfiguring the default routing table"
route add default gw 192.168.0.1
eend

einfo "VPN should now be disconnected"

Uruchamianie vpnc przy startowaniu systemu

Z wersją 0.4.0-r1 programu vpnc dostarczany jest plik init dla Gentoo(/etc/init.d/vpnc), który radzi sobie nawet z obsługą wielu konfiguracji. Domyślny plik przygotowany jest dla pliku konfiguracyjnego /etc/vpnc/vpnc.conf. Przed i po zatrzymaniu i uruchomieniu skrypty napisane przez nas mogą być wykonane w połączeniu z odpowiadającymi im skryptami inir (od wersji 0.5.1-r1). Nazwy takich plików kończą się na -preup.sh, -postup.sh, -predown.sh i -postdown.sh. Przechowujemy je w katalogu /etc/init.d/scripts.d/. Ogólną zasadę nazewnictwa przedstawiono w poniższej tabeli.

Dodajemy vpnc do domyślnego poziomu uruchomieniowego z odpowiednimi poleceniami (w tym wypadku dla standardowej konfiguracji). Należy pamiętać o dodaniu modułu tun (jeśli zbudowaliśmy go w ten sposób) do mechanizmu ładowania modułów jądra przy uruchamianiu systemu.

# rc-update add vpnc default

Jeśli nie chcemy zapisywać hasła w pliku konfiguracyjnym, możemy pozwolić skryptowi init pokazywać wszelkie komendy i informacje na standardowym wyjściu, poprzez edycję pliku /etc/conf.d/vpnc. Ustawiamy zmienną VPNCOUTPUT na wartość yes lub no, gdzie wartością domyślną jest wartość no.

9.  Dodatki

Zdalny graficzny dostęp

Program grdesktop to wspierająca protokół RDP nakładka graficzna napisana w języku Gtk, więc dobrze wpasowująca się w ogólny styl Gnome, jednak nie jest od niego zależna. Jeżeli nie chcemy korzystać z nakładki graficznej grdesktop, zainstalujmy jedynie rdesktop, na którego grdesktop jest nakładką.

W KDE dobrym wyborem będzie kvpnc. Jest to dopracowana i dojrzała nakładka graficzna do zarządzania VPN.

W przypadku gdy zechcemy połączyć się z komputerem, na którym zainstalowano system Windows, dla którego nie dodaliśmy wpisu DNS, a znamy adres dostępnego serwera WINS, możemy użyć programu nmblookup. Polecenie to pomoże nam odpytać serwer WINS o adres komputer, którego chcemy się połączyć. Niestety, aby było ono dostępne należy zainstalować sambę. Jednak w przypadku gdy chcemy pracować z komputerami z systemem Windows być może będziemy chcieli zainstalować program samba, który zawiera kilka przydatnych narzędzi.

# emerge -av samba

Kiedy samba jest już zainstalowana, powinniśmy przetestować polecenie nmblookup odwołując się do serwer WINS znajdującego się pod adresem 192.168.125.11 o komputer nazwany wintelbox1.

# nmblookup -U 192.168.125.11 -R 'wintelbox1'
querying wintelbox1 on 192.168.125.11
172.25.230.76 wintelbox1

Inne skrypty startowe

Dzięki własnym skryptom init.d można dokładnie dopasować typ routowania do danego połączenia. Podane niżej przykłady pokazują jak skonfigurować tabelę routingu tak, że tylko połączenia 123.234.x.x będą przekierowywane przez VPN a wszystkie pozostałe będą korzystać z domyślnej bramy. W przykładzie wykorzystamy skrypt work-preup.sh w celu zapisania domyślnej bramy przed startem vpnc. Po uruchomieniu vpnc skrypt work-postup.sh kasuje nową domyślną stworzoną przez VPN bramę i zastępuje ją tą zapisaną przez pierwszy skrypt oraz przekierowuje przez nią wszystkie połączenia poza 123.234.x.x (które są przesyłane przez vpnc).

#!/bin/sh
route -n | grep -E '^0.0.0.0 ' | cut -c 17-32 >/var/tmp/defaultgw

#!/bin/sh
route del -net 0.0.0.0 netmask 0.0.0.0 dev tun1
route add default gw $(cat /var/tmp/defaultgw)
route add -net 123.234.0.0 netmask 255.255.0.0 dev tun1

W przykładach zakładamy, że połączenie vpnc korzysta z urządzenia tun1. Można to ustawić w pliku konfiguracyjnym danego połączenia.

Interface name tun1
IPSec gateway vpn.mywork.com
Pidfile /var/run/vpnc.work.pid

10.  Przydatne linki

• Strona domowa vpnc
• Strona domowa kvpnc
• Strona domowa grdesktop

11.  Ostatnie uwagi

W tym momencie powinniśmy być w stanie połączyć się z naszym tunelem VPN, a praca z nim będzie bezproblemowa. Gdy znajdziemy błąd w powyższym dokumencie lub gdy zechcemy dopisać dodatkowe informacje można wysłać raport na bugs.gentoo.org.

Materiał udostępniany na podstawie licencji Creative Commons - Attribution / Share Alike.