Proxy vẫn ở địa chỉ tunnel cũ sau khi kết nối lại VPN?

Khởi động lại ứng dụng VPN chỉ chứng minh rằng tunnel đã trở lại. Nó không nói gì về proxy được lệnh đi ra qua tunnel đó. Squid, tinyproxy và hầu hết các bộ chuyển tiếp khác giữ địa chỉ nguồn cục bộ mà chúng phân giải lúc khởi động cho đến khi có gì đó buộc chúng tải lại. Khi việc kết nối lại cấp một địa chỉ tunnel mới, bộ chuyển tiếp hoặc thất bại ở mọi kết nối ra ngoài, hoặc bắt đầu đi ra qua tuyến thông thường của bạn.

Lỗi thứ hai mới là nguy hiểm: tunnel hoạt động, trang vẫn tải, và chỉ địa chỉ ra ngoài là sai.

Bắt đầu từ bộ lắng nghe, không phải tunnel

Có ba địa chỉ trong cuộc chơi, và việc kết nối lại chỉ dịch chuyển một số. Bộ lắng nghe là nơi trình duyệt của bạn trỏ tới, thường là 127.0.0.1 hoặc một địa chỉ LAN, và nó không quan tâm tunnel đã thay đổi. Nguồn cục bộ đi ra là thứ bộ chuyển tiếp yêu cầu nhân hệ điều hành dùng khi quay số bước tiếp theo, và nó gắn với thiết bị tunnel. Lối ra công cộng là thứ máy chủ web ghi lại, và có thể là một địa chỉ đã được dịch cách đó vài bước.

Tra cứu IP công cộng chỉ trả lời câu hỏi cuối cùng. Nó không thể cho bạn biết bộ chuyển tiếp nên gắn vào địa chỉ cục bộ nào, vì một lối ra công cộng có thể che nhiều nguồn nội bộ. Hãy đọc địa chỉ từ bên sở hữu kết nối: đầu ra trạng thái của ứng dụng, chính giao diện, hoặc không gian tên nơi tunnel sống. Việc chộp lấy giao diện đầu tiên có tên giống tunnel sẽ cho câu trả lời sai ngay khi tồn tại hồ sơ thứ hai.

Cách bố trí container và không gian tên phá vỡ giả định này một cách lặng lẽ. Một bộ chuyển tiếp trong một không gian tên mạng không thể gắn vào tunnel tồn tại trong không gian tên khác, và không lượng chỉnh sửa cấu hình nào sửa được điều đó.

Bốn bước kiểm tra trước khi sửa bất cứ thứ gì

Làm theo thứ tự. Bước kiểm tra thất bại đầu tiên là nơi bạn dừng lại, vì các bước sau giả định các bước trước đúng.

1. Xác nhận tunnel đang dùng là hồ sơ mà proxy được xây quanh, không phải hồ sơ thứ hai tự kết nối.
2. In địa chỉ hiện có trên thiết bị đó và so sánh với địa chỉ trong cấu hình đang chạy.
3. Hỏi bộ chuyển tiếp xem nó đã phân giải nguồn nào, thay vì điều tệp trên đĩa tuyên bố.
4. Xác nhận lưu lượng từ bộ chuyển tiếp thực sự chịu chính sách định tuyến và tường lửa mà bạn mong đợi.

Địa chỉ thiết bị thì dễ: ip -4 addr show dev tun0 in địa chỉ hiện tại, và ip -4 route get 1.1.1.1 cho biết nhân sẽ chọn giao diện nào cho đích đó. Bộ chuyển tiếp gắn vào một địa chỉ chính xác sẽ thất bại ồn ào khi địa chỉ biến mất. Bộ chuyển tiếp gắn vào thiết bị, hoặc quay về nguồn mặc định, vẫn tiếp tục hoạt động và rò rỉ, và đó là kết quả lặng lẽ.

Khớp tài liệu với bản phát hành bạn chạy, không phải kết quả tìm kiếm đầu tiên. Chỉ thị địa chỉ đi ra của Squid được ghi tài liệu cho v7 và trước đó, và tài liệu v8 nói rõ rằng chỉ thị không có ở đó, nên một script xây quanh nó không vượt qua ranh giới đó (xem tài liệu tham chiếu Squid tcp_outgoing_address). Hãy xác thực bằng chính bộ phân tích của sản phẩm trước khi tải lại bất cứ thứ gì: squid -k parse báo lỗi và thoát mà không chạm vào tiến trình đang chạy.

