Супер Любо - ADSL

Здравейте, имам проблеми с така нареченият Любо. Ако някой го срещне някъде моля препратете го при нас. :)
Вече 3-та седмица звъня на прословутият теелфон 070017111 с молба за помощ. Е вярно, не само БТК са виновни за случката но случвало ли ви се е "Царя да дава а пъдаря не"... Те такъв е нащият случай.
Преди близо 3 седмици имахме хардуерни проблеми в офиса и се налоги набързо да спретнем нещо за да имаме интернет. В бързината сме забравили един squid "отворен" и естественно са ни набутали в "black lists". Та поразшетахме се за да изчистим IP-то от тях. Но за една листа ([линк]) се оказа че не става без Revers DNS запис. Хората добре са го намислили - не можеш да изкараш от черната листа сървър ако нямаш Revers DNS запис защото рекуеста за изваждането от черната листа се изпраща до реверс записа на сървъра ([email protected], [email protected] - стандартни маил служебни акаунти ) , а идеята е че в противен случай всеки спамър може да си изкара вкаран в черната листа сървър и да продължи да си ползва сървъра... Да но какво се оказва в нашият случай - за БТК липсват всякакви DNS записи за IP-тата раздавани по ADSL-лите, все пак можеха да си организират някакъв DNS за "динамично" раздавание IP-та за да не се налага клиентите които ползват бизнес акаунти да звънят всеки ден и да молят за решение в което маил сървъра им да работи... Да не говорим че на всяко обаждане започваме с цялата история отново и отново, с което след 20 мин. се стига до момента че не предлагат Reverse DNS като услуга...

Проблем номер 2 - какво става ако ъплоад канала ти е 512Кбита, имаш маил сървър на firewall-a и шефа ти реши да изпрати 5МБ маил до 20 човека... Ами просто оставаш без IP и проблема се решава... Абсурдно е но е така, БТК си имат DHCP сървър а LEASEDTIME за IP-то е 30 сек. което предполага че ако ъплоад канала ти е пълен за по дълъг период от 2-3 минути оставаш без IP. Проблема със шефа наистина го имах във един прекрасен неделен ден, все пак човека от къде да знае че не няма право да изпраща писма. А на тъпият системен администратор ( моя милост ) му отне 2-3 часа за да разбере какво става на прага на собственната му кочина ...

Е, помислете си ако все още искате ADSL от БТК за служебни нужди - архитектура на network-a и какви ресурси ще са ви необходими ... Нямам нищо против БТК но като голяма компания нека помислят и за клиентите си. А аз продължавам да чакам да се случи така че маил сървъра ми да работи,... и дано Дядо Коледа не ми сервира подобен някакъв подарък ...

Абеее по принцип не е хубаво мейл сървъра да ти е на IP където няма обратен резолвинг...някои мейл сървъри режат писма от такива места, дори и да не си в някой спамерски списък.

Относно втория проблем - как така оставаш без IP адрес? Аз си мислех, че един път го вземаш и след това чак докато не си поискаш пак, DHCP сървърът въобще не се занимава с тебе, освен да помни кога за последно ти е видял MAC адреса в ARP таблицата си и колко време е минало оттогава.

Да не би тоя АДСЛ модем постоянно да си иска настройките от DHCP-то през някакъв малък интервал от време? Странно...

А иначе, можеш да ограничиш скоростта с която излизат различните изходящи потоци информация...това става с CBQ да речем и u32 classifiers.

recompile kernel -> networking -> QoS and fair queue-> добавяш CBQ и u32
man tc
man tc-cbq

Дефинираш си един qdisc с максималния bandwidth на линията.
Дефинираш си един клас с максималния bandwidth за примерно SMTP трафика.
Дефинираш си един u32 филтър с който match-ваш съответния трафик (примерно tcp dport 25 (SMTP изходящ) ) към съответния клас.

Да речем в твоя случай това може да стане така:

tc qdisc add dev eth1 (да речем че това ти е ADSL modem-a) root handle 1: cbq avpkt 1000 bandwidth 512 kbit

tc class add dev eth1 parent 1: classid 1:1 cbq rate 128 kbit allot 1500 prio 1 bounded isolated

tc filter add dev eth1 parent 1: protocol ip prio 2 u32 match ip dport 25 0xFFFF flowid 1:1

И готово. Има закво да се заяде човек де, но вярвам че ще сработи като хората (в случая изходящият SMTP трафик ти се реже на 128 кбит/с)

Надявам се това да свърши работа...

> Относно втория проблем - как така оставаш без IP адрес? Аз си мислех, че
> един път го вземаш и след това чак докато не си поискаш пак, DHCP
> сървърът въобще не се занимава с тебе, освен да помни кога за последно ти
> е видял MAC адреса в ARP таблицата си и колко време е минало оттогава.

DHCP сървъра дава IP адресите за определено време. След като това време изтече, клиента трябва пак да си поиска адрес.

За шеъпъра не се притеснявам, проблем ми е историята със "black list" .... Не знам как да си реша проблемите които не зависят от мен ....

Вторият постинг го направих по скоро като информация за останалите - хората които са решили да ползват ADSL от БТК. А администраторите могат да помислят и за достъп до торентите и за маил-а да не говорим за FTP достъп ... И всичко това трябва да мине през шейпър по разбираеми причини. Т.е нуждата от gateway машина е наложителен дори и ADSL-a да ти играе роля на firewall...

