Amazon VPC ve Linux Server arasında IPSec VPN

9

VPN sistemlerini ve bir Linux sunucusunu kullanarak kurumsal ağımız ve Amazon'un Sanal Özel Bulutu arasında bir IPSec VPN bağlantısı kurmaya çalışıyorum. Ne yazık ki, bulduğum tek kılavuz, bir ana Linux makinesi kullanarak tünelin nasıl kurulacağını ve o linux makinesinin VPC örneklerine erişmesini nasıl sağlayacağını tartışıyor, ancak örneğin şirket ağına erişmesi için çevrimiçi olarak nasıl bulacağım hakkında bir tartışma yok (veya internetin geri kalanı bu ağ üzerinden).

Ağ bilgileri

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

İşte benim /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;

İşte /etc/racoon/racoon.conf'um:

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 iyi çalışıyor, bu yüzden bu yapılandırmaları göndermeyeceğim.

İşte işe yarayan

  • Linux kutusundan, yerel uç noktalara (169.254.249.2/169.254.249.6) ve bunların uzak eşdeğerlerine (169.254.249.1/169.254.249.5) ping atabilirim.
  • Ayrıca VPC, SSH örneklerini onlara ping atabilirim.
  • VPC'deki uzak örneklerden, yerel ve uzak uç noktalara da ping atabilirim
  • 10.3.0.0/25 alt ağındaki yerel sunuculara ping atılamıyorum

Basit bir şey eksik olduğumu varsayıyorum, ancak {local subnet} <-> {remote endpoint} kullanarak {yerel uç nokta} <-> {uzak alt ağ} 'ı yansıtmak için ipsec-tools.conf dosyasına giriş eklemeyi denedim. ama işe yaramadı.

{Uzak yönetim ortamından} yerel sunucuya ping attığımda ping zaman aşımı. Paketler eth0 arabiriminde görülebilir (yerel ağ eth1'de olmasına rağmen).

Google çok az yardımcı oldu; yalnızca OpenSwan'ı kullanmaya çalışan veya benzer sorunları olan ancak donanım yönlendiricileri olan veya eski araçları kullanan kişileri gösterir.

vpn  ipsec  amazon-vpc 
— Dan Udey
kaynak
Ben uzman değilim ama ipsec kullanırken manuel olarak uzak yerel ağa yollar eklemek zorunda wiki.debian.org/IPsec gibi görünüyor , ben de olsa yanlış olabilir ..
— user993553

Yanıtlar:

3

Peki, hile yaptım :) Resmi olarak Amazon tarafından desteklenen Astaro ağ geçidini kurdum ve sonra bunu kendim modellemek için kullandım. Sadece SSH'yi Astaro ünitesine girebilir ve her şeyi nasıl kurduklarını görebilirsiniz. Tabii ki, ödeme yapmak istiyorsanız Astaro ünitesine bağlı kalabilirsiniz.

— Petter
kaynak
1
Lütfen çözümünüzü biraz açıklayabilir misiniz? "Kendi modelimi" ile ne demek istiyorsun? Aynı soruna takılı kaldım ve nasıl çözdüğünle ilgilenecektim, teşekkürler!
— Max
3

Anladım. Benim ipsec-tools.conf değiştirmek zorunda kaldı:

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;

Ve racoon.conf'umu şu şekilde değiştirin:

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;
}

Ancak, anladığım kadarıyla, bu yapılandırma sadece 10.3.0.0/25 ve 10.4.0.0/16 arasındaki trafiği ilk tünele (xxx121 üzerinden) yönlendirecektir. Bunu anladığımda cevabı güncelleyeceğim.

— Dan Udey
kaynak
Ben de bir süredir bu sorunla karşılaştım ve cevabınız gerçekten yardımcı oldu. Her iki tünel üzerinden de yönlendirme yapmak için bir çözüm buldunuz mu? 'Genel yönlendirme' parçalarını diğer tünel IP'sine ekledim ancak test etmedim.
— Will
Her iki tünel üzerinden de yönlendirme için iyi bir çözüm bulamadım, ama bence bu bir bağlamda mantıklı. Buradaki fikir artıklık sağlamaktır ve ideal olarak her iki uçta fazlalık da içerir. İkinci tünelde ayrı bir sunucu kurabilir ve VPN'lerinize iki yol sağlayabilirsiniz (örneğin, standart sunucularınıza her kutuya bir tane olmak üzere iki yol sağlayarak). Ya bu, ya da bir tür izleme sistemi ile manuel yük devretmeyi tetiklersiniz. Her iki çözüm de gerçekten 'optimal' değildir, ancak birincisi sizin de fazlalık sağlar.
— Dan Udey
0

Setkey yapılandırması için "kullan" yerine "zorunlu" kullanmanın nedenini biliyor musunuz? Ayrıca, ifadeleri uzak ve sainfo bölümlerine hangi sırayla yerleştirdiğimi ve yanlışlıkla belirli ifadeleri çoğalttığımı biliyor musunuz? Örneğin:

#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
}

Ayrıca her iki tünelde de trafiğin nasıl akacağını anladınız mı?

Herhangi bir rehberlik için teşekkürler.

— DPfiler
kaynak
Serverfault'a hoş geldiniz. Görünüşe göre başka bir posterin sorusunun cevap bölümünde bir soru sormaya çalışıyorsunuz. Yeni bir sorunuz varsa, lütfen serverfault.com adresine giderek ve büyük kırmızı "Soru Sor" düğmesini tıklayarak yeni bir soru olarak gönderin.
— vjones
İzleyeceğiniz için teşekkür ederim.
— DPfiler
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.