Ostanio zastanawiałem się nad tymi dwoma rzeczami dla IPSec. Przeglądałem archiwum i znalazłem cosik tu:
http://www.ccie.pl/viewtopic.php?t=4791
mam właściwie takie pytanko:
Generalnie to transport od tunnel różni się tym że jedno jest GRE w IPSEC a drugie w IPSEC w GRE?
Do konfiguracji tunnel trzeba zrobić odrębną konfigurację interfejsu Tunnel, który będzie służył do zestawienia tunelu GRE, tak?
W konfiguracji transport wykorzystywany jest adres fizycznego interfejsu, którym będą wychodziły pakiety i w sumie jest to połączenie punkt-punkt, przez które będzie routing LANów?
Jak to jest? Czy są jakieś wskazania w tworzeniu tych dwóch typów tuneli?
ipsec transport i tunnel
W prosty sposob mozna powiedziec, ze roznica miedzy tunnel mode, a transport mode sprowadza sie do tego "jak gleboko szyfrujemy" - czy wlaczajac w ta warstwe IP czy nie.
Wycinek z Cisco Press powinien Ci pomoc.
--cut--
When IPsec headers are simply inserted in an IP packet (after the IP header), it is called transport mode. In transport mode, the original IP header is exposed and unprotected. Data at the transport layer and higher layers benefits from the implemented IPsec features.
Another way to think of this is that transport mode protects the transport layer and up.
In tunnel mode, the actual IP addresses of the original IP header, along with all the data within the packet, are protected. Tunnel mode creates a new external IP header that contains the IP addresses of the tunnel endpoints (such as routers or VPN Concentrators). The exposed IP addresses are the tunnel endpoints, not the device IP addresses that sit behind the tunnel end points.
--cut--
BTW: ten rysunek to fajnie pokazuje
Wycinek z Cisco Press powinien Ci pomoc.
--cut--
When IPsec headers are simply inserted in an IP packet (after the IP header), it is called transport mode. In transport mode, the original IP header is exposed and unprotected. Data at the transport layer and higher layers benefits from the implemented IPsec features.
Another way to think of this is that transport mode protects the transport layer and up.
In tunnel mode, the actual IP addresses of the original IP header, along with all the data within the packet, are protected. Tunnel mode creates a new external IP header that contains the IP addresses of the tunnel endpoints (such as routers or VPN Concentrators). The exposed IP addresses are the tunnel endpoints, not the device IP addresses that sit behind the tunnel end points.
--cut--
BTW: ten rysunek to fajnie pokazuje
Re: ipsec transport i tunnel
Niepotrzebnie uzalezniles model szyfrowania IPSec od wspolpracy z GRE. Transport mode, jak i tunnel mode mozna stosowac niezaleznie od wersji tunelowania, a wiec zarowno dla GRE over IPSec, jak i odwrotnie dla IPSec over GRE. Jedyna zauwazalna roznica na wyjsciowym interfejsie routera, to rozna wielkosc pakietu. Galus przedstawil dobry, pogladowy rysunek, jak dokonywane jest szyfrowanie. W przypadku GRE over IPSec pakiet bedzie wiekszy dla tunnel mode, niz dla transport mode. IPSec szyfruje bowiem dodatkowo naglowek GRE/IP. Jednak juz przy IPSec over GRE pakiet bedzie taki sam dla tunnel, jak i transport mode.lukas pisze:Ostanio zastanawiałem się nad tymi dwoma rzeczami dla IPSec. Przeglądałem archiwum i znalazłem cosik tu:
http://www.ccie.pl/viewtopic.php?t=4791
mam właściwie takie pytanko:
Generalnie to transport od tunnel różni się tym że jedno jest GRE w IPSEC a drugie w IPSEC w GRE?
Tak jak napisalem wyzej. Konfiguracja GRE z IPSec jest niezalezna od trybu pracy IPSec.lukas pisze:Do konfiguracji tunnel trzeba zrobić odrębną konfigurację interfejsu Tunnel, który będzie służył do zestawienia tunelu GRE, tak?
W konfiguracji transport wykorzystywany jest adres fizycznego interfejsu, którym będą wychodziły pakiety i w sumie jest to połączenie punkt-punkt, przez które będzie routing LANów?
Wskazania juz sie pojawialy na forum jezeli masz na mysli konfiguracje. W celu usystematyzowania przyklady ponizej.lukas pisze:Jak to jest? Czy są jakieś wskazania w tworzeniu tych dwóch typów tuneli?
Topologia:
Kod: Zaznacz cały
[Host1 30.0.0.1]-------[ R1 192.168.2.4]--------[192.168.2.5 R2 ]-------[60.0.0.1 Host 2]Wycinek konfiguracji R1 (analogicznie na R2):
Kod: Zaznacz cały
!
crypto isakmp policy 1
encr 3des
hash md5
authentication pre-share
group 2
crypto isakmp key cisco address 192.168.2.5 no-xauth
!
crypto ipsec transform-set vpn esp-3des esp-md5-hmac
!
crypto map VPN 1 ipsec-isakmp
set peer 192.168.2.5
set transform-set vpn
match address 121
!
interface Tunnel0
ip address 140.0.0.1 255.255.255.252
tunnel source Serial1/1
tunnel destination 192.168.2.5
!
interface Serial1/1
ip address 192.168.2.4 255.255.255.128
crypto map VPN
!
ip route 60.0.0.1 255.255.255.255 Tunnel0
!
access-list 121 permit gre host 192.168.2.4 host 192.168.2.5
!Wycinek konfiguracji R1 (analogicznie na R2):
Kod: Zaznacz cały
!
crypto isakmp policy 1
encr 3des
hash md5
authentication pre-share
group 2
crypto isakmp key cisco address 192.168.2.5 no-xauth
!
crypto ipsec transform-set vpn esp-3des esp-md5-hmac
!
crypto map VPN 1 ipsec-isakmp
set peer 192.168.2.5
set transform-set vpn
match address 120
!
interface Tunnel0
ip address 140.0.0.1 255.255.255.252
tunnel source Serial1/1
tunnel destination 192.168.2.5
crypto map VPN
!
interface Serial1/1
ip address 192.168.2.4 255.255.255.128
!
ip route 60.0.0.1 255.255.255.255 Tunnel0
!
access-list 120 permit ip host 30.0.0.1 host 60.0.0.1
!Re: ipsec transport i tunnel
to może inaczej. Bo trochę się gubie.gangrena pisze:Niepotrzebnie uzalezniles model szyfrowania IPSec od wspolpracy z GRE. Transport mode, jak i tunnel mode mozna stosowac niezaleznie od wersji tunelowania, a wiec zarowno dla GRE over IPSec, jak i odwrotnie dla IPSec over GRE. Jedyna zauwazalna roznica na wyjsciowym interfejsie routera, to rozna wielkosc pakietu. Galus przedstawil dobry, pogladowy rysunek, jak dokonywane jest szyfrowanie. W przypadku GRE over IPSec pakiet bedzie wiekszy dla tunnel mode, niz dla transport mode. IPSec szyfruje bowiem dodatkowo naglowek GRE/IP. Jednak juz przy IPSec over GRE pakiet bedzie taki sam dla tunnel, jak i transport mode.lukas pisze:Ostanio zastanawiałem się nad tymi dwoma rzeczami dla IPSec. Przeglądałem archiwum i znalazłem cosik tu:
http://www.ccie.pl/viewtopic.php?t=4791
mam właściwie takie pytanko:
Generalnie to transport od tunnel różni się tym że jedno jest GRE w IPSEC a drugie w IPSEC w GRE?
Tak jak napisalem wyzej. Konfiguracja GRE z IPSec jest niezalezna od trybu pracy IPSec.lukas pisze:Do konfiguracji tunnel trzeba zrobić odrębną konfigurację interfejsu Tunnel, który będzie służył do zestawienia tunelu GRE, tak?
W konfiguracji transport wykorzystywany jest adres fizycznego interfejsu, którym będą wychodziły pakiety i w sumie jest to połączenie punkt-punkt, przez które będzie routing LANów?
Wskazania juz sie pojawialy na forum jezeli masz na mysli konfiguracje.lukas pisze:Jak to jest? Czy są jakieś wskazania w tworzeniu tych dwóch typów tuneli?
Nawiązując do rysunku, który wstawił nam tu kolega. Złóżmy topologię:
10.0.0.0/24 |--- R1 --- | Internet | --- R2 --- | 10.0.1.0/24
W transport mode nagłówek IP zostaje niezmieniony tak? Zatem to co wychodzi z 10.0.0.0/24 i dąży do 10.0.1.0/24 będzie miało IP z puli prywatnej, co z kolei nie przejdzie przez sieć publiczną.
W tunnel mode zostanie stworzony nowy nagłówek IP, a ten który pochodzi od orginalnej maszyny zostanie zaszyty w danych IPSeca. Czy to ma jakiś ścisły i nierozerwalny związek z interfejsem Tunnel?
zrobioną mam przy czyjejś pomocy konfigurację mniej więcej taką:
Kod: Zaznacz cały
crypto isakmp policy 1
encr 3des
hash md5
authentication pre-share
group 2
crypto isakmp key klucz-dla-ipsec address 111.111.111.111
!
crypto ipsec transform-set transofrmacje-ipsec esp-3des esp-md5-hmac
!
crypto map mapa-ipsec 1 ipsec-isakmp
set peer 111.111.111.111
set transform-set transofrmacje-ipsec
set pfs group2
match address 103
!
access-list 103 permit ip host 192.168.0.100 host 111.111.111.111
!
!
interface FastEthernet0
ip address 22.22.22.22 255.255.255.248
duplex auto
speed auto
crypto map mapa-ipsec
!
Jak to z tym jest bo nie do końca pojmuję? Jaka różnica będzie w takim razie między tą konfiguracją a tą z postu wyżej?
W sumie, to zadajesz to samo pytanie co wczesniej. Odpowiedz jest rowniez ta sama. Tunnel mode w IPSec ma tak nierozerwalny zwiazek z interfejsem Tunnel, jak zamek u spodni z Zamkiem Krolewskim. Nie kieruj sie nazwami przy poszukiwaniu zaleznoscilukas pisze: to może inaczej. Bo trochę się gubie.
Nawiązując do rysunku, który wstawił nam tu kolega. Złóżmy topologię:
10.0.0.0/24 |--- R1 --- | Internet | --- R2 --- | 10.0.1.0/24
W transport mode nagłówek IP zostaje niezmieniony tak? Zatem to co wychodzi z 10.0.0.0/24 i dąży do 10.0.1.0/24 będzie miało IP z puli prywatnej, co z kolei nie przejdzie przez sieć publiczną.
W tunnel mode zostanie stworzony nowy nagłówek IP, a ten który pochodzi od orginalnej maszyny zostanie zaszyty w danych IPSeca. Czy to ma jakiś ścisły i nierozerwalny związek z interfejsem Tunnel?
Co do trybu pracy IPSec w opcji GRE over IPSec, to podalem przyklad konfiguracji, gdzie obydwa tunele GRE oraz IPSec terminowane sa na tym samym routerze. Wowczas mozna stosowac zarowno transport mode, jak i tunnel mode. Jezeli jednak tunel GRE terminowany jest na innych routerach gdzies poza routerem brzegowym wewnatrz sieci, to trzeba w IPSec zastosowac tunnel mode.
Roznica jest podstawowa: konfiguracja, ktora wkleiles to wylacznie tunel IPSec. Konfiguracje podane we wczesniejszym poscie to tandem GRE z IPSec. Jezeli chcesz zestawic tunel szyfrowany pomiedzy lokalizacjami to wystarczy sam IPSec. Nie ma zadnej potrzeby stosowania GRE. Jezeli chcesz uruchomic np. protokoly routingu pomiedzy lokalizacjami, a jednoczesnie caly ruch szyfrowac, wowczas trzeba skorzystac z GREoIPSec.lukas pisze:zrobioną mam przy czyjejś pomocy konfigurację mniej więcej taką:
i to funkcjonuje. Tyle że połączenia są nawiązywane z drugiej strony, a ten host 192.168.0.100 ma tylko odpowiadać na zapytania.Kod: Zaznacz cały
crypto isakmp policy 1 encr 3des hash md5 authentication pre-share group 2 crypto isakmp key klucz-dla-ipsec address 111.111.111.111 ! crypto ipsec transform-set transofrmacje-ipsec esp-3des esp-md5-hmac ! crypto map mapa-ipsec 1 ipsec-isakmp set peer 111.111.111.111 set transform-set transofrmacje-ipsec set pfs group2 match address 103 ! access-list 103 permit ip host 192.168.0.100 host 111.111.111.111 ! ! interface FastEthernet0 ip address 22.22.22.22 255.255.255.248 duplex auto speed auto crypto map mapa-ipsec !
Jak to z tym jest bo nie do końca pojmuję? Jaka różnica będzie w takim razie między tą konfiguracją a tą z postu wyżej?
Ok, ale nadal intryguje mnie zachowanie IPsec w tym przypadku. Co się dzieje z nagłówkiem, w którym src IP jest 192.168.0.100? Zostaje zaszyfrowany i dokładany jest nowy nagłówek z ip 22.22.22.22? Czyli de facto jest to tunel mode?gangrena pisze:W sumie, to zadajesz to samo pytanie co wczesniej. Odpowiedz jest rowniez ta sama. Tunnel mode w IPSec ma tak nierozerwalny zwiazek z interfejsem Tunnel, jak zamek u spodni z Zamkiem Krolewskim. Nie kieruj sie nazwami przy poszukiwaniu zaleznoscilukas pisze: to może inaczej. Bo trochę się gubie.
Nawiązując do rysunku, który wstawił nam tu kolega. Złóżmy topologię:
10.0.0.0/24 |--- R1 --- | Internet | --- R2 --- | 10.0.1.0/24
W transport mode nagłówek IP zostaje niezmieniony tak? Zatem to co wychodzi z 10.0.0.0/24 i dąży do 10.0.1.0/24 będzie miało IP z puli prywatnej, co z kolei nie przejdzie przez sieć publiczną.
W tunnel mode zostanie stworzony nowy nagłówek IP, a ten który pochodzi od orginalnej maszyny zostanie zaszyty w danych IPSeca. Czy to ma jakiś ścisły i nierozerwalny związek z interfejsem Tunnel?
Co do trybu pracy IPSec w opcji GRE over IPSec, to podalem przyklad konfiguracji, gdzie obydwa tunele GRE oraz IPSec terminowane sa na tym samym routerze. Wowczas mozna stosowac zarowno transport mode, jak i tunnel mode. Jezeli jednak tunel GRE terminowany jest na innych routerach gdzies poza routerem brzegowym wewnatrz sieci, to trzeba w IPSec zastosowac tunnel mode.
Roznica jest podstawowa: konfiguracja, ktora wkleiles to wylacznie tunel IPSec. Konfiguracje podane we wczesniejszym poscie to tandem GRE z IPSec. Jezeli chcesz zestawic tunel szyfrowany pomiedzy lokalizacjami to wystarczy sam IPSec. Nie ma zadnej potrzeby stosowania GRE. Jezeli chcesz uruchomic np. protokoly routingu pomiedzy lokalizacjami, a jednoczesnie caly ruch szyfrowac, wowczas trzeba skorzystac z GREoIPSec.lukas pisze:zrobioną mam przy czyjejś pomocy konfigurację mniej więcej taką:
i to funkcjonuje. Tyle że połączenia są nawiązywane z drugiej strony, a ten host 192.168.0.100 ma tylko odpowiadać na zapytania.Kod: Zaznacz cały
crypto isakmp policy 1 encr 3des hash md5 authentication pre-share group 2 crypto isakmp key klucz-dla-ipsec address 111.111.111.111 ! crypto ipsec transform-set transofrmacje-ipsec esp-3des esp-md5-hmac ! crypto map mapa-ipsec 1 ipsec-isakmp set peer 111.111.111.111 set transform-set transofrmacje-ipsec set pfs group2 match address 103 ! access-list 103 permit ip host 192.168.0.100 host 111.111.111.111 ! ! interface FastEthernet0 ip address 22.22.22.22 255.255.255.248 duplex auto speed auto crypto map mapa-ipsec !
Jak to z tym jest bo nie do końca pojmuję? Jaka różnica będzie w takim razie między tą konfiguracją a tą z postu wyżej?
istnienie dwóch termów tunnel i transport jest w sumie już oczywiste (nowy nagłówek, a stary jest zapakowany i zaszyfrowany oraz szyfrowana tylko zawartość powyżej nagłówka IP). próbuję pojąć co się dzieje na brzegu routera na którym jest skonfigurowany IPsec, co widać między routerami używającymi IPsec w tych trybach.
dzięki za szczegółowe poprzednie odpowiedzi
Generalnie dorwałem się do dwóch cisco 1800 i spróbuje się pobawić. przepuszcze ruch przez swój linuxowy router i zobaczę jak to wygląda.
Zgadza sie. Konfiguracja dla IPSec, ktora podales pracuje w trybie tunnel. W tym trybie pracy z naglowkiem dzieje sie to, co napisales, czyli dokladany jest nowy naglowek z ip 22.22.22.22.lukas pisze:Ok, ale nadal intryguje mnie zachowanie IPsec w tym przypadku. Co się dzieje z nagłówkiem, w którym src IP jest 192.168.0.100? Zostaje zaszyfrowany i dokładany jest nowy nagłówek z ip 22.22.22.22? Czyli de facto jest to tunel mode?
Sluszna idealukas pisze:Generalnie dorwałem się do dwóch cisco 1800 i spróbuje się pobawić. przepuszcze ruch przez swój linuxowy router i zobaczę jak to wygląda.
gangrena pisze:Zgadza sie. Konfiguracja dla IPSec, ktora podales pracuje w trybie tunnel. W tym trybie pracy z naglowkiem dzieje sie to, co napisales, czyli dokladany jest nowy naglowek z ip 22.22.22.22.lukas pisze:Ok, ale nadal intryguje mnie zachowanie IPsec w tym przypadku. Co się dzieje z nagłówkiem, w którym src IP jest 192.168.0.100? Zostaje zaszyfrowany i dokładany jest nowy nagłówek z ip 22.22.22.22? Czyli de facto jest to tunel mode?
Sluszna idealukas pisze:Generalnie dorwałem się do dwóch cisco 1800 i spróbuje się pobawić. przepuszcze ruch przez swój linuxowy router i zobaczę jak to wygląda.
testowana sieć:
10.0.1.0/24 |--- R1 ---|10.0.0.0/24 |--- Rlinux ---|10.0.2.0/24 |--- R2 ---|10.0.3.0/24
Efekt moich testów:
config router R1:
Kod: Zaznacz cały
crypto isakmp policy 1
encr 3des
hash md5
authentication pre-share
group 2
crypto isakmp key klucz123 address 10.0.2.1
!
!
crypto ipsec transform-set trset esp-3des esp-md5-hmac
!
crypto map tunnel 1 ipsec-isakmp
set peer 10.0.2.1
set transform-set trset
set pfs group2
match address 100
!
!
!
!
interface FastEthernet0
ip address 10.0.0.1 255.255.255.0
duplex auto
speed auto
crypto map tunnel
!
ip route 0.0.0.0 0.0.0.0 10.0.0.2
ip route 10.0.2.0 255.255.255.0 10.0.0.2
ip route 10.0.3.0 255.255.255.0 10.0.2.1
!
access-list 100 permit ip 10.0.1.0 0.0.0.255 10.0.3.0 0.0.0.255
!
Kod: Zaznacz cały
crypto isakmp policy 1
encr 3des
hash md5
authentication pre-share
group 2
crypto isakmp key klucz123 address 10.0.0.1
!
!
crypto ipsec transform-set trset esp-3des esp-md5-hmac
!
crypto map tunnel 1 ipsec-isakmp
set peer 10.0.0.1
set transform-set trset
set pfs group2
match address 102
!
!
!
!
interface FastEthernet0
ip address 10.0.2.1 255.255.255.0
duplex auto
speed auto
crypto map tunnel
!
ip route 10.0.0.0 255.255.255.0 10.0.2.2
ip route 10.0.1.0 255.255.255.0 10.0.0.1
!
access-list 102 permit ip 10.0.3.0 0.0.0.255 10.0.1.0 0.0.0.255
!
Kod: Zaznacz cały
13:56:03.274277 IP (tos 0x0, ttl 255, id 17378, offset 0, flags [DF], proto: ESP (50), length: 168) 10.0.0.1 > 10.0.2.1: ESP(spi=0xce049755,seq=0x84382), length 148
13:56:03.274295 IP (tos 0x0, ttl 254, id 17378, offset 0, flags [DF], proto: ESP (50), length: 168) 10.0.0.1 > 10.0.2.1: ESP(spi=0xce049755,seq=0x84382), length 148
13:56:03.275088 IP (tos 0x0, ttl 255, id 19450, offset 0, flags [DF], proto: ESP (50), length: 176) 10.0.2.1 > 10.0.0.1: ESP(spi=0x6f25e726,seq=0x44ae6), length 156
Jeszcze sprawdzę wersję z interfejsem tunnel i zobaczę co to zmieni.
mam teraz pytanko jeszcze może w międzyczasie.
Jak to trzeba zmodyfikować by szyfrować tylko zawartość i zrobić transport?
Teraz jeżeli dorzucę "interfejs tunel" - GRE skonfigurowany na obu końcach to będzie to już GREoIPsec. Czyli nagłówek GRE będzie jeszcze dodatkowo zapakowany z tego co przechodzi z jednego końca do drugiego. Zatem jak wspomniałeś, o protokołach routingu np EIGR czy RIP, które działają na bazie bezpośrednio podłączonych do siebie routerów, to mają one szansę zdziałać. Bo w tym co zrobiłem nie ma opcji, bo nie są defacto bezpośrednio podłączone.
Jeszcze tak się zastanawiam teoretycznie czy zestawiając GREoIPsec do routerów za brzegowym routerem czy raczej ruch szyfruje się do brzegowego routera czy do końcowego routera, i ewentualnie po co tworzyć tunele do wewnętrznych routerów zamiast do brzegowego. Tak się zastanawiam jaka jest celowość, co ułatwia?
Zeby sprawdzic wersje transport nie potrzebujesz interfejsu Tunnellukas pisze:Czyli cały pakiet IP jest ładowany w IPsec i wstawiany jest nowy nagłówek IP.
Jeszcze sprawdzę wersję z interfejsem tunnel i zobaczę co to zmieni.
Wystarczy ze wpiszesz:lukas pisze:mam teraz pytanko jeszcze może w międzyczasie.
Jak to trzeba zmodyfikować by szyfrować tylko zawartość i zrobić transport?
Kod: Zaznacz cały
crypto ipsec transform-set trset esp-3des esp-md5-hmac
mode transportTo, jak zostanie zaimplementowany GRE over IPSec zalezy - tak jak wszystko - od ukladow biznesowych, topologii sieci, konkretnej funkcjonalnosci. Prosty przyklad sytuacji, kiedy tunel IPSec oraz GRE nie sa terminowane na tym samym urzadzeniu, to firewall na brzegu sieci terminujacy tunel IPSec oraz stojacy za nim router przeznaczony do routingu ze skonfigurowanym tunelem GRE.lukas pisze:Jeszcze tak się zastanawiam teoretycznie czy zestawiając GREoIPsec do routerów za brzegowym routerem czy raczej ruch szyfruje się do brzegowego routera czy do końcowego routera, i ewentualnie po co tworzyć tunele do wewnętrznych routerów zamiast do brzegowego. Tak się zastanawiam jaka jest celowość, co ułatwia?
no tak tak, to wiemgangrena pisze:Zeby sprawdzic wersje transport nie potrzebujesz interfejsu Tunnellukas pisze:Czyli cały pakiet IP jest ładowany w IPsec i wstawiany jest nowy nagłówek IP.
Jeszcze sprawdzę wersję z interfejsem tunnel i zobaczę co to zmieni.
w sumie tak zrobiłem i nic się nie zmieniło, nadal widziałem ruch między 10.0.2.1 a 10.0.0.1 a nie między 10.0.3.1 a 10.0.1.1 :/ nie wiem czemu, stąd moje pytanie.gangrena pisze:Wystarczy ze wpiszesz:lukas pisze:mam teraz pytanko jeszcze może w międzyczasie.
Jak to trzeba zmodyfikować by szyfrować tylko zawartość i zrobić transport?Kod: Zaznacz cały
crypto ipsec transform-set trset esp-3des esp-md5-hmac mode transport
no tak też sie domyślałem.gangrena pisze:To, jak zostanie zaimplementowany GRE over IPSec zalezy - tak jak wszystko - od ukladow biznesowych, topologii sieci, konkretnej funkcjonalnosci. Prosty przyklad sytuacji, kiedy tunel IPSec oraz GRE nie sa terminowane na tym samym urzadzeniu, to firewall na brzegu sieci terminujacy tunel IPSec oraz stojacy za nim router przeznaczony do routingu ze skonfigurowanym tunelem GRE.lukas pisze:Jeszcze tak się zastanawiam teoretycznie czy zestawiając GREoIPsec do routerów za brzegowym routerem czy raczej ruch szyfruje się do brzegowego routera czy do końcowego routera, i ewentualnie po co tworzyć tunele do wewnętrznych routerów zamiast do brzegowego. Tak się zastanawiam jaka jest celowość, co ułatwia?
A pytanko jeszcze takie. Zrobiłem to GRE tylko tam w konfigu dwóch routerów, który podałeś masz:
Kod: Zaznacz cały
interface Tunnel0
ip address 140.0.0.1 255.255.255.252
tunnel source Serial1/1
tunnel destination 192.168.2.5
!
interface Serial1/1
ip address 192.168.2.4 255.255.255.128
crypto map VPN
!
Kod: Zaznacz cały
interface Tunnel0
ip address 140.0.0.1 255.255.255.252
tunnel source Serial1/1
tunnel destination 192.168.2.5
crypto map VPN
!
interface Serial1/1
ip address 192.168.2.4 255.255.255.128
!
Pytanko, zapodałem na oba interfejsy tunnel 0 crypto map i teraz mam coś takiego:
Kod: Zaznacz cały
IP (tos 0x0, ttl 254, id 86, offset 0, flags [none], proto: GRE (47), length: 120) 10.0.2.1 > 10.0.0.1: GREv0, Flags [none], length 100
IP (tos 0x0, ttl 255, id 12969, offset 0, flags [DF], proto: ESP (50), length: 96) 10.0.2.1 > 10.0.0.1: ESP(spi=0x65aba5ae,seq=0xb), length 76
16:46:50.978656 IP (tos 0x0, ttl 254, id 86, offset 0, flags [none], proto: GRE (47), length: 120) 10.0.2.1 > 10.0.0.1: GREv0, Flags [none], length 100
IP (tos 0x0, ttl 255, id 12969, offset 0, flags [DF], proto: ESP (50), length: 96) 10.0.2.1 > 10.0.0.1: ESP(spi=0x65aba5ae,seq=0xb), length 76
16:46:50.980042 IP (tos 0x0, ttl 255, id 82, offset 0, flags [none], proto: GRE (47), length: 120) 10.0.0.1 > 10.0.2.1: GREv0, Flags [none], length 100
IPSec w transport mode podmienia naglowek IP na swoj.lukas pisze:w sumie tak zrobiłem i nic się nie zmieniło, nadal widziałem ruch między 10.0.2.1 a 10.0.0.1 a nie między 10.0.3.1 a 10.0.1.1 :/ nie wiem czemu, stąd moje pytanie.
W tunnel mode doklada nowy, zas otrzymany szyfruje wraz z payload.
Ehh... Tutaj wychodzi na to, ze nie przeanalizowales konfiguracji, ktore wkleilem. Pierwsza z nich, to GRE over IPSec, gdzie crypto mape zaklada sie na interfejs wyjsciowy. Drugi przyklad to IPSec over GRE, gdzie crypto mape zaklada sie na interfejs Tunnel. Mozesz oczywiscie zalozyc crypto mapy na obydwu interfejsach jednoczesnie, ale pytanie po co? W starszych softach, jak to juz bylo omawiane przy innym watku, trzeba bylo zalozyc crypto mape jednoczesnie na interfejsie fizycznym oraz Tunnel, aby uzyskac GRE over IPSec. Obecnie nie trzeba. Jezeli sie uprzesz, to mozesz zrobic IPSec over GRE over IPSec stosuja dwie rozne crypto mapy.lukas pisze:A pytanko jeszcze takie. Zrobiłem to GRE tylko tam w konfigu dwóch routerów, który podałeś masz:
...
gdzie crypto mapa jest a to na serialu a to na interfejsie tunnel. Nie powinna być tylko na interfejsie Tunnel?
Niestety namieszales. Przeanalizuj prosze jeszcze raz konfiguracje GRE over IPSec w trzecim poscie od gory. Dla tej wersji powinienes widziec pakiety ESP. Zadnych GRE. W ACL w crypto mapie trzeba ujac protokol GRE tak, aby byl opakowany przez IPSec. W przykladzie jest to ACL 121.lukas pisze:Pytanko, zapodałem na oba interfejsy tunnel 0 crypto map i teraz mam coś takiego:
Czy w ogóle powinny pojawiać się jakieś pakiety GRE ? Czy powinienem mieć tylko ESP? Bo coś mi się wydaje że coś skrzaczyłem. Chyba, że w ACLce do crypto mapy trzeba ująć jeszcze adresację tuneli GRE.Kod: Zaznacz cały
IP (tos 0x0, ttl 254, id 86, offset 0, flags [none], proto: GRE (47), length: 120) 10.0.2.1 > 10.0.0.1: GREv0, Flags [none], length 100 IP (tos 0x0, ttl 255, id 12969, offset 0, flags [DF], proto: ESP (50), length: 96) 10.0.2.1 > 10.0.0.1: ESP(spi=0x65aba5ae,seq=0xb), length 76 16:46:50.978656 IP (tos 0x0, ttl 254, id 86, offset 0, flags [none], proto: GRE (47), length: 120) 10.0.2.1 > 10.0.0.1: GREv0, Flags [none], length 100 IP (tos 0x0, ttl 255, id 12969, offset 0, flags [DF], proto: ESP (50), length: 96) 10.0.2.1 > 10.0.0.1: ESP(spi=0x65aba5ae,seq=0xb), length 76 16:46:50.980042 IP (tos 0x0, ttl 255, id 82, offset 0, flags [none], proto: GRE (47), length: 120) 10.0.0.1 > 10.0.2.1: GREv0, Flags [none], length 100
Czyli muszę poszukać jakiegoś sensownego zastosowania dla trybu transportowego. Jak tak ustawiłem to w sumie nic się nie działo, a skoro podmienia nagłówek IP na swój to skąd wie gdzie dostarczyć pakiet po drugiej stronie?gangrena pisze:IPSec w transport mode podmienia naglowek IP na swoj.lukas pisze:w sumie tak zrobiłem i nic się nie zmieniło, nadal widziałem ruch między 10.0.2.1 a 10.0.0.1 a nie między 10.0.3.1 a 10.0.1.1 :/ nie wiem czemu, stąd moje pytanie.
W tunnel mode doklada nowy, zas otrzymany szyfruje wraz z payload.
ten temat już opanowałem, znaczy wydaje mi się że opanowałem i chyba wiem już jak to działa. W każdym razie zrobiłem sobie test z konfiguracją:gangrena pisze:Niestety namieszales. Przeanalizuj prosze jeszcze raz konfiguracje GRE over IPSec w trzecim poscie od gory. Dla tej wersji powinienes widziec pakiety ESP. Zadnych GRE. W ACL w crypto mapie trzeba ujac protokol GRE tak, aby byl opakowany przez IPSec. W przykladzie jest to ACL 121.lukas pisze:Pytanko, zapodałem na oba interfejsy tunnel 0 crypto map i teraz mam coś takiego:
Czy w ogóle powinny pojawiać się jakieś pakiety GRE ? Czy powinienem mieć tylko ESP? Bo coś mi się wydaje że coś skrzaczyłem. Chyba, że w ACLce do crypto mapy trzeba ująć jeszcze adresację tuneli GRE.Kod: Zaznacz cały
IP (tos 0x0, ttl 254, id 86, offset 0, flags [none], proto: GRE (47), length: 120) 10.0.2.1 > 10.0.0.1: GREv0, Flags [none], length 100 IP (tos 0x0, ttl 255, id 12969, offset 0, flags [DF], proto: ESP (50), length: 96) 10.0.2.1 > 10.0.0.1: ESP(spi=0x65aba5ae,seq=0xb), length 76 16:46:50.978656 IP (tos 0x0, ttl 254, id 86, offset 0, flags [none], proto: GRE (47), length: 120) 10.0.2.1 > 10.0.0.1: GREv0, Flags [none], length 100 IP (tos 0x0, ttl 255, id 12969, offset 0, flags [DF], proto: ESP (50), length: 96) 10.0.2.1 > 10.0.0.1: ESP(spi=0x65aba5ae,seq=0xb), length 76 16:46:50.980042 IP (tos 0x0, ttl 255, id 82, offset 0, flags [none], proto: GRE (47), length: 120) 10.0.0.1 > 10.0.2.1: GREv0, Flags [none], length 100
******************* ROUTER 1 *******************
Kod: Zaznacz cały
rypto isakmp policy 1
encr 3des
hash md5
authentication pre-share
group 2
crypto isakmp key klucz123 address 10.0.0.1 no-xauth
!
!
crypto ipsec transform-set trset esp-3des esp-md5-hmac
!
crypto map tunnel 1 ipsec-isakmp
set peer 10.0.0.1
set transform-set trset
set pfs group2
match address 150
!
!
!
!
interface Tunnel0
ip address 172.16.1.2 255.255.255.252
tunnel source FastEthernet0
tunnel destination 10.0.0.1
!
interface FastEthernet0
ip address 10.0.2.1 255.255.255.0
duplex auto
speed auto
crypto map tunnel
!
ip route 10.0.1.0 255.255.255.0 172.16.1.1
!
access-list 150 permit gre host 10.0.2.1 host 10.0.0.1
!
Kod: Zaznacz cały
crypto isakmp policy 1
encr 3des
hash md5
authentication pre-share
group 2
crypto isakmp key klucz123 address 10.0.2.1 no-xauth
!
!
crypto ipsec transform-set trset esp-3des esp-md5-hmac
!
crypto map tunnel 1 ipsec-isakmp
set peer 10.0.2.1
set transform-set trset
set pfs group2
match address 150
!
!
!
!
interface Tunnel0
ip address 172.16.1.1 255.255.255.252
tunnel source FastEthernet0
tunnel destination 10.0.2.1
crypto map tunnel
!
interface FastEthernet0
ip address 10.0.0.1 255.255.255.0
duplex auto
speed auto
crypto map tunnel
!
match address 150
!
!
ip route 10.0.3.0 255.255.255.0 172.16.1.2
!
access-list 150 permit gre host 10.0.0.1 host 10.0.2.1
!
Kod: Zaznacz cały
IP (tos 0x0, ttl 254, id 4412, offset 0, flags [none], proto: ESP (50), length: 816) 10.0.0.1 > 10.0.2.1: ESP(spi=0x40813537,seq=0x9e45), length 796
IP (tos 0x0, ttl 255, id 4413, offset 0, flags [none], proto: ESP (50), length: 808) 10.0.0.1 > 10.0.2.1: ESP(spi=0x40813537,seq=0x9e46), length 788
IP (tos 0x0, ttl 254, id 4413, offset 0, flags [none], proto: ESP (50), length: 808) 10.0.0.1 > 10.0.2.1: ESP(spi=0x40813537,seq=0x9e46), length 788
IP (tos 0x0, ttl 255, id 4414, offset 0, flags [none], proto: ESP (50), length: 1104) 10.0.0.1 > 10.0.2.1: ESP(spi=0x40813537,seq=0x9e47), length 1084
Jest to podane w tej linii:lukas pisze:Jak tak ustawiłem to w sumie nic się nie działo, a skoro podmienia nagłówek IP na swój to skąd wie gdzie dostarczyć pakiet po drugiej stronie?
Kod: Zaznacz cały
set peer 10.0.0.1no ok, ale skąd wie gdzie za tunelem dostarczyć pakiet?gangrena pisze:Jest to podane w tej linii:lukas pisze:Jak tak ustawiłem to w sumie nic się nie działo, a skoro podmienia nagłówek IP na swój to skąd wie gdzie dostarczyć pakiet po drugiej stronie?Kod: Zaznacz cały
set peer 10.0.0.1
skoro oryginalny src ip i dst ip jest zmazywany tymi poleceniami peer, to skąd on wie że musi trafić do innej maszyny za tunelem w trybie transport?
Wszystko sie zgadza. Dlatego jednym z wczesniejszych postow napisalem, ze: jezeli tunel GRE terminowany jest na innych routerach gdzies poza routerem brzegowym wewnatrz sieci, to trzeba w IPSec zastosowac tunnel mode. Jezeli GRE oraz IPSec terminowane sa na tym samym routerze, to mozna uzyc zarowno transport, jak i tunnel mode.lukas pisze:no ok, ale skąd wie gdzie za tunelem dostarczyć pakiet?
skoro oryginalny src ip i dst ip jest zmazywany tymi poleceniami peer, to skąd on wie że musi trafić do innej maszyny za tunelem w trybie transport?