Truy cập thiết bị trong nhà qua VPN truy cập từ xa: năm cổng
Một đường hầm tới nhà bạn cần một cổng trên mạng đó, chuyển tiếp và một đường phản hồi. Năm cổng, và cổng đầu tiên không có bằng chứng là vấn đề.
Một VPN thoát internet thương mại che giấu địa chỉ của bạn; nó không kết nối bạn với chính ngôi nhà của bạn. Để tới NAS hoặc máy in trên mạng trong nhà cần một cổng nằm trên mạng đó và một ứng dụng khách dựng đường hầm tới nó. Sau đó gói tin phải qua năm bước kiểm tra, và bất kỳ bước nào thất bại cũng trông giống nhau từ bên ngoài.
Cổng 1: ứng dụng khách phải chọn đường hầm
Kiểm tra xem tiền tố đích có thực sự được định tuyến vào đường hầm trên ứng dụng khách không. Một hồ sơ chia đường hầm chỉ đẩy subnet của chính VPN sẽ gửi 192.168.x.x thẳng ra khỏi giao diện cục bộ, nơi nó không tới được đâu. Hãy xem bảng định tuyến của ứng dụng khách, không phải tên hồ sơ.
Đây là lỗi phổ biến nhất ở ứng dụng khách điện thoại, vốn thường mặc định chỉ gửi DNS hoặc chỉ một tiền tố. Nếu thiếu tuyến, bắt tay có thể hoàn hảo mà thiết bị vẫn không tới được.
Xác nhận địa chỉ pool của ứng dụng khách và subnet trong nhà không chồng lấn trước khi tiếp tục.
Cổng 2: cổng phải chuyển tiếp
VPN kết thúc trên một máy chủ phải chuyển tiếp gói đã giải mã vào LAN. Điều đó đòi hỏi bật chuyển tiếp IP và chính sách tường lửa cho phép luồng từ giao diện VPN sang giao diện LAN. Trên thiết bị router điều này thường có sẵn; trên máy Linux chạy strongSwan hoặc WireGuard đó là hai thiết lập mà người ta quên. Kiểm tra cả hai trước khi thử dịch vụ, vì mỗi cái riêng lẻ đều tạo ra cùng một thời gian chờ.
Thử với bắt gói trên giao diện LAN, vì gói không bao giờ xuất hiện ở đó đã bị bỏ hoặc chưa từng được chuyển tiếp.
Đây là lỗi khác với dịch vụ từ chối kết nối, và sự phân biệt đó tiết kiệm rất nhiều thời gian. Giữ quyền hẹp, giới hạn ở dịch vụ và pool VPN thay vì toàn bộ subnet.
Cổng 3: đường phản hồi quyết định mọi thứ
Đích trả lời địa chỉ nguồn mà nó thấy, đó là địa chỉ pool của ứng dụng khách hoặc cổng, tùy thuộc bạn có dịch địa chỉ hay không. Nếu cổng mặc định của đích là router trong nhà và router đó không có tuyến tới pool VPN, phản hồi đi ra internet và chết. Đây là kết nối một chiều kinh điển.
Có hai cách sửa hợp lệ: thêm tuyến cho pool trên cổng LAN, hoặc làm source-NAT trên cổng VPN để đích luôn chỉ thấy địa chỉ cổng. Cách thứ hai dễ hơn và mất danh tính nguồn gốc.
Chọn một cách có chủ đích và ghi lại cách nào, vì các quy tắc tường lửa và nhật ký phụ thuộc vào điều đó. Hướng dẫn chuyển tiếp của strongSwan đi qua phía Linux của quyết định đó.
Cổng 4: tên và chồng lấn tiền tố
Tên khám phá cục bộ không vượt qua ranh giới định tuyến, nên một thiết bị hiện ra với tên thân thiện trong nhà có thể vô hình qua đường hầm. Cung cấp DNS cho vùng riêng, hoặc ghi lại địa chỉ. Bất kỳ tên nào bạn dùng phải phân giải thành thứ mà ứng dụng khách từ xa có thể định tuyến. Đó là lý do một thiết bị có thể tới được bằng địa chỉ và vô hình bằng tên cùng lúc.
Tiền tố chồng lấn là cái bẫy khác: nếu pool của ứng dụng khách là 192.168.1.0/24 và mạng trong nhà cũng vậy, ứng dụng khách coi đích là cục bộ và không bao giờ gửi qua đường hầm.
Đánh số lại một bên, hoặc dùng pool từ một dải mà bạn sẽ không bao giờ gặp ở nhà.
Cổng 5: thử từ bên ngoài nhà
Thử từ bếp không chứng minh được gì, vì lưu lượng có thể không bao giờ rời LAN. Kết nối từ điểm phát sóng di động hoặc mạng khác, rồi đi qua các cổng theo thứ tự: tuyến trên ứng dụng khách, bắt gói trên giao diện LAN, phản hồi của dịch vụ, bắt gói phản hồi và phân giải tên. Cổng đầu tiên không tạo ra bằng chứng là nơi cần làm việc.
Nếu dịch vụ trả lời nhưng tên thì không, bạn có vấn đề DNS chứ không phải vấn đề đường hầm.
Lưu cấu hình đang hoạt động vào một ghi chú cùng pool, tuyến và lựa chọn NAT, vì lần thay router tiếp theo sẽ đặt lại cả ba.