Sự cố ứng dụng khách Libreswan và Mac OS X Big Sur

Tôi đang nhờ đến sự trợ giúp sau một khoảng thời gian dài khắc phục sự cố kết nối giữa máy khách và máy chủ.

Rắc rối

Máy khách Mac OS X Catalina và Linux hoạt động tốt khi kết nối với máy chủ, nhưng Big Sur thì không. Tôi chưa thử nghiệm Mojave (dù sao về lý thuyết cũng sẽ lỏng lẻo hơn về bảo mật), tôi cũng chưa thử nghiệm Windows 10. Lý do cho tất cả các ứng dụng khách khác nhau rất phức tạp, nhưng về cơ bản chúng tôi là một công ty tư vấn nhỏ nơi mọi người có thể chọn nền tảng của họ mặc dù Mojave cũ hơn đơn giản là vì họ chưa nâng cấp. Dù bằng cách nào thì công việc của tôi (với tư cách là quản trị viên hệ thống) phức tạp hơn đáng kể, nhưng đúng là như vậy.

May chủ

• Mũ đỏ 8.2. Một cái được định cấu hình ở chế độ FIPS, cái khác thì không, do OpenVPN. Tất nhiên cả hai đều đang chạy Libreswan.
• Cài đặt mặc định Libreswan từ yum. Phiên bản: 3.29-7
• IKEv2 sử dụng NSS, với chứng chỉ RSA để xác thực.
• Cơ sở hạ tầng CA gốc/trung gian tùy chỉnh. CRL hợp lệ, được tích hợp và lưu trữ trong NSS.
• Tường lửa, bảng định tuyến, cài đặt sysctl, v.v., dường như tất cả đều được định cấu hình chính xác. Tôi đang sử dụng iptables với bộ quy tắc tùy chỉnh, thay vì tường lửa.

khách hàng

• Mac OS X Mojave, Catalina và Big Sur
• cửa sổ 10
• Máy khách Ubuntu và RedHat Linux

Cấu hình

Phía khách hàng (Mobileconfig để đóng gói tất cả lại với nhau)

Tôi đang sử dụng ứng dụng khách mạng tích hợp, không có ứng dụng khách bên ngoài để đơn giản hóa mọi thứ. Hầu hết các ứng dụng khách trả tiền dường như không hỗ trợ IKEv2, mặc dù tôi đã dùng thử GreenBow VPN trong một thời gian ngắn.

Tab Tải trọng VPN (Apple Configurator 2, cả Catalina/Big Sur cùng dữ liệu/cấu hình)

1. Kiểu kết nối: IKEv2
2. Máy chủ/Số nhận dạng từ xa: IP của máy chủ (Chứng chỉ máy chủ có SubjectAltName IP: IP máy chủ)
3. Mã định danh cục bộ: Địa chỉ email của người dùng dường như hoạt động tốt ở đây với giả định rằng đó không phải là Big Sur. Đặt nó ở dạng trống cũng hoạt động cùng một lúc. Tôi không chắc mình đã thay đổi điều gì hay chính tôi đã thay đổi, nhưng Email cần phải có mặt ngay bây giờ.Tôi cũng đã bắt đầu thêm điều này làm phía máy khách trường email subjectAltName, theo gợi ý từ đồng nghiệp.
4. Xác thực máy là chứng chỉ, RSA cho loại và tên nhà phát hành CA được đặt chính xác.
5. Tất cả các nội dung bảo mật khác, như thông số DH và tiền điện tử đều thuộc loại trung cấp, AES-256 và DH21. Tôi đã định cấu hình ban đầu với AES-256-GCM để cố gắng tránh mọi thứ liên quan đến lỗi cắt ngắn SHA2. Điều đó cũng không hoạt động.

Thẻ tải trọng chứng chỉ

1. Tôi đã cấu hình cái này theo nhiều cách khác nhau. Mặc dù vậy, nội dung tiêu chuẩn được áp dụng ở đây: Danh tính .p12, có cả mật khẩu khóa riêng cho người dùng cũng như mật khẩu xuất (cả hai đều dài 23 ký tự). Thời hạn là 920 ngày. Tôi đã đọc ở đâu đó rằng đây có thể là vấn đề, nhưng nhật ký tôi tìm thấy phía khách hàng không phản ánh việc khó chịu với khoảng thời gian hợp lệ. Ngoài ra, tôi đã kiểm tra thời gian chứng chỉ ngắn hơn, 500 giờ để xem điều đó có hiệu quả không; Nó đã không làm.
2. CA gốc/CA trung gian đã được bao gồm trong hai cấu hình ở đây trong quá trình tạo PKCS12: Chỉ CA trung gian, so với toàn bộ chuỗi ca. Cả hai cấu hình đều không hoạt động ở Big Sur.
3. Nhập CA gốc/trung gian theo cách thủ công; Tôi đã đánh dấu cả hai là đáng tin cậy cho tất cả các trường hợp sử dụng. Tôi đã nhập/sao chép chúng từ móc khóa đăng nhập vào móc khóa Hệ thống. Tôi đã làm mọi thứ mà tôi có thể tìm thấy về chủ đề này và không có gì hiệu quả.