Đánh số từng tunnel và vứt bỏ các lần hoán đổi cũ

Kết nối lại là một lần bàn giao, và bàn giao cần thứ tự. Gắn thẻ cho mọi kết nối quan sát được bằng bộ đếm hoặc dấu thời gian tăng mỗi lần thiết lập thành công, rồi mang thẻ đó vào trong cấu hình ứng viên. Khi thẻ trên ứng viên cũ hơn thẻ hiện tại, hãy vứt ứng viên thay vì áp dụng nó, vì một bản cập nhật chậm viết cho tunnel trước sẽ ghi đè cài đặt của tunnel hiện tại. Gộp các đợt sự kiện để một liên kết chập chờn tạo ra một lần chuyển thay vì mười lăm.

Sắp xếp công việc thành bốn bước: vô hiệu hóa trạng thái ra cũ, chờ chủ sở hữu kết nối báo hoàn tất, chỉ dựng đoạn được quản lý, rồi xác thực và kích hoạt qua trình quản lý dịch vụ. Tạo lại toàn bộ tệp từ hai giá trị địa chỉ chính là cách các hạn chế của bộ lắng nghe, xác thực và chính sách đích biến mất lặng lẽ. Hãy tôn trọng cả việc dừng có chủ ý. Một trợ giúp vẫn quay số tới tunnel mà người dùng đã tắt là lỗi, không phải khả năng chịu lỗi.

Các socket đang mở sẽ không theo địa chỉ mới

Cấu hình lại bộ chuyển tiếp không nói gì về các kết nối đã thiết lập. Chúng có rút cạn hay chết tùy sản phẩm, nên hãy quan sát hành vi thay vì giả định.

Một yêu cầu được phục vụ qua socket mở trước lần hoán đổi vẫn đi ra theo đường cũ, ngay cả khi cấu hình mới đúng. Nếu điều đó quan trọng, hãy quyết định rõ ràng: cho một cửa sổ rút cạn ngắn và ngừng nhận việc mới, hoặc đóng các socket cũ và chấp nhận lỗi. Sau đó thử với kết nối mới và giữ kết quả đó tách khỏi bước kiểm tra rút cạn. Gắn vào nguồn cũng không phải ranh giới bảo mật. Khi lưu lượng không bao giờ được chạm vào tuyến thông thường, hãy cưỡng chế bằng dấu và quy tắc tường lửa, kể cả DNS và IPv6, để một lần tải lại thất bại để proxy ở trạng thái tắt rõ ràng thay vì mở.

Chứng minh lối ra mới bằng một yêu cầu mới

Điều quan trọng là yêu cầu được mở sau khi kích hoạt, không phải ping và không phải trang đã nằm trong bộ nhớ đệm. Yêu cầu proxy lấy một URL thật và đọc địa chỉ ra mà đầu xa báo cáo, rồi so sánh với góc nhìn của chính ứng dụng về tunnel khi nhà cung cấp hiển thị một địa chỉ.

Giữ phân tích, tải lại và yêu cầu thành các lệnh riêng để một lỗi chỉ ra một bước. Hai bước đầu không thay đổi gì khi thất bại, và đó chính là lý do chúng chạy trước khi khởi động lại.

squid -k parse
sudo squid -k reconfigure
curl -x http://127.0.0.1:3128 -sS -o /dev/null -w '%{http_code} %{remote_ip}\n' https://example.com

Nếu tải lại thất bại, hãy dừng dịch vụ và sửa đoạn đó; một proxy phục vụ với lối ra cũ tệ hơn một lần gián đoạn ngắn. Nếu tải lại thành công nhưng yêu cầu mới vẫn đi ra ở đâu đó bất ngờ, hãy quay lại bước kiểm tra định tuyến thay vì sửa địa chỉ lần nữa. Ghi lại thế hệ tunnel mà bạn đã xác thực, để lần kết nối lại tiếp theo có thứ cụ thể để so sánh.