Điểm:-2

Sự cố kết nối với sê-ri 127.x.x.x

lá cờ gt

Đã hỏi điều này trong kỹ thuật mạng trong trao đổi ngăn xếp và đã được chuyển hướng đến đây.

Tôi có một vài máy chủ với cấu hình bên dưới

máy chủ 1:

eno1: 127.15.0.1/16 phạm vi toàn cầu
eno2: 5.0.0.1/24

máy chủ2:

lo: 127.0.0.1/16 (nó có /8. Tôi đã thay đổi mặt nạ mạng con bằng 'ip addr del 127.0.0.1/8 dev lo; ip addr add 127.0.0.1/16 dev lo')
eno2: 5.0.0.2/24

eno1 của server1 được kết nối với một mạng L2 hoàn toàn khác và hoàn toàn bị cô lập.

giao diện eno2 của cả hai máy chủ được kết nối với cùng một mạng L2. Bây giờ tôi phải truy cập 127.15.0.1 từ server2.

Server1 đã được triển khai từ lâu và tôi không có quyền thay đổi bất kỳ loại cấu hình nào. Tôi không biết tại sao một số người sử dụng mạng con 127.x.x.x với phạm vi toàn cầu. Không chắc đó có phải là một cấu hình hợp lệ hay không nhưng tôi phải sống với nó. Tôi có toàn quyền kiểm soát trên server2 và tôi có thể thay đổi mọi thứ.

Cả hai máy chủ đều dựa trên linux.

kết nối giữa 5.0.0.1 <-> 5.0.0.2 là tốt.

Lần thử đầu tiên của tôi là thêm một tuyến đường trong server2 như bên dưới

ip r thêm 127.15.0.1/32 qua 5.0.0.1 ping 127.15.0.1 từ máy chủ2. Tôi thấy các yêu cầu ping và trả lời trong tcpdump trên server2, nhưng lệnh ping bị mất 100%.

Tôi đã tắt rp_filters

sysctl.cnf:

net.ipv4.conf.all.rp_filter=0
net.ipv4.conf.default.rp_filter=0
net.ipv4.conf.lo.rp_filter=0
net.ipv4.conf.eno2.rp_filter=0

khởi động lại sau khi cập nhật sysctl.conf

Và tôi đã xóa iptables. (iptables -F)

Cùng một kết quả. Tôi nghĩ có thể server2 không thích sử dụng sê-ri 127.x.x.x. Vì vậy, tôi đã thêm quy tắc dưới đây vào máy chủ 2

iptables -t nat -A OUTPUT -d 5.0.0.1 -j DNAT --to-destination 127.15.0.1

quy tắc này được cho là thay thế ip đích thành 127.15.0.1 nếu gói được định sẵn là 5.0.0.1.

ping 5.0.0.1 từ máy chủ2. Iptables đã thay thế ip đích bằng 127.15.0.1 (đã xác nhận điều này trên server1 tcpdump). Server1 đã trả lời nhưng các câu trả lời lại bị hủy.

Tôi đã hết ý tưởng vào thời điểm này. Tôi đã gỡ server1 xuống để bảo trì và thay thế 127.15.0.1/26 bằng 192.168.1.1/16. Kết nối hoạt động tốt trong trường hợp này (có và không có iptables). Bây giờ câu hỏi đặt ra là vấn đề có phải do sử dụng 127.x.x.x không? Nếu có, có cách nào thoát khỏi nó không ?? Nếu không, tôi có thể thử cái gì khác?

Lưu ý: Cấu hình này đã hoạt động trước đây. Gần đây chúng tôi đã mất server2 (có Linux cũ) và tôi đang xây dựng nó từ đầu. Ngoài ra, các cửa sổ không cho phép sử dụng 127.x.x.x cho các giao diện khác ngoài vòng lặp. Không chắc tại sao Linux lại cho phép nó trên các giao diện không lo. có thể có một lý do!

Để tóm tắt tôi có những câu hỏi sau:

  1. Windows hoàn toàn từ chối cấu hình khi chúng tôi cố gắng định cấu hình 127.x.x.x nhưng Linux cho phép điều đó và điều đó cũng xảy ra với phạm vi toàn cầu. Có một trường hợp sử dụng cho việc này?
  2. Trong trường hợp này, server2 gửi các yêu cầu đến 127.x.x.x và server1 thực sự đang gửi trả lời lại. Nếu chỉ 127.x.x.x máy chủ nội bộ, tại sao họ thậm chí gửi các gói trên liên kết ??
