Пе­репе­чата­но из жур­на­ла "Ха­кер"

Воз­можнос­тей у Squ­id столь­ко, что раз­ра­бот­чи­ки час­то да­же не ус­пе­ва­ют их под­робно опи­сывать. Об­щая наст­рой­ка, как пра­вило, проб­лем не вы­зыва­ет. Cлож­ности на­чина­ют­ся, ког­да не­об­хо­димо наст­ро­ить ог­ра­ниче­ния на ис­поль­зо­вание ка­нала, ор­га­низо­вать дос­туп к прок­си при по­мощи внеш­них средств или выб­рать прог­рамму для ра­боты с жур­на­лами.

Все по­делим по­ров­ну

Си­ту­ация, ког­да один ка­нал нуж­но спра­вед­ли­во раз­де­лить меж­ду поль­зо­вате­лями, от­нюдь не ред­кость. В Squ­id ре­гули­ров­ка про­пуск­ной спо­соб­ности ка­нала про­из­во­дит­ся при по­мощи пу­лов. За наст­рой­ки от­ве­ча­ет груп­па па­рамет­ров «De­lay Po­ols». Боль­шинс­тво па­рамет­ров этой сек­ции тре­бу­ют ком­пи­ляции squ­id с оп­ци­ей '--enab­le-de­lay-po­ols'. По умол­ча­нию – так и есть. Уз­нать па­рамет­ры сбор­ки ус­та­нов­ленно­го Squ­id, мож­но вве­дя ко­ман­ду «squ­id –v».

Прин­цип ог­ра­ниче­ния ско­рос­ти прост. Каж­дый зап­ра­шива­емый объект сна­чала по­пада­ет в бу­фер, а толь­ко за­тем пе­реда­ет­ся кли­ен­ту. Каж­дый пул оп­ре­деля­ет­ся дву­мя па­рамет­ра­ми: ско­ростью за­пол­не­ния и раз­ме­ром бу­фера. Ес­ли объем дан­ных мень­ше раз­ме­ра бу­фера, то кли­ент по­луча­ет их с мак­си­маль­ной ско­ростью, но при дос­ти­жении ли­мита ин­форма­ция бу­дет вы­давать­ся в со­от­ветс­твии с ус­та­нов­ка­ми. По ме­ре опус­то­шения пу­ла Squ­id бу­дет по­лучать ос­таль­ную часть зап­ра­шива­емой ин­форма­ции.

Ско­рость за­пол­не­ния пу­ла за­висит от клас­са. Для каж­до­го пу­ла при по­мощи de­lay_class дол­жен быть ус­та­нов­лен один из пя­ти клас­сов (до вер­сии 2.6 – один из трех):

• 1 – ог­ра­ниче­ния дей­стви­тель­ны для всех;
• 2 – дей­ству­ют об­щие ог­ра­ниче­ния, плюс ин­ди­виду­аль­ные ог­ра­ниче­ния для от­дель­ных хос­тов (би­ты 25 – 32 се­тево­го ад­ре­са);
• 3 – дей­ству­ют об­щие ог­ра­ниче­ния, плюс ин­ди­виду­аль­ные ог­ра­ниче­ния для се­тей (би­ты 17 - 24) и от­дель­ных хос­тов (би­ты 17 - 32);
• 4 – все, что оп­ре­деле­но в клас­се 3, плюс вве­дены ог­ра­ниче­ния для конк­рет­но­го поль­зо­вате­ля;
• 5 – зап­ро­сы груп­пи­ру­ют­ся в со­от­ветс­твии с их те­гами, оп­ре­делен­ны­ми при по­мощи ex­ternal_acl.

От­сю­да мож­но сде­лать вы­вод, что чем вы­ше класс, тем че­рез боль­шее ко­личест­во ог­ра­ниче­ний про­ходит со­еди­нение. Так для чет­верто­го клас­са сна­чала дей­ству­ют об­щие ог­ра­ниче­ния, за­тем ог­ра­ниче­ния под­се­ти, от­дель­но­го уз­ла и, на­конец, для поль­зо­вате­ля. Не сто­ит ожи­дать, что поль­зо­ватель по­лучит чет­ко про­писан­ную часть ка­нала, ес­ли его под­сеть выб­ра­ла свой ли­мит.

