RTFM.Samba + pam
Krótkie Howto o tym jak zrobić by użytkownicy samby mogli być autoryzowani w pamie (/etc/passwd).
Instalacja oparta o: System:
Fedora Core release 2 (Tettnang)
RPM:
samba-common-3.0.3-5 samba-3.0.3-5
samba-3.0.3-5 - Samba is the protocol by which a lot of PC-related machines share files, printers, and other information (such as lists of available files and printers). The Windows NT, OS/2, and Linux operating systems support this natively, and add-on packages can enable the same thing for DOS, Windows, VMS, UNIX of all kinds, MVS, and more. This package provides an SMB server that can be used to provide network services to SMB (sometimes called "Lan Manager") clients. Samba uses NetBIOS over TCP/IP (NetBT) protocols and does NOT need the NetBEUI (Microsoft Raw NetBIOS frame) protocol.
Najważniejsze są poniższe ustawienia w pliku
/etc/samba/smb.conf
security = user obey pam restrictions = no encrypt passwords = noPozwalają one wykorzystać prawie przykładową definicję katalogu domowego udostępnianą użytkownikowi:
[homes] comment = Home Directories browseable = no writable = yes valid users = %S create mode = 0644 directory mode = 0775Aby uruchomić autoryzowanie w pam'ie potrzebna jest jeszcze poprawna konfiguracja pliku:
/etc/pam.d/samba
#%PAM-1.0 auth required pam_stack.so service=system-auth account required pam_warn.so account required pam_stack.so service=system-authno i restart samby na koniec.
I tutaj ważna uwaga dla wszystkich posiadaczy Windows XP, którzy chcą skorzystać z takiej formy autentykacji
w swoich windowsach do zasobów udostępnianych przez sambę. Wyłączone musi być szyfrowanie hasła do autentykacji
co można uczynić importując do rejestru poniższy klucz.
Dla Windows XP:
Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters] "DisablePasswordChange"=dword:00000000 "maximumpasswordage"=dword:0000001e "requiresignorseal"=dword:00000001 "requirestrongkey"=dword:00000000 "sealsecurechannel"=dword:00000001 "signsecurechannel"=dword:00000001 "Update"="no" "enableplaintextpassword"=dword:00000001 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\VXD] "enableplaintextpassword"=dword:00000001 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanworkstation\parameters] "enableplaintextpassword"=dword:00000001 "enablesecuritysignature"=dword:00000001 "requiresecuritysignature"=dword:00000000 "ServiceDll"=hex(2):25,00,53,00,79,00,73,00,74,00,65,00,6d,00,52,00,6f,00,6f,\ 00,74,00,25,00,5c,00,53,00,79,00,73,00,74,00,65,00,6d,00,33,00,32,00,5c,00,\ 77,00,6b,00,73,00,73,00,76,00,63,00,2e,00,64,00,6c,00,6c,00,00,00 "OtherDomains"=hex(7):00,00Dla Windows 2k:
regedt32 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SeCEdit\Reg Values\MACHINE/System/CurrentControlSet/Services/LanmanWorkstation/Parameters/EnablePlainTextPassword] "ValueType"=dword:00000004 "DisplayType"=dword:00000000 "DisplayName"="Microsoft network client: Send unencrypted password to third-party SMB servers" "EnablePlainTextPassword"=dword:00000001
a HOWTO o tym jak zrobić tunel IPSEC między maszynami opartymi o Win2k/XP.
Tutaj....
Dovecot + stunnel
Krótkie howto o tym jak puścić demona do czytania poczty po pop3 po tunelu SSL.
W związku z tym, że podsłuchanie pakietów nie jest żadnym problemem w czasach obecnych warto zabezpieczyć swoją transmisję połączenia pop3.
Najłatwiejszym sposobem na to, jest skorzystanie z tunelowania SSL i przeniesienie transmisji z portu 110 na port 995.
System:
Fedora Core release 2 (Tettnang)
RPM:
dovecot-0.99.10.4-4 - Dovecot is an IMAP server for Linux/UNIX-like systems, written with security primarily in mind. It also contains a small POP3 server. It supports mail in either of maildir or mbox formats.
stunnel-4.05-1 - Stunnel is a socket wrapper which can provide SSL (Secure Sockets Layer) support to ordinary applications. For example, it can be used in conjunction with imapd to create an SSL secure IMAP server.
Dovecot pozwala na pracę z obsługą protokołu SSL, jednak ja z pewnych powodów chciałem uruchomić dovecot'a bez SSL i dookoła postawić stunnel.
Konfiguracja dovecot:
vi /etc/dovecot.conf
W pliku tym definiujemy pracę demona dovecot - czyli jakie usługi ma obsłgiwać:
# Protocols we want to be serving: # imap imaps pop3 pop3s protocols = pop3 imap
resztę opcji w pliku /etc/dovecot.conf pozostawiamy bez zmian jako defaultowe.
Po wydaniu polecenia:
/etc/rc.d/init.d/dovecot start
demon powinien wystartować co sprawdzić można poleceniem:
[root@host etc]# ps aux | grep dov root 31776 0.0 0.0 4972 1004 ? S Nov04 0:05 /usr/sbin/dovecot root 31779 0.0 0.1 5880 1288 ? S Nov04 0:21 dovecot-auth dovecot 6574 0.0 0.1 4620 1440 ? S 01:35 0:00 pop3-login dovecot 6584 0.0 0.1 4012 1440 ? S 01:39 0:00 pop3-login dovecot 6600 0.0 0.1 4968 1440 ? S 01:46 0:00 pop3-login root 8608 0.0 0.0 4368 536 pts/44 S 07:32 0:00 grep dov [root@host etc]#Warto jeszcze sprawdzić czy można wykonac połączenie na port lokalny 110 (pop3):
[root@host stunnel]# telnet localhost 110 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. +OK dovecot ready. user test +OK pass test +OK Logged in. Connection closed by foreign host. [root@host stunnel]#
Drugim krokiem jest konfiguracja stunnel'u dla zestawiania połączeń SSL. Po uruchomieniu stunnel'a komunikacja będzie przebiegała następująco: użytkownik łączyć się będzie na port 995 protokołem SSL. Stunnel przechwytując połączenie rozszyfruje je i przekaże na standardowy port usługi pop3 - 110. Połączenie na port 110 nie będzie więc realizowane przez zdalnego użytkownika, a przez lokalne połączenie (localhost) z adresu IP loopback (127.0.0.1).
Konfiguracja stunnel:
vi /etc/stunnel/stunnel.confDefiniujemy parametry dla usługi którą jesteśmy zainteresowani:
# Service-level configuration [pop3s] accept = 995 connect = 110
i przygotowujemy plik
/etc/stunnel/stunnel.pemzawierający klucz prywatny oraz certyfikat przygotowany w openssl'u. Ważne jest aby ten plik koniecznie był w postaci:
-----BEGIN RSA PRIVATE KEY----- MIICWwIBAAKBgQCu9U4CYzDz8cYOOQD4RmB5cTQR/36TxSd2VQoAKcSjp97AxTwN . .tutaj poprawny klucz prywatny . rekPscER7SKoNNWpiQJAAwfPZH7rmPQP9kH1Q+e36iMWaGIT7B2rXPK61FXxEbHt mTY+ag2jj3FIb6oSo3ltnUNc7uNuQy+y3Yxm1utNbQ== -----END RSA PRIVATE KEY----- -----BEGIN CERTIFICATE----- MIIEfTCCA+agAwIBAgIBCDANBgkqhkiG9w0BAQUFADCBlDELMAkGA1UEBhMCUEwx ETAPBgNVBAgTCFdhcnN6YXdhMREwDwYDVQQHEwhXYXJzemF3YTEaMBgGA1UEChMR . .tutaj poprawny certyfikat . lopQgHtwMZfAgqs+3e2GlZfZZecwdtyHyamJEt5P712eolb3mEGAZrbzARn47muz VQ== -----END CERTIFICATE-----
!!! Ważne !!! aby między kluczem prywatnym a certyfikatem była jedna wolna linia.
Po konfiguracji wystarczy uruchomić demona stunnel:
/usr/sbin/stunnel
i sprawdzić czy istnieje odpowiedni proces:
[root@host stunnel]# ps aux | grep stunnel nobody 31934 0.0 0.2 5836 2288 ? S Nov04 0:01 /usr/sbin/stunnel root 8656 0.0 0.0 5140 544 pts/44 S 07:44 0:00 grep stunnel [root@host stunnel]#
Po udanej konfiguracji wystarczy zmienić w konfiguracji swojego programu pocztowego opcje odbioru poczty i ustawić, że serwer wymaga bezpiecznego połączenia SSL. W programie Outlook Express opcja ta znajduje się na ostatniej zakładce właściowści konta pocztowego - zaawansowane.
Linksys befvp41 <- VPN IPSEC -> Liknsys befvp41 Jak zestawić tunel VPN oparty o IPSEC między routerami Linksys befvp41. Bezpieczeństwo oparte o PSK (preshared key).
Oczekiwany efekt:
Zestawienie tunelu VPN między dwiem prywatnymi sieciami.
10.0.14.0/24 <--> GATEWAY <--> INTERNET <--> GATEWAY <--> 10.0.13.0/24 publiczny IP pierwszej sieci (z lewej): 1.2.3.4 publiczny IP drugiej sieci (z prawej) : 2.3.4.5
Konfiguracja oparta o dwa routery sprzętowe firmy Linksys BEFVP41 v2.
Konfiguracja routera z lewej:
MENU: Security -> VPN: IPSec Pass-Through: Enabled PPTP Pass-Through : Enabled Select Tunnel Entry: 1 VPN Tunnel: ENabled Tunnel Name: do 10-0-13-0 Local Secure Group: Subnet IP: 10.0.14.0 Mask: 255.255.255.0 Remote Secure Group: Subnet IP: 10.0.13.0 Mask: 255.255.255.0 Remote Security Gateway: IP ADdr. IP Address: 2.3.4.5 Encryption: 3DES Authentication: MD5 Key Management: Auto. (IKE) PFS: Enabled Pre-shared Key: abcdefghijk123456789 Key Lifetime: 3600 Advanced Setting: Operation Mode: Aggressive: proposal phase 1: Encryption: DES Authentication: MD5 Group: 1024-bit Key Lifetime: 3600 phase2: Encryption: 3DES Authentication: MD5 PFS: ON Group: 1024-bit Key Lifetime: 3600 Other setting: NetBIOS broadcast: ON Anti-replay: ON Keep-Alive: ON Konfiguracja routera z prawej: MENU: Security -> VPN: IPSec Pass-Through: Enabled PPTP Pass-Through : Enabled Select Tunnel Entry: 1 VPN Tunnel: ENabled Tunnel Name: do 10-0-13-0 Local Secure Group: Subnet IP: 10.0.13.0 Mask: 255.255.255.0 Remote Secure Group: Subnet IP: 10.0.14.0 Mask: 255.255.255.0 Remote Security Gateway: IP ADdr. IP Address: 1.2.3.4 Encryption: 3DES Authentication: MD5 Key Management: Auto. (IKE) PFS: Enabled Pre-shared Key: abcdefghijk123456789 Key Lifetime: 3600 Advanced Setting: Operation Mode: Main mode proposal phase 1: Encryption: DES Authentication: MD5 Group: 1024-bit Key Lifetime: 3600 phase2: Encryption: 3DES Authentication: MD5 PFS: ON Group: 1024-bit Key Lifetime: 3600 Other setting: NetBIOS broadcast: ON Anti-replay: ON Keep-Alive: ON
Po takim zapisaniu ustawień korzystając z "View Logs" oraz "Summary" umieszczonych na stronie konfiguracji tunelu VPN można obserwować etapy zestawiania tunelu VPN oraz listować stany aktualnie skonfigurowanych tuneli. Routery Linksys pozwalają na konfigurację do 70 jednoczesnych tuneli VPN.
Warto skorzystać, po zestawieniu tunelu, z dowlonego programu do nasłuchu ramek ethernetowych (tcpdump, ethereal), który musi zostać umieszczony między routerami. Ramki tunelowane przy pomocy IPSEC można od razu zauważyć - są typu ESP.
Miłej zabawy.
FreeS/Wan <- VPN IPSEC -> Liknsys befvp41
Krótkie Howto o tym jak zrobić tunel VPN oparty o IPSEC między routerem sprzętowym Linksys BEFVP41 i linuxem.
Instalacja oparta o:
Fedora Core release 1 (Yarrow) Kernel: 2.6.4 FreeS/Wan enabledRPM:
freeswan-userland-2.06_2.4.22_1.2115.nptl-0 This package contains the daemons and userland tools for setting up FreeS/WAN on a freeswan enabled kernel.
oraz router sprzętowy Linksys BEFVP41 v2 z firmware 1.0.13.
Linux jest wykorzystywany jako gateway (brama) do sieci prywatnej. Podobnie router sprzętowy BEFVP41.
Schemat sieci:
10.0.14.0/24 <--> LINKSYS <--> INTERNET <--> LINUX <--> 10.0.10.0/24 publiczny IP pierwszej sieci (z lewej - LINKSYS): 1.2.3.4 publiczny IP drugiej sieci (z prawej - LINUX) : 2.3.4.5Konfiguracja daemona IPSEC w pliku /etc/ipsec.conf:
# /etc/ipsec.conf - FreeS/WAN IPsec configuration file
# RCSID $Id: ipsec.conf.in,v 1.11 2003/06/13 23:28:41 sam Exp $
# http://www.freeswan.org/freeswan_trees/freeswan-2.06/doc/examples
version 2.0 # conforms to second version of ipsec.conf specification
# basic configuration
config setup
# Debug-logging controls: "none" for (almost) none, "all" for lots.
klipsdebug=all
plutodebug=all
#interfaces="ipsec0=eth0"
interfaces=%defaultroute
conn packetdefault
auto=ignore
conn block
auto=ignore
conn private
auto=ignore
conn private-or-clear
auto=ignore
conn clear-or-private
auto=ignore
conn clear
auto=ignore
# We keep with tradition - left = local, right = remote
# This is a connection for a remote site w/Static IP
conn linksys
right=1.2.3.4
rightsubnet=10.0.14.0/24
rightnexthop=%defaultroute
left=2.3.4.5
leftsubnet=10.0.10.0/24
leftnexthop=%defaultroute
keyexchange=ike
ikelifetime=240m
keylife=60m
pfs=yes
compress=no
authby=secret
auto=add
Konfiguracja w /etc/ipsec.secrets:
# Same PSK 80.48.50.167 : PSK "1234567890poiuytrewqasdfghjkl"Aby uruchomić tunel IPSec między dwiema sieciami należy:
- wystartować daemona IPSec poleceniem
/etc/rc.d/init.d/ipsec start- upewnić się że działa
ps aux | grep plutotaki powinien byc mniej więcej wynik działania powyższej komendy:
[root@gateway linux]# ps aux | grep pluto root 31112 0.0 0.6 2132 828 pts/136 S 08:41 0:00 /bin/sh /usr/local/lib/ipsec/_plutorun --debug all --uniqueids yes --nocrsend --strictcrlpolicy --crlcheckinterval 0 --dump --opts --stderrlog --wait no --pre --post --log daemon.error --pid /var/run/pluto.pid root 31113 0.0 0.6 2132 836 pts/136 S 08:41 0:00 /bin/sh /usr/local/lib/ipsec/_plutorun --debug all --uniqueids yes --nocrsend --strictcrlpolicy --crlcheckinterval 0 --dump --opts --stderrlog --wait no --pre --post --log daemon.error --pid /var/run/pluto.pid root 31114 0.0 0.7 2204 988 pts/136 S 08:41 0:00 /usr/local/libexec/ipsec/pluto --nofork --secretsfile /etc/ipsec.secrets --policygroupsdir /etc/ipsec.d/policies --debug-all --uniqueids root 31115 0.0 0.6 2132 828 pts/136 S 08:41 0:00 /bin/sh /usr/local/lib/ipsec/_plutoload --wait no --post root 31116 0.0 0.2 1500 308 pts/136 S 08:41 0:00 logger -s -p daemon.error -t ipsec__plutorun root 31141 0.0 0.2 1436 260 pts/136 S 08:41 0:00 _pluto_adns -d root 2049 0.0 0.4 3912 552 pts/136 S 10:21 0:00 grep pluto [root@gateway linux]#- postawić tunel IPSec poleceniem:
ipsec auto -up linksysWynikiem wydania komendy tej jest:
004 "linksys" #8: STATE_QUICK_I2: sent QI2, IPsec SA established {ESP=>0x06bfe0d6 <0x45c8f1b5}
Router sprzętowy winien mieć skonfigurowany tunel VPN o następujących parametrach:
MENU: Security -> VPN:
IPSec Pass-Through: Enabled
PPTP Pass-Through : Enabled
Select Tunnel Entry: 1
VPN Tunnel: ENabled
Tunnel Name: do_LINUXA
Local Secure Group: Subnet
IP: 10.0.14.0
Mask: 255.255.255.0
Remote Secure Group: Subnet
IP: 10.0.10.0
Mask: 255.255.255.0
Remote Security Gateway: IP ADdr.
IP Address: 2.3.4.5
Encryption: 3DES
Authentication: MD5
Key Management: Auto. (IKE)
PFS: Enabled
Pre-shared Key: 1234567890poiuytrewqasdfghjkl
Key Lifetime: 3600
Advanced Setting:
Operation Mode: Aggressive:
proposal phase 1:
Encryption: DES
Authentication: MD5
Group: 1024-bit
Key Lifetime: 3600
phase2:
Encryption: 3DES
Authentication: MD5
PFS: ON
Group: 1024-bit
Key Lifetime: 3600
Other setting:
NetBIOS broadcast: ON
Anti-replay: ON
Keep-Alive: ON
Po poprawnej konfiguracji i postawieniu tunelu IPSec na linuxie połączenie zostanie zestawione między sieciami prywatnymi za routerami.
Należy jednak pamiętać że transportowe właściwości tunelu IPSec nie pozwalają na diagnostykę połączenia z routera do przeciwnej sieci prywatnej. Aby sprawdzić działanie tunelu trzeba, przykładowo, wydać polecenie ping z jednej sieci prywatnej do drugiej.
Firewall musi zawierać reguły pozwalające na transmisję dla protokołu ESP i ISAKMP.
$IPTABLES -A INPUT -p 50 -s 1.2.3.4 -d 2.3.4.5 -j ACCEPT $IPTABLES -A INPUT -p udp -s 1.2.3.4 -d 2.3.4.5 --dport 500 -i eth0 -j ACCEPT
Tak wygląda tcpdump ping'a z jednej sieci do drugiej na eth1 (bez szyfrowania):
[root@gateway linux]# tcpdump -ieth1 tcpdump: listening on eth1 10:34:06.192378 pecet_za_linuksem.lab > pecet_za_linksysem.lab: icmp: echo request 10:34:06.194135 pecet_za_linksysem.lab > pecet_za_linuksem.lab: icmp: echo reply 10:34:06.269744 pecet_za_linksysem.lab > pecet_za_linuksem.lab: icmp: echo request 10:34:06.269871 pecet_za_linuksem.lab > pecet_za_linksysem.lab: icmp: echo reply 10:34:06.319593 arp who-has 10.0.10.30 tell 10.0.10.20 10:34:07.192427 pecet_za_linuksem.lab > pecet_za_linksysem.lab: icmp: echo request 10:34:07.194212 pecet_za_linksysem.lab > pecet_za_linuksem.lab: icmp: echo reply 10:34:07.281099 pecet_za_linksysem.lab > pecet_za_linuksem.lab: icmp: echo request 10:34:07.281226 pecet_za_linuksem.lab > pecet_za_linksysem.lab: icmp: echo reply 10:34:07.819645 arp who-has 10.0.10.30 tell 10.0.10.20 10:34:08.192480 pecet_za_linuksem.lab > pecet_za_linksysem.lab: icmp: echo request 10:34:08.194267 pecet_za_linksysem.lab > pecet_za_linuksem.lab: icmp: echo reply 10:34:08.292517 pecet_za_linksysem.lab > pecet_za_linuksem.lab: icmp: echo request 10:34:08.292643 pecet_za_linuksem.lab > pecet_za_linksysem.lab: icmp: echo reply
A tak na eth0 (pakiety zaszyfrowane):
[root@gateway linux]# tcpdump proto 50 tcpdump: listening on eth0 10:37:51.815198 linksys.lab > gateway.lab: ESP(spi=0x45c8f1b5,seq=0x78d) 10:37:51.815830 gateway.lab > linksys.lab: ESP(spi=0x06bfe0d6,seq=0x78b) 10:37:52.205533 gateway.lab > linksys.lab: ESP(spi=0x06bfe0d6,seq=0x78c) 10:37:52.206791 linksys.lab > gateway.lab: ESP(spi=0x45c8f1b5,seq=0x78e) 10:37:52.826404 linksys.lab > gateway.lab: ESP(spi=0x45c8f1b5,seq=0x78f) 10:37:52.827045 gateway.lab > linksys.lab: ESP(spi=0x06bfe0d6,seq=0x78d) 10:37:53.205586 gateway.lab > linksys.lab: ESP(spi=0x06bfe0d6,seq=0x78e)
No to... HAPPY TUNNELING... ;-)
Cisco 1720 <- VPN IPSEC -> Liknsys befvp41
Krótkie Howto o tym jak zrobić tunel VPN oparty o IPSEC między routerem sprzętowym Linksys BEFVP41 i routerem Cisco 1720.
Instalacja oparta o:
Cisco 1720 soft IOS (tm) C1700 Software (C1700-K8SY-M), Version 12.2(27), RELEASE SOFTWARE (fc3) befvp41 v2 firmware 1.0.13
Za routerami istnieją sieci prywatne. Tunel zestawiony zostanie między tymi sieciami.
Schemat sieci:
10.0.14.0/24 <--> LINKSYS <--> INTERNET <--> CISCO <--> 192.168.1.0/24 publiczny IP pierwszej sieci (z lewej - LINKSYS): 1.2.3.4 publiczny IP drugiej sieci (z prawej - CISCO) : 2.3.4.5
Router linksys befvp41 winien mieć skonfigurowany tunel VPN o następujących parametrach:
MENU: Security -> VPN:
IPSec Pass-Through: Enabled
PPTP Pass-Through : Enabled
Select Tunnel Entry: 1
VPN Tunnel: ENabled
Tunnel Name: do_CISCO
Local Secure Group: Subnet
IP: 10.0.14.0
Mask: 255.255.255.0
Remote Secure Group: Subnet
IP: 192.168.1.0
Mask: 255.255.255.0
Remote Security Gateway: IP ADdr.
IP Address: 2.3.4.5
Encryption: DES
Authentication: SHA
Key Management: Auto. (IKE)
PFS: Enabled
Pre-shared Key: 1234567890poiuytrewqasdfghjkl
Key Lifetime: 3600
Advanced Setting:
Operation Mode: Aggressive:
proposal phase 1:
Encryption: DES
Authentication: SHA
Group: 1024-bit
Key Lifetime: 3600
phase2:
Encryption: DES
Authentication: SHA
PFS: ON
Group: 1024-bit
Key Lifetime: 3600
Other setting:
NetBIOS broadcast: ON
Anti-replay: ON
Keep-Alive: ON
Konfiguracja routera CISCO 1720:
! version 12.2 service timestamps debug uptime service timestamps log uptime no service password-encryption ! hostname RouterA ! boot system flash c1700-k8sy-mz.122-27 enable password haslo ! memory-size iomem 25 ip subnet-zero ! ! crypto isakmp policy 10 authentication pre-share group 2 lifetime 3600 crypto isakmp key 1234567890poiuytrewqasdfghjkl address 1.2.3.4 ! ! crypto ipsec transform-set tunel esp-des esp-sha-hmac ! crypto map mapa 10 ipsec-isakmp set peer 1.2.3.4 set transform-set tunel set pfs group1 match address 111 ! ! ! ! ! interface BRI0 no ip address encapsulation hdlc shutdown ! interface FastEthernet0 ip address 2.3.4.5 255.255.255.0 speed auto crypto map mapa ! interface Serial0 ip address 192.168.1.2 255.255.255.252 no fair-queue ! router rip network 192.168.0.0 network 192.168.1.0 ! ip classless ip route 0.0.0.0 0.0.0.0 x.x.x.x no ip http server ! access-list 111 permit ip 192.168.1.0 0.0.0.255 10.0.14.0 0.0.0.255 access-list 111 permit ip 192.168.1.0 0.0.0.255 10.0.10.0 0.0.0.255 ! line con 0 line aux 0 line vty 0 4 password haslo login ! no scheduler allocate end
Ważne aby router Cisco mógł obsługiwać soft posiadający możliwość szyfrowania algorytmem 3DES, gdyż użyty w przykładzie powyższym DES może nie być wsytarczająco bezpieczny.
Tak wygląda tracert z kolejnego routera za routerem Cisco 1720 będącym początkiem tunelu do sieci 10.0.14.0/255.255.255.0:
RouterB#trace 10.0.14.100 Type escape sequence to abort. Tracing the route to 10.0.14.100 1 192.168.1.2 4 msec 4 msec 0 msec 2 10.0.14.100 4 msec 8 msec 8 msecA tak wygląda debug na routerze Cisco 1720 pingów przychodzących z sieci 10.0.14.0/255.255.255.0 zza routera Linksys befvp41 do sieci
192.168.1.0/255.255.255.0:
21:54:02: IP: s=10.0.14.100 (Serial0), d=192.168.1.1 (Serial0), len 60, rcvd 3 21:54:02: IP: tableid=0, s=192.168.1.1 (local), d=10.0.14.100 (Serial0), routed via RIB 21:54:02: IP: s=192.168.1.1 (local), d=10.0.14.100 (Serial0), len 60, sending 21:54:02: IP: tableid=0, s=10.0.14.100 (Serial0), d=192.168.1.1 (Serial0), route d via RIB 21:54:02: IP: s=10.0.14.100 (Serial0), d=192.168.1.1 (Serial0), len 92, rcvd 3 21:54:02: IP: tableid=0, s=192.168.1.1 (local), d=10.0.14.100 (Serial0), routed via RIB 21:54:02: IP: s=192.168.1.1 (local), d=10.0.14.100 (Serial0), len 92, sending 21:54:03: IP: tableid=0, s=10.0.14.100 (Serial0), d=192.168.1.1 (Serial0), route d via RIB 21:54:03: IP: s=10.0.14.100 (Serial0), d=192.168.1.1 (Serial0), len 60, rcvd 3 21:54:03: IP: tableid=0, s=192.168.1.1 (local), d=10.0.14.100 (Serial0), routed via RIB 21:54:03: IP: s=192.168.1.1 (local), d=10.0.14.100 (Serial0), len 60, sending 21:54:03: IP: tableid=0, s=10.0.14.100 (Serial0), d=192.168.1.1 (Serial0), route d via RIB
Każdy może sobie tunelować do woli.
Podziękowania dla STONKI za cierpliwą zabawę.
.