Brana z innej podsieci - dlaczego działa ?

[Marek]

Dzisiaj spotkałem ciekawy przypadek na Win XP:
http://imageshack.us/photo/my-images/84/35595817.jpg/
gateway jest z innej podsieci ale wyjście na świat działa - dlaczego ?

Pozdrawiam
Marek

[Robson]

W dniu 2011-11-12 15:51, Marek pisze:

Dlatego, że podsieć, w której jest komputer jest podsiecią zawierającą
się w sieci w której jest brama.
Gdyby bramą był 192.168.1.81 albo 10.0.0.1 to by nie zadziałało.

R

[Olo]

no właśnie, chciałem napisać że nie rozumiem pytania, bo wszystko się
zgadza :)

[Bartosz Kiziukiewicz]

On Sat, 12 Nov 2011 15:51:37 +0100, "Marek" <brak@email_no_spam>
wrote:

> Dzisiaj spotkałem ciekawy przypadek na Win XP:
> http://imageshack.us/photo/my-images/84/35595817.jpg/
> gateway jest z innej podsieci ale wyjście na świat działa - dlaczego ?

on-link ?

--
Pozdrawiam
Bartek

Moje poglądy prezentowane w Usenecie są całkowicie prywatne.

[Jacek Politowski]

In article <j9mje3$gu6$1...@news.onet.pl>

Robson <rob...@z.pl> wrote:
> W dniu 2011-11-12 15:51, Marek pisze:

>> Dzisiaj spotkałem ciekawy przypadek na Win XP:
>> http://imageshack.us/photo/my-images/84/35595817.jpg/
>> gateway jest z innej podsieci ale wyjście na świat działa - dlaczego ?

> Dlatego, że podsieć, w której jest komputer jest podsiecią zawierającą
> się w sieci w której jest brama.

???

http://jodies.de/ipcalc?host=192.168.1.67&mask1=28&mask2=


--
Jacek Politowski

[Jacek Politowski]

In article <4ebe87f8$0$2181$6578...@news.neostrada.pl>

Pokaż tablicę routingu na tej maszynie.


--
Jacek Politowski

[or...@pwr.wroc.pl]

Wygląda na to, że Windows w ramach swojej idiotoodporności nie sprawdza
czy brama jest dostępna w jego lanie i wysyła ARP, bo może ktoś coś źle
skonfigurował albo gdzieś stoi arp-proxy z tą bramą na innym
interfejsie?

Ktoś może potwierdzić, że to tak działa?

--
Pozdrawiam
orcus

[karol]

Dnia 15.11.2011 20:36, or...@pwr.wroc.pl pisze:

> Wygląda na to, że Windows w ramach swojej idiotoodporności nie sprawdza
> czy brama jest dostępna w jego lanie i wysyła ARP, bo może ktoś coś źle
> skonfigurował albo gdzieś stoi arp-proxy z tą bramą na innym
> interfejsie?
>
> Ktoś może potwierdzić, że to tak działa?
>

Ale jaja sprawdziłem faktycznie działa na XP, normalnie brak
słów.....Pozostałych postów wedle których to normalna sytuacja nie
komentuje. :)

Musi być tak jak mówisz debilno odporny Windows wysła zapytanie arp do
bramy nie sprawdzając czy jest ona z tej samej sieci.

ko

[Adam Przybyla]

... akurat pewne rzeczy wynikaja z samego tcp/ip:
[root@hacker ~]# show in eth0.15
Interface eth0.15 is up, line protocol detection is disabled
index 31 metric 1 mtu 1500
flags: <UP,BROADCAST,RUNNING,MULTICAST>
HWaddr: 00:13:20:21:c3:a0
inet 62.182.231.180/26 broadcast 62.182.231.191
inet 62.182.231.180/29
inet6 fe80::213:20ff:fe21:c3a0/64
[root@hacker ~]# arping -I eth0.15 62.182.224.126 -c2
ARPING 62.182.224.126 from 62.182.231.180 eth0.15
Unicast reply from 62.182.224.126 [00:1B:21:88:ED:4A] 1.102ms
[root@hacker ~]#
Brama nie musi byc w tej samej podsieci;-) Z powazaniem
Adam Przybyla

