IPSec VPN między Amazon VPC a Linux Server

9

Próbuję ustanowić połączenie IPSec VPN między naszą siecią korporacyjną a wirtualną chmurą prywatną Amazon, używając ich systemu VPN i serwera Linux. Niestety, jedyny przewodnik, jaki znalazłem, omawia sposób konfigurowania tunelu za pomocą hosta na maszynie z systemem Linux i uzyskiwania tej maszyny do systemu Linux do uzyskiwania dostępu do instancji VPC, ale nie ma dyskusji, w której można znaleźć w Internecie, jak uzyskać instancję w celu uzyskania dostępu do sieci korporacyjnej (lub reszta Internetu za pośrednictwem tej sieci).

Informacje o sieci

Local subnet: 10.3.0.0/25
Remote subnet: 10.4.0.0/16

Tunnel 1:
  Outside IP Addresses:
    - Customer Gateway:        : 199.167.xxx.xxx
    - VPN Gateway              : 205.251.233.121

  Inside IP Addresses
    - Customer Gateway         : 169.254.249.2/30
    - VPN Gateway              : 169.254.249.1/30

Tunnel 2:
  Outside IP Addresses:
    - Customer Gateway:        : 199.167.xxx.xxx
    - VPN Gateway              : 205.251.233.122

  Inside IP Addresses
    - Customer Gateway         : 169.254.249.6/30
    - VPN Gateway              : 169.254.249.5/30

Oto mój /etc/ipsec-tools.conf:

flush;
spdflush;

spdadd 169.254.249.2/30 169.254.249.1/30 any -P out ipsec
   esp/tunnel/199.167.xxx.xxx-205.251.233.121/require;

spdadd 169.254.249.1/30 169.254.249.2/30 any -P in ipsec
   esp/tunnel/205.251.233.121-199.167.xxx.xxx/require;

spdadd 169.254.249.6/30 169.254.249.5/30 any -P out ipsec
   esp/tunnel/199.167.xxx.xxx-205.251.233.122/require;

spdadd 169.254.249.5/30 169.254.249.6/30 any -P in ipsec
   esp/tunnel/205.251.233.122-199.167.xxx.xxx/require;



spdadd 169.254.249.2/30 10.4.0.0/16 any -P out ipsec
   esp/tunnel/199.167.xxx.xxx-205.251.233.121/require;

spdadd 10.4.0.0/16 169.254.249.2/30 any -P in ipsec
   esp/tunnel/205.251.233.121-199.167.xxx.xxx/require;

spdadd 169.254.249.6/30 10.4.0.0/16 any -P out ipsec
   esp/tunnel/199.167.xxx.xxx-205.251.233.122/require;

spdadd 10.4.0.0/16 169.254.249.6/30 any -P in ipsec
   esp/tunnel/205.251.233.122-199.167.xxx.xxx/require;

Oto mój /etc/racoon/racoon.conf:

remote 205.251.233.122 {
        exchange_mode main;
        lifetime time 28800 seconds;
        proposal {
                encryption_algorithm aes128;
                hash_algorithm sha1;
                authentication_method pre_shared_key;
                dh_group 2;
        }
        generate_policy off;
}

remote 205.251.233.121 {
        exchange_mode main;
        lifetime time 28800 seconds;
        proposal {
                encryption_algorithm aes128;
                hash_algorithm sha1;
                authentication_method pre_shared_key;
                dh_group 2;
        }
        generate_policy off;
}

sainfo address 169.254.249.2/30 any address 169.254.249.1/30 any {
    pfs_group 2;
    lifetime time 3600 seconds;
    encryption_algorithm aes128;
    authentication_algorithm hmac_sha1;
    compression_algorithm deflate;
}

sainfo address 169.254.249.6/30 any address 169.254.249.5/30 any {
    pfs_group 2;
    lifetime time 3600 seconds;
    encryption_algorithm aes128;
    authentication_algorithm hmac_sha1;
    compression_algorithm deflate;
}

BGP działa dobrze, więc nie zamierzam publikować tych konfiguracji.