Zac67 avatar
lá cờ ru
127.0.0.0/8 được dành riêng cho *host-internal* loopback và không được sử dụng trên mạng cục bộ, xem RFC 5735. Có nhiều dải địa chỉ chức năng khác theo RFC 1918.
RBK050 avatar
lá cờ gt
Cảm ơn bạn. Tôi không muốn tỏ ra thô lỗ nhưng tôi đã biết điều đó. Như đã đề cập trong câu hỏi, thời điểm tôi thay đổi mạng con thành mạng con riêng tư/công khai, nó hoạt động. Tôi đang làm việc để sửa cấu hình. Tôi đã tóm tắt các truy vấn của mình ở cuối câu hỏi. Sẽ rất thú vị nếu có (các) quan điểm của bạn về nó.
anx avatar
lá cờ fr
anx
Ngay cả khi bạn không có quyền truy cập vào máy chủ khác, sẽ là phù hợp nếu người chịu trách nhiệm bảo trì máy chủ đó a) tự giải thích b) chỉ cho bạn cấu hình có liên quan để bạn không phải thắc mắc *tại sao* điều này thậm chí trước đó đã hoạt động và c ) sửa chữa mớ hỗn độn này.
Ron Maupin avatar
lá cờ us
Các địa chỉ trong khối loopback `127.0.0.0/8` không thể xuất hiện trên bất kỳ mạng nào, ở bất kỳ đâu. Xem [câu trả lời này](https://networkengineering.stackexchange.com/a/40156/8499) để biết các RFC có liên quan. Phạm vi đó được chính IPv4 nhận ra và bất kỳ triển khai IPv4 nào cho phép lưu lượng truy cập đến một địa chỉ trong phạm vi đó để thoát khỏi máy chủ đều là một triển khai IPv4 thiếu sót. Lưu lượng truy cập đến các địa chỉ đó _required_ để lặp lại bên trong máy chủ nguồn.
Ron Maupin avatar
lá cờ us
_[RFC 1122, Yêu cầu đối với máy chủ Internet -- Lớp giao tiếp](https://tools.ietf.org/html/rfc1122#section-3.2.1.3)_: "_Địa chỉ loopback của máy chủ nội bộ. Các địa chỉ dạng này KHÔNG ĐƯỢC xuất hiện bên ngoài vật chủ."_
RBK050 avatar
lá cờ gt
Thư giãn đi các bạn. Tôi biết rõ về các RFC. Tôi chỉ muốn biết nếu linux hỗ trợ nó. Và có vẻ như nó làm. Xin vui lòng nhìn vào câu trả lời. Tôi không khuyến khích bất cứ ai sử dụng nó. Chỉ muốn biết nếu có một khả năng.
Điểm:0
lá cờ fr
anx

Các cờ sysctl của Linux tại

/sys/net/ipv4/conf/*/route_localnet

cho phép vô hiệu hóa xử lý hợp lý cho các gói như vậy.

route_localnet - BOOLESE

Không coi địa chỉ loopback là nguồn hoặc đích sao Hỏa trong khi định tuyến. Điều này cho phép sử dụng 127/8 cho mục đích định tuyến cục bộ. mặc định SAI

Vì rất ít người lành mạnh sẽ làm điều đó, nên điều này có thể hoạt động hoặc có thể không hoạt động trong những ngày này (tôi đã thử nghiệm nó lần cuối cách đây vài năm).

Vui lòng chỉ định bất kỳ dành riêng cho mục đích này (có thể là liên kết cục bộ, nhưng không phải nội bộ máy chủ) hoặc sở hữu không gian IP cho các giao diện được đề cập. Tiếp tục với thiết lập kỳ lạ này sẽ chỉ gây ra nhiều rắc rối hơn, đặc biệt là khi có những lựa chọn thay thế dễ dàng.

RBK050 avatar
lá cờ gt
Điều này đã làm việc. Mục proc này là lý do cho ma thuật đen. Sau khi cài đặt này, kết nối đã hoạt động. Tôi đã có thể thuyết phục nhóm của mình sử dụng IP riêng. Cảm ơn bạn

Đăng câu trả lời

Hầu hết mọi người không hiểu rằng việc đặt nhiều câu hỏi sẽ mở ra cơ hội học hỏi và cải thiện mối quan hệ giữa các cá nhân. Ví dụ, trong các nghiên cứu của Alison, mặc dù mọi người có thể nhớ chính xác có bao nhiêu câu hỏi đã được đặt ra trong các cuộc trò chuyện của họ, nhưng họ không trực giác nhận ra mối liên hệ giữa câu hỏi và sự yêu thích. Qua bốn nghiên cứu, trong đó những người tham gia tự tham gia vào các cuộc trò chuyện hoặc đọc bản ghi lại các cuộc trò chuyện của người khác, mọi người có xu hướng không nhận ra rằng việc đặt câu hỏi sẽ ảnh hưởng—hoặc đã ảnh hưởng—mức độ thân thiện giữa những người đối thoại.