[Tomek]

Adam, skłonny jestem polemizować z Twoją wypowiedzią.

Z tego co pamiętam, urządzenie sieciowe próbujące komunikować się ze
zdalną siecią potrzebuje wskazania trasy - możesz zrobić to na dwa
sposoby: podając szczegółową trasę (statycznie bądź dynamicznie) i
bramę, lub podając bramę domyślną.

Podanie jako bramy do sieci adresu IP który jest nieosiągalny skutkuje
problem z osiągnięciem celu. Jeśli wyślesz arp z zapytaniem o adres IP
spoza sieci w której się znajdujesz - to nie otrzymasz odpowiedzi ( btw
router separuje domeny broadcastowe). Diametralnie inna sytuacja będzie
w przypadku gdy router ma włączony mechanizm proxy-arp. (Tak na
marginesie po co stosuje się vlany i routery, skoro można wszystko
trzymać w jednym vlanie ;) )

W tym przypadku z samego TCP/IP wynika tylko tyle, że potrzebujemy
asocjacji MAC<->IP (RFC826). Przypisanie adresów MAC-IP pozwala na
komunikację w sieci Ethernet w domenie rozgłoszeniowej. Wysyłając pakiet
do sieci zdalnych w ramce wysyłasz jako docelowy adres MAC Twojej bramy
(np. bramy domyślnej). Wniosek jest prosty brama domyślna POWNINNA
znajdować się w sieci lokalnej.

Co do przykładu podanego przez Ciebie - arping działa w drugiej warstwie
OSI - jeśli gateway ma włączony proxy-arp - odpowie na pytanie odsyłają
swój adres MAC.
Przykład ARP arping 212.77.100.101 na ubuntu bez bramy domyślnej
> 00:16:58.005385 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 212.77.100.101 (ff:ff:ff:ff:ff:ff) tell 192.168.0.13, length 28
> 00:16:59.005488 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 212.77.100.101 (ff:ff:ff:ff:ff:ff) tell 192.168.0.13, length 28

i cisza... :)

[or...@pwr.wroc.pl]

On 17.11.2011, Adam Przybyla <ad...@rybnik.pl> wrote:

> karol <nos...@nospam.pl> wrote:
>> Musi być tak jak mówisz debilno odporny Windows wysła zapytanie arp do
>> bramy nie sprawdzając czy jest ona z tej samej sieci.
> ... akurat pewne rzeczy wynikaja z samego tcp/ip:
> [root@hacker ~]# show in eth0.15
> Interface eth0.15 is up, line protocol detection is disabled
> index 31 metric 1 mtu 1500
> flags: <UP,BROADCAST,RUNNING,MULTICAST>
> HWaddr: 00:13:20:21:c3:a0
> inet 62.182.231.180/26 broadcast 62.182.231.191
> inet 62.182.231.180/29
> inet6 fe80::213:20ff:fe21:c3a0/64
> [root@hacker ~]# arping -I eth0.15 62.182.224.126 -c2
> ARPING 62.182.224.126 from 62.182.231.180 eth0.15
> Unicast reply from 62.182.224.126 [00:1B:21:88:ED:4A] 1.102ms
> [root@hacker ~]#
> Brama nie musi byc w tej samej podsieci;-) Z powazaniem

Za RFC826 - ARP:
>As a packet is sent down through the network layers, routing
>determines the protocol address of the next hop for the packet
>and on which piece of hardware it expects to find the station
>with the immediate target protocol address.

Czyli to routing powinien powiedzieć gdzie się spodziewać
danego adresu i tylko tam generujemy ARP Request.

--
Pozdrawiam
orcus

[Bartosz Kiziukiewicz]

On Thu, 17 Nov 2011 15:05:30 +0100, karol <nos...@nospam.pl> wrote:

> Ale jaja sprawdziłem faktycznie działa na XP, normalnie brak
> słów.....Pozostałych postów wedle których to normalna sytuacja nie
> komentuje. :)

Powyższe byłoby prawdą, gdyby nie fakt, że takiego linuksa też można
zmusić do takiej pracy ;-)