Cấu hình phía máy chủ

auto=thêm
  authby=rsasig
  dpddelay=30
  dpdtimeout=120
  dpdaction=xóa
  phân mảnh = không (Big sur đưa ra một lỗi khác khi bật tính năng này)
  modecfgpull=có
  modecfgdns="DNS nội bộ"
  pfs=vâng
  rekey=có 
  thời gian sống = 8h
  ikelifetime=8h
  left=IP CÔNG CỘNG
  leftcert=PUBLIC IP (Tôi đã thử các hình thức khác nhau ở đây; @PUB... v.v.)
  leftid=IP CÔNG CỘNG
  leftsendcert=luôn luôn
  leftsubnet=0.0.0.0/0
  leftrsasigkey=%chứng chỉ
  leftmodecfgserver=có
  rightaddresspool=Nhóm địa chỉ nội bộ
  đúng =% bất kỳ
  rightrsasigkey=%chứng chỉ
  rightmodecfgclient=có

Nhật ký phía khách hàng

Trước hết, cửa sổ bật lên lỗi GUI duy nhất tôi thấy ở đây khi thử kết nối là "Xác thực người dùng không thành công". Sau đó, tôi sử dụng lệnh sau để có được các bản ghi tốt hơn/hữu ích hơn trên Mac OS X:

nhật ký hiển thị --start DATE --predicate 'senderImagePath chứa[cd] "NetworkExtension"'

Phần lớn các nhật ký này là 1000 dòng rác. Điều đó nói rằng, điều này có vẻ có liên quan:

10-08-2021 0x1aa44  Lỗi                 2375  0      NEIKEv2Provider: (NetworkExtension) [com.apple.networkextension:] Lỗi đánh giá chứng chỉ = kSecTrustResultRecoverableTrustFailure
2021-08-10 0x1aa44  Lỗi                    2375  0                           2375    NEIKEv2Provider: (NetworkExtension) [com.apple.networkextension:] Chứng chỉ không đáng tin cậy
2021-08-10 0x1aa44  Lỗi                2375  0                             ÂIKEv2Provider: (NetworkExtension) [com.apple.networkextension:] Không thể xác minh dữ liệu xác thực chứng chỉ
08-08-2021 0x1aa44   Mặc định  0x0            2375  0    NEIKEv2Provider: (NetworkExtension) [com.apple.networkextension:] IKEv2IKESA[2.2, C4CABCADAB06C2CF-75E7F26177F83ing] Trạng thái kết nối1 > Lỗi ngắt kết nối (null) -> Miền lỗi=NEIKEv2ErrorDomain Code=8 "Xác thực: Không thể xác minh dữ liệu xác thực chứng chỉ" UserInfo={NSLocalizedDescription=Authentication: Không thể xác minh dữ liệu xác thực chứng chỉ}
10-08-2021 0x1aa44  Lỗi                  2375  0      NEIKEv2Provider: (NetworkExtension) [com.apple.networkextension:] IKEv2Session[2, C4CABCADAB06C2CF-75E7F26177F831] Không thành công xử lý gói IKE Auth (kết nối)

ghi chú

Như được mô tả trong các nhận xét trước đó về cấu hình máy khách .. Có vẻ như tôi đã hoàn thành công việc để làm điều này đúng. Nó hiển thị ngay cả trong màn hình Trình cấu hình Apple, rằng đây là gói cấu hình có thể chấp nhận được. Rõ ràng là nó không được ký bởi Apple, nhưng không có gì ngạc nhiên.Cấu hình IKEv2 thủ công, tiêu chuẩn đơn giản là không đủ toàn diện cho nhu cầu của chúng tôi. Và chắc chắn là nó cũng không hoạt động. Ít nhất là đối với bất cứ thứ gì phức tạp hơn đồ chơi trẻ em của máy chủ.

