Am întrebat acest lucru în inginerie de rețea în schimbul de stive și a fost redirecționat aici.
Am câteva servere cu configurația de mai jos
server1:
eno1: 127.15.0.1/16 scope global
eno2: 5.0.0.1/24
server2:
lo: 127.0.0.1/16 (avea /8. Am schimbat masca de subrețea folosind „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 al serverului1 este conectat la o rețea L2 complet diferită și este complet izolat.
Interfețele eno2 ale ambelor servere sunt conectate la aceeași rețea L2. Acum trebuie să accesez 127.15.0.1 de pe server2.
Server1 a fost implementat cu mult timp în urmă și nu am permisiunea de a schimba niciun fel de configurație. Nu știu de ce cineva a folosit subrețeaua 127.x.x.x cu scop global. Nu sunt sigur dacă este o configurație validă, dar trebuie să trăiesc cu ea. Am control complet pe server2 și pot schimba orice.
Ambele servere sunt bazate pe Linux.
conectivitatea între 5.0.0.1 <-> 5.0.0.2 este bună.
Prima mea încercare a fost să adaug o rută în server2 ca mai jos
ip r adăugați 127.15.0.1/32 prin 5.0.0.1
ping 127.15.0.1 de la server2. Văd cererile și răspunsurile ping în tcpdump pe server2, dar comanda ping arată o pierdere de 100%.
Am dezactivat 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
repornit după actualizarea sysctl.conf
Și am spălat iptable-urile. (iptables -F)
Același rezultat. Am crezut că server2 nu-i place să folosească seria 127.x.x.x. Așa că am adăugat regula de mai jos pe serverul 2
iptables -t nat -A OUTPUT -d 5.0.0.1 -j DNAT --to-destination 127.15.0.1
această regulă ar trebui să înlocuiască ip destinație la 127.15.0.1 dacă pachetul este destinat la 5.0.0.1.
ping 5.0.0.1 de la server2. Iptables a înlocuit adresa IP de destinație cu 127.15.0.1 (a confirmat acest lucru pe server1 tcpdump). Server1 a răspuns, dar răspunsurile sunt eliminate din nou.
Am rămas fără idei în acest moment. Am dat jos server1 pentru întreținere și am înlocuit 127.15.0.1/26 cu 192.168.1.1/16. Conectivitatea a funcționat bine în acest caz (cu și fără iptables). Acum întrebarea este, problema este din cauza utilizării 127.x.x.x? Daca da, exista o cale de iesire?? Dacă nu, ce altceva pot încerca?
Notă: această configurație funcționa înainte. Am pierdut recent serverul 2 (care avea Linux vechi) și îl construiesc de la zero. De asemenea, Windows nu permite utilizarea 127.x.x.x pentru alte interfețe decât loopback. Nu sunt sigur de ce Linux îl permite pe interfețe non-lo. poate exista o justificare!
Pentru a rezuma, am aceste întrebări:
- Windows respinge complet configurația atunci când încercăm să configurăm 127.x.x.x, dar Linux o permite și asta cu un scop global. Există un caz de utilizare pentru asta?
- În acest caz, serverul 2 trimite cereri destinate 127.x.x.x, iar serverul 1 trimite de fapt răspunsuri înapoi. Dacă 127.x.x.x este doar gazdă-internă, de ce trimit chiar pachete pe link??
