W przypadku aliasingu IP, w jaki sposób system operacyjny określa, który adres IP będzie wykorzystywany jako źródło dla wychodzących połączeń TCP / IP?

Mam serwer z systemem Ubuntu Server z czterema adresami IP przypisanymi do jednej karty sieciowej.

eth0       192.168.1.100
eth0:0     192.168.1.101
eth0:1     192.168.1.102
eth0:2     192.168.1.103

(Używając 192.168.xx dla przykładu, załóżmy, że są one NAT -owane dla szeregu publicznych adresów IP)

Jeden z naszych klientów publikuje swoje zapasy za pośrednictwem FTP, więc logujemy się co noc, aby pobrać duży plik z ich serwera. Zapora ogniowa oczekuje, że nasze (pasywne) połączenie FTP zostanie nawiązane z 192.168.1.100.

Biorąc pod uwagę, że mój serwer ma logicznie cztery adresy IP na jednym adapterze, w jaki sposób system operacyjny określa, który adres IP jest używany jako źródło dla wychodzących połączeń TCP / IP?

Powiedzmy, że ssh na mój serwer 192.168.1.101 i uruchamiam FTP interaktywnie. Czy wychodzące połączenie TCP / IP będzie używać 192.168.1.101, ponieważ system operacyjny wie, że jest to interfejs, przez który jest połączona moja powłoka?

Co się stanie, jeśli zadanie FTP jest uruchamiane nieinteraktywnie za pośrednictwem zadania cron, w którym nie ma powłoki?

Jak zapewne możesz powiedzieć, to mnie bardzo zagubiło, więc mam nadzieję, że moje pytania przynajmniej miały sens.

Edytować

Aby wyjaśnić, dlaczego pytam - nie wprowadziłem żadnych zmian w tabeli routingu i faktycznie wyświetla ona „eth0” jako IFace dla tras 0.0.0.0. Jednak wszystko wskazuje na to, że faktycznie używa on eth0: 0 jako źródła.

Destination    Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.1.0    0.0.0.0         255.255.255.0   U     0      0        0 eth0
0.0.0.0        192.168.1.1     0.0.0.0         UG    100    0        0 eth0

Mogę majstrować przy tablicy routingu lub zlecić naszemu klientowi zmianę reguł zapory, aby uzyskać potrzebne zachowanie, ale staram się uzyskać trochę wglądu, jak to działa, aby wiedzieć, czy w systemie operacyjnym jest błąd, czy po prostu naiwne zrozumienie jak wszystkie elementy pasują do siebie.

Dzięki

Domyślnie w systemie Linux, jeśli interfejs ma wiele adresów znajdujących się w różnych podsieciach, ruch przeznaczony dla odpowiednich podsieci będzie miał właściwe źródłowe IP. Oznacza to, że jeśli eth0 ma dwa adresy 192.168.1.1/24 i 10.1.1.1/8, wówczas ruch do czegokolwiek w podsieci 10.0.0.0 będzie miał źródło 10.1.1.1, a ruch do czegokolwiek w podsieci 192.168.1.0 będzie miał źródło 192.168.1.1. W tym przypadku możesz również przypisać adresy źródłowe, używając opcji „src 1.2.3.4” do „trasy ip”.

Jednak w twoim przypadku wszystkie adresy znajdują się w tej samej podsieci, więc „podstawowy” (jak ujawnia „lista adresów IP urządzenia dev eth0”) jest używany jako źródłowy adres IP ruchu wychodzącego z tego interfejsu. Myślę, że w tym przypadku możliwe jest kontrolowanie źródłowych adresów IP za pomocą „trasy ip”, ale łatwiej mi było użyć iptables do przepisania adresów źródłowych dla interesującego ruchu.

Jeśli chcesz wymusić użycie określonego adresu źródłowego dla określonych miejsc docelowych, możesz to zrobić za pomocą reguły SNAT:

iptables -t nat -I POSTROUTING -o eth0 -d dest-IP-or-net/mask -s primary-IP-of-eth0 -j SNAT --to-source desired-source-IP

Jeśli więc „podstawowym” adresem IP eth0 jest 192.168.100.1, ale chcesz, aby ruch do 1.2.3.4 miał źródło 192.168.100.2, zrób to:

iptables -t nat -I POSTROUTING -o eth0 -d 1.2.3.4/0 -s 192.168.100.1 -j SNAT --to-source 192.168.100.2