[Adam Przybyla]

nie ma wlaczonego. tez mnei to kiedys dziwilo ale jesli ipek jest na innym
interface w takim ruterze to odpowiada.
Z powazaniem
Adam Przybyla

[Tomasz Winiarski]

On 18.11.2011 08:39, Bartosz Kiziukiewicz wrote:
> On Thu, 17 Nov 2011 15:05:30 +0100, karol <nos...@nospam.pl> wrote:
>
>> Ale jaja sprawdziłem faktycznie działa na XP, normalnie brak
>> słów.....Pozostałych postów wedle których to normalna sytuacja nie
>> komentuje. :)
>
> Powyższe byłoby prawdą, gdyby nie fakt, że takiego linuksa też można
> zmusić do takiej pracy ;-)
>

Małe przykłady:
Windows XP:
C:\Documents and Settings\twin>route add 192.168.200.0 mask 255.255.255.0 212.77.100.101
The route addition failed: Either the interface index is wrong or the gateway does not lie
on the same network as the interface. Check the IP Address Table for the machine.

Linux:
be ~ # route add -net 192.168.200.0/24 gw 212.77.100.101
SIOCADDRT: No such process

be ~ # ip r a 192.168.200.0/24 via 212.77.100.101
RTNETLINK answers: No such process

Wygląda to tak, że z poziomu GUI w windows może sobie ustawić różne głupoty.


--
Tomasz Winiarski
Jabber: tomekwin at jabber.org
mail: inactive user

[Tomasz Winiarski]

To się może zdarzyć bo linux widząc broadcast odpowie jeśli posiada taki adres IP o który
jest zapytanie ARP na dowolnym z interfesjów. Można zablokować takie zachowanie - sysctl i
arp_filter.
Dla przykładu przełącznik(mls) Cisco nie dał się w ten sposób podejść i nie odpowiedział
ARPem na pytanie o adres IP z innego vlanu.

[Tomasz Winiarski]

sorki miało być : arp_ignore

Z dokumentacji ip-sysctl
> arp_ignore - INTEGER
> Define different modes for sending replies in response to
> received ARP requests that resolve local target IP addresses:
> 0 - (default): reply for any local target IP address, configured
> on any interface
> 1 - reply only if the target IP address is local address
> configured on the incoming interface
> 2 - reply only if the target IP address is local address
> configured on the incoming interface and both with the
> sender's IP address are part from same subnet on this interface
> 3 - do not reply for local addresses configured with scope host,
> only resolutions for global and link addresses are replied
> 4-7 - reserved
> 8 - do not reply for all local addresses

[Bartosz Kiziukiewicz]

On Fri, 18 Nov 2011 10:20:03 +0100, Tomasz Winiarski
<to...@from.elblag.pl> wrote:

> be ~ # route add -net 192.168.200.0/24 gw 212.77.100.101
> SIOCADDRT: No such process
>
> be ~ # ip r a 192.168.200.0/24 via 212.77.100.101
> RTNETLINK answers: No such process

debian:/home/kiziuk# ip route
192.168.116.0/24 dev eth0 proto kernel scope link src
192.168.116.137
default via 192.168.116.2 dev eth0

debian:/home/kiziuk# ip route add 10.0.0.0/24 via 192.168.1.1 dev eth0

RTNETLINK answers: No such process

debian:/home/kiziuk# ip route add 10.0.0.0/24 via 192.168.1.1 dev eth0
onlink

debian:/home/kiziuk# ip route
192.168.116.0/24 dev eth0 proto kernel scope link src
192.168.116.137
10.0.0.0/24 via 192.168.1.1 dev eth0 onlink
default via 192.168.116.2 dev eth0

[Tomasz Winiarski]

ok, ale opcja onlink wymusza przyjęcie takiej bramy mimo, że jest ona nie osiągalna taki
wpis stosuje się np. w przypadku tuneli

[Bartosz Kiziukiewicz]

On Fri, 18 Nov 2011 16:43:30 +0100, Tomasz Winiarski
<to...@from.elblag.pl> wrote:

> > debian:/home/kiziuk# ip route
> > 192.168.116.0/24 dev eth0 proto kernel scope link src
> > 192.168.116.137
> > 10.0.0.0/24 via 192.168.1.1 dev eth0 onlink
> > default via 192.168.116.2 dev eth0
> >
> ok, ale opcja onlink wymusza przyjęcie takiej bramy mimo, że jest ona nie osiągalna taki
> wpis stosuje się np. w przypadku tuneli

Informuje też maszynę, że brama jest zlokalizowana w tym samym
segmencie L2 -> w związku z czym jest fizycznie osiągalna w L2.
Maszyna wysyła więc ARP Query i lokalizuje adres fizyczny routera.
Jeśli tylko router będzie chętny przyjąć ten ruch (ARP i całą resztę
IP) , uzyskamy dokładnie to, czemu dziwił się wątkodawca.
Taką konfigurację też się czasami stosuje, ale akurat częściej pod
Windowsem, który robi sobie "onlink" domyślnie.

[Tomek]

On 2011-11-18 19:25, Bartosz Kiziukiewicz wrote:
> On Fri, 18 Nov 2011 16:43:30 +0100, Tomasz Winiarski
> <to...@from.elblag.pl> wrote:
>
>>> debian:/home/kiziuk# ip route
>>> 192.168.116.0/24 dev eth0 proto kernel scope link src
>>> 192.168.116.137
>>> 10.0.0.0/24 via 192.168.1.1 dev eth0 onlink
>>> default via 192.168.116.2 dev eth0
>>>
>> ok, ale opcja onlink wymusza przyjęcie takiej bramy mimo, że jest ona nie osiągalna taki
>> wpis stosuje się np. w przypadku tuneli

> Taką konfigurację też się czasami stosuje, ale akurat częściej pod
> Windowsem, który robi sobie "onlink" domyślnie.
>

Jak sam zauważyłeś - linuxa trzeba zmusić do takiego zachowania. Co
ciekawsze w windows z linii poleceń też w prosty sposób nie pozwoli na
dodanie bramy spoza sieci. W prosty sposób daj się to zrobić za pomocą gui.

[Jacek Politowski]

In article <ja57mp$5jo$1...@polsl.pl>

Adam Przybyla <ad...@rybnik.pl> wrote:

> nie ma wlaczonego. tez mnei to kiedys dziwilo ale jesli ipek jest na innym
> interface w takim ruterze to odpowiada.

Generalnie mówisz o tym co wynika z weak/strong host model i który
model realizuje dany system?

--
Jacek Politowski

[Bartosz Kiziukiewicz]

On Fri, 18 Nov 2011 20:47:51 +0100, Tomek <to...@from.elblag.pl>
wrote:

> >> ok, ale opcja onlink wymusza przyjęcie takiej bramy mimo, że jest ona nie osiągalna taki
> >> wpis stosuje się np. w przypadku tuneli
>
> > Taką konfigurację też się czasami stosuje, ale akurat częściej pod
> > Windowsem, który robi sobie "onlink" domyślnie.
> >
>
> Jak sam zauważyłeś - linuxa trzeba zmusić do takiego zachowania. Co
> ciekawsze w windows z linii poleceń też w prosty sposób nie pozwoli na
> dodanie bramy spoza sieci. W prosty sposób daj się to zrobić za pomocą gui.

?

C:\Windows\system32>netsh interface ip set address "Połączenie
lokalne" static 192.168.10.10 255.255.255.0 192.168.1.1 1


C:\Windows\system32>netsh interface ip show config

[...]

Konfiguracja interfejsu Połączenie lokalne
DHCP włączone: Nie
Adres IP: 192.168.10.10
Prefiks podsieci: 192.168.10.0/24 (maska
255.255.255.
0)
Brama domyślna: 192.168.1.1
Metryka bramy: 1
Metryka interfejsu: 10
Statycznie skonfigurowane serwery DNS: 172.31.30.254
Rejestrowanie za pomocą którego sufiksu: Tylko
podstawowy
Statycznie skonfigurowane serwery WINS: Brak

[...]

C:\Windows\system32>