Dotaz: Vice siti a SSH ListenAddress

[MMichal]

Zdravim,

resim nasledujici problem. Mejme server s eth0: 192.168.1.1/24 a eth1: 192.168.2.1/24. SSH je nakonfigurovano tak, ze posloucha pouze na 192.168.2.1 (pomoci ListenAddress). Dale mejme stanici, ktera ma eth0: 192.168.1.2/24, pricemz eth0 stanice je propojenos eth0 serveru.

Ze stanice nelze pouzit ssh 192.168.2.1, protoze site nejsou proroutovane a zaroven nelze pouzit ssh 192.168.1.1, protoze na te adrese SSH neposloucha.

Lze vsak udelat na stanici: ip route add 192.168.2.1 via 192.168.1.1 a pote ze stanice zadat ssh 192.168.2.1 - a toto funguje, pricemz na serveru je prichozi spojeni na rozhrani eth0, avsak s cilovou adresou z rozhrani eth1 (192.168.2.1). Ale ja tomu chci zabranit.

A ted dotaz: Lze nejakym zpusobem (napr. pres sysctl resp. /proc/sys/net/...) zakazat prijem paketu, kdy cilova adresa odpovida jinemu rozhrani (resp. neodpovida danemu rozhrani po kterem prichazi a je dokonce i v jine siti) ?

Vim ze to lze pres netfilter/iptables, ale radeji bych jinou variantu, pokud existuje.

Predem diky za kazdou radu.

michal

Odpovědi

[Ondřej Kopka]

Střelím od pasu ale co říká tohle?:

cat /proc/sys/net/ipv4/ip_forward

Pokud je tam 1, pak je třeba vypnout ipv4 forwarding.

[Michal Kubeček]

Ne, to rozhodně ne. Příjem paketu, který má "naši" cílovou adresu, i když nastavenou na jiném rozhraní, nemá s IP forwardingem nic společného.

[Michal Kubeček]

Takový požadavek je nesmyslný. IP adresa adresuje váš počítač, takže paket s vaší cílovou adresou je určen pro váš počítač a je úplně jedno, jestli přijde na "správné" rozhraní nebo na kterékoli jiné. Pokud chcete zakázat přístup ke službě ze "špatné strany", použijte k tomu nástroj, který je k tomu určený, tedy netfilter. Možnost nastavit lokální adresu naslouchajícího soketu k tomu určená není.

Celé to patrně pochází z nešťastného historického zlozvyku pocházejícího z dob, kdy platila bijekce mezi rozhraními a adresami. Tehdy autoři řady démonů mátli uživatele tím, že volbu adres, na kterých démon poslouchá, v dokumentaci a konfiguračních souborech prezentovali jako volbu rozhraní, na kterých démon poslouchá. Ale tak to nefunguje a nikdy ani nefungovalo. Ten démon nemá možnost rozlišovat, na které rozhraní paket přišel, a vlastně mu do toho ani nic není.

[xkucf03]

Nečekal jsem, že by to fungovalo, ale proč vlastně: co když odeberu na lo rozhraní adresu 127.0.0.1 a nasměruji ji přes jiný počítač?

ip addr del 127.0.0.1/8 dev lo
ip route add 127.0.0.1 via 192.168.1.1

Server na HTTP portu naslouchá, ale připojit se nejde (a neprojde ani ping na localhost):

telnet 127.0.0.1 http
Trying 127.0.0.1...
telnet: Unable to connect to remote host: Connection timed out

Jen tak pro zajímavost – kde je v Linuxu zadrátovaná ta výjimka, že se lokální adresy chovají jinak než normální – aneb proč to s 192.168.2.1 jde, ale se 127.0.0.1 ne?

[Michal Kubeček]

Tak to je opravdu zvláštní, tcpdump na cílovém stroji ten paket ještě vidí, ale pak jako by se někam ztratil. Určitě se to tak ale nechovalo vždy. Až budu mít trochu času, zkusím prozkoumat, proč se to děje.

[rADOn]

Neni to nahodou tim ze jsi smazal routu ale ne rozhrani, takze odchozi paket ma 127.1 jako zdrojou IP? Pak by brana odpovedela sama sobe.

[xkucf03]

Když dám ping -I eth0 127.0.0.1, tak to pingá z mojí IP (ne ze 127.0.0.1), takže tím to asi nebude.

A v rámci jednoho stroje a standardního nastavení – tohle funguje:

ping -I lo 127.0.0.1

tohle nefunguje:

ping -I eth0 127.0.0.1

a tohle zase funguje:

ping -I lo 192.168.1.2

Takže to lo/eth0 je jakoby „propustné“ jen v jednom směru.