mail relay?
за това понятие чували ли сме? хммм?

TANSTAAFL! There AiNt Such Thing As A Free Lunch

А ако не си поиска какво точно се случва?

Аз си мислех че lease time е срока, в който dhcpd-to асоцира IP адреса с MAC адреса, след като този MAC адрес изчезне от ARP таблицата на сървъра...и след като изтече този срок не е гарантирано че същия NIC
ще си вземе предишното IP...явно съм бил в голямо заблуждение, хмм

i kakvo za mail relay ?

ясно колко си чувал

с думи прости - твоят мейл сървер го наместваш да предава пощата на сървер, който се резолв-ва и не е в листите. в случая някой от мейлърите на бтк. и толкоз.

попрочети документацията на мейл сървера как се прави и звънни на супер любо да ти каже ип.

TANSTAAFL! There AiNt Such Thing As A Free Lunch

т.е. имаш идея да използвам БТК mail server за mail gateway ?

clienta pravi release na adresa


DrFrancky

Не е много ясно какво точно се случва, но теоретично dhcp сървъра може да го даде на друг компютър. Вярно, че спецификацията казва да се сървъра трябва да се опита да разбере дали компютъра все още е вързан, но според мен си зависи от имплементацията на сървъра.

pulni gluposti
aide sprete s prostotiite

vobste ne e rabota na servera
rabota na clienta e da si zeme IP adres a ne na servera
servera dava samo PRI ZAIAVKA ... da ne mislis che ste fane da prasta na sichki razni shitz ?
na 50% ot lease time clienta prasta renew na 85% pak ako tova ne stane sled kato isteche lease time clienta prasta zaiavka za nov adres . iasno kato bial den. nema implementacii nema prostotii

sto se obazdade kato ne vi vdevat kuharkite ? traite si , ot vreme na vreme puskaite nekoi "molia","blagodaria" etc etc za da vi misliat horata za intelegentni
sprete da si butate gagata tam kadeto ne i e miastoto
fanete se s nesto drugo kadeto ste ste po profuktivni ... nasazdenia za gluharcheta primerno ?


DrFrancky

е защо не четете:
man dhcpd

The DHCP protocol allows a host which is unknown to the network administrator to be automatically
assigned a new IP address out of a pool of IP addresses for its network. In order for this to work,
the network administrator allocates address pools in each subnet and enters them into the dhcpd.conf(5)
file.On startup, dhcpd reads the dhcpd.conf file and stores a list of available addresses on each subnet in
memory. When a client requests an address using the DHCP protocol, dhcpd allocates an address for it.
Each client is assigned a lease, which expires after an amount of time chosen by the administrator (by
default, one day). Before leases expire, the clients to which leases are assigned are expected to renew
them in order to continue to use the addresses. Once a lease has expired, the client to which that
lease was assigned is no longer permitted to use the leased IP address.

Хехехе, гениалният системен администратор пак се обажда неподготвен.

Работа на сървъра е да администрира списъка от IP адреси. И той може да ги дава за определено време, и ако клиента не се опита да продължи времето, да ги даде на друг клиент.

e sto pa na men go kazvas ?

DrFrancky

be ti vobste chetes li si glupostite ? pomnis li kfo govoris ?

p.s.
ne mi se zanimava s fenomen ot tvoia razmer .. kretenei si ne mi prechis

DrFrancky

Много добре помня какво говоря. Ето всичко, което съм казал по темата, кажи кое е грешно или къде си противореча:

Първо:

DHCP сървъра дава IP адресите за определено време. След като това време 

изтече, клиента трябва пак да си поиска адрес.

След това:

Не е много ясно какво точно се случва, но теоретично dhcp сървъра може да 

го даде на друг компютър. Вярно, че спецификацията казва да се сървъра 

трябва да се опита да разбере дали компютъра все още е вързан, но според 

мен си зависи от имплементацията на сървъра.

Ето какво пише в спецификацията на DHCP за задълженията на сървъра при даване на същия адрес на друг компютър:

In some environments it will be necessary to reassign network addresses due to 

exhaustion of available addresses. In such environments, the allocation 

mechanism will reuse addresses whose lease has expired. The server should use 

whatever information is available in the configuration information repository to 

choose an address to reuse. For example, the server may choose the least 

recently assigned address. As a consistency check, the allocating server SHOULD 

probe the reused address before allocating the address, e.g., with an ICMP echo 

request, and the client SHOULD probe the newly received address, e.g., with ARP.

И накрая:

Работа на сървъра е да администрира списъка от IP адреси. И той може да ги 

дава за определено време, и ако клиента не се опита да продължи времето, 

да ги даде на друг клиент.

Сравни го с непълния коментар, които даваш ти:

clienta pravi release na adresa 

Клиентът може да направи release на адреса, но изобщо не е длъжен да го прави.
И никой нормален програмист не би написал сървър, който разчита на добрата воля на клиента. Точно затова клиента получава адреса за определено време.

che zashto da si cheta glupostite kato ima takiva kato teb? Nali te se vyrzvat na tjah :) ...

P.S. ti syshto ne mi prechish .... Mogesh da kagesh vsichko, mogesh i nishto ... Izbora e tvoj ;) ...

Offtopic:

Това е грозно, но няма страшно, лечимо е. Сексът и въздържанието от стимуланти правели чудеса...