L2TP không có IPsec trên Linux: xl2tpd, pppd và NAT

L2TP trần là PPP trong một phong bì, và không gì khác. Nó mang các khung của bạn; nó không mã hóa chúng và không chứng minh ai ngồi ở đầu bên kia, đó là lý do gần như mọi triển khai đều đặt IPsec bên dưới. Vẫn có những lý do chân thành để chạy phiên bản trần: một băng ghế phòng thí nghiệm, một bước chuyển đổi, hoặc một liên kết đã nằm trong một con đường được bảo vệ khác.

Nếu bạn vẫn tiếp tục, hãy ghi lời cảnh báo đó vào ghi chú thiết kế và để nó ở đó. Những gì sau đây là con đường vận hành tôi dùng trên các máy chủ thuộc họ Debian và RHEL: tệp nào chịu trách nhiệm việc gì, MTU ngăn sự cố đứng hình kinh điển, và các quy tắc chuyển tiếp khiến đường hầm đáng giá.

Ba tệp chia nhau công việc

xl2tpd kết thúc kết nối điều khiển và giao từng phiên cho một daemon PPP, vì vậy cấu hình trải trên hai chương trình không bao giờ đọc tệp của nhau. Bộ lắng nghe sống trong /etc/xl2tpd/xl2tpd.conf, bên trong một phần [lns default] đặt tên nhóm địa chỉ bằng ip range, phía máy chủ bằng local ip và việc bàn giao cho PPP bằng pppoptfile. Bật require authentication = yes, để length bit và flow bit được bật, và chọn một nhóm mà không thứ gì khác trên máy chủ đang dùng.

Chính sách PPP thuộc về tệp mà tùy chọn đó nêu tên, thường là /etc/ppp/options.xl2tpd: auth, từ chối cho pap, chap và mschap, require-mschap-v2, MTU và MRU là 1460, và một địa chỉ DNS mà máy khách có thể tới sau khi liên kết lên. Thông tin đăng nhập lại là tệp thứ ba, /etc/ppp/chap-secrets, nơi trường thứ hai phải khớp với tên phần LNS và trường thứ tư có thể ghim một địa chỉ cụ thể từ nhóm.

Vì sao đường hầm kết nối rồi đứng hình

Một khung Ethernet 1500 byte không vừa trong một con đường đã tốn byte cho tiêu đề của chính nó. Tiêu đề IPv4 bên ngoài tốn 20, UDP tốn 8 và tiêu đề L2TP khoảng 12, để lại 1460 cho PPP và phần tải của nó. Chính việc quảng bá con số nhỏ hơn đó trong PPP là thứ giữ cho các gói lớn khỏi bị phân mảnh hoặc bị bỏ rơi âm thầm ở đâu đó giữa đường.

Triệu chứng là một đường hầm trông khỏe mạnh cho đến khi lưu lượng thật đến: ping và các thông điệp điều khiển đi qua, việc sao chép tệp bị treo, không gì trong nhật ký giải thích điều đó. Giảm MTU và MRU cùng lúc ở cả hai đầu. Chỉ chỉnh máy khách thường biến treo cứng thành treo chập chờn, khó chẩn đoán hơn.

Một cổng mang hai cuộc trò chuyện

UDP 1701 nằm dưới cả hai nửa của giao thức, và riêng sự thật đó phá vỡ nhiều quy tắc tường lửa hơn bất kỳ phần nào khác của thiết lập. Đầu tiên là yêu cầu bắt đầu kết nối điều khiển và trả lời của nó; yêu cầu phiên và xác nhận theo sau không thiết lập gì hơn cặp định danh. Sau đó PPP tiếp quản: điều khiển liên kết, rồi xác thực, rồi giao thức điều khiển IP để thống nhất địa chỉ. Mỗi giai đoạn có từ vựng riêng trong nhật ký, và không giai đoạn nào tự công bố là sự cố L2TP.

Đọc một bản ghi đúng theo thứ tự đó cho bạn biết giai đoạn nào thất bại, và lỗi xác thực PPP không được sửa bằng cách chỉnh sửa xl2tpd. Cổng dùng chung giải thích một lỗi phổ biến khác: một quy tắc chỉ cho phép các gói đầu tiên của một luồng để phiên thiết lập rồi chặn việc truyền. Cho phép 1701 cho toàn bộ cuộc trò chuyện, theo cả hai hướng.

Làm cho đường hầm hữu ích: chuyển tiếp và NAT

Một phiên tự nó chỉ tới được máy chủ. Truy cập internet của máy khách cần chuyển tiếp, một quy tắc NAT cho nhóm trên liên kết lên, và DNS mà máy khách thực sự có thể hỏi sau khi liên kết lên. Nhóm cũng phải nằm ngoài dải LAN, nếu không các trả lời gửi cho máy khách sẽ được giao cục bộ thay vì bị đẩy ngược vào đường hầm.

Trên máy chủ, bật chuyển tiếp bằng sysctl -w net.ipv4.ip_forward=1, dịch nhóm bằng iptables -t nat -A POSTROUTING -s 10.44.0.0/24 -o eth0 -j MASQUERADE, rồi nhận lưu lượng đường hầm đi ra bằng quy tắc FORWARD cho -i ppp0 -o eth0 và lưu lượng quay về bằng quy tắc gương cộng -m state --state RELATED,ESTABLISHED. Hãy làm cho các quy tắc đó bền vững qua các lần khởi động lại, vì một máy chủ trở lại mà không có chúng trông đúng như một cấu hình L2TP hỏng.

Tới LAN của chính máy chủ là việc khác: thêm tuyến quay về cho nhóm trên router LAN, hoặc proxy ARP trên máy chủ. Giấu máy khách sau NAT khi có thứ gì trong LAN phải nhắm trực tiếp tới họ chỉ là lên lịch một phiên gỡ lỗi thứ hai về sau.

Ngăn xếp trần không làm gì, và cách kiểm chứng

Không phần nào của ngăn xếp này mã hóa các khung PPP, và không gì trong đó xác thực đầu xa như đúng máy chủ bạn đã chọn. MS-CHAPv2 có bảo vệ việc trao đổi thông tin đăng nhập khỏi một kẻ nghe chỉ quan sát, nhưng kẻ tấn công nằm trên đường vẫn có thể can thiệp vào phiên. Máy khách gốc của Windows chỉ cung cấp L2TP cùng với IPsec, nên hãy tính Linux, firmware router và máy khách bên thứ ba là đối tác của bạn. Hãy coi cấu hình trần là một bậc chẩn đoán, không bao giờ là nơi dừng lại.

Kiểm tra theo một thứ tự cố định: chạy xl2tpd -D ở tiền cảnh, theo dõi nhật ký cho giai đoạn PPP, đọc địa chỉ được cấp từ ip addr ở cả hai đầu, rồi bắt UDP 1701 để xác nhận dữ liệu chảy sau khi phiên lên. Nếu cả bốn khớp và lưu lượng vẫn thất bại, lỗi nằm ở định tuyến, NAT hay MTU chứ không phải bản thân L2TP.