Zauważ, że „-s 192.168.100.1” jest ważne: zapobiega przepisywaniu adresów źródłowych przesyłanego ruchu przez tę regułę.

Jeśli zamierzasz wdrożyć złożone konfiguracje sieciowe w systemie Linux, powinieneś przeczytać dokumentację dotyczącą zaawansowanego routingu i kontroli ruchu w systemie Linux, http://lartc.org

Widzę w twoim przykładzie, że wszystkie IP są zbyt blisko, aby nie być w tej samej sieci

czy jesteś pewien, że faktycznie korzystasz z wielu usług i nie masz po prostu 4 aliasów IP?

jeśli to drugie, to możesz ustawić źródłowy ip na trasie z czymś podobnym do tego

/ sbin / ip route show 192.168.222.0/24 dev eth0 proto kernel scope link src 192.168.222.178 169.254.0.0/16 dev eth0 scope link domyślnie przez 192.168.222.1 dev eth0

sudo / sbin / ip route replace default default 192.168.222.1 src 192.168.222.178

/ sbin / ip route show
192.168.222.0/24 dev eth0 proto kernel scope link src 192.168.222.178 169.254.0.0/16 dev eth0 scope link domyślnie przez 192.168.222.1 dev eth0 src 192.168.222.178

zobacz interfejsy man, jak sprawić, by było trwałe między restartami

Używa wszystkiego, co domyślna brama znajduje się w tabeli routingu, chyba że istnieje konkretna trasa, która nakazuje jej użycie innej: route -n

EDYCJA: Zbyt szybko przeczytałem twoje pytanie ...

Ponieważ używasz trybu pasywnego, a klient zawsze będzie inicjował połączenie, myślę, że pole src ip w nagłówku IP będzie zawsze wyświetlane jako dowolne IP, z którym klient się podłączył. Gdyby to był tryb aktywny, serwer inicjowałby połączenie, myślę, że zawsze byłby to „podstawowy” adres IP. Jeśli twoje adresy znajdują się w tej samej podsieci, Linux sprawi, że pierwszy adres, który dodałeś, będzie „Podstawowy”, a pozostałe dodatkowe.

Nie jestem jednak do końca pewien, uruchomiłbym tcpdump -n i zobaczyłby to, co widzi jako adres IP src.

EDIT2: OK, napisałem powyższe z punktu widzenia, że ​​działałeś na serwerze, więc ponieważ jesteś klientem i inicjujesz połączenie, myślę, że zawsze będzie pochodzić z podstawowego adresu IP, ale ponownie spróbuj i zobacz z tcpdump.

Chyba że twoje zadanie FTP ma sposób na określenie interfejsu używanego do połączeń, uważam, że domyślnie jest to pierwszy fizyczny interfejs w odpowiedniej podsieci (w tym przypadku eth0). Jeśli masz serwer z dwiema kartami sieciowymi w różnych podsieciach, na podstawie tabeli routingu dowiesz się, którego interfejsu użyć.

Ponieważ w systemie jest tylko jeden interfejs fizyczny (eth0) i cztery wirtualne / aliasy (od eth0: 0 do eth0: 2) w tej samej podsieci, ruch wychodzący użyje adresu IP eth0 jako źródła, chyba że aplikacja jest wystarczająco inteligentna zadeklarować interfejs wychodzący.

Możesz zobaczyć, które urządzenie i adres IP src będą używane przez polecenie ip route get, tak jak poniżej:

$ /sbin/ip route get 1.1.1.1
1.1.1.1 via 2.2.2.2 dev eth0  src 2.2.2.2 
    cache  mtu 1500 advmss 1460 hoplimit 64

Nie próbowałem tego w środowisku aliasu, ale mam nadzieję, że to pomoże.

Podczas ustanawiania połączenia wychodzącego serwer zajrzy do swojej tabeli routingu, aby określić, którego z czterech interfejsów użyć; połączenia TCP będą miały źródłowy adres IP interfejsu wyjściowego.

netstat -rn

Otrzymasz dane wyjściowe z tabeli routingu; poszukaj konkretnych wpisów pasujących do adresu IP klienta, z którym próbujesz się połączyć. Jeśli nie istnieje, użyjesz domyślnej trasy (0.0.0.0, maska ​​0.0.0.0). Jeśli masz wiele tras domyślnych, wybrana zostanie ta o najniższym koszcie.