Cổng VPN trên Raspberry Pi: một card mạng hay một cổng máy khách riêng
Một cổng của Pi có thể phục vụ các máy khách được chọn, hoặc cổng thứ hai có thể nhốt thiết bị vào trong. Chọn cách bố trí theo mức khoanh vùng, chính sách dự phòng và ai sở hữu DNS.
Bạn có một Pi, một hồ sơ VPN đi ra đang hoạt động và hai thiết bị cần ra internet qua nó. Câu hỏi quyết định toàn bộ việc dựng đặt không phải là theo hướng dẫn nào, mà là cần bao nhiêu khoanh vùng. Một cổng cho phép Pi đứng cạnh các thiết bị đó trên LAN của router và hoạt động như một cổng phụ; cổng thứ hai cho phép đặt chúng vào một phân đoạn nơi Pi là lối ra duy nhất. Mọi thứ sau lựa chọn đó — DHCP, phạm vi tường lửa, DNS, tình huống đứt — đều bắt nguồn từ nó.
Hai cách bố trí thực sự khác nhau ở đâu
Cả hai thiết kế đều định tuyến. Khác biệt là ai khác đứng trên sợi cáp và điều gì xảy ra khi chính sách của bạn sai.
| Layout A: Pi on the ISP LAN | Layout B: dedicated client port | |
|---|---|---|
| Cabling | One Ethernet port, existing switch port | Two interfaces: uplink plus a separate LAN port |
| Can a client bypass the Pi? | Yes, by using the ISP router as its gateway | No, unless the device has another radio or link |
| Who hands out addresses | The ISP router, with a per-client setting or a DHCP option | The Pi, on its own LAN interface only |
| Blast radius of a mistake | Any LAN host, if a rule is too broad | The attached segment |
| Good fit for | One laptop, a console, a temporary test client | Appliances, always-on boxes, untrusted devices |
Trục thật là khoanh vùng. Cách A mang tính khuyến nghị: thiết bị bỏ qua cổng do DHCP cấp và chọn router vẫn hoạt động, nhưng không mã hóa. Cách B bị topo mạng cưỡng chế, vì không có bước nhảy kế tiếp nào khác để chọn.
Cách A: Pi như một cổng phụ trên LAN hiện có
Giả sử router của ISP là 192.168.50.1, Pi là 192.168.50.2, và các máy khách được chọn trỏ vào Pi. Điều quan trọng là hai luồng gói khác nhau dùng chung một sợi cáp. Gói bên trong của máy khách đến Pi và phải đi ra qua đường hầm; gói đã mã hóa của chính Pi tới đối tác VPN phải đi ra qua cùng sợi cáp đó tới router. Chúng đi ngược chiều nhau trên cùng một giao diện và cần cách xử lý khác nhau.
Cấp địa chỉ cho Pi qua trình quản lý mạng đã cài đặt, không phải bằng công thức tệp giao diện cũ vốn tranh thiết bị với nó. Sau đó cấu hình máy khách: một cổng tĩnh trên một thiết bị, hoặc một đặt trước DHCP cấp 192.168.50.2 làm router. Đừng đổi toàn bộ dải DHCP của router vì hai thiết bị, và đừng cho rằng máy khách tôn trọng tùy chọn đó — hãy kiểm chứng.
Điểm yếu là cấu trúc, không thể sửa. Bất kỳ máy khách nào trong phân đoạn đó đều có thể trỏ vào 192.168.50.1 và đi ra bằng văn bản rõ, và một thiết bị có giao diện thứ hai hay radio di động sẽ rời bỏ hoàn toàn đường cưỡng chế của bạn. Nếu câu đó không chấp nhận được với thiết bị liên quan thì bạn đã có câu trả lời: dùng cách B.
Cách B: một cổng riêng nhốt thiết bị vào trong
Ở đây Pi giữ 192.168.50.2 trên đường lên với cổng 192.168.50.1, và nhận 10.20.0.1/24 trên giao diện thứ hai cho các thiết bị kết nối. Giờ Pi là router có hai mạng, và phân đoạn được kết nối có đúng một lối ra.
Kiểm tra dải địa chỉ với mọi thứ khác trước khi cam kết: mạng con của chính đường hầm, các tiền tố giữa các site khác và mọi thứ tiếp cận được qua VPN. Một 10.20.0.0/24 xung đột với LAN ở xa cho kết quả nửa hoạt động khiến việc chẩn đoán tốn cả buổi tối. Nếu cổng thứ hai là bộ chuyển đổi USB, hãy xác nhận nó được hỗ trợ và ghim tên nó trong trình quản lý mạng để việc sắp xếp lại sau khi khởi động không làm dịch địa chỉ LAN của bạn.
Chỉ chạy trình lắng nghe DHCP trên giao diện đó. Một máy chủ trả lời trên đường lên sẽ cạnh tranh với router của ISP và cấp địa chỉ của phân đoạn bạn cho phần còn lại của nhà. Hãy gắn nó với giao diện LAN, giới hạn trong dải đã khai báo, và giữ địa chỉ của chính Pi ngoài vùng cấp phát.
Chuyển tiếp, biên dịch và quy tắc đóng khi hỏng
Bốn thứ thường được mô tả như một và không phải một. Bật chuyển tiếp (net.ipv4.ip_forward=1) chỉ nói với nhân rằng nó có thể chuyển gói giữa các giao diện; tự nó không cho phép gì và không bảo đảm đường nào. Chọn lối ra là quyết định định tuyến. Cho phép gói là quyết định chính sách trong chuỗi forward. Ghi lại nguồn của nó là quyết định postrouting. Một bản dựng chỉ làm điều thứ nhất tạo ra một Pi vui vẻ chuyển tiếp lưu lượng máy khách ra ngoài qua đường lên.
Giới hạn quyền cho đúng các nguồn bạn định và đúng giao diện mà lưu lượng phải dùng, và bao gồm đường về cùng các đích cần thiết của chính Pi. Sau đó biên dịch ở lối ra của đường hầm nếu nhà cung cấp không định tuyến tiền tố LAN của bạn ngược về cho bạn. hướng dẫn nftables coi chuyển tiếp, lối ra cục bộ và biên dịch nguồn là các thao tác riêng biệt, và đó là mô hình tư duy đúng ở đây.
Lỗi thường gặp là một quy tắc masquerade rộng trên giao diện vật lý. Khi đó lưu lượng tới internet theo đường của ISP trong khi từ phía máy khách nó trông đúng như một VPN đang chạy. Điều đó không chứng minh gì. Hãy giữ việc biên dịch gắn với lối ra đã khai báo, và giữ các quy tắc của bạn trong tường lửa mà máy chủ đã dùng, thay vì thêm một bộ quy tắc cạnh tranh làm rỗng chuỗi postrouting dùng chung.
Sau đó xử lý việc không có đường hầm. Một hồ sơ máy khách cài đặt tuyến mặc định rộng cũng có nghĩa là khi đường hầm sập, tuyến mặc định thông thường có thể quay lại và lưu lượng máy khách lặng lẽ quay về đường lên. Ở nơi việc quay lại văn bản rõ là không chấp nhận được, chính sách forward phải từ chối rõ ràng lưu lượng từ máy khách tới đường lên, trong trạng thái tuyến VPN đã mất. Hãy viết đó như một quy tắc từ chối, không phải một giả định. Việc vận chuyển đã mã hóa của chính Pi tới đối tác VPN là một luồng local-output riêng và phải tiếp tục được cho phép, nếu không đường hầm sẽ không bao giờ quay lại được.
DNS và IPv6 cần câu trả lời riêng
Nếu máy khách dùng Pi làm trình phân giải, chúng chạm tới một trình lắng nghe cục bộ và Pi khởi tạo một truy vấn mới. Truy vấn lên đó đi theo tuyến của chính Pi, không phải quy tắc forward bạn viết cho máy khách, nên đường của máy khách chỉ qua đường hầm cộng với một trình phân giải đi thẳng ra là một sự rò rỉ không có thông báo lỗi nào. Hãy quyết định có chủ đích: một trình phân giải tiếp cận qua đường hầm, hay một trình cục bộ mà bạn chấp nhận là trực tiếp, và làm cho chính sách ra của Pi khớp với quyết định đó.
IPv6 lại là trường hợp riêng. Một quy tắc forward cho IPv4 không giới hạn gì về IPv6, và các thông báo router trên đường lên có thể cấp cho Pi, và qua nó là phân đoạn được kết nối, một tuyến mặc định thứ hai vòng qua chính sách của bạn. Hoặc cho IPv6 một đường riêng được bảo vệ theo cùng nguyên tắc, hoặc giới hạn nó rõ ràng trên phân đoạn máy khách và nói ra điều đó.
Kiểm tra ranh giới trước khi tin vào nó
Chỉ chấp nhận thiết kế sau bốn lần kiểm tra riêng biệt, vì phép thử đơn lẻ đầy cám dỗ — mở trình duyệt trên một máy khách — vẫn qua được trong nhiều trạng thái hỏng.
Xác nhận một máy khách thật ra được internet qua đường hầm, rồi xác nhận chính máy khách đó không ra được internet khi đường hầm xuống. Xác nhận việc phân giải DNS hoạt động và truy vấn đi ra đúng nơi bạn định. Xác nhận việc vận chuyển của chính Pi vẫn hoạt động sau khi khởi động lại đường hầm, và việc phục hồi không đòi hỏi khởi động lại máy. Cuối cùng, kiểm tra một thiết bị bạn không chọn: ở cách A nó phải tiếp tục chạy bình thường, và ở cách B nó không được tồn tại trong phân đoạn đó.
- Hai cổng và một quy tắc từ chối cho sự cưỡng chế; một cổng và một tùy chọn DHCP cho lời khuyên.
- Biên dịch trên sai giao diện trông như thành công và không phải.
- Lưu lượng của chính Pi, DNS và IPv6 mỗi thứ cần một quyết định, không phải một suy luận.