Oto, co działa

  • Z poziomu Linux mogę pingować lokalne punkty końcowe (169.254.249.2/169.254.249.6) i ich zdalne odpowiedniki (169.254.249.1/169.254.249.5).
  • Mogę również pingować instancje w VPC, SSH itp.
  • Ze zdalnych instancji w VPC mogę również pingować lokalne i zdalne punkty końcowe
  • Nie mogę pingować lokalnych serwerów w podsieci 10.3.0.0/25

Zakładam, że brakuje mi czegoś prostego, ale próbowałem dodać wpisy do ipsec-tools.conf, aby dublować {lokalny punkt końcowy} <-> {zdalna podsieć}, używając {lokalna podsieć} <-> {zdalny punkt końcowy}, ale nie działało.

Podczas pingowania z {instancji zdalnej} na {serwer lokalny} upłynął limit czasu pingów. Pakiety są widoczne na interfejsie eth0 (nawet jeśli sieć lokalna działa na eth1).

Google niewiele pomógł; pokazuje tylko osoby próbujące używać OpenSwan, mające podobne problemy, ale z routerami sprzętowymi lub starszymi narzędziami.

Dan Udey
źródło
Nie jestem ekspertem, ale wydaje się, że stąd wiki.debian.org/IPsec, że musisz ręcznie dodawać trasy do zdalnej sieci lokalnej podczas korzystania z ipsec, mogę się mylić ..
user993553

Odpowiedzi:

3

Oszukałem :) Zainstalowałem bramę Astaro, która jest oficjalnie obsługiwana przez Amazon, a następnie wykorzystałem ją do modelowania własnej. Możesz po prostu włączyć SSH do jednostki Astaro i zobaczyć, jak skonfigurowali wszystko. Oczywiście możesz trzymać jednostkę Astaro, jeśli masz ochotę za nią zapłacić.

Petter
źródło
1
Czy mógłbyś rozwinąć swoje rozwiązanie? Co masz na myśli przez „modeluj własne”? Utknąłem na tym samym problemie i chciałbym być zainteresowany sposobem jego rozwiązania, dzięki!
Maks.
3

Domyśliłam się. Musiałem zmienić mój plik ipsec-tools.conf na to:

flush;
spdflush;

# Generic routing
spdadd 10.4.0.0/16 10.3.0.0/25 any -P in  ipsec esp/tunnel/205.251.233.121-199.167.xxx.xxx/require;
spdadd 10.3.0.0/25 10.4.0.0/16 any -P out ipsec esp/tunnel/199.167.xxx.xxx-205.251.233.121/require;

# Tunnel 1
spdadd 169.254.249.1/30 169.254.249.2/30 any -P in  ipsec esp/tunnel/205.251.233.121-199.167.xxx.xxx/require;
spdadd 169.254.249.2/30 169.254.249.1/30 any -P out ipsec esp/tunnel/199.167.xxx.xxx-205.251.233.121/require;

spdadd 10.4.0.0/16 169.254.249.2/30 any -P in  ipsec esp/tunnel/205.251.233.121-199.167.xxx.xxx/require;
spdadd 169.254.249.2/30 10.4.0.0/16 any -P out ipsec esp/tunnel/199.167.xxx.xxx-205.251.233.121/require;

# Tunnel 2
spdadd 169.254.249.5/30 169.254.249.6/30 any -P in  ipsec esp/tunnel/205.251.233.122-199.167.xxx.xxx/require;
spdadd 169.254.249.6/30 169.254.249.5/30 any -P out ipsec esp/tunnel/199.167.xxx.xxx-205.251.233.122/require;

spdadd 10.4.0.0/16 169.254.249.6/30 any -P in  ipsec esp/tunnel/205.251.233.122-199.167.xxx.xxx/require;
spdadd 169.254.249.6/30 10.4.0.0/16 any -P out ipsec esp/tunnel/199.167.xxx.xxx-205.251.233.122/require;

I zmień mój plik racoon.conf na:

path pre_shared_key "/etc/racoon/psk.txt";

