Điểm:2

Người dùng iPhone không kết nối với StrongSwan VPN, trong khi người dùng Android và Windows 10 thì sao?

lá cờ us

Tôi có VPN StrongSwan mà vì lý do nào đó tôi không biết không thể kết nối người dùng iOS với máy chủ VPN của tôi.

Một vài lưu ý nhanh:

  • Máy chủ StrongSwan của tôi dành cho các máy khách VPN kết nối với mạng của tôi. tôi đã sử dụng bảo vệ dây cho định tuyến trang web phụ trợ của tôi.

  • Tất cả người dùng StrongSwan VPN đều được xác thực dựa trên một Bán kính tự do người phục vụ.

  • Khách hàng StrongSwan được chỉ định một IP trên 192.168.201.0/24 mạng con, trong khi mạng đường trục WireGuard đang chạy trên 192.168.200.0/24 mạng con.

  • Tất cả các máy khách cũng được cấp một địa chỉ IPv6 công khai thuộc mạng con/48 được chỉ định cho tôi.

Tôi chạy StrongSwan trên Ubuntu 20.04 và tệp cấu hình của tôi nằm trong /etc/swanctl/config/ thư mục và được bao gồm theo mặc định do tên tệp kết thúc trên .conf.

Nội dung như sau:

# Cài đặt máy chủ VPN mặc định cho tất cả các kết nối
kết nối mặc định {
    local_addrs = PUBLIC_IPV4, PUBLIC_IPV6

    địa phương {
      xác thực = khóa công khai
      chứng chỉ = vpn-ecdsa.cer
      id = vpn.example.com
    }

    phiên bản = 2
    send_certreq = không
    send_cert = luôn luôn
    duy nhất = không bao giờ
    phân mảnh = có
    đóng gói = có
    dpd_delay = 60 giây

    rekey_time = 0s
}

# Phương thức đăng nhập mặc định
eap-mặc định {
  Xa xôi {
   auth = bán kính eap
   id =% bất kỳ
   eap_id = % bất kỳ
  }
}

kết nối
{
  # Cấu hình Android chung được mở rộng xuống dưới.
  #
  # Hoạt động với ứng dụng khách StrongSwan VPN cho Android
  conn-unix : mặc định conn, mặc định eap {
    bọn trẻ {
      bọc lưới {
        local_ts = 0.0.0.0/0, ::/0
      }

      net-unix : mặc định con {
      }

      esp_proposals = aes128gcm128-x25519
    }

    đề xuất = aes128-sha256-x25519
  }

  # Tất cả khách hàng Windows khớp với quy tắc này dưới dạng xác thực tên người dùng 
  # được thực hiện bởi 'eap_start = yes' trong Strongswan.conf. 
  #
  # Hoạt động với máy khách VPN tích hợp trong Windows 10.
  conn-windows : conn-defaults, eap-defaults {
    bọn trẻ {
      bọc lưới {
        local_ts = 0.0.0.0/0, ::/0
      }

      esp_proposals = aes256-sha256-prfsha256-modp1024
    }

    đề xuất = aes256-sha256-prfsha256-modp1024
    pool = IkeVPN-site-ipv4, IkeVPN-site-ipv6

  }

  # Một cấu hình rất giống với máy khách Windows 
  # cấu hình, ngoại trừ iOS sử dụng phím 2048 bit, 
  # trong khi Windows sử dụng khóa 1024 bit.
  #
  # KHÔNG hoạt động ở trạng thái hiện tại.
  conn-ios : conn-defaults, eap-defaults {
    bọn trẻ {
      bọc lưới {
        local_ts = 0.0.0.0/0, ::/0
      }

      esp_proposals = aes256-sha2_256
      pool = IkeVPN-site-ipv4, IkeVPN-site-ipv6

    }

    đề xuất = aes256-sha256-prfsha256-modp2048
  }

  # Người dùng Android phù hợp với kết nối này như họ vốn có 
  # đang chạy ứng dụng khách StrongSwan VPN. Tên người dùng được thông qua trong
  # trường 'id' tới máy chủ StrongSwan VPN.
  conn-unix-site : kết nối.conn-unix {
    Xa xôi {
      id = *@site.example.com
    }
    pool = IkeVPN-site-ipv4, IkeVPN-site-ipv6
  }
}

hồ bơi
{
   IkeVPN-site-ipv4 {
      địa chỉ = 192.168.201.0/24
      dns = 192.168.200.1
   }

   IkeVPN-site-ipv6 {
      addrs = 2001:db8:cafe::/97
      dns = 2001:db8::1
   }
}

