Điểm:0

Triển khai rfc3442 (tuyến tĩnh không có lớp) trong máy chủ Freeradius DHCP

lá cờ us

Tôi đang cố gắng thiết lập máy chủ Strongswan chạy ở chế độ đường hầm phân tách, điều đó có nghĩa là tôi phải tắt sử dụng máy chủ làm cổng mặc định ở phía máy khách và cũng tắt định tuyến đầy đủ theo lớp trong máy khách VPN.

sau đó tôi phải gửi Tùy chọn DHCP 121 (tuyến tĩnh không có lớp) và Tùy chọn DHCP 249 (Biến thể Microsoft của tuyến tĩnh không có lớp) khi máy khách yêu cầu địa chỉ IP từ máy chủ Strongswan VPN.

Tôi cần cả hai tùy chọn 121 và 249 để tính đến tất cả các tổ hợp hệ điều hành có thể kết nối (Windows, Linux, Android, MacOS, iPhone, v.v.).

Tôi không đạt được nhiều thành công khi sử dụng máy chủ ISC DHCP với Strongswan, vì tôi không hài lòng khi nghe lưu lượng truy cập qua giao diện WireGuard.Nó nói rằng nó không hỗ trợ giao diện WireGuard hoặc loopback và về cơ bản, nó đã bỏ qua các yêu cầu DHCP đến từ máy chủ Strongswan VPN ở phía bên kia của liên kết wireguard.

Vì vậy, tôi đã chuyển sang máy chủ Freeradius DHCP, vì Strongswan đã sử dụng Freeradius để xác thực người dùng khi đăng nhập vào máy chủ Strongswan VPN.

Rốt cuộc: Nó khó đến mức nào, vì tôi chỉ định thêm "một vài tệp cấu hình vào Freeradius"? :-)

Hóa ra nó hơi phức tạp một chút, nhưng tôi đã khiến Freeradius lắng nghe lưu lượng truy cập trên liên kết Wireguard của mình bằng cách sử dụng cấu hình sau:

nghe {
        loại = dhcp
        # Mạng con 192.168.200.0/24 là mạng con WireGuard của tôi hoạt động như một 
        # Đường trục VPN từ trang này sang trang khác.

        ipaddr = 192.168.200.4
        src_ipaddr = 192.168.200.4
        cổng = 67
        giao diện = wg0
        phát sóng = không
}

Trong tệp Strongswan.conf của tôi, tôi có những điều sau đây:

