Bước nhảy tiếp theo trong tuyến VPN: vì sao cổng phải tiếp cận được tại chỗ

Một tuyến vào mạng VPN mang hai địa chỉ dễ nhầm lẫn: tiền tố đích mà gói tin đang cố chạm tới và bước nhảy tiếp theo sẽ đưa nó gần hơn một bước. Trên một máy chủ LAN, bước nhảy tiếp theo đó phải là một bộ định tuyến mà bạn thực sự tiếp cận được trên cùng liên kết. Địa chỉ VPN từ xa không phải là bước nhảy tiếp theo, dù nó khớp với đích trong đầu bạn gọn gàng đến đâu.

Cẩm nang này bao quát trường hợp thông thường: một máy tính xách tay trên 192.168.20.0/24, một cổng VPN có địa chỉ LAN là 192.168.20.5, và một mạng từ xa 10.70.0.0/24 phía sau cổng đó. Mọi lệnh bên dưới giả định bạn đang ở trên máy tính xách tay trừ khi có nói khác.

Hai địa chỉ, một tuyến

Mục dự kiến là 10.70.0.0/24 via 192.168.20.5. Tiền tố cho biết gói tin đi đâu; địa chỉ via cho biết ai mang nó tới đó. Nhân từ chối cài một tuyến mà nó không thể chạm tới cổng qua giao diện bạn nêu, và sự từ chối đó chính là toàn bộ vấn đề: một bước nhảy tiếp theo cần đường hầm để tiếp cận được không thể là bước nhảy tiếp theo dựng nên đường hầm.

Vì vậy kiểm tra đầu tiên không phải «cổng có hoạt động không» mà là «cổng có trên liên kết này không». Subnet của chính máy tính xách tay, mục ARP hoặc láng giềng của nó, và giao diện trong tuyến đều phải khớp nhau. Một địa chỉ chỉ tồn tại bên trong 10.70.0.0/24 có thể là đích của tuyến thứ hai, nhưng không bao giờ là via của tuyến đầu.

Bước nhảy tiếp theo ràng buộc cổng vào điều gì

Cài tuyến trên máy tính xách tay chỉ quyết định lần bàn giao đầu. Sau đó cổng cần đường đi của riêng nó: bật chuyển tiếp, một tuyến đường hầm cho 10.70.0.0/24 và mọi chính sách truy cập quy định ai được dùng nó. Trên Linux đó là net.ipv4.ip_forward=1 cộng một tuyến đường hầm; tường lửa phía trước cần một quy tắc cho phép luồng được chuyển tiếp.

Chiều quay về là phần người ta hay quên. Phía từ xa phải có tuyến quay về 192.168.20.0/24, hoặc thiết kế phải dịch nguồn của máy tính xách tay thành thứ mà phía từ xa biết. Một ping chạy được từ cổng chứng minh cổng chạm tới mạng từ xa; nó không nói gì về việc gói tin của máy tính xách tay có sống sót qua chuyến về hay không.

Xác minh tra cứu từ máy chủ gửi đi

Hỏi nhân xem nó sẽ chọn bước nhảy tiếp theo nào, và đọc giao diện trong câu trả lời:

ip route get 10.70.0.10
ip route show 10.70.0.0/24
ip neigh show 192.168.20.5

Nếu tra cứu báo cổng và giao diện LAN, đoạn đầu đã được cấu hình đúng như dự kiến. Nếu nó báo thiết bị đường hầm, một mục nào đó phía trước trong bảng cụ thể hơn và đang thắng. Nếu tuyến hoàn toàn không cài được, nhân đang nói với bạn rằng cổng không tiếp cận được, và thông điệp đó hữu ích hơn mọi lần bắt gói tin.

Sau đó lặp lại phép thử từ đúng chỗ. Một yêu cầu tạo trên cổng dùng địa chỉ nguồn của chính cổng, điều này có thể che mất tuyến quay về bị thiếu hoặc chính sách chỉ cho phép một số nguồn nhất định. Cẩm nang ip-route tách đích, cổng và phần ghi đè onlink, và phần ghi đè đáng để hiểu trước khi dùng.

Đừng dùng onlink để giả vờ khả năng tiếp cận

onlink bảo nhân bỏ qua phép kiểm tra tiếp cận của một cổng và vẫn gửi tới đó. Nó không tạo đường đi, không phân giải ARP cho một địa chỉ không tồn tại và không khiến một bộ định tuyến từ xa trả lời trên phân đoạn Ethernet của bạn. Nó hợp lệ với những cổng trả lời nhưng không nằm trong subnet kết nối, và nó là cái bẫy khi được dùng để bịt im một lỗi mà bạn chưa giải thích.

Nếu tuyến chỉ cài được với onlink, câu hỏi tiếp theo là vì sao cổng không ở nơi bạn nghĩ. VLAN sai, địa chỉ thứ hai trên giao diện sai, hoặc lỗi đánh máy ở octet cuối đều tạo ra điều này, và mỗi thứ trong số đó cũng phá đường quay về ngay khi lưu lượng bắt đầu chảy.

Đường hầm điểm-điểm không phải Ethernet

Một thiết bị đường hầm không làm ARP và thường không có subnet láng giềng có ý nghĩa. Các tuyến của nó thường trông như 10.70.0.0/24 dev tun0, không có via nào cả, vì đối tác là đầu kia duy nhất. Sao chép một via kiểu LAN vào bảng đó tạo ra một tuyến mà nhân có thể từ chối hoặc, tệ hơn, một tuyến trỏ tới địa chỉ mà đối tác không bao giờ trả lời.

Hãy tách hai mô hình trong cẩm nang: tuyến LAN có một cổng tiếp cận được, tuyến đường hầm có một giao diện và một đối tác. WireGuard, OpenVPN và IPsec đều thể hiện những hình dạng hơi khác nhau, nên hãy ghi lại hình dạng bạn thực sự dùng thay vì khái quát hóa từ một máy chủ.

Thêm, xác nhận, gỡ lại

Toàn bộ thay đổi là ba lệnh và một phép kiểm tra, và nên được ghi lại theo đúng thứ tự đó:

sudo ip route add 10.70.0.0/24 via 192.168.20.5
ip route get 10.70.0.10
ping -c 3 10.70.0.10
sudo ip route del 10.70.0.0/24 via 192.168.20.5

Xác nhận đường đi, xác nhận một đích, rồi giữ sẵn dòng xoá phòng khi thay đổi khiến máy chủ không tiếp cận được theo cách bạn không lường trước. Nếu tuyến phải sống sót qua lần khởi động lại, hãy đặt nó trong cấu hình mạng của máy chủ chứ không phải trong hồ sơ shell, và thử khởi động lại trước khi dựa vào nó. Một tuyến chỉ tồn tại trong shell đã thêm nó là tuyến bạn sẽ gỡ lỗi hai lần.