remote 205.251.233.122 {
        exchange_mode main;
        lifetime time 28800 seconds;
        proposal {
                encryption_algorithm aes128;
                hash_algorithm sha1;
                authentication_method pre_shared_key;
                dh_group 2;
        }
        generate_policy off;
}

remote 205.251.233.121 {
        exchange_mode main;
        lifetime time 28800 seconds;
        proposal {
                encryption_algorithm aes128;
                hash_algorithm sha1;
                authentication_method pre_shared_key;
                dh_group 2;
        }
        generate_policy off;
}

sainfo address 169.254.249.2/30 any address 169.254.249.1/30 any {
    pfs_group 2;
    lifetime time 3600 seconds;
    encryption_algorithm aes128;
    authentication_algorithm hmac_sha1;
    compression_algorithm deflate;
}

sainfo address 169.254.249.6/30 any address 169.254.249.5/30 any {
    pfs_group 2;
    lifetime time 3600 seconds;
    encryption_algorithm aes128;
    authentication_algorithm hmac_sha1;
    compression_algorithm deflate;
}

sainfo address 10.3.0.0/25 any address 10.4.0.0/16 any {
    pfs_group 2;
    lifetime time 3600 seconds;
    encryption_algorithm aes128;
    authentication_algorithm hmac_sha1;
    compression_algorithm deflate;
}

Jednak ta konfiguracja, jak rozumiem, będzie kierować ruchem między 10.3.0.0/25 a 10.4.0.0/16 przez pierwszy tunel (przez xxx121). Zaktualizuję odpowiedź, kiedy się zorientuję.

Dan Udey
źródło
Utknąłem również z tym problemem przez pewien czas i twoja odpowiedź naprawdę pomogła. Czy opracowałeś rozwiązanie do rutowania w obu tunelach? Dodałem części „Generic routing” z drugim adresem IP tunelu, ale go nie przetestowałem.
Czy
Nie znalazłem żadnego dobrego rozwiązania dla routingu przez oba tunele, ale myślę, że ma to sens w jednym kontekście. Chodzi tutaj o zapewnienie redundancji, a najlepiej, aby obejmowała redundancję na obu końcach. Możesz ustawić osobny serwer w drugim tunelu i zapewnić dwie trasy do twoich VPN (np. Dostarczając swoim standardowym serwerom dwie trasy, po jednej do każdego urządzenia). Albo to, albo uruchomisz ręczne przełączanie awaryjne za pomocą pewnego rodzaju systemu monitorowania. Żadne z tych rozwiązań nie jest tak naprawdę „optymalne”, ale pierwsze zapewnia również nadmiarowość po twojej stronie.
Dan Udey
0

Czy znasz powód używania „wymagaj” zamiast „używaj” do konfiguracji zestawu kluczy? Czy wiesz również, czy ma to znaczenie, w jakiej kolejności umieszczam instrukcje w sekcjach zdalnych i sainfo i omyłkowo powielam niektóre instrukcje? Na przykład:

#original
remote 205.251.233.121 {
        exchange_mode main;
        lifetime time 28800 seconds;
        proposal {
                encryption_algorithm aes128;
                hash_algorithm sha1;
                authentication_method pre_shared_key;
                dh_group 2;
        }
        generate_policy off;
}

vs

#edited
remote 205.251.233.121 {
        generate_policy off;                           #moved/duplicated
        lifetime time 28800 seconds;
        proposal {
                dh_group 2;                           #moved
                encryption_algorithm aes128;
                hash_algorithm sha1;
                authentication_method pre_shared_key;
        }
         exchange_mode main;                      #moved
        generate_policy off;                   #duplicated/moved
}

Czy wymyśliłeś też, jak zmusić ruch do przepływu w obu tunelach?

Dziękuję za wszelkie wskazówki.

DPfiler
źródło
Witamy w Serverfault. Wygląda na to, że próbujesz zadać pytanie w sekcji odpowiedzi na pytanie innego plakatu. Jeśli masz nowe pytanie, prześlij je jako nowe pytanie, wchodząc na serverfault.com i klikając duży czerwony przycisk „Zadaj pytanie”.
vjones
Będę dziękuję za kontynuację.
DPfiler,