charon {
  load_modular = có
  bổ sung {
    bao gồm Strongswan.d/charon/*.conf

    dhcp {
        force_server_address = có
        danh tính_lease = có
        giao diện = wg0
        tải = có
        máy chủ = 192.168.200.4
        use_server_port = có
    }
  }
}

Dù sao đi nữa: Tôi đã yêu cầu máy chủ Freeradius DHCP phân phát địa chỉ ip cho máy khách VPN khi Strongswan gửi DHCP-Discover hoặc DHCP-Request tới máy chủ Freeradius DHCP, nhưng bằng cách nào đó tôi không thể yêu cầu nó gửi các tuyến tĩnh?

Tôi có thể thấy trong tập tin từ điển cư trú tại /etc/freeradius/3.0 rằng từ điển cho các tùy chọn cụ thể của dhcp đang được tải từ /usr/share/freeradius/dictionary.dhcp.

Trong tệp đó, tôi có thể tìm thấy hai thông tin sau:

# Tùy chọn định tuyến tĩnh không có lớp
THUỘC TÍNH DHCP-Classless-Static-Route 121 octet

...

THUỘC TÍNH DHCP-Site-cụ thể-25 249 octet

Dựa theo Thiên Nga Mạnh Wiki Tôi có thể đặt cổng bước tiếp theo cho tuyến tĩnh của mình thành 0.0.0.0, vì vậy nếu tôi muốn nói rằng mạng con 192.168.200.0/24 có thể truy cập thông qua liên kết VPN. Tôi phải mã hóa tuyến đường dưới dạng octet được viết dưới dạng mã hex theo thứ tự: {CIDR}{Network}{Gateway}.

Cho nên 192.168.200.0/24 qua 0.0.0.0 trở thành 0x18C0A8C800000000

Vì vậy, tôi nghĩ rằng tôi chỉ nên sửa đổi cập nhật trả lời Trong dhcp DHCP-Khám phádhcp DHCP-Yêu cầu theo sau:

cập nhật câu trả lời {
    &DHCP-Domain-Name-Server = 192.168.200.1
    &DHCP-Subnet-Mask = 255.255.255.0
    &DHCP-IP-Địa chỉ-Thời gian thuê = 86400
    &DHCP-Classless-Static-Route = 0x18C0A8C800000000
    &DHCP-Site-cụ thể-25 = 0x18C0A8C800000000
    &DHCP-DHCP-Số nhận dạng máy chủ = 192.168.200.4
}

Tuy nhiên, tôi không thể thấy rằng tuyến đường đang được đẩy vào bảng định tuyến của mình khi tôi cố đăng nhập qua máy khách Windows VPN.

Vì vậy, những gì tôi đang thiếu?

Cập nhật

Hóa ra mã hóa cho Tùy chọn DHCP 249 hơi khác một chút so với tùy chọn DHCP 121.

Ít nhất là theo Trang web của Microsoft cho tùy chọn DHCP 249.

Tuy nhiên, tôi hơi bối rối về cách điều này chuyển thành mã hóa trong Freeradius.

Theo như tôi có thể nói, tôi đã nói rằng tiêu đề bắt đầu bằng tùy chọn DHCP 249, do cách DHCP-Site-cụ thể-25 đang được định nghĩa trong từ điển.

Nhưng trang web của Microsoft nói rằng byte đầu tiên sau đó là độ dài của tất cả các tuyến trong DHCP được đo bằng byte, theo sau là mã hóa tương tự cho các tuyến như được xác định trong tùy chọn DHCP 121.

Vì vậy, tuyến đường được mã hóa 0x18C0A8C800000000 phải được chuẩn bị trước với 08, do đó, dòng với Định tuyến tĩnh của Microsoft hiện có nội dung:

&DHCP-Site-cụ thể-25 = 0x0818C0A8C800000000

Tôi đã thử nghiệm với sửa đổi đó, nhưng vẫn không gặp may.

cập nhật thứ hai

Loay hoay thêm một chút với tệp cấu hình cho DHCP và sau đó theo dõi qua tcpdump về những gì đang thực sự xảy ra.

Bất cứ khi nào khách hàng đăng nhập vào Strongswan, yêu cầu về địa chỉ IP sẽ được chuyển tiếp đến máy chủ DCHP, do đó, về bản chất, Strongswan sẽ đóng vai trò là tác nhân chuyển tiếp DHCP nếu tôi hiểu đúng phần đó.

Trong tcpdump tôi có thể thấy quá trình trao đổi sau đang diễn ra:

Máy khách gửi DHCP Khám phá Máy chủ trả lời với Ưu đãi DHCP Máy khách gửi yêu cầu DHCP Máy chủ trả lời bằng DHCP ACK

Điểm nổi bật đầu tiên của tôi khi theo dõi tcpdump là tôi không phải tính toán độ dài byte trên tuyến tĩnh được mã hóa, bởi vì điều đó làm sai lệch đầu ra từ tcpdump.

Nói cách khác, mã hóa cho tùy chọn DHCP 121 và tùy chọn DHCP 249 là giống nhau.

Đọc thêm đề xuất định tuyến tĩnh được liên kết với Thông tin DHCP, nhưng tôi chưa bao giờ thấy gói đó trong tcpdump.

Đầu ra từ tcpdump khi chạy với cấu hình ban đầu của tôi là cập nhật trả lời ở trên đưa ra phiên sau:

tcpdump: lắng nghe trên wg0, RAW loại liên kết (IP thô), kích thước chụp 262144 byte

10:58:17.185671 IP (tos 0x0, ttl 64, id 46089, offset 0, flags [none], proto UDP (17), chiều dài 300)
    192.168.200.1.67 > 192.168.200.4.67: [udp sum ok] BOOTP/DHCP, Yêu cầu từ 7a:a7:8f:1f:b7:88, độ dài 272, xid 0x5c9716b5, Cờ [không] (0x0000)
          Cổng-IP 192.168.200.1
          Client-Ethernet-Address 7a:a7:8f:1f:b7:88
          Phần mở rộng của nhà cung cấp-rfc1048
            Bánh quy ma thuật 0x63825363
            DHCP-Message Tùy chọn 53, độ dài 1: Khám phá
            Client-ID Tùy chọn 61, độ dài 22: loại phần cứng 108, 61:73:73:65:40:68:6f:6d:65:2e:6d:6f:6c:67:61:61:72:64: 2e:65:75
            Tham số-Yêu cầu Tùy chọn 55, độ dài 2:
              Domain-Name-Server, Netbios-Name-Server
            KẾT THÚC Tùy chọn 255, độ dài 0

10:58:17.195305 IP (tos 0x0, ttl 64, id 19475, offset 0, flags [none], proto UDP (17), chiều dài 328)
    192.168.200.4.67 > 192.168.200.1.67: [bad udp cksum 0x129d -> 0x9ffd!] BOOTP/DHCP, Reply, độ dài 300, xid 0x5c9716b5, Flags [none] (0x0000)
          IP của bạn 192.168.201.13
          Cổng-IP 192.168.200.1
          Client-Ethernet-Address 7a:a7:8f:1f:b7:88
          Phần mở rộng của nhà cung cấp-rfc1048
            Bánh quy ma thuật 0x63825363
            DHCP-Message Tùy chọn 53, độ dài 1: Ưu đãi
            Subnet-Mask Tùy chọn 1, độ dài 4: 255.255.255.0
            Tên miền-Máy chủ Tùy chọn 6, độ dài 4: 192.168.200.1
            Tùy chọn Thời gian thuê 51, chiều dài 4: 86400
            Server-ID Tùy chọn 54, độ dài 4: 192.168.200.4
            Classless-Static-Route Tùy chọn 121, chiều dài 8: (192.168.200.0/24:0.0.0.0)
            Classless-Static-Route-Microsoft Option 249, chiều dài 8: (192.168.200.0/24:0.0.0.0)
            KẾT THÚC Tùy chọn 255, độ dài 0
            PAD Tùy chọn 0, độ dài 0, xảy ra 12

10:58:17.219444 IP (tos 0x0, ttl 64, id 46098, offset 0, flags [none], proto UDP (17), chiều dài 312)
    192.168.200.1.67 > 192.168.200.4.67: [udp sum ok] BOOTP/DHCP, Yêu cầu từ 7a:a7:8f:1f:b7:88, độ dài 284, xid 0x5c9716b5, Cờ [không] (0x0000)
          Cổng-IP 192.168.200.1
          Client-Ethernet-Address 7a:a7:8f:1f:b7:88
          Phần mở rộng của nhà cung cấp-rfc1048
            Bánh quy ma thuật 0x63825363
            DHCP-Message Tùy chọn 53, độ dài 1: Yêu cầu
            Client-ID Tùy chọn 61, độ dài 22: loại phần cứng 108, 61:73:73:65:40:68:6f:6d:65:2e:6d:6f:6c:67:61:61:72:64: 2e:65:75
            Tùy chọn IP được yêu cầu 50, độ dài 4: 192.168.201.13
            Server-ID Tùy chọn 54, độ dài 4: 192.168.200.4
            Tham số-Yêu cầu Tùy chọn 55, độ dài 2:
              Domain-Name-Server, Netbios-Name-Server
            KẾT THÚC Tùy chọn 255, độ dài 0

10:58:17.228663 IP (tos 0x0, ttl 64, id 19477, offset 0, flags [none], proto UDP (17), chiều dài 328)
    192.168.200.4.67 > 192.168.200.1.67: [bad udp cksum 0x129d -> 0x9d02!] BOOTP/DHCP, Reply, độ dài 300, xid 0x5c9716b5, Flags [none] (0x0000)
          IP của bạn 192.168.201.8
          Cổng-IP 192.168.200.1
          Client-Ethernet-Address 7a:a7:8f:1f:b7:88
          Phần mở rộng của nhà cung cấp-rfc1048
            Bánh quy ma thuật 0x63825363
            DHCP-Message Tùy chọn 53, độ dài 1: ACK
            Subnet-Mask Tùy chọn 1, độ dài 4: 255.255.255.0
            Tên miền-Máy chủ Tùy chọn 6, độ dài 4: 192.168.200.1
            Tùy chọn Thời gian thuê 51, chiều dài 4: 86400
            Server-ID Tùy chọn 54, độ dài 4: 192.168.200.4
            Classless-Static-Route Tùy chọn 121, chiều dài 8: (192.168.200.0/24:0.0.0.0)
            Classless-Static-Route-Microsoft Option 249, chiều dài 8: (192.168.200.0/24:0.0.0.0)
            KẾT THÚC Tùy chọn 255, độ dài 0
            PAD Tùy chọn 0, độ dài 0, xảy ra 12

Thực tế là tôi có thể nhìn thấy Classless-Static-RouteClassless-Static-Route-Microsoft được công bố và họ thực sự nói rằng mạng con 192.168.200.0/24 có sẵn thông qua đường hầm, cho tôi gợi ý rằng tôi đang đi đúng hướng.

Tuy nhiên:

Tuyến đường vẫn không xuất hiện trong bảng định tuyến của tôi.

Có lẽ nó có liên quan gì đó với dòng sau:

192.168.200.4.67 > 192.168.200.1.67: [không hợp lệ udp cksum 0x129d -> 0x9ffd!] BOOTP/DHCP, Reply, độ dài 300, xid 0x5c9716b5, Flags [none] (0x0000)

Bất cứ ai biết những gì là những gì cần sửa chữa?

Đă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.