Изпечатай

[never_mind]

Ситуацията е следната:
192.168.143.2 -> xl0 ( .1 ) |
                                        |-> rl0 -> gw
192.168.144.2-> xl1 ( .1 )  |
Нет ми дава евроком софия. Имам рутер с openbsd 4 , който дава нет на други два компа отзад, всеки свързан с по 1 интерфейс на рутера. От известно време насам обаче имам проблеми с нета ( пинг към гейт на ISP-то изчезва точно за 1 мин. ( 60 пакета )) и после се появява за различно време ( 15 сек, 1 мин и т.н. ) и пак изчезва за 60 сек. и така цял ден. Открих, че пинга изчезва, когато получа следният лог в messages

Примерен код

/bsd: arp: attempt to overwrite entry for 192.168.143.2 on xl0 by 00:30:48:8d:2f:b1 on rl0 /bsd: arp: attempt to overwrite entry for 192.168.144.2 on xl0 by 00:30:48:8d:2f:b1 on rl0

като 192.168.143.2 е едното вътрешно IP, което е към xl0 ( 192.168.143.1 ) интерфейса на рутера, MAC адреса е на gw на ISP-то, а rl0 ми е външния интерфейс, който гледа към гейта. С други думи пълна каша. Ако заредя лайф cd на рутера с кнопикс нет има и нямам подобни проблеми ( всъщност има, но мнооого по-рядко, пак от време на време имам загуба на пинг точно 60 сек, но е мнооого по-рядко, отколкото ако заредя bsd-то. Според ISP-то проблем няма с мрежата. Но аз имам. Също друго интересно нещо е

Примерен код

#arp -a unknown.ddns-lan.pl.ekk.bg (89.215.53.1) at 00:30:48:8d:2f:b1 on rl0 89-215-53-2.2072977634.ddns-lan.pl.ekk.bg (89.215.53.2) at 00:30:48:8d:2f:b1 on rl0 89-215-53-9.2072974383.ddns-lan.pl.ekk.bg (89.215.53.9) at 00:30:48:8d:2f:b1 on rl0

Забележете MAC -овете! Arp proxy на gw? Някакви идеи защо под бсд нета така се губи, докато под линукс не чак толкова и някой в мрежата флуди с грешни arp пакети и какво аджеба изобщо става.

[never_mind]

Какво забелязах днес. По време на този тайм аут ( загуба на пинг ) и вътрешната мрежа е омазана - нямам arp -a или route show, всичко зависва, ssh се губи, аве цялото рутиране е омазано. Обяснявам си го така - по някаква причина получавам пакет на rl0 , че 143.1 е с MAC -а на gw и всичко започва да се пренасочва към него и ест нет няма, нищо няма. Само не знам защо получавам такъв пакет, аз ли пращам arp заявка към гейта, той ли флуди постоянно, tcpdump не показва нищо ненормално...

[sdr]

ARP Poisoning?

[never_mind]

Възможен вариант, но не го вярвам. След рестарт би трябвало да се оправи, нали? Но не. И как да се предпазя от подобни опити? Дори и при зададен permanent static MAC адрес на вътрешните компютри пак се получава проблема. Според мен външния ми интерфейс по някаква причина изисква who is 143.1 от външната мрежа ( gw ) и той връща своя MAC ( поради arp proxy на него, това е сигурно! ) и става мазаландията. Въпросът е как да опиша рутинг таблицата на bsd-то да не праща навън who is, ако това е проблема де?

[savago]

-s hostname ether_addr [temp | permanent] [pub]
             Create an ARP entry for the host called hostname with the Ether-
             net address ether_addr.  The Ethernet address is given as six
             hexadecimal bytes separated by colons.
             The permanent, pub, or temp modifiers may be specified with mean-
             ings as given above.

DIAGNOSTICS msg:
http://www.openbsd.org/cgi-bin....at=html

[gat3way]

Съвсем идиотско предположение, имайки предвид опита си с линукс (с БСД имам доооста по-малко опит и нямам подръка БСД система да проверя). Значи в линукс по дефолт и route и arp  правят DNS lookups на IP адресите, които изкарват в арп/рутинг таблиците. Нямаш ли работещ resolver, изходът и от двете отнема адски много време (чакаш дъълги таймаути от резолвъра).

openssh и при линукс и при БСД е почти еквивалентно нещо предполагам. Демонът  се опитва да прави reverse (PTR) резолвинг на адреса на клиента, който иска да се върже, при линукс ако нямаш работещ резолвър, sshd таймаут-ва за няколко секунди, демонът се отказва да резолв-ва и преминава към автентикацията.  Под OBSD може и да не е така обаче, така че аз бих се замислил малко. И arp и route би трябвало да имат опции подобно на "-n" в линукс, да не се хабят да правят резолвинг. Пробвал ли си когато стане проблемът да пробваш с тях?

Сигурен ли си, че това специално не е проблем, идващ от "счупена" комуникация с твоят DNS сървър?

Просто предположение де..