Vì sao tra cứu tên thất bại qua một đường hầm OpenVPN được định tuyến

Một máy trả lời ping theo địa chỉ nhưng thất bại ở mọi tra cứu theo tên. Đường hầm đang hoạt động và tuyến đã có, nên kết luận tự nhiên là VPN bị cấu hình sai. Một kết luận hữu ích hơn là tra cứu đó chưa bao giờ có thể định tuyến: đường hầm định tuyến chỉ mang unicast IP, trong khi truy vấn là một quảng bá đi tìm một phân đoạn không tồn tại ở phía bên kia. Khi sự lệch tầng hiện ra, các cách sửa tự sắp xếp theo chi phí.

Lầm tưởng: đường hầm hỏng vì tên thất bại

Triệu chứng thuyết phục vì mọi thứ phía trên tầng tên đều hoạt động. Địa chỉ được định tuyến, giao diện đang hoạt động, và đầu bên kia trả lời ping. Thứ thất bại là một cơ chế khám phá chưa bao giờ có đường đi qua một liên kết điểm-điểm, và đó là một phát biểu khác với đường hầm hỏng. Tách hai phát biểu đó ra chính là phần lớn của việc chẩn đoán.

Coi đó là lỗi đường hầm dẫn đến những chỉnh sửa hồ sơ không thể giúp gì. Thêm tuỳ chọn, đổi mã hoá hay cài lại máy khách đều để nguyên quảng bá ở chỗ cũ.

Hãy gọi tên cơ chế đã thất bại trước khi gọi tên cách sửa. Tra cứu dùng quảng bá cần một phân đoạn, còn tra cứu dùng bộ phân giải cần một địa chỉ để hỏi.

TUN mang gì và không mang gì

Thiết bị TUN là một giao diện IP, và chính điều đó khiến nó định tuyến được. OpenVPN cấp cho máy khách một địa chỉ và một tập tuyến, và từ đó máy khách gửi datagram tới đầu bên kia. Không gì trong mô hình đó tạo ra một liên kết chia sẻ nơi mọi máy đều nghe mọi khung.

Lưu lượng khám phá hoàn toàn không khớp với mô hình đó. Các truy vấn tên cũ của Windows, thông báo SSDP và yêu cầu mDNS được gửi tới mọi người trong một phân đoạn chứ không phải một đích. Một liên kết định tuyến không có «mọi người» để gửi tới. Mỗi cơ chế đó đều giả định một môi trường chia sẻ.

Vì vậy đường hầm có thể khoẻ mạnh trong khi khám phá thất bại hoàn toàn. Đó chính là câu cần bám vào khi ai đó báo rằng VPN đã chết.

Bắc cầu hoạt động bằng cách xoá ranh giới

Thiết bị TAP mang khung, và một cầu nối gắn nó vào một phân đoạn LAN thật. Máy khách khi đó có địa chỉ trên phân đoạn đó và nghe lưu lượng quảng bá của nó. Đó là lý do bắc cầu có vẻ chữa được vấn đề tên. Nó cũng làm máy khách phụ thuộc vào phân đoạn đó để đánh địa chỉ.

Cách chữa là xoá bỏ ranh giới định tuyến, không phải một khả năng đặt tên mới bên trong đường hầm. Mọi thứ phân đoạn quảng bá nay cũng đi qua liên kết.

Với một phòng thí nghiệm nhỏ thì đó là trao đổi công bằng. Với một lực lượng lao động phân tán thì hiếm khi.

Đẩy DNS và WINS là cách sửa hẹp hơn

Cho máy khách một chỗ cụ thể để hỏi. dhcp-option DNS và dhcp-option DOMAIN trỏ tên nội bộ tới một máy chủ biết vùng, và một máy khách Windows còn dựa vào NetBIOS cũng có thể nhận máy chủ WINS theo cùng cách. Đường hầm vẫn định tuyến và phân đoạn vẫn ở đúng chỗ của nó.

Hai điều kiện quyết định việc đó có hiệu quả hay không. Máy chủ được nêu phải trả lời cho vùng, và truy vấn phải được cho phép đi qua đường hầm.

Hãy thử bộ phân giải từ máy khách chứ không phải từ shell của chính máy chủ. Một bộ phân giải chạy cục bộ không nói gì về thứ đường hầm mang.

Tìm ra tầng nào đã thất bại

Trước hết ping địa chỉ, sau đó phân giải tên và đọc xem máy chủ nào đã trả lời. Một câu trả lời phủ định từ máy chủ không lưu trữ vùng trông khác với một truy vấn chưa bao giờ rời khỏi máy. Một tên phân giải được nhưng từ chối kết nối là vấn đề thứ ba hoàn toàn khác.

Multicast nằm sau cùng bức tường đó. Một nhóm như 224.0.0.251 không được chuyển tiếp qua đường hầm định tuyến theo mặc định, và một tuyến cho nhóm là không đủ nếu thiếu đường đi hiểu multicast hoặc một bộ phản xạ trên LAN.