VPN bật và localhost ngừng hoạt động: tên, proxy hay bind?

Máy chủ phát triển của bạn đã trả lời một phút trước, và giờ khi đường hầm đã lên yêu cầu hết thời gian chờ với một tên máy chủ bạn chưa từng gõ. Hai cơ chế giải thích gần như mọi trường hợp, và từ bên ngoài chúng trông giống nhau. Hậu tố tìm kiếm biến tên ngắn thành tên doanh nghiệp, trong khi proxy gửi lưu lượng loopback đến một máy chủ không thể tiếp cận nó. Tách hai thứ này tốn một truy vấn và tiết kiệm quy tắc tường lửa bạn sắp viết.

Khi localhost phân giải vào vùng doanh nghiệp

Kiểm tra tên phân giải thành gì khi đường hầm đang lên, sau đó chạy lại truy vấn đó khi đường hầm xuống và so sánh hai câu trả lời. Dấu hiệu là một địa chỉ trong dải doanh nghiệp ở nơi bạn mong đợi 127.0.0.1. Một bản ghi như localhost.mycompany.corp thắng mục loopback ngay khi máy khách thêm hậu tố đó vào danh sách tìm kiếm, và yêu cầu đi đến một máy chủ riêng không có gì lắng nghe trên cổng đó. Hãy đọc danh sách tìm kiếm thay vì đoán, vì máy khách có thể thêm nhiều hơn một tên miền và thứ tự quyết định ứng viên nào được thử trước:

getent hosts localhost
resolvectl domain
ss -ltnp | grep 8080

Thay tên máy chủ bằng địa chỉ nguyên văn trong ứng dụng, máy khách cơ sở dữ liệu hoặc URL sổ tay, rồi lặp lại yêu cầu. Nếu lỗi biến mất thì bạn gặp vấn đề đặt tên và đường hầm chỉ là tác nhân kích hoạt. Nếu vẫn còn, trình lắng nghe hoặc tuyến là nghi phạm tiếp theo và cái tên chỉ là dấu vết sai.

Cài đặt proxy bắt lấy loopback

Proxy hệ thống được áp dụng khi đường hầm lên sẽ nhận yêu cầu tới 127.0.0.1 và chuyển nó đến một proxy từ xa không biết bạn muốn nói gì. Danh sách loại trừ trống biến một yêu cầu cục bộ thành yêu cầu từ xa, và thông báo lỗi hiếm khi nói vậy. Thêm các địa chỉ loopback vào danh sách loại trừ cho cả phiên chứ không phải một lệnh, rồi xác nhận công cụ tôn trọng điều đó trước khi kết luận bất cứ điều gì về mạng.

Các khung ứng dụng đọc biến môi trường của riêng chúng và đôi khi cả tệp cấu hình của chúng, nên một ngoại lệ hoạt động cho một công cụ không chứng minh gì cho công cụ tiếp theo. Trình duyệt thêm một chi tiết: trình duyệt dựa trên Chromium bỏ qua proxy cho loopback một cách ngầm định, và một mã thông báo ngoại lệ có thể loại bỏ hành vi đó. Hãy kiểm tra quyết định proxy thực tế thay vì cho rằng cài đặt hệ điều hành là toàn bộ câu chuyện. Hai lệnh giải quyết điều này cho mọi thứ được khởi chạy từ shell:

curl --noproxy '*' http://127.0.0.1:8080/health
NO_PROXY=localhost,127.0.0.1,::1 your-tool

Địa chỉ bind quyết định ai có thể kết nối

Máy chủ khởi động trên 127.0.0.1 chỉ chấp nhận kết nối từ máy đó, thường là mặc định đúng cho phát triển. Máy chủ trên 0.0.0.0 trả lời trên mọi giao diện, kể cả bộ điều hợp VPN, đây là mức phơi bày lớn hơn hầu hết mọi người dự định. Khi địa chỉ loopback nguyên văn thất bại, hãy kiểm tra bind trước mọi thứ khác.

Nhìn vào socket đang lắng nghe và ghi lại địa chỉ mà nó được gắn vào, không chỉ cổng. Nếu thiết bị khác hoặc container phải tiếp cận dịch vụ qua đường hầm, hãy gắn vào giao diện cụ thể mà nó sẽ dùng và cho phép cổng đó một cách có chủ ý. Nếu chỉ máy của bạn cần, hãy giữ bind hẹp và sửa máy khách thay vì mở rộng máy chủ. Chuyển tiếp cổng hoặc một lớp đường hầm có thể nối cả hai, nhưng mỗi thứ thêm một thành phần sẽ cần tự gỡ lỗi sau này.

Nơi công cụ gỡ lỗi mong đợi LAN

Công cụ gỡ lỗi mang theo những giả định mà đường hầm phá vỡ âm thầm. Cầu gỡ lỗi điện thoại mất thiết bị khi VPN bắt mạng con của thiết bị, nên kết nối lại qua địa chỉ LAN hoặc cáp sẽ tránh xung đột. Trung tâm tự động hóa trình duyệt hết thời gian chờ khi trung tâm chỉ tiếp cận được qua proxy, hoặc khi tường lửa cục bộ bỏ cổng điều khiển của nó. Trình gỡ lỗi từ xa có thể yêu cầu nâng quyền và địa chỉ loopback ở nơi máy khách đã viết lại tuyến.

Xác định cổng điều khiển và cổng dữ liệu riêng biệt, vì thường một cái sống sót còn cái kia thì không. Sau đó quyết định xem bản sửa thuộc về cấu hình công cụ, một tuyến cho mạng con đó hay quy tắc đường hầm chia tách. Sửa tệp hosts trên từng máy lập trình viên mở rộng kém nhất và bị quên đầu tiên. Ưu tiên cài đặt sống cùng hồ sơ và có thể được xem lại bởi bất kỳ ai sở hữu đường hầm.

Dừng ở giai đoạn đầu tiên thất bại

Đi xuống ba giai đoạn: phân giải tên, mở socket tới địa chỉ nguyên văn, rồi để công cụ tự tạo kết nối của nó. Mỗi giai đoạn loại bỏ một lớp, nên lỗi đầu tiên gọi tên lớp cần sửa và mọi thứ sau đó vẫn chưa được kiểm tra. Ghi lại kết quả trước khi thay đổi bất cứ điều gì, vì một bản sửa áp dụng trước khi đo không thể phân biệt với may mắn. Nếu lần thử đầu thất bại và lần lặp lại hoạt động, đường hầm có lẽ chưa sẵn sàng khi công cụ khởi động.

Thay chờ cố định bằng kiểm tra sẵn sàng có giới hạn chờ tuyến, và giữ giai đoạn thất bại trong nhật ký để người tiếp theo thấy nó dừng ở đâu. Một công cụ tự phục hồi không phải đã được sửa, nó chỉ may mắn, và may mắn cạn trên máy của người khác. Thay đường hầm sau cùng, và chỉ cho giai đoạn thực sự thất bại. Thứ tự đó cũng là đường ngắn nhất trở lại một bản dựng hoạt động, vì nó ngăn bạn dựng lại một thành phần chưa từng tham gia.