route-gateway không phải redirect-gateway: điều gì thực sự thay đổi
Tùy chọn chỉ cung cấp bước nhảy tiếp theo cho các tuyến mà OpenVPN cài đặt. Xóa nó không tắt một đường hầm đầy đủ được đẩy xuống, và bản sửa thuộc về chuyển hướng.
Đường hầm của bạn dựng lên, mạng con riêng phản hồi, và việc duyệt web thông thường vẫn biến mất vào VPN dù ai đó đã xóa dòng cổng khỏi hồ sơ. Sự kết hợp đó là dấu vân tay của việc sửa sai chỉ thị. Phần bị xóa đang cấp cho máy khách bước nhảy tiếp theo cho các tuyến nó cài đặt; phần tiếp tục bắt lưu lượng đến từ nơi khác và được máy chủ đẩy xuống. Phạm vi phủ và bước nhảy tiếp theo là hai công việc riêng, và chỉ một trong đó quyết định các đích công cộng có dùng đường hầm hay không.
Dòng bạn xóa là bước nhảy tiếp theo, không phải công tắc chính sách
Mỗi tuyến máy khách cài đặt cần một địa chỉ cổng để trỏ tới, và chỉ thị cổng là nguồn của địa chỉ đó khi tuyến không tự nêu tên. Xóa nó và các tuyến ấy không có chỗ bám, nên chúng hoặc không cài được hoặc rơi vào một đường không dẫn tới đâu. Mạng con riêng chính là thứ mà một tuyến như vậy đang chuyên chở.
Trong khi đó hành vi sống sót có một tác giả khác: một tùy chọn chuyển hướng trong khối được đẩy xuống, nó chuyển lưu lượng đi ra thông thường vào đường hầm theo các cờ của nó. Xóa cổng không tắt và cũng không làm yếu nó. Kết quả là tệ nhất của cả hai trạng thái, lưu lượng công cộng vẫn bị bắt và đích riêng đã biện minh cho đường hầm nay không thể tới được. Vì thế lần sửa thứ hai, làm cùng tinh thần, cũng không thay đổi gì.
Bốn đòn bẩy, bốn công việc khác nhau
Trong cuộc thảo luận này bốn chỉ thị được trích dẫn lẫn nhau, và chỉ một trong đó chi phối phạm vi phủ, tức là đích nào đi qua đường hầm. Chỉ thị thứ hai đặt bước nhảy tiếp theo mà các tuyến dùng, thứ ba cài một tiền tố duy nhất, và thứ tư ném bỏ mọi thứ máy chủ đẩy xuống, kể cả các tuyến riêng mà việc triển khai cần. Bảng sắp chúng theo điều quản trị viên muốn thay đổi chứ không theo tên, vì chính các tên gây ra nhầm lẫn. Hãy coi chúng là bốn quyết định riêng và chọn cái bạn thực sự muốn hoàn tác.
Trên thực tế cả bốn thường đến trong một khối được đẩy xuống, dòng nối dòng, khiến chúng trông như các phần của một thiết lập duy nhất. Không phải vậy, và tài liệu tham khảo OpenVPN ghi chúng là những cơ chế riêng chính vì lý do đó. Xác định quyết định nào bạn đang hoàn tác là công việc; việc sửa chỉ là một dòng.
| What you are trying to change | Directive that decides it | What it leaves alone |
|---|---|---|
| Which destinations use the tunnel | redirect-gateway | Per-prefix routes and resolver choice |
| The next hop a pushed route points at | route-gateway | Coverage of public destinations |
| One reachable prefix | route | Every other destination, default path included |
| All pushed routing and DNS at once | route-nopull | Nothing, which is the problem |
Lọc dòng được đẩy xuống, giữ bước nhảy tiếp theo
Nếu phạm vi phủ bạn phản đối đến dưới dạng tùy chọn được đẩy xuống, câu trả lời hẹp là bỏ qua tùy chọn đó theo tên và để phần còn lại của khối được đẩy nguyên vẹn. Viết dưới dạng bộ lọc, nó trông như dòng bên dưới, và chỗ của nó là trong hồ sơ của máy khách bị ảnh hưởng, không phải trong cấu hình máy chủ.
pull-filter ignore "redirect-gateway"Tính hẹp chính là điểm mấu chốt. Vì bộ lọc so sánh một tiền tố văn bản, mẫu ngắn hơn cũng khớp với chỉ thị bước nhảy tiếp theo, điều này bóc đúng thông tin mà các tuyến riêng phụ thuộc vào và lặp lại lỗi ban đầu trong bộ áo mới. Bộ lọc cũng chỉ tác động lên các tùy chọn được đẩy xuống, nên nó không bao giờ chạm vào một dòng tương đương được viết cục bộ hoặc bị trình quản lý mạng áp đặt. Hãy kết nối lại sau đó, vì một phiên đang sống không đánh giá lại những gì máy chủ đã đẩy xuống.
Đọc cuộc tra cứu, không phải bảng
Sau khi tải lại hồ sơ, hỏi nhân hệ điều hành xem hai đích thực sự sẽ đi đâu: một bên trong tiền tố riêng và một trên internet công cộng. Một bản kết xuất đầy đủ của bảng chính khó đọc hơn và dễ đọc sai hơn, vì một tuyến có thể tồn tại mà vẫn thua một khớp cụ thể hơn. Với định tuyến dựa trên chính sách, quy tắc, bảng và địa chỉ nguồn cũng thuộc phần kiểm tra.
ip route get 10.40.7.25
ip route get 203.0.113.77
ip rule showBiến thể def1 đáng được biết, vì nó để mục mặc định cũ hiện ra trong khi một cặp nửa mặc định thắng cuộc tra cứu. Vì thế một dòng 0.0.0.0/0 trong đầu ra tự nó không chứng minh điều gì. Cuộc tra cứu trả lời câu hỏi mà bản liệt kê chỉ có vẻ trả lời.
DNS, IPv6 và tuyến riêng vẫn phải hoạt động
Từ chối một chuyển hướng IPv4 không nói gì về bộ phân giải, nên một tùy chọn DNS được đẩy xuống có thể tiếp tục gửi truy vấn vào đường hầm trong khi các tuyến trông đúng. Mặc định IPv6 cũng có thể làm vậy với một họ địa chỉ mà kiểm tra IPv4 chưa từng chạm tới. Cả hai cần một quyết định rõ ràng thay vì giả định. Sau đó xác nhận dịch vụ riêng vẫn phản hồi, vì một đường hầm tách rời đã mất tuyến riêng của nó không phải là đường hầm tách rời, mà là đường hầm hỏng.
Một công cụ rộng hơn đáng được cảnh báo: route-nopull vứt bỏ mọi tuyến được đẩy xuống và mọi tùy chọn DNS được đẩy xuống, điều này chắc chắn dừng toàn bộ đường hầm và cũng chắc chắn làm gãy các tuyến riêng mà việc triển khai dựa vào, nên nó là một cây búa lớn hơn nhiều so với bộ lọc theo tên nhắm vào một tùy chọn. Kiểm tra đích riêng, một đích công cộng và bộ phân giải sau mọi thay đổi, và coi một cái bắt tay đã hoàn tất là bằng chứng cho không gì khác ngoài cái bắt tay.