Класс для пу­ла за­да­ет­ся при по­мощи па­рамет­ра de­lay_class, ар­гу­мен­та­ми ко­торо­го яв­ля­ют­ся но­мер пу­ла и но­мер клас­са. Ко­личест­во пу­лов за­да­ет­ся па­рамет­ром de­lay_po­ols. Нап­ри­мер, соз­да­дим два пу­ла и оп­ре­делим для каж­до­го из них свой класс. Для это­го про­писы­ва­ем в squ­id.conf сле­ду­ющие стро­ки:

# vim /etc/squ­id/squ­id.conf

# За­да­ем спис­ки дос­ту­па, по ко­торым бу­дем расп­ре­делять юзе­ров по пу­лам

acl of­fi­ce src 192.168.1.0/24

acl of­fi­ce2 src 192.168.2.0/24

acl user src 192.168.1.20/32

acl boss src 192.168.1.12/32

de­lay_po­ols 2 # 2 пу­ла

de­lay_class 1 2 # пул 1, класс 2

de­lay_class 2 3 # пул 2, класс 3

При­над­лежность поль­зо­вате­лей к пу­лу за­да­ет­ся при по­мощи de­lay_ac­cess. Его син­таксис на­поми­на­ет http_ac­cess:

de­lay_ac­cess po­ol al­low/de­ny ACL

По­иск пу­ла для конк­рет­но­го ад­ре­са бу­дет про­ис­хо­дить толь­ко до пер­во­го сов­па­дения, по­это­му при объяв­ле­нии пу­лов не­об­хо­димо соб­лю­дать нуж­ный по­рядок. В од­ной стро­ке сле­ду­ет ис­поль­зо­вать толь­ко один ACL. Ес­ли про­писать их нес­коль­ко, в пул по­падет толь­ко пер­вый. Так­же как и в http_ac­cess, что­бы в не­го не по­пал «лиш­ний» ад­рес, каж­дый пул сле­ду­ет зак­ры­вать при по­мощи конс­трук­ции de­ny all.

de­lay_ac­cess 1 al­low of­fi­ce

de­lay_ac­cess 1 al­low user

de­lay_ac­cess 1 de­ny all

de­lay_ac­cess 2 al­low of­fi­ce2

de­lay_ac­cess 2 al­low boss

de­lay_ac­cess 2 de­ny all

http_ac­cess al­low of­fi­ce of­fi­ce2 boss user

http_ac­cess de­ny all

В пер­вый пул вклю­чены кли­ен­ты, опи­сан­ные в ACL of­fi­ce и user, во вто­рой – of­fi­ce2 и boss. Важ­но пом­нить, что ACL, не ука­зан­ные в de­lay_ac­cess, бу­дут вы­ходить в Сеть без ог­ра­ниче­ний. При по­мощи de­lay_pa­rame­ters за­да­ем ог­ра­ниче­ния по ско­рос­ти для каж­до­го пу­ла. В за­виси­мос­ти от клас­са пу­ла ко­личест­во ар­гу­мен­тов бу­дет раз­личным. Так для чет­верто­го клас­са пол­ный фор­мат за­писи выг­ля­дит так:

de­lay_pa­rame­ters пул об­щий сеть ин­ди­виду­аль­ный_поль­зо­ватель

Со­от­ветс­твен­но, в третьем клас­се не ис­поль­зу­ет­ся пос­ледний ар­гу­мент, а во вто­ром от­сутс­тву­ют «сеть» и «поль­зо­ватель». Ко­личест­во пар долж­но со­от­ветс­тво­вать клас­су. Ес­ли что-то про­пус­тить, сквид от­ка­жет­ся ра­ботать. Ог­ра­ниче­ния на каж­дой из по­зиций сос­то­ят из па­ры ско­рость за­пол­не­ния/объем пу­ла. Зна­чения здесь ука­зыва­ют­ся в бай­тах, а ско­рость про­вай­де­ры счи­та­ют в би­тах. В по­зици­ях, в ко­торых нет ог­ра­ниче­ний, ус­та­нав­ли­ва­ем «-1»:

de­lay_pa­rame­ters 1 16000/16000 8000/8000

de­lay_pa­rame­ters 2 32000/32000 -1/-1 16000/16000

Для пер­во­го пу­ла ус­та­нов­ле­но об­щее ог­ра­ниче­ние в 128К и 64К для ин­ди­виду­аль­но­го ад­ре­са. Для вто­рого об­щее ог­ра­ниче­ние – 256К; ли­мита на под­сеть нет, но есть ус­та­нов­ка для от­дель­но­го IP-ад­ре­са. Для каж­до­го пу­ла долж­на быть толь­ко од­на стро­ка de­lay_pa­rame­ters.

Ис­поль­зуя раз­личные ти­пы acl (смот­ри ][ за май это­го го­да), мож­но ввес­ти ог­ра­ниче­ния по вре­мени, про­токо­лам, ти­пу фай­лов и др. Нап­ри­мер, при по­мощи та­кой конс­трук­ции лег­ко ог­ра­ничить ско­рость лю­бите­лям ка­чать муль­ти­медиа:

acl mul­ti­media url­path_re­gex -i \.mp3$ \.mpeg$ \.avi$

de­lay_po­ols 3

de­lay_class 3 1

de­lay_ac­cess 3 al­low mul­ti­media

de­lay_ac­cess 3 de­ny all

de­lay_pa­rame­ters 3 8000/8000

Те­перь при за­кач­ке фай­лов ука­зан­ных ти­пов ско­рость вы­ше 64 кбит под­ни­мать­ся не бу­дет. Ана­логич­но ус­та­нав­ли­ва­ют­ся ог­ра­ниче­ния по вре­мени. Нап­ри­мер, что­бы умень­шить для всех поль­зо­вате­лей ско­рость до 32 кбит в ра­бочее вре­мя, при­меня­ем пра­вило:

acl work_ho­urs ti­me M T W T F 9:00-18:00

de­lay_class 4 2

de­lay_ac­cess 4 al­low work_ho­urs

de­lay_ac­cess 4 de­ny all

de­lay_pa­rame­ters 4 -1/-1 4000/4000

Та­ким же об­ра­зом наст­ра­ивают­ся ог­ра­ниче­ния по про­токо­лам, ад­ре­сам и дру­гим ти­пам ACL, под­держи­ва­емым Squ­id. Но что­бы пра­вила ра­бота­ли вер­но, их нуж­но рас­по­лагать в том по­ряд­ке, в ко­тором они долж­ны при­менять­ся. Нап­ри­мер, ес­ли од­ним поль­зо­вате­лям ус­та­нав­ли­ва­ют­ся ог­ра­ниче­ния по ад­ре­су, а дру­гим по вре­мени, то сна­чала сле­ду­ет про­писать пул для пер­вых, а за­тем для вто­рых. Будь вни­мате­лен!

Аутен­ти­фика­ция в Squ­id

До это­го мо­мен­та спис­ки дос­ту­па фор­ми­рова­лись на ос­но­ве IP-ад­ре­са компьюте­ра или его при­над­лежнос­ти к не­кото­рой се­ти. Не­ред­ко воз­ни­ка­ет си­ту­ация, ког­да за од­ним компьюте­ром ра­бота­ют нес­коль­ко че­ловек, и не­об­хо­димо пре­дос­та­вить дос­туп толь­ко пос­ле вво­да ло­гина и па­роля. Squ­id под­держи­ва­ет раз­личные ва­ри­ан­ты аутен­ти­фика­ции. Что­бы обес­пе­чить про­вер­ку «под­линнос­ти» кли­ен­тов, сле­ду­ет ис­поль­зо­вать тип ACL pro­xy_auth и оп­ре­делить с по­мощью па­рамет­ра auth_pa­ram (ра­нее aut­henti­cate_prog­ram) прог­рамму для аутен­ти­фика­ции.

acl USERS pro­xy_auth RE­QU­IRED

http_ac­cess al­low USERS

http_ac­cess de­ny all

auth_pa­ram /usr/lib/squ­id/ncsa_auth /etc/squ­id/passwd

auth_pa­ram child­ren 5

auth_pa­ram ba­sic re­alm Squ­id pro­xy-ca­ching web ser­ver

auth_pa­ram ba­sic cre­den­ti­alsttl 2 ho­urs

В пер­вых трех стро­ках объяв­лен но­вый acl и при по­мощи http_ac­cess раз­ре­шен дос­туп для всех кли­ен­тов, вхо­дящих в дан­ный спи­сок. Зна­чение RE­QU­IRED ука­зыва­ет на то, что лю­бой поль­зо­ватель, про­шед­ший аутен­ти­фика­цию, бу­дет до­пущен. Как ва­ри­ант, здесь мож­но про­писать конк­рет­ные ло­гины. В стро­ке ни­же ука­зыва­ем прог­рамму для аутен­ти­фика­ции и рас­по­ложе­ние фай­ла па­ролей. В раз­ных дист­ри­бути­вах мес­то­рас­по­ложе­ние ncsa_auth от­ли­ча­ет­ся. Най­ти его прос­то:

$ dpkg -L squ­id3 | grep ncsa_auth

Или – для RPM:

# rpm -ql squ­id | grep nsca_auth

Па­раметр child­ren поз­во­ля­ет за­дать мак­си­маль­ное ко­личест­во про­цес­сов, ис­поль­зу­емых для аутен­ти­фика­ции. Не­боль­шое ко­личест­во про­цес­сов мо­жет ее за­мед­лить. Ис­поль­зуя re­alm, оп­ре­делим со­об­ще­ние Squ­id, вы­води­мое юзе­ру в ок­не вво­да па­роля. В прин­ци­пе, текст здесь мож­но ввес­ти и на русс­ком, но то, как он бу­дет вы­веден поль­зо­вате­лю – за­висит от наст­ро­ек бра­узе­ра. И, на­конец, cre­den­ti­alsttl ука­зыва­ет вре­мя кэ­широ­вания па­роля.

Файл па­ролей соз­да­ет­ся при по­мощи ути­литы htpasswd, ко­торая вхо­дит в сос­тав па­кета Apa­che. Соз­да­дим поль­зо­вате­ля grin­der:

$ su­do htpasswd -c /etc/squ­id/passwd grin­der

New pass­word:

Re-ty­pe new pass­word:

Ad­ding pass­word for user grin­der

На­пом­ню, что ключ '–с' ис­поль­зу­ет­ся толь­ко од­нажды (для соз­да­ния фай­ла). В даль­ней­шем до­бав­ля­ем учет­ные за­писи с клю­чом '-b'. Для удобс­тва па­роль мож­но ука­зывать пря­мо в ко­манд­ной стро­ке:

$ su­do htpasswd -b /etc/squ­id/passwd user 123456

Пе­реза­пус­кать Squ­id при из­ме­нении спис­ка поль­зо­вате­лей не тре­бу­ет­ся. Что­бы ник­то дру­гой не мог по­лучить дос­туп к фай­лу па­ролей, сле­ду­ет ус­та­новить со­от­ветс­тву­ющие пра­ва:

$ su­do chmod 440 /etc/squ­id/passwd

$ su­do chown squ­id:squ­id /etc/squ­id/passwd

Про­бу­ем подк­лю­чить­ся к прок­си-сер­ве­ру. Что­бы не вво­дить каж­дый раз ло­гин и па­роль, их мож­но ука­зать в наст­рой­ках кли­ент­ско­го бра­узе­ра.