Phản hồi của VPN site-to-site không đi qua đường hầm

Tôi dành một buổi sáng cho một đường hầm dựng lên sạch sẽ và chỉ chuyển lưu lượng theo đúng một hướng: chi nhánh đến được máy chủ tệp ở trụ sở, còn mọi kết nối mở từ trụ sở vào chi nhánh đều chết ở SYN đầu tiên. Các SA đã lên, bộ đếm đường hầm tăng, và bắt tay chưa bao giờ là vấn đề. Phản hồi đang được định tuyến đến nơi đường hầm không phủ tới, và lựa chọn đó thuộc về phía xa. VPN site-to-site chỉ chở những gói mà host giao cho cổng, và mỗi host đưa ra lựa chọn đó riêng, theo từng hướng, từ bảng định tuyến của chính nó.

Hai hướng được định tuyến riêng

IP không ghi nhớ hướng của một cuộc trò chuyện. Mỗi host gửi gói tự chạy tra cứu tiền tố dài nhất, chọn một bước nhảy kế tiếp và quên quyết định đó. Yêu cầu và phản hồi là hai gói không liên quan tình cờ thuộc cùng một kết nối, và đường hầm là một bước nhảy mà mỗi gói có thể dùng hoặc không. Không có gì trong trao đổi IKE dạy máy chủ xa cách đến mạng con của bạn; thương lượng chỉ đồng ý những tiền tố nào được mã hóa.

Thỏa thuận đó là cánh cổng thứ hai. Trên strongSwan, bộ chọn lưu lượng là leftsubnet và rightsubnet, và gói có nguồn hoặc đích nằm ngoài cặp đã thương lượng sẽ không được mã hóa, bảng định tuyến nói gì cũng vậy. Một tiền tố được định tuyến vào đường hầm nhưng thiếu trong bộ chọn là một lỗi âm thầm một chiều: tuyến trông đúng, gói vẫn ra ngoài ở dạng rõ hoặc bị bỏ, và chỉ nhật ký charon phàn nàn.

Host xa không biết gì về đường hầm của bạn

Bên trong LAN xa, phản hồi là một gói bình thường gửi tới máy khách của bạn. Host đích không thấy tiêu đề IPsec nào và không có lý do ưu tiên cổng VPN; nó tra tiền tố của bạn, không tìm thấy gì cụ thể hơn tuyến mặc định của nó và đi theo tuyến đó. Nếu tuyến mặc định trỏ tới một tường lửa lõi, tường lửa hoặc có tuyến quay lại đường hầm hoặc không. Khi không có, bạn nhận được một lần bỏ im lặng, một ICMP unreachable, hoặc một phản hồi đi ra qua giao diện hướng internet rồi chết.

Một giao diện thứ hai là đủ để phá điều này ngay cả khi đã có tuyến. Một NAS có liên kết quản trị trên VLAN khác, một máy chủ có uplink dự phòng, một quy tắc chính sách đẩy một dải nguồn sang bảng thứ hai: bất kỳ cái nào trong số này đều có thể bắt lấy phản hồi. Trên Linux, ip rule show và ip route show table all hiển thị các quy tắc và bảng mà danh sách mặc định giấu đi.

Đọc quyết định trên máy gửi phản hồi

Hãy hỏi nhân trước khi thay đổi bất cứ điều gì, và đưa cho nó địa chỉ nguồn, vì các quy tắc phụ thuộc nguồn làm thay đổi câu trả lời.

ip route get 10.10.5.10 from 10.20.30.15
ip rule show
ip route show table all
ss -tn state established "( sport = :445 )"

Kết quả nêu giao diện đi ra và bước nhảy kế tiếp. Nếu giao diện không phải là giao diện hướng tới cổng VPN, bạn đã tìm ra khiếm khuyết, và việc còn lại là chọn nơi tuyến nên nằm. Ping từ cổng chứng minh được ít ở đây: nó trả lời bằng một địa chỉ mà host xa có thể đặt vào bảng, không phải địa chỉ máy tính xách tay của bạn.

