Перейти к содержимому
Калькуляторы

muchacho

покажите что у вас в iptables. целиком

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

muchacho

покажите что у вас в iptables. целиком

не думаю что в этом дело. Пробовал очищать iptables полностью - всё тоже самое.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

muchacho,

ИМХО правильный для вас вариант - пилите здесь http://accel-ppp.org/forum/viewforum.php?f=16 фичреквест, чтобы можно было в аргументах командной строки accel-cmd передать пароль.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Дело не в передаче пароля.

Дело в том, что accel-cmd в моём случае вобще нормально не отрабатывает, с пайпом, без пайпа - разницы нет. netcat хотябы без пайпа отрабатывает нормально.

И я не могу понять в чём дело, единственное что я смог нарыть это сообщение connection reset by peer.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Вечер добрый Xeb

вопрос по IPV6.

В начале я не понял, почему аккель на ::.38 склеивал ласты, но затем это посторилось на ::.39 ((...

 

 

по логам, абонент переподключился с одного браса на другой

2014-11-13 15:27:43  	2014-11-13 19:11:08 	88:ae:1d:2d:2a:5c VEN 	10.35.124.43 	91.219.168.35 	34 / 914 	00D 03:43:25
2014-11-13 20:58:13 	[завершить сессию] 	88:ae:1d:2d:2a:5c VEN 	10.39.112.63 	91.219.168.39 	0 / 0 	        00D 01:53:42

и тут СЛУЧИЛОСЬ Х(

 

 

вот лог с ::.39

[2014-11-13 20:58:39]:  info: ppp36: send [DHCPv6 Reply XID=fe1194 <Server-ID 3:001b0000000000000001>
<Client-ID 1:00011b17845988ae1d2d2a5c> <IA-NA 209a5418 T1=302400 T2=483840
{IA-Addr 2001:67c:21f0:383f:e8b6:ccb3:a20d:280a pref_lifetime=604800 valid_lifetime=2592000}>
<DNSSL> <DNS 2001:67c:21f0::39,2001:67c:21f0::1> <Preference 255>]
[2014-11-13 20:58:40]:  info: ppp36: recv [DHCPv6 Rebind XID=86a0d9 <Elapsed-Time 16777216>
<Client-ID 1:00011b17845988ae1d2d2a5c> <IA-PD 209a5418 T1=0 T2=0 {IA-Prefix 2001:67c:21f0:8005::/64
pref_lifetime=604800 valid_lifetime=2592000}> <Vendor-Class 6002462675370573824> <Option-Request
DNSSL,DNS,Vendor-Specific>]

 

похоже. что ПО абонета запросило делегировать префикс 2001:67c:21f0:8005::/64 на .39 брасе, а он этого не подтвердил и никому больше ничего не сказав, склеил ласты.

 

вот конфиг аккеля с ::.39


[ipv6-pool]
2001:67c:21f0:3800::/53,64
#delegate=2001:67c:21f0:7800::/53,64

[ipv6-dns]
2001:67c:21f0::39
2001:67c:21f0::1
dnssl=localka.net
##dnssl=suffix2.local.net.

[ipv6-dhcp]
verbose=1
pref-lifetime=604800
valid-lifetime=2592000
route-via-gw=0

 

фишка, что этот префикс 2001:67c:21f0:8005::/64 выдан на ::35 брасе

 

2001:67c:21f0:3800::/53 2001:67c:21f0::39 UG1 vlan3

2001:67c:21f0:4000::/53 2001:67c:21f0::35 UG1 vlan3

2001:67c:21f0:8000::/53 2001:67c:21f0::35 UG1 vlan3

 

 

вот конфиг аккеля с ::.35

[ipv6-pool]
2001:67c:21f0:4000::/53,64
delegate=2001:67c:21f0:8000::/53,64

 

 

 

куда копать?

Изменено пользователем pashaumka

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Добрый день, используем у себя пару десятков пппое серверов, accel слушает кучу вланов на bond интерфейсах. Каждый bond собран их 2-х сетевых. Проблема в том, что со стороны свича идет перегрузка 1-го интерфейса входящим трафиком. К примеру на одном может быть под 1Гб/с, на втором 200-300Мбит/с.

 

Со стороны свича проблему решить не удалось (используем brocade RX + SX), различные hash algorithm на aggregation при тестах на длинке тоже не помогли.

 

Решили попробовать избавиться от bond-ов. К примеру, раньше было:

 

[pppoe]

interface=bond0.6

 

станет

 

[pppoe]

interface=eth0.6

interface=eth1.6

 

но есть сомнения, насколько я понимаю, при этом клиенту будут прилетать два PADO с одинаковым AC-Name. Согласно rfc AC-Name должен быть уникальным, поэтому не уверен в работоспособности.

 

Как вариант, можно запустить несколько accel на одном сервере с разными AC-Name на разных сетевых, но как при этом будет вести себя ядро с именованием интерфейсов (ведь оба будут использовать ppp*), не будет ли конфликтов?

 

Как поступить? Буду раз любым советам, заранее спасибо.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

У вас там несколько vlan-ов? Разбросьте их руками на две карты и всё.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

куда копать?
я сейчас в командировке, приеду посмотрю...

 

но есть сомнения, насколько я понимаю, при этом клиенту будут прилетать два PADO с одинаковым AC-Name. Согласно rfc AC-Name должен быть уникальным, поэтому не уверен в работоспособности.
не думаю что с этим будут какие-то проблемы, клиент выберет любой

но и не думаю что таким образом удастся решить проблему балансировки

надо всё-таки как-то через bond решать

 

Со стороны свича проблему решить не удалось (используем brocade RX + SX), различные hash algorithm на aggregation при тестах на длинке тоже не помогли.
я так понимаю основной трафик - это трафик по направлению к клиенту, значит, наверно, надо bond на сервере крутить

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Xeb, выкладываю ещё порцию логов, но уже с 2-мя серверами )

 

писал в 23:50

 

лог подключений

2014-11-14 13:51:59 	2014-11-14 22:14:27 	10:78:d2:3e:cb:c7 VEN 	10.36.240.1 	91.219.168.36 	100 / 2047 	00D 08:22:28
2014-11-15 14:25:56 	[завершить сессию] 	10:78:d2:3e:cb:c7 VEN 	10.39.240.2 	91.219.168.39 	0 / 0 	00D 09:19:21
2014-11-15 14:31:06 	[завершить сессию] 	10:78:d2:3e:cb:c7 VEN 	10.38.240.11 	91.219.168.38 	0 / 0 	00D 09:14:11
2014-11-15 14:39:22 	[завершить сессию] 	10:78:d2:3e:cb:c7 VEN 	10.36.240.1 	91.219.168.36 	150 / 2047 	00D 09:05:55

 

 

лог аккеля с ::.39

[2014-11-15 14:26:18]:  info: ppp39: recv [LCP Ident id=2 <MSRASV5.20>]
[2014-11-15 14:26:18]:  info: ppp39: recv [LCP Ident id=3 <MSRAS-0-XXXXXX-XX>]
[2014-11-15 14:26:18]:  info: ppp39: recv [LCP Ident id=4 <GXXHXNXNXXXX%;X!>]
[2014-11-15 14:26:18]:  info: ppp39: recv [PAP AuthReq id=0]
[2014-11-15 14:26:18]: debug: ppp39: radius(1): req_enter 1
[2014-11-15 14:26:18]:  info: ppp39: send [RADIUS(1) Access-Request id=1 <User-Name "rubanskaya"> <NAS-Identifier
"bras39"> <NAS-IP-Address 91.219.168.39> <NAS-Port 39> <NAS-Port-Id "ppp39"> <NAS-Port-Type Virtual> <Service-Type
Framed-User> <Framed-Protocol PPP> <Calling-Station-Id "10:78:d2:3e:cb:c7"> <Called-Station-Id "00:1e:67:03:9e:e8">
<User-Password >]
[2014-11-15 14:26:18]: debug: ppp39: radius(1): req_exit 0
[2014-11-15 14:26:18]:  info: ppp39: recv [RADIUS(1) Access-Accept id=1 <Filter-Id "f_el_100mbit*10*003560020000000*
-120.83*a6e7253d57d6c8529cf238fd1b807efb*1770*NO"> <Framed-Pool "block_po_oplate"> <PPPD-Upstream-Speed-Limit 25600>
<PPPD-Downstream-Speed-Limit 81920> <Service-Type Framed-User> <Framed-Protocol PPP> <Framed-MTU 1492>
<Termination-Action RADIUS-Request> <Framed-IP-Netmask 255.255.255.255>]
[2014-11-15 14:26:18]:  info: ppp39: send [PAP AuthAck id=0 "Authentication succeeded"]
[2014-11-15 14:26:18]: debug: ppp39: auth_layer_started
[2014-11-15 14:26:18]: debug: ppp39: ccp_layer_start
[2014-11-15 14:26:18]: debug: ppp39: ipcp_layer_start
[2014-11-15 14:26:18]:  info: ppp39: send [iPCP ConfReq id=1 <addr 91.219.168.39>]
[2014-11-15 14:26:18]: debug: ppp39: ipv6cp_layer_start
[2014-11-15 14:26:18]:  info: ppp39: send [iPV6CP ConfReq id=1 <addr 7056:4b81:f138:90e1>]
[2014-11-15 14:26:18]:  info: ppp39: rubanskaya: authentication succeeded
[2014-11-15 14:26:18]:  info: ppp39: recv [iPV6CP ConfReq id=5 <addr f86c:5632:f807:5322>]
[2014-11-15 14:26:18]:  info: ppp39: send [iPV6CP ConfAck id=5]
[2014-11-15 14:26:18]:  info: ppp39: recv [iPCP ConfReq id=6 <addr 0.0.0.0> <dns1 0.0.0.0> <wins1 0.0.0.0>
<dns2 0.0.0.0> <wins2 0.0.0.0>]
[2014-11-15 14:26:18]:  info: ppp39: send [iPCP ConfNak id=6 <addr 10.39.240.2> <dns1 91.219.168.39>
<dns2 91.219.168.1>]
[2014-11-15 14:26:18]:  info: ppp39: recv [iPCP ConfAck id=1 <addr 91.219.168.39>]
[2014-11-15 14:26:18]:  info: ppp39: recv [iPV6CP ConfAck id=1 <addr 7056:4b81:f138:90e1>]
[2014-11-15 14:26:18]: debug: ppp39: ipv6cp_layer_started
[2014-11-15 14:26:18]:  info: ppp39: recv [iPCP ConfReq id=7 <addr 10.39.240.2> <dns1 91.219.168.39> <wins1 0.0.0.0>
<dns2 91.219.168.1> <wins2 0.0.0.0>]
[2014-11-15 14:26:18]:  info: ppp39: send [iPCP ConfAck id=7]
[2014-11-15 14:26:18]: debug: ppp39: ipcp_layer_started
[2014-11-15 14:26:18]: debug: ppp39: radius(1): req_enter 1
[2014-11-15 14:26:18]:  info: ppp39: send [RADIUS(1) Accounting-Request id=1 <User-Name "rubanskaya">
<NAS-Identifier "bras39"> <NAS-IP-Address 91.219.168.39> <NAS-Port 39> <NAS-Port-Id "ppp39"> <NAS-Port-Type Virtual>
<Service-Type Framed-User> <Framed-Protocol PPP> <Calling-Station-Id "10:78:d2:3e:cb:c7"> <Called-Station-Id
"00:1e:67:03:9e:e8"> <Acct-Status-Type Start> <Acct-Authentic RADIUS> <Acct-Session-Id "e54700dd64e900e1">
<Acct-Session-Time 0> <Acct-Input-Octets 0> <Acct-Output-Octets 0> <Acct-Input-Packets 0> <Acct-Output-Packets 0>
<Acct-Input-Gigawords 0> <Acct-Output-Gigawords 0> <Framed-IP-Address 10.39.240.2> <Framed-Interface-Id
f86c:5632:f807:5322> <Framed-IPv6-Prefix 2001:67c:21f0:3acb::/64>]
[2014-11-15 14:26:18]: debug: ppp39: radius(1): req_exit 0
[2014-11-15 14:26:18]:  info: ppp39: recv [RADIUS(1) Accounting-Response id=1]
[2014-11-15 14:26:18]:  info: ppp39: pppd_compat: ip-pre-up started (pid 18992)
[2014-11-15 14:26:18]:  info: ppp39: pppd_compat: ip-pre-up finished (0)
[2014-11-15 14:26:18]:  info: ppp39: shaper: installed shaper 81920/25600 (Kbit)
[2014-11-15 14:26:18]: debug: ppp39: pppoe: ppp started
[2014-11-15 14:26:18]:  info: ppp39: pppd_compat: ip-up started (pid 18995)
[2014-11-15 14:26:18]:  info: ppp39: pppd_compat: ip-up finished (0)
[2014-11-15 14:26:19]:  info: ppp39: recv [DHCPv6 Rebind XID=248920 <Elapsed-Time 16777216>
<Client-ID 1:00011b5853921078d23ecbc7> <IA-PD 205b9212 T1=0 T2=0 {IA-Prefix 2001:67c:21f0:8010::/64 pref_lifetime=604800
valid_lifetime=2592000}> <Vendor-Class 6002462675370573824> <Option-Request DNSSL,DNS,Vendor-Specific>]

Ласты --

 

 

лог аккеля с ::.38

[2014-11-15 14:30:49]:  info: ppp214: connect: ppp214 <--> pppoe(10:78:d2:3e:cb:c7)
[2014-11-15 14:30:52]:  info: ppp214: send [RADIUS(1) Access-Request id=1 <User-Name "rubanskaya"> <NAS-Identifier
"bras38"> <NAS-IP-Address 91.219.168.38> <NAS-Port 214> <NAS-Port-Id "ppp214"> <NAS-Port-Type Virtual> <Service-Type
Framed-User> <Framed-Protocol PPP> <Calling-Station-Id "10:78:d2:3e:cb:c7"> <Called-Station-Id "00:15:17:8c:fc:e5">
<User-Password >]
[2014-11-15 14:30:52]:  info: ppp214: recv [RADIUS(1) Access-Accept id=1 <Filter-Id "f_el_100mbit*10*003560020000000*
-120.83*a6e7253d57d6c8529cf238fd1b807efb*1770*NO"> <Framed-Pool "block_po_oplate"> <PPPD-Upstream-Speed-Limit 25600>
<PPPD-Downstream-Speed-Limit 81920> <Service-Type Framed-User> <Framed-Protocol PPP> <Framed-MTU 1492> <Termination
-Action RADIUS-Request> <Framed-IP-Netmask 255.255.255.255>]
[2014-11-15 14:30:52]:  info: ppp214: rubanskaya: authentication succeeded
[2014-11-15 14:30:52]:  info: ppp214: send [RADIUS(1) Accounting-Request id=1 <User-Name "rubanskaya"> <NAS-Identifier
"bras38"> <NAS-IP-Address 91.219.168.38> <NAS-Port 214> <NAS-Port-Id "ppp214"> <NAS-Port-Type Virtual> <Service-Type
Framed-User> <Framed-Protocol PPP> <Calling-Station-Id "10:78:d2:3e:cb:c7"> <Called-Station-Id "00:15:17:8c:fc:e5">
<Acct-Status-Type Start> <Acct-Authentic RADIUS> <Acct-Session-Id "580fb6e7883c4330"> <Acct-Session-Time 0>
<Acct-Input-Octets 0> <Acct-Output-Octets 0> <Acct-Input-Packets 0> <Acct-Output-Packets 0> <Acct-Input-Gigawords 0>
<Acct-Output-Gigawords 0> <Framed-IP-Address 10.38.240.11> <Framed-Interface-Id f86c:5632:f807:5322>
<Framed-IPv6-Prefix 2001:67c:21f0:2437::/64>]
[2014-11-15 14:30:52]:  info: ppp214: recv [RADIUS(1) Accounting-Response id=1]

и ласты--

 

результат

pppoe-mini-crash-39.png

pppoe-mini-crash-38.png

 

чертята в общем-то, забили на радиус и очень весело подхватили абонов, причем это один из ещё 3-х брасов

pppoe-mini-crash-37.png

 

 

 

что срубило 38-й и 39-й...???

 

p.s. отключил модуль dhcpv6 - аккель перестало колбасить

 

 

вообще можно поиграться, или выдавать делегируемый префикc с пула браса, или через радиус всем раздать <Delegated-ipv6-Prefix>

Изменено пользователем pashaumka

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Что означает

 

warn: l2tp: short packet received (1363/34179)

?

 

В чем может быть проблема?

Изменено пользователем morfair

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Доброго времени суток.

Подскажите в таком вопрое:сейчас перешел на использование accel-ppp в качестве pppoe сервера (ранее использовал стандатрный ppp+ rp_pppoe)

При переходе на accel у абонов переодически стало появляться сообщение при попытке авторизации о входе в домен (http://postimg.org/image/s5tu14oel/)

у кого стоит роутер все в порядке,у кого винда бывает выскакивает сообщение по несколько раз потом подключается. У кого было такое как решили ? польностью отключить ipv4 на сетевой карте не предлагать (т.к. есть внутренние сервисы.)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

У вас там несколько vlan-ов? Разбросьте их руками на две карты и всё.

 

 

но есть сомнения, насколько я понимаю, при этом клиенту будут прилетать два PADO с одинаковым AC-Name. Согласно rfc AC-Name должен быть уникальным, поэтому не уверен в работоспособности.
не думаю что с этим будут какие-то проблемы, клиент выберет любой

но и не думаю что таким образом удастся решить проблему балансировки

надо всё-таки как-то через bond решать

 

Со стороны свича проблему решить не удалось (используем brocade RX + SX), различные hash algorithm на aggregation при тестах на длинке тоже не помогли.
я так понимаю основной трафик - это трафик по направлению к клиенту, значит, наверно, надо bond на сервере крутить

 

На всякий случай отпишу, вдруг кому пригодится. Странно, но изменение xmit_hash_policy на l2 для bond не помогло, остановились на варианте с дублированием вланов на двух сетевых, в pppoe-discovery видно два PADO c разными маками и одинаковыми AC-Name , багов за 3 дня не замечено, трафик с клиентами делится примерно поровну между обоими сетевыми. Спасибо.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Всем привет. Подскажите как сделать префикс к логину при ipoe?

 

сейчас у меня строки username/password закоментированы и в качестве логина и пароля передается ИП адрес клиента, надо приписать префикс для данного сервера.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

в текущей реализации - никак

 

можно добавить realm, тогда логины будут вида x.x.x.x@REALM

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Подскажите как сделать префикс к логину при ipoe?

Может через LUA выйти к слову, хотя на 100% не уверен (сверяться с мануалом лень).

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Почините пожалуйста шейпер в 731b6b13149ab333158aadfd3c7b841f5c1fc3b4

http://accel-ppp.org/forum/viewtopic.php?f=12&t=53

 

Спасибо :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

День добрый Xeb.

 

вы dhcpv6 смотрели?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

gentoo (kernel 3.16.5):

 

git clone git://git.code.sf.net/p/accel-ppp/code accel-ppp-code
...
cmake -DRADIUS=TRUE -DBUILD_IPOE_DRIVER=TRUE -DNETSNMP=TRUE -DLUA=TRUE -DSHAPER=TRUE ../accel-ppp-code/
...
make
...
/root/build/drivers/ipoe/driver/ipoe.c: In function 'ipoe_stats64':
/root/build/drivers/ipoe/driver/ipoe.c:1065:4: error: implicit declaration of function 'u64_stats_fetch_begin_bh' [-Werror=implicit-function-declaration]
   start = u64_stats_fetch_begin_bh(&st->sync);
   ^
/root/build/drivers/ipoe/driver/ipoe.c:1068:3: error: implicit declaration of function 'u64_stats_fetch_retry_bh' [-Werror=implicit-function-declaration]
  } while (u64_stats_fetch_retry_bh(&st->sync, start));
  ^
cc1: some warnings being treated as errors
scripts/Makefile.build:263: recipe for target '/root/build/drivers/ipoe/driver/ipoe.o' failed
make[4]: *** [/root/build/drivers/ipoe/driver/ipoe.o] Error 1
Makefile:1333: recipe for target '_module_/root/build/drivers/ipoe/driver' failed
make[3]: *** [_module_/root/build/drivers/ipoe/driver] Error 2
drivers/ipoe/CMakeFiles/ipoe_drv.dir/build.make:55: recipe for target 'drivers/ipoe/driver/ipoe.ko' failed
make[2]: *** [drivers/ipoe/driver/ipoe.ko] Error 2
CMakeFiles/Makefile2:1286: recipe for target 'drivers/ipoe/CMakeFiles/ipoe_drv.dir/all' failed
make[1]: *** [drivers/ipoe/CMakeFiles/ipoe_drv.dir/all] Error 2
Makefile:136: recipe for target 'all' failed
make: *** [all] Error 2

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

gentoo (kernel 3.16.5): ...

Нашел только здесь https://launchpad.net/ubuntu/+source/linux/+changelog

net: Replace u64_stats_fetch_begin_bh to u64_stats_fetch_begin_irq

оно?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

спасиб попробую уже в пнд :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

фич реквест

 

некоторые заблокированнве абоны, аху.....

подключаются - получают блок из бан пула - им вылетает страничка "заплати". всё здорово...

но для некорых гугл/ютуб, яндекс и в вконтакте - более не надо - по IPV6 получают адрес и довольны, "жизнь налаживается", а потом с воплями звонят... "а у мееня 2-3 сайта открывается" вы .....пидо..

 

что надо

аналогично с ipv4 - пулы адресов/префиксов от радуса

 

есть

[ip-pool]

gw-ip-address=AA.VV.XX.39

10.39.0.0/20,name=gray_ip_inet_pool

10.39.112.0/20,name=ip_pool_server_based

10.39.192.0/20,name=block_adm_disabled

10.39.240.0/20,name=block_po_oplate

 

надо допилить

[ipv6-pool]

2001:XXXX:TTTT:3800::/53,mask=64,name=ip_pool_server_based

0001:XXXx:TTTT:3000::/53,mask=64,name=block_po_oplate

 

а дальне форвардом задрать на "заплати"

и передвать делегированный префикс в скрипты, чтобы забивать на них

 

ИЛИ

в скрипты просто передвать или через переменные окружения, или через радиус аттрибут pool_name, v6_префикс и делегируемый_в6_префикс

Изменено пользователем pashaumka

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

commit ebc0ec740280efd2ea7f22abbb84eda53ab06632

проверяй

 

что изменено, как демон будет реагировать на делегируемый префикс, роутить через себя ( объявив через оспф6 ) или забивать на вопли клиента?

Изменено пользователем pashaumka

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

нормально будет реагировать, как и раньше

что изменено - реакция на REBIND, оно игнорируется, если клиент не получил ип "по-нормальному", через REQUEST

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.