Cấu hình của tôi được tạo bằng cấu trúc được cung cấp từ trang web sau:

https://wiki.strongswan.org/projects/strongswan/wiki/Strongswanconf#Referencing-other-Sections

Lý do tại sao tôi sử dụng nó là do tránh lặp lại các cài đặt cấu hình giống nhau trên tất cả các cấu hình kết nối của tôi.

Nếu bạn không quen với thiết lập này, cấu hình sau đây dành cho conn-ios điều này nên được coi là tương đương:

conn-ios {
   # Thu được từ conn-default
   local_addrs = PUBLIC_IPV4, PUBLIC_IPV6

   địa phương {
      xác thực = khóa công khai
      chứng chỉ = vpn-ecdsa.cer
      id = vpn.example.com
   }

   phiên bản = 2
   send_certreq = không
   send_cert = luôn luôn
   duy nhất = không bao giờ
   phân mảnh = có
   đóng gói = có
   dpd_delay = 60 giây

   rekey_time = 0s

   # Thu được từ eap-defaults
   Xa xôi {
      auth = bán kính eap
      id =% bất kỳ
      eap_id = % bất kỳ
   }

   # Thu được từ cấu hình conn-ios ban đầu ở trên.
   bọn trẻ {
      bọc lưới {
         local_ts = 0.0.0.0/0, ::/0
      }

      esp_proposals = aes256-sha2_256
      pool = IkeVPN-site-ipv4, IkeVPN-site-ipv6
   }

   đề xuất = aes256-sha256-prfsha256-modp2048
}

Chứng chỉ máy chủ được liệt kê trong kết nối mặc định phần là chứng chỉ ECDSA nhận được từ Let's Encrypt bằng Acme.sh.

Các giá trị mã hóa cho đề xuấtđặc biệt_proposals trong cấu hình iOS được lấy từ gợi ý trong: https://wiki.strongswan.org/projects/strongswan/wiki/AppleClients.

Khi kiểm tra tất cả các kết hợp của người dùng Android hoặc Windows kết nối mà không có bất kỳ sự cố nào, nhưng khi ai đó cố gắng đăng nhập bằng iPhone thì kết nối sẽ bị treo.

Đầu ra từ nhật ký khi iPhone cố gắng kết nối như sau:

10[IKE] CLIENT_IPV4 đang khởi tạo IKE_SA
10[CFG] received proposals: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048, IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/ECP_256, IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1536, IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, IKE:3DES_CBC /HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
10[CFG] đề xuất được định cấu hình: IKE:AES_CBC_128/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/CURVE_25519
10[IKE] không tìm thấy đề xuất phù hợp, đang thử cấu hình thay thế
10[CFG] received proposals: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048, IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/ECP_256, IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1536, IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, IKE:3DES_CBC /HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
10[CFG] đề xuất được định cấu hình: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024
10[IKE] không tìm thấy đề xuất phù hợp, đang thử cấu hình thay thế
10[CFG] đề xuất đã chọn: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
10[IKE] máy chủ từ xa đứng sau NAT
10[ENC] tạo phản hồi IKE_SA_INIT 0 [ SA KE Không N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(CHDLESS_SUP) N(MULT_AUTH) ]
10[NET] gửi gói: từ PUBLIC_IPV4[500] đến CLIENT_IPV4[6452] (456 byte)
06[NET] gói đã nhận: từ CLIENT_IPV4[13549] đến PUBLIC_IPV4[4500] (512 byte)
06[ENC] loại thuộc tính không xác định INTERNAL_DNS_DOMAIN
06[ENC] đã phân tích yêu cầu IKE_AUTH 1 [ IDi N(INIT_CONTACT) IDr CPRQ(ADDR MASK DHCP DNS ADDR6 DHCP6 DNS6 MIỀN) N(ESP_TFC_PAD_N) N(NON_FIRST_FRAG) SA TSi TSr N(MOBIKE_SUP) ]
06[CFG] đang tìm cấu hình ngang hàng khớp với PUBLIC_IPV4[vpn.example.com]...CLIENT_IPV4[PRIVATE_CLASS_A_ADDRESS]
06[CFG] đã chọn cấu hình ngang hàng 'conn-ios'
06[IKE] khởi tạo phương thức EAP_IDENTITY (id 0x00)
06[IKE] đã nhận được ESP_TFC_PADDING_NOT_SUPPORTED, không sử dụng phần đệm TFC ESPv3
06[IKE] ngang hàng hỗ trợ MOBIKE
06[IKE] xác thực 'vpn.example.com' (chính tôi) với chữ ký ECDSA-256 thành công
06[IKE] gửi chứng nhận thực thể cuối "CN=vpn.example.com"
06[IKE] gửi chứng chỉ nhà phát hành "C=US, O=Let's Encrypt, CN=R3"
06[ENC] tạo phản hồi IKE_AUTH 1 [ IDr CERT CERT AUTH EAP/REQ/ID ]
06[ENC] tách bản tin IKE (2816 byte) thành 3 đoạn
06[ENC] tạo phản hồi IKE_AUTH 1 [ EF(1/3) ]
06[ENC] tạo phản hồi IKE_AUTH 1 [ EF(2/3) ]
06[ENC] tạo phản hồi IKE_AUTH 1 [ EF(3/3) ]
06[NET] gửi gói: từ PUBLIC_IPV4[4500] đến CLIENT_IPV4[13549] (1236 byte)
06[NET] gửi gói: từ PUBLIC_IPV4[4500] đến CLIENT_IPV4[13549] (1236 byte)
06[NET] gửi gói: từ PUBLIC_IPV4[4500] đến CLIENT_IPV4[13549] (500 byte)
11[JOB] xóa IKE_SA mở một nửa bằng CLIENT_IPV4 sau khi hết thời gian chờ

Người dùng iPhone đang kết nối bằng ứng dụng khách VPN tích hợp bằng các cài đặt sau:

  • Nhập IKEv2

  • Mô tả: Máy chủ VPN

  • Máy chủ: vpn.example.com

  • Id từ xa: vpn.example.com

  • Id cục bộ: TRỐNG

  • Xác thực tên người dùng và mật khẩu.

  • Tên người dùng: [email protected]

  • Mật khẩu: ItIsASSecret

Có ai biết tại sao kết nối bị treo đối với người dùng iOS khi đã tải conn-ios Hồ sơ?

CẬP NHẬT Và chúng ta đã cất cánh! :-)

Theo lời khuyên từ @ecdsa, tôi đã chuyển chứng chỉ sang chứng chỉ RSA 2048-bit.

Máy chủ Radius của tôi được gọi. Xác thực người dùng thành công và khách hàng được chỉ định địa chỉ ip. Tôi hạnh phúc. :-)

cấu hình của tôi cho conn-ios Hiện tại là:

  conn-ios : conn-defaults, eap-defaults {

    # Ghi đè giá trị mặc định từ 'conn-default'
    địa phương {
      xác thực = khóa công khai
      chứng chỉ = vpn-rsa.cer
      id = vpn.example.com
    }

    bọn trẻ {
      bọc lưới {
        local_ts = 0.0.0.0/0, ::/0
      }

      esp_proposals = aes256-sha256
    }

    pool = IkeVPN-site-ipv4, IkeVPN-site-ipv6
    đề xuất = aes256-sha256-prfsha256-modp2048
  }

Mọi thứ khác vẫn như cấu hình ban đầu của tôi.

lá cờ cn
Không có truyền lại, vì vậy rất có thể máy khách không tin tưởng/hỗ trợ chứng chỉ máy chủ. Bạn sử dụng Let's Encrypt, phần mềm mà hầu hết khách hàng nên hỗ trợ.Vì vậy, điều duy nhất tôi có thể nghĩ đến là máy khách gặp sự cố với chứng chỉ máy chủ ECDSA. Bạn đã thử với chứng chỉ RSA chưa?
lá cờ us
Không kết hợp với iPhone, nhưng nó sẽ dễ kiểm tra. Tuy nhiên, họ xuất ra từ nhật ký cho biết việc xác minh chứng chỉ đã thành công. Xem: `xác thực 'vpn.example.com' (chính tôi) bằng chữ ký ECDSA-256 thành công`.
lá cờ us
Thật lạ là Lets Encrypt ECDSA không hoạt động với VPN, vì tôi có iPhone và iPad sử dụng cùng một chứng chỉ khi chúng gửi hoặc nhận thư vì máy chủ thư của tôi được lưu trữ trên cùng một máy với VPN của tôi.
lá cờ cn
Thông báo nhật ký là từ máy chủ tạo chữ ký (không xác minh). Điều đó không nói lên điều gì về việc khách hàng có thể xác minh hay không (bạn cần truy cập nhật ký khách hàng qua Xcode để biết điều đó). Và ứng dụng thư khách rõ ràng là một phần mềm hoàn toàn khác với ứng dụng khách VPN, vì vậy bạn thực sự không thể so sánh hai phần mềm này.
lá cờ us
Đúng. Thách thức lớn nhất của tôi khi gỡ lỗi iPhone là tôi không thực sự có iPhone, vì vậy việc thử nghiệm đã được một người bạn thực hiện từ xa, người về cơ bản chỉ trả lời là "nó hoạt động" hoặc "không hoạt động". Chắc lần tới gặp bạn mình tôi phải gỡ rối một chút.
lá cờ cn
Tôi sẽ thử với chứng chỉ RSA. Các ứng dụng khách của Apple rõ ràng không hỗ trợ [RFC 7427](https://datatracker.ietf.org/doc/html/rfc7427) (nếu không, bạn sẽ thấy thuật toán băm thông báo trong thông báo `IKE_SA_INIT`) và trong cơ sở IKEv2 RFC các tùy chọn cho ECDSA khá hạn chế (đường cong cụ thể và thuật toán băm). Vì vậy, họ chỉ có thể chấp nhận/sử dụng nó nếu được định cấu hình rõ ràng trong [hồ sơ cấu hình](https://wiki.strongswan.org/projects/strongswan/wiki/AppleIKEv2Profile) (có một tùy chọn `Loại chứng chỉ` có thể được đặt thành ` ECDSA256`).
lá cờ us
@ecdsa: Và chúng ta đã cất cánh! :-) Bạn có thể vui lòng thêm một câu trả lời để bạn có thể nhận được tín dụng cho câu trả lời đúng không? :-)
Điểm:0
lá cờ cn

Như chúng ta có thể thấy trong nhật ký, máy khách không hỗ trợ RFC 7427 (nếu không, thuật toán băm thông báo sẽ được trao đổi trong quá trình IKE_SA_INIT), định nghĩa xác thực dựa trên chữ ký linh hoạt.

Mặc dù IKEv2 cũng hỗ trợ ECDSA mà không cần phần mở rộng đó, RFC 4754 chỉ thêm hỗ trợ hạn chế cho nó (chỉ có thể sử dụng ba đường cong NIST và mỗi đường cong có một thuật toán băm cụ thể được chỉ định). Vì vậy, có thể khách hàng của Apple chỉ chấp nhận/sử dụng ECDSA nếu được định cấu hình rõ ràng trong hồ sơ cấu hình (có một tùy chọn Loại chứng chỉ có thể được đặt thành ví dụ: ECDSA256).

Nếu sử dụng cấu hình cấu hình không phải là một tùy chọn, thì cách thay thế duy nhất là sử dụng Chứng chỉ máy chủ RSA, ít nhất là cho đến khi Apple triển khai hỗ trợ cho RFC 7427 trong ứng dụng khách IKEv2 của họ.

lá cờ us
Cảm ơn bạn. Giải pháp dành cho trường học có hơn 200 người dùng, vì vậy tôi muốn thứ gì đó có thể được sử dụng với càng ít hỗ trợ kỹ thuật cho người dùng cuối càng tốt. Do đó, mục tiêu là chỉ cho họ biết máy chủ nào sẽ kết nối và tên người dùng và mật khẩu sẽ sử dụng. Bất cứ điều gì ngoài đó được coi là "quá phức tạp" đối với người dùng cuối. :-)

Đăng câu trả lời

Hầu hết mọi người không hiểu rằng việc đặt nhiều câu hỏi sẽ mở ra cơ hội học hỏi và cải thiện mối quan hệ giữa các cá nhân. Ví dụ, trong các nghiên cứu của Alison, mặc dù mọi người có thể nhớ chính xác có bao nhiêu câu hỏi đã được đặt ra trong các cuộc trò chuyện của họ, nhưng họ không trực giác nhận ra mối liên hệ giữa câu hỏi và sự yêu thích. Qua bốn nghiên cứu, trong đó những người tham gia tự tham gia vào các cuộc trò chuyện hoặc đọc bản ghi lại các cuộc trò chuyện của người khác, mọi người có xu hướng không nhận ra rằng việc đặt câu hỏi sẽ ảnh hưởng—hoặc đã ảnh hưởng—mức độ thân thiện giữa những người đối thoại.