Trên Windows, tương đương là Find-NetRoute -RemoteIPAddress 10.10.5.10 cho quyết định và Get-NetRoute cho bảng. Một tuyến thêm bằng New-NetRoute mang metric cao hơn tuyến mặc định sẽ thua trong im lặng, nên hãy đọc cột metric, không phải mục nhập. Rồi xác nhận bằng gói: tcpdump -ni any "host 10.10.5.10 and tcp port 445" trên giao diện LAN xa cho thấy yêu cầu, và cùng bộ lọc đó ở phía đường hầm cho thấy phản hồi có quay về hay không. Thấy yêu cầu mà không có phản hồi nghĩa là phản hồi đã được định tuyến đi nơi khác hoặc bị bỏ; một phản hồi trên giao diện sai cho bạn thủ phạm trước khi bạn chạm vào tuyến.

Khi cổng của máy chủ không phải điểm cuối VPN

Nhiều nơi đặt tường lửa giữa máy chủ và bộ tập trung. Tường lửa đó chuyển tiếp phản hồi, nên nó cần một tuyến cho tiền tố máy khách của bạn trỏ tới cổng VPN, và chính sách chuyển tiếp ở cả hai hướng. Thiết bị có trạng thái làm mọi thứ tệ hơn: yêu cầu đi qua tường lửa từ một host LAN mà nó cho phép, phản hồi giờ đến từ hướng khác, và mục theo dõi kết nối không còn khớp, nên gói bị bỏ vì không hợp lệ thay vì bị từ chối. Đó là lý do nhật ký chính sách trông trống trong khi lưu lượng biến mất.

Cổng có bộ lọc thứ hai của riêng nó. Lọc đường dẫn ngược của Linux bỏ những gói mà nguồn không thể tiếp cận qua giao diện chúng đi vào, và đó chính xác là hình dạng của một đường về không đối xứng hợp lệ. hướng dẫn chuyển tiếp của strongSwan yêu cầu net.ipv4.ip_forward và một net.ipv4.conf.all.rp_filter nới lỏng đúng vì lý do đó. Giá trị nghiêm ngặt 1 trên một trong hai cổng phá một tuyến đúng trong im lặng, và nstat -az cho thấy các lần bỏ nếu bạn biết nhìn ở đâu.

Định tuyến hoặc dịch, rồi xác minh theo cả hai hướng

Hai cách sửa không tương đương. Thêm tuyến giữ nguyên địa chỉ máy khách, nên các quy tắc dựa trên nguồn, nhật ký kiểm toán và ứng dụng ghi lại người gọi vẫn hoạt động; cái giá là mỗi bước nhảy ra quyết định đều cần tuyến, tức là nhiều chỗ để sai hơn. Mặt nạ tại cổng xa nén đường về thành một bước nhảy, vì phản hồi giờ được gửi tới chính cổng, và che đi máy khách nào đã làm gì.

iptables -t nat -A POSTROUTING -o eth1 -s 10.20.30.0/24 -j MASQUERADE

Hãy chọn nó một cách có chủ đích: khi máy khách xuất hiện dưới địa chỉ của cổng, các ACL dựa trên nguồn không còn phân biệt được chúng, và conntrack phải giữ ánh xạ để phản hồi được ghi ngược vào đường hầm. Nếu bộ chọn vẫn loại trừ tiền tố máy khách, NAT không thay đổi gì, vì yêu cầu chưa bao giờ vào đường hầm.

Trước khi nói đã sửa, hãy xác nhận bốn điều theo thứ tự: tuyến trên host gửi phản hồi, tuyến trên mỗi bước nhảy chuyển tiếp nó, các bộ chọn bao phủ cả hai tiền tố, và một bản bắt cho thấy phản hồi đi vào đường hầm với nguồn bạn mong đợi. Sau đó lặp lại thử nghiệm từ nơi khác. Một hướng đi qua là thiết kế nửa mở, và hướng thứ hai thường hỏng vì lý do khác với lý do bạn vừa sửa.