Linux за българи: Форуми

Зравейте,
Имам OpenBSD рутер, и доставчик резнал ттл-а и портовете на нат-а, и немога да си пусна нет към локалната мрежа. Опитах да си реша проблема с pf-а но не стана:
# pf.conf
scrub out on $ext_if all min-ttl 10
nat on $extif from <localnet> -> $extif \
       port 1025:10000

 Някой има ли идея ?

Не трябва ли да е scrub in? Все пак искаш да "оправиш" TTL стойността на входящите пакети?

За TTL-a - напсувай няколко пъти доставчиците си и сложи в /etc/sysctl.conf:
net.inet.ip.stealth=1

За /etc/pf.conf -достатъчно е:
ext_if="външния интерфейс"
int_if="вътрешния интерфейс"
internal_net="10.1.1.0/24"  -примерно
nat on $ext_if from $internal_net to any -> ($ext_if)

За /etc/rc.conf :
sendmail_enable="NONE"
router_enable="YES"
router="/sbin/routed"
gateway_enable="YES"

Пробвай и пиши какво става.

GoodT, за пореден път мислиш, че всичко що е BSD е 1 към 1 с FreeBSD.

1. OpenBSD няма опция на ядрото IP_STEALTH, там се прави именно със scrub правило в PF. А доколкото знам в FreeBSD не е (или поне не беше в предишни версии) компилирано с тази опция по подразбиране.

2. В OpenBSD е прието настройките да се слагат в /etc/rc.conf.local за да няма проблеми при обновяване.

3. sendmail_enable няма в OpenBSD. Има sendmail_flags, което се настройва на NO ако искаш да не се стартира, но така или иначе не виждам какво общо има sendmail с маршрутизацията.

4. В OpenBSD няма router_enable и router. Пак има routed_flags, като за sendmail горе.

5. Ако ситуацията е както предполагам - домашна мрежа с един доставчик на интернет - не виждам каква файда има от routed.

6. gateway_enable също няма. Това се прави с дефинирането на net.inet.ip.forwarding=1 в /etc/sysctl.conf.

Не се заяждам, просто наистина поста ти е неадекватен, имайки предвид, че става дума за OpenBSD.

Поздрави.

Аха, с това съм съгласна -> scrub out on $ext_if all min-ttl 10
Обаче сигурно е че пробвах и резултата е = 0

GoodT таккова животно нема в sysctl.conf при мене каквото пишеш...

Четох тук решение за линукс:
echo "1025 10000" > /proc/sys/net/ipv4/ip_local_port_range

..но явно не намирам правилният начин за OBSD

Портовете за ната при Openbsd се задават от sysctl точно и по default sa:
net.inet.ip.portfirst = 1024
net.inet.ip.portlast = 49151
net.inet.ip.porthifirst = 49152
net.inet.ip.porthilast = 65535

..смених стойностите на такива:
sysctl -w net.inet.ip.portfirst=1024
sysctl -w net.inet.ip.portlast=10000
sysctl -w net.inet.ip.porthifirst=10001
sysctl -w net.inet.ip.porthilast=30000
sysctl -w net.inet.ip.ttl=128

трябва ли да прекомпилирам кернела или това ще да е свършило работа и проблема ми е нейде другаде?

Hapkoc, благодаря ти за уместната забележка. Горното го написах в бързината. Твърдо съм против такива ограничения.
С OpenBSD не съм работил (трябва да го тествам, някой голям ден, това животно )
Между другото намерих това, това и това.
Ще се радвам (и не само аз), след като се реши проблема да се напише решението.
Успех!

GoodT, абсолютно съм съгласен с теб за ограниченията.

myrla:

Цитат

Аха, с това съм съгласна -> scrub out on $ext_if all min-ttl 10 Обаче сигурно е че пробвах и резултата е = 0

Нещо не стоплих съвсем - пробва ли:

scrub in on $ext_if all min-ttl 10

понеже в последния пост пак пишеш 'scrub out'? Печатна грешка ли е или пробва с in и пак не става?

Абсолютно пробвах да ( печатна грешка беше )
#pfctl -s rules
scrub in on pppoe0 all min-ttl 10 fragment reassemble

#pfctl -s nat
nat on pppoe0 inet all -> pppoe0 port 1025:10000

#ping <GW>
PING <GW>: 56 data bytes
64 bytes from <GW>: icmp_seq=0 ttl=64 time=1.280 ms
64 bytes from <GW>: icmp_seq=1 ttl=64 time=0.532 ms

Ами аз от изхода на ping командата ми се струва, че TTL-а, който пристига при теб, съвсем не е орязан. Сигурно ли е, че в TTL е проблема? Какво казва:

sysctl net.inet.ip.forwarding

Тааам казва..
net.inet.ip.forwarding=1

 Виж Наркос, предполагам че не давам достатъчно информация за да ми се помогне та да го кажа така. Знам как се конфигурира OBSD и как се пуска нат и къде се пишат днс-ите. Протокола е пппое както стана ясно, използвам кернел пппое. Имах възможност да тествам с "не орязан" акаунт на същия този доставчик и с "орязан" такъв ( ако мога така да се изразя ). При еднакви други условия с първия няма грижа с втория няма нат
... Четох из нета, и ттл-то и резнатите високи портове ми се видяха най-вероятните причини, но ето стигнах до 9-та глуха и идеите ми свършиха
Или нещо неправилно правя или проблема ми е друг. От месец се опитвам да отгатна кво ли са направили тия дяволи..

Ясно. :)

Извинявай, ако съм те засегнал, но наистина от информацията, която даваш, не ставаше съвсем ясно какво се случва.

В такъв случай нямам идея какъв може да е зора, на мен поне ми изглеждат наред нещата. Можеш да пробваш да пуснеш ping от машина зад OpenBSD-то и на OpenBSD-то tcpdump - така можеш да установиш дали наистина проблема е в TTL-а, въпреки че същото би трябвало да може да се установи и с ping от OpenBSD машината... Знам ли.

Ако установиш къде е зора пиши, че ми е интересно и на мен. :)

Чувал съм че софийските доставчици въртят подобни мизерии, за да не може да нат-ваш на съседите. Покрай това съм чувал и че има начин за заобикаляне, ттл-то може да се увеличи с пачнат кернел на ФрийБСД, но нито съм го правил, нито съм го виждал. Предполагам че трябва да потърсите по надълбоко и понеже ми е интересно, ще помоля този който намери решение да го сподели тук  

Аха ..
Кофти е че нямам пингове и трасета, виждам само gw ..

thc,FreeBSD 6 си има пълна имплементация на pf, scrub min_ttl върши перфектна работа подобни доставчици ;-)

myrla, пробвай да послухтиш интерфейса какво точно идва и минава през него ... в подобни случаи tcpdump е почти незаменим инструмент :-) Тамън и ще видиш с какъв TTL изобщо идват пакетите към теб ;-)

# pf.conf
scrub in on pppoe0 all min-ttl 128
scrub out on pppoe0 all min-ttl 128

nat on pppoe0 from <localnet> -> pppoe0 \
           port 1025:32768


Туй е решението ))))))

В тоя случай за TTL-а явно доставчика е сложил филтър със твърдо указана стойност за TTL, а именно стойността по подразбиране за Windows.

Не мога да разбера докого ще се гаврят по тоя начин родните доставчици с клиентите си.

Ха, мерси
Да знаем и ние как да лекуваме доставчици тип "Андрешко"

А така и така се разкри проблема, не мисля, че ще е грешно, дори напротив, да се сподели кой е доставчикЪ, и който знае други такива мизерници пак да каже. (А ако има тема някъде за интернет доставчици може и там?)