Tôi cũng đã nghiên cứu vấn đề về Tính minh bạch của chứng chỉ; Thật không may, đây không phải là giải pháp cho Mac OS X. Đây chỉ là giải pháp áp dụng cho các thiết bị như iPad, v.v. Cố gắng cài đặt mobileconfig cho OS X có bật CT và ngoại trừ một số chứng chỉ, nó bị từ chối và sẽ không cài đặt mobileconfig.

Nhật ký phía máy chủ

Tôi có máy chủ bên ngoài ở chế độ gỡ lỗi để tạo nhiều nhật ký hơn bình thường. Điều đó nói rằng, trong trường hợp này, máy chủ có vẻ hoàn toàn hài lòng với giao dịch, nhưng phía khách hàng lại ghét ........ gì đó. Tôi không biết những gì.

Đây là những gì tôi thấy mặc dù:

Ngày 10 tháng 8 serverName pluto[]: | đã cung cấp CA: 'C=US, ST=US, O=companyName, OU=OUCA, CN=CAName, [email protected]'
Ngày 10 tháng 8 serverName pluto[]: "remote"[51] serverIP #90: ID ngang hàng chế độ IKEv2 là ID_USER_FQDN: '[email protected]'
Ngày 10 tháng 8 serverName pluto[]: | đã nhận v2N_INITIAL_CONTACT                              
Ngày 10 tháng 8 serverName pluto[]: | Đã nhận được thông báo không xác định/không được hỗ trợ v2N_NON_FIRST_FRAGMENTS_ALSO - bị bỏ qua
Ngày 10 tháng 8 serverName pluto[]: | đã nhận v2N_MOBIKE_SUPPORTED trong khi nó không được gửi       
Ngày 10 tháng 8 serverName pluto[]: | đã nhận được tải trọng CERTREQ; sẽ giải mã nó              
Ngày 10 tháng 8 serverName pluto[]: | CERT_X509_SIGNATURE CR:                                   
Ngày 10 tháng 8 serverName pluto[]: | 10 81 9a c1 4c a6 94 70 ca d1 7d 77 e1 5a ab 36      
Ngày 10 tháng 8 serverName pluto[]: | 93 3d cd 39                                             
Ngày 10 tháng 8 serverName pluto[]: | nội dung blob chứng chỉ không phải là nhị phân ASN.1                   
Ngày 10 tháng 8 serverName pluto[]: | xác minh tải trọng AUTH                                    
Ngày 10 tháng 8 serverName pluto[]: | RSA CA bắt buộc là '%any'                                 
Ngày 10 tháng 8 serverName pluto[]: | kiểm tra khóa RSA 'serverIP' để khớp với '[email protected]'
Ngày 10 tháng 8 serverName pluto[]: | kiểm tra RSA keyid 'C=US, ST=US, L=City, O=companyName, OU=OUCA, CN=UserCN, [email protected]' để khớp với '[email protected]'                                                                                                                         
Ngày 10 tháng 8 serverName pluto[]: | kiểm tra khóa RSA '[email protected]' để khớp với '[email protected]'
Ngày 10 tháng 8 serverName pluto[]: | Trusted_ca_nss: người được ủy thác A = 'C=US, ST=US, O=companyName, OU=OUCA, CN=CAName, [email protected]'
Ngày 10 tháng 8 serverName pluto[]: | nhà phát hành khóa CA là 'C=US, ST=US, O=companyName, OU=OUCA, CN=CAName, [email protected]'
Ngày 10 tháng 8 serverName pluto[]: | kiểm tra RSA Sig được thông qua với *AwEAAbi14 [chứng chỉ từ xa]
Ngày 10 tháng 8 serverName pluto[]: "remote"[51] serverIP #90: Được xác thực bằng RSA          

Nhật ký máy chủ cho thấy rằng máy khách Mac OS X Big Sur, xác thực đúng cách. Sau đó, nó tiếp tục xây dựng mối quan hệ SA, v.v., như bạn thường thấy. Khách hàng, là người từ chối kết nối ra khỏi tầm tay. Điều tôi không hiểu là điều gì đã thay đổi giữa Catalina và Big Sur ??

Tôi không tìm thấy thông tin nào về sự thay đổi hệ điều hành này. Tôi không hiểu tại sao đây không phải là phông chữ 60 point, in đậm, trên trang nhất của trang web Apple, ồ, thật thú vị, chúng tôi đã thay đổi hoàn toàn cách thức hoạt động của IPSEC trong phiên bản HĐH này. Và, tôi mệt mỏi với việc nhổ tóc hoặc đập đầu vào tường liên tục.

Bất kỳ trợ giúp sẽ được đánh giá cao.