Почему меняется ttl при пинге
Перейти к содержимому

Почему меняется ttl при пинге

  • автор:

unixforum.org

Попробуй в обоих случаях посмотреть traceroute, может путь меняется.
А как далеко от тебя сервер находится?
И что у тебя в правилах по поводу ttl есть?

Не шалю, никого не трогаю, починяю примус.
Спасибо сказали:
serg_sk Бывший модератор Сообщения: 2749 Статус: ОС: Gentoo Linux Контактная информация:

Re: Меняется значение ttl (Time to Live)

Сообщение serg_sk » 14.01.2006 18:47

Jan2ary
Это были пинги с роутера, который стоит в двух сантиметрах от фтп От меня тоже самое почти, только чуть дольше.
В праивлах по поводу ttl ничего нету.

router ~ # ping 172.16.23.253 PING 172.16.23.253 (172.16.23.253) 56(84) bytes of data. 64 bytes from 172.16.23.253: icmp_seq=1 ttl=64 time=1.07 ms 64 bytes from 172.16.23.253: icmp_seq=2 ttl=64 time=0.116 ms --- 172.16.23.253 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1001ms rtt min/avg/max/mdev = 0.116/0.596/1.077/0.481 ms router ~ # ssh -l serg_sk 172.16.23.253 ssh: connect to host 172.16.23.253 port 22: Connection refused router ~ # ping 172.16.23.253 PING 172.16.23.253 (172.16.23.253) 56(84) bytes of data. 64 bytes from 172.16.23.253: icmp_seq=1 ttl=128 time=153 ms 64 bytes from 172.16.23.253: icmp_seq=2 ttl=128 time=524 ms --- 172.16.23.253 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1001ms router ~ # traceroute 172.16.23.253 traceroute to 172.16.23.253 (172.16.23.253), 30 hops max, 40 byte packets 1 172.16.23.253 (172.16.23.253) 300.842 ms 380.945 ms 368.305 ms

В этот де момент издому наблюдалась такая картина:

serg_sk@Elvenhome ~ $ ping 172.16.23.253 PING 172.16.23.253 (172.16.23.253) 56(84) bytes of data. 64 bytes from 172.16.23.253: icmp_seq=1 ttl=64 time=150 ms 64 bytes from 172.16.23.253: icmp_seq=2 ttl=64 time=338 ms 64 bytes from 172.16.23.253: icmp_seq=3 ttl=64 time=94.6 ms 64 bytes from 172.16.23.253: icmp_seq=4 ttl=64 time=243 ms --- 172.16.23.253 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3003ms rtt min/avg/max/mdev = 94.626/206.778/338.023/92.652 ms serg_sk@Elvenhome ~ $ ssh 172.16.23.253 Password: Last login: Sat Jan 14 14:00:59 2006 from elvenhome.info serg_sk@FTP ~ $ sudo su - Password: FTP ~ # /etc/init.d/proftpd stop * Stopping proftpd . [ ok ] FTP ~ # /etc/init.d/proftpd stRead from remote host 172.16.23.253: Connection reset by peer Connection to 172.16.23.253 closed. serg_sk@Elvenhome ~ $ ssh 172.16.23.253 ssh: connect to host 172.16.23.253 port 22: Connection refused serg_sk@Elvenhome ~ $ ping 172.16.23.253 PING 172.16.23.253 (172.16.23.253) 56(84) bytes of data. 64 bytes from 172.16.23.253: icmp_seq=1 ttl=128 time=208 ms 64 bytes from 172.16.23.253: icmp_seq=2 ttl=128 time=352 ms 64 bytes from 172.16.23.253: icmp_seq=4 ttl=128 time=50.4 ms --- 172.16.23.253 ping statistics --- 5 packets transmitted, 3 received, 40% packet loss, time 4000ms rtt min/avg/max/mdev = 50.456/203.815/352.609/123.395 ms serg_sk@Elvenhome ~ $

В это время шел трасероут из-дому и завершился в момент когда мне написало «Connection to 172.16.23.253 closed.»:

Elvenhome ~ # traceroute 172.16.23.253 traceroute to 172.16.23.253 (172.16.23.253), 30 hops max, 40 byte packets 1 * * * 2 * * * 3 * * * 4 * * * 5 * * * 6 * * 172.16.23.253 (172.16.23.253) 99.618 ms

почему может изменяться TTL?

если сделать ping 194.х.х.х (веб-сервер нашего корпуса), то получается такое:

Обмен пакетами с 194.х.х.х по 32 байт:

Ответ от 194.х.х.х: число байт=32 время=1мс TTL=63
Ответ от 194.х.х.х: число байт=32 времяОтвет от 194.х.х.х: число байт=32 времяОтвет от 194.х.х.х: число байт=32 время

при этом в таблицу arp того компа, с которого пинг пускаешь, добавляется запись для 194.х.х.х (после первого же пинга)

посмотреть на 194.х.х.х разумеется нельзя, кто нас туда пустит. тем не менее надо что то ответить, почему первые 2 пинга возвращаются с ТТЛ=63?

буду благодарен за идеи

rain87
03.06.09 21:27:31 MSD

e000xf000h ★
( 03.06.09 21:41:15 MSD )
Ответ на: комментарий от e000xf000h 03.06.09 21:41:15 MSD

Поле Время жизни (Time to Live = TTL) занимает один байт и означает предельный срок, в течение которого пакет может перемещаться по сети. Время жизни данного пакета измеряется в секундах и задается источником передачи. На маршрутизаторах и в других узлах сети по истечении каждой секунды из текущего времени жизни вычитается единица; единица вычитается и в том случае, когда время задержки меньше секунды. Поскольку современные маршрутизаторы редко обрабатывают пакет дольше, чем за одну секунду, то время жизни можно считать равным максимальному числу узлов, которые разрешено пройти данному пакету до того, как он достигнет места назначения. Если параметр времени жизни станет нулевым до того, как пакет достигнет получателя, этот пакет будет уничтожен. Время жизни можно рассматривать как часовой механизм самоуничтожения. Значение этого поля изменяется при обработке заголовка IP-пакета.

e000xf000h ★
( 03.06.09 21:43:41 MSD )
Ответ на: комментарий от e000xf000h 03.06.09 21:43:41 MSD

e000xf000h ★
( 03.06.09 21:45:33 MSD )

Я точно не уверен. Но может он сначала попытался выйти через какой-то маршрутизатор. Маршрутеризатор понял что пакет надо вернуть обратно в локальную сеть, в которой находится пингуемый компьютер. А после этого твой компьютер догадался, что можно направлять пинги напрямую в обход маршрутеризатора.

Соответстенно там где пакет проходил через один лишний узел TTL меньше на 1

kol65536
( 03.06.09 21:49:45 MSD )
Ответ на: комментарий от e000xf000h 03.06.09 21:43:41 MSD

e000xf000h, а вы вопрос мой вообще читали? что такое ТТЛ я вроде как не спрашивал, благо и сам знаю. я спрашивал почему он меняется, и всегда одинаково — первые 2 пинга возвращаются с ТТЛ=63, все следующие — 64. если остановить пинг и минут через 10 опять попробовать — опять первые 2 будут 63, следующие — 64

rain87
( 03.06.09 21:51:33 MSD ) автор топика
Ответ на: комментарий от rain87 03.06.09 21:51:33 MSD

А известна топология сети? Мне кажется трудно ответить на вопрос о том какие должны быть TTL и почему не зная топологии.

kol65536
( 03.06.09 21:58:39 MSD )

очевидно же: там где-то венда. это баги, да.

MoRoZ
( 03.06.09 21:59:41 MSD )
Ответ на: комментарий от rain87 03.06.09 21:51:33 MSD

>вы вопрос мой вообще читали?

>я спрашивал почему он меняется

Ты спросил, я тебе ответил, что-то не так?

e000xf000h ★
( 03.06.09 22:00:21 MSD )
Ответ на: комментарий от rain87 03.06.09 21:51:33 MSD

>первые 2 пинга возвращаются с ТТЛ=63, все следующие

e000xf000h ★
( 03.06.09 22:02:16 MSD )
Ответ на: комментарий от e000xf000h 03.06.09 21:43:41 MSD

согласно этой логике дело в задержке

andreas90
( 03.06.09 22:02:36 MSD )

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

kol65536
( 03.06.09 22:04:35 MSD )
Ответ на: комментарий от kol65536 03.06.09 21:58:39 MSD

>А известна топология сети? Мне кажется трудно ответить на вопрос о том какие должны быть TTL и почему не зная топологии.

в том то и проблема 🙁 мне тоже трудно ответить на этот вопрос, ничего не зная о сети. экстрасенсорными способностями к сожалению не отличаюсь. но преподу пофиг, упёрся и чё хочешь то и делай

есть предположение что 10.64.255.254 и 194.х.х.х это одна и та же машина, причём оба эти интерфейса смотрят в одну сеть (буквально в один свич воткнуты). однако хз чем это предположение может помочь

ты хочешь сказать что первые 2 пакета там стабильно по секунде ждут непонятно чего? не смешно

rain87
( 03.06.09 22:05:32 MSD ) автор топика
Ответ на: комментарий от andreas90 03.06.09 22:02:36 MSD

Да нету там нигде задержки больше 1с. Посмотрите время ответа пингов — 1мс.

kol65536
( 03.06.09 22:06:01 MSD )

serji@localhost:~$ ping 195.94.224.3 PING 195.94.224.3 (195.94.224.3) 56(84) bytes of data. 64 bytes from 195.94.224.3: icmp_seq=1 ttl=59 time=6.52 ms 64 bytes from 195.94.224.3: icmp_seq=2 ttl=59 time=10.6 ms 64 bytes from 195.94.224.3: icmp_seq=3 ttl=59 time=5.33 ms 64 bytes from 195.94.224.3: icmp_seq=4 ttl=59 time=5.23 ms ^C --- 195.94.224.3 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3004ms rtt min/avg/max/mdev = 5.233/6.938/10.658/2.207 ms serji@localhost:~$ tracepath 195.94.224.3 1: 192.168.20.135 (192.168.20.135) 0.168ms pmtu 1500 1: 192.168.20.129 (192.168.20.129) 6.372ms 1: 192.168.20.129 (192.168.20.129) 6.368ms 2: 77.108.96.169 (77.108.96.169) 8.627ms 3: 62.117.100.166 (62.117.100.166) 10.822ms 4: dul-iki.comcor.ru (62.117.100.194) 9.900ms 5: 62.117.100.154 (62.117.100.154) 11.505ms asymm 3 6: 77.108.101.154 (77.108.101.154) 11.899ms asymm 4 7: switch.westcall.ru (195.94.226.33) 10.812ms asymm 5 8: ns2.westcall.ru (195.94.224.3) 10.923ms reached Resume: pmtu 1500 hops 8 back 59

e000xf000h ★
( 03.06.09 22:06:08 MSD )
Ответ на: комментарий от e000xf000h 03.06.09 22:06:08 MSD

Resume: pmtu 1500 hops 8 back 59

e000xf000h ★
( 03.06.09 22:07:01 MSD )
Ответ на: комментарий от e000xf000h 03.06.09 22:07:01 MSD

e000xf000h, ты(вы?) случаем не мой препод? 🙂 лаконичность у вас схожа

rain87
( 03.06.09 22:18:57 MSD ) автор топика
Ответ на: комментарий от rain87 03.06.09 22:18:57 MSD

>ты(вы?) случаем не мой препод?

>лаконичность у вас схожа

Спасибо, я не специально.

e000xf000h ★
( 03.06.09 22:32:10 MSD )
Ответ на: комментарий от rain87 03.06.09 22:05:32 MSD

> есть предположение что 10.64.255.254 и 194.х.х.х это одна и та же машина, причём оба эти интерфейса смотрят в одну сеть (буквально в один свич воткнуты). однако хз чем это предположение может помочь

Ну как раз это предположение помочь может. Рутер при таком раскладе по идее пошлёт редирект (http://en.wikipedia.org/wiki/ICMP_Redirect_Message) хосту.

До того как хост получит его, пакеты идут через 10.64.255.254 (+1 хоп, TTL-=1). После получения редиректа, пакеты перенаправляются на 194. напрямую, минуя 10.64.255.254 (лишнего хопа нет, TTL не уменьшается).

DrLivsy
( 03.06.09 22:33:27 MSD )
Ответ на: комментарий от DrLivsy 03.06.09 22:33:27 MSD

логично, я оже об этом пдумал, но где тогда редирект-сообщение?

Den0k ★
( 03.06.09 22:54:46 MSD )
Ответ на: комментарий от DrLivsy 03.06.09 22:33:27 MSD

спс за ответ, но я не совсем понимаю как оно работает в моём случае
вот сценарий:

The ICMP Redirect message is only sent in the following situation:

1. Host A is sending a packet to Host B. Host A’s default IP router is router R1. Because Host B is a remote host, Host A forwards the packet destined for Host B to its default router R1.
2. R1 checks its routing table and finds that the next hop for the route to the network for Host B is router R2.
3. If Host A and R2 are on the same network that is also directly attached to R1, an ICMP Redirect message is sent to Host A informing it that R2 is the better route when sending to Host B.
4. Router R1 then forwards the IP datagram to R2.
5. Host A adds a host route to its routing table for Host B’s IP address with router R2’s IP address as the forwarding address. Subsequent datagrams from Host A to Host B are forwarded by means of router R2.

пункт 3 — If Host A and R2 are on the same network — в моём случае мой комп находится в сети 10.64.0.0/16, а R2 (который в моём случае является и Host B, 194.х.х.х) — в другой сети. и соответственно пункт 5 никак не может выполнится

rain87
( 03.06.09 23:00:54 MSD ) автор топика
Ответ на: комментарий от rain87 03.06.09 23:00:54 MSD

Есть такое понятие, shared medium, когда на одном к примеру эзернет сегменте сидят несколько различных ip подсеток. Вот, почитай, в принципе вроде здесь http://book.chinaunix.net/special/ebook/oreilly/Understanding_Linux_Network_I. как раз твой случай описан.

DrLivsy
( 04.06.09 00:02:05 MSD )
Ответ на: комментарий от Den0k 03.06.09 22:54:46 MSD

так это проверить можно только tcpdump’ом, до пинга оно не доходит

DrLivsy
( 04.06.09 00:05:16 MSD )
Ответ на: комментарий от rain87 03.06.09 23:00:54 MSD

а пробовал tcpdump глядеть что по интерфейсу при пинге проходит? нужно нечто вроде

tcpdump -n -v ‘icmp’

tcpdump -n -v -X ‘icmp’

и глядеть содержимое. опять же traceroute до узла полезно сделать.

iero
( 04.06.09 00:12:36 MSD )
Ответ на: комментарий от iero 04.06.09 00:12:36 MSD

tcpdump не канает. админских прав на машины нет, а к 194.х.х.х вообще доступа нет

traceroute идёт за 2 хопа, 10.64.255.254 и потом 194.х.х.х

>Есть такое понятие, shared medium, когда на одном к примеру эзернет сегменте сидят несколько различных ip подсеток. Вот, почитай, в принципе вроде здесь http://book.chinaunix.net/special/ebook/oreilly/Understanding_Linux_Network_I. как раз твой случай описан.

очень похоже на мой случай. как я понимаю, дело происходит таким макаром: есть А (мой комп, 10.64.0.1 к примеру), Б (мой шлюз, 10.64.255.254, который знает где 194.х.х.х), В (194.х.х.х, у него в качестве маршрута на 10.64.0.0/16 прописан Б). все 3 компа включены в один свич

когда А посылает первый пинг на В(194.х.х.х), он идёт к Б(10.64.255.254), который соображает что А и В находятся в shared media, и говорит А чтоб тот говорил с В напрямую. при этом, допустим, он SNAT-ит этот пинг и пересылает его на В. В отвечает через Б, ТТЛ=63

А посылает АРП запрос, узнаёт мак В. и посылает второй пинг уже напрямую В. В отвечает через Б (поскольку 10.64.0.0/16 у него в роутах прописана на Б), Б аналогично соображает что А и В находятся в shared media, и отсылает В редирект. второй пинг проходит с ТТЛ=63

А посылает третий пинг, напрямую В. к этому времени В уже тоже узнал мак А и отвечает напрямую, ТТЛ=64. все последующие пинги аналогичные

похоже на правду?

rain87
( 04.06.09 00:53:02 MSD ) автор топика
Ответ на: комментарий от rain87 04.06.09 00:53:02 MSD

Вроде так. За исключением того, что Б не SNAT-ит ничего, он просто форвардит пакет по таблице на В. И сообщение-редирект по идее приходит только на A. Почему это проходит спустя 2 пинга — хз.

DrLivsy
( 04.06.09 01:11:42 MSD )
Ответ на: комментарий от DrLivsy 04.06.09 01:11:42 MSD

>Вроде так. За исключением того, что Б не SNAT-ит ничего, он просто форвардит пакет по таблице на В. И сообщение-редирект по идее приходит только на A. Почему это проходит спустя 2 пинга — хз.

я для этого и написал что он снатит. если б он просто форвардил, то по идее только один пинг был 63. а если снат, то вроде как раз 2

хотя нафиг снат когда прописаны роуты — загадка конечно. но у нас в универе всё можно ожидать, вполне может быть что так и есть

rain87
( 04.06.09 01:34:56 MSD ) автор топика
Ответ на: комментарий от rain87 04.06.09 01:34:56 MSD

в общем про SNAT я тупанул, ночью дело было. понятно что снат он не будет редиректить, иначе глупость может получиться

вопрос теперь стоит ребром — почему именно в начале именно 2 ТТЛа по 63?

если ставить его пинговать, скажем, на полчасика, то каждые минут 10 проскакивает один ТТЛ=63, т.е. чётко вписывается в теорию про ICMP REDIRECT. но в самом начале 2 ТТЛа по 63, и вопрос именно про них. куда нить ещё ткнёте?

rain87
( 04.06.09 12:25:25 MSD ) автор топика

доброго времени суток. отпишусь таки, на всякий пожарный

препод сёдня соизволил дать ответ на вопрос, заданный в начале топика. привожу ответ дословно (в меру своей памяти):

«ТТЛ изменяется из-за того, что в сети находится реальный ИП. Первый пакет он пытается вытолкнуть наружу, но потом раздупляется что он находится в одной сети с ним, и шлёт напрямую. А почему 2 раза? А потому что винда так работает с ARP кешем, и не успевает до второго пинга. А если сеть будет сильно загружена, то тогда второй пинг будет 64»

короче бред редкостный. особенно порадовал ещё один его изыск на тему, почему винда отсылает пакеты с ТТЛ=128, а линух — с ТТЛ=64: «а линух принимает 128, а что такое 128 он не знает, он знает 64, вот и посылает»

почему _на самом деле_ 2 первых пинга возвращаются с ТТЛ=63, я так и не разобрался. ересь про то что винда что то там не успевает легко опровергается двумя одиночными пингами с разрывом секунд 10 (оба приходят с ТТЛ=63). да и собсно причём тут винда, если это ответные пинги с 194.х.х.х? ))

ноут свой я к сети подключал, снифером смотрел. действительно, первые 2 пинга возвращаются от шлюза, с маком шлюза, следующие пакеты — с маком от 194.х.х.х. шлюз действительно высылает ICMP_REDIRECT, правда я так и не уловил закономерности — иногда он приходил через 2 пинга, иногда через 3

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

forum.lissyara.su

Правила форума
Убедительная просьба юзать теги [cоde] при оформлении листингов.
Сообщения не оформленные должным образом имеют все шансы быть незамеченными.

Первое новое сообщение • 12 сообщений • Страница 1 из 1
treycom проходил мимо Сообщения: 2 Зарегистрирован: 2010-12-18 10:50:05

Проблема с сетевкой ttl странности

Добрый день коллеги, прошу помощи!

В моей практике такого еще не было, суть в том, что с некоторых пор начал пропадать пинг до сервера
с 8.0-RELEASE FreeBSD. Сервер смотрит одним интерфейсом в локальную сеть и имеет ip 10.40.40.40.1 а вторым в инет.
Проблема появилась не так давно, до этого работал 3 месяца без сбоев.
Когда Я начинаю пинговать до сервака из локальной сети до интерфейса 10.40.40.1 до пинг имеет ttl 127 и нифига ничего не работает(апач, днс,фтп). Когда же Я самого сервера начинаю пинговать какой нить компьютер из сегмента локальной сети к примеру 10.40.40.4, то у пинга с домашнего компа до сервера с фряхой ttl меняется резко до 63 и всё начинает работать(апач, фтп,днс).

На рисунке видно как пингуется сервер, ttl 127-> начинаю пинговать до с фряхи до др. сервака и ttl поменялась, пинга пропала и ttl обратно поменялась на 127. Как будто интерфейс нужна какая то взбучка
Написал скрипт, чтобы он постояно пинговал какой нить другой сервер. Но не прокатывает всё равно.

Внутренняя сетевая была подключена в циску С2960 потерь на интерфейсе ничего нету. Подключил в другую циску, такая же муть приключается, т.е. не из за коммутаторов.

Может ли быть такое, что кто то из локальной сети себе ставит такой же IP ? И на моём сервере приключается такая же муть. Ядро не пере собирал, фаерволл не подключен.

bge0: flags=8843 metric 0 mtu 1500 options=9b ether 00:18:fe:28:4e:08 inet 10.40.40.1 netmask 0xffff0000 broadcast 10.40.255.255 media: Ethernet autoselect (100baseTX ) status: active bge1: flags=8843 metric 0 mtu 1500 options=9b ether 00:18:fe:28:4e:09 inet 77.233.172.131 netmask 0xfffffff8 broadcast 77.233.172.135 media: Ethernet autoselect (1000baseT ) status: active lo0: flags=8049 metric 0 mtu 16384 options=3 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff000000 
teleset74# netstat -rn Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 77.233.172.129 UGS 3 4717 bge1 10.40.0.0/16 link#1 U 0 1882 bge0 10.40.40.1 link#1 UHS 0 111 lo0 77.233.172.128/29 link#2 U 0 0 bge1 77.233.172.131 link#2 UHS 0 0 lo0 127.0.0.1 link#3 UH 0 35 lo0 Internet6: Destination Gateway Flags Netif Expire ::1 ::1 UH lo0 fe80::%lo0/64 link#3 U lo0 fe80::1%lo0 link#3 UHS lo0 ff01:3::/32 fe80::1%lo0 U lo0 ff02::%lo0/32 fe80::1%lo0 U lo0 

Последний раз редактировалось f_andrey 2011-01-12 8:03:04, всего редактировалось 1 раз.
Причина: Автору, выбирайте пожалуйста раздел соответствуюший тематике вашего сообщения

Почему при пинге выдаёт высокий TTL?

В нормальном состоянии маршрутизатор (TPLINK) пингуется с 64 TTL, сеть работает без проблем.
В некоторые моменты времени пинг выдаёт TTL 254, время пинга не увеличивается, сетка падает, инета нет. До перезагрузки устройства. К остальным устройствам пинг обычный

  • Вопрос задан более трёх лет назад
  • 14638 просмотров

Комментировать
Решения вопроса 1

Energoblock

Константин ™ @Energoblock

Иногда такой TTL появляется при переводе устройства в Recovery mode.
Если роутер делает так самостоятельно, то лучше обновить прошивку до самой последней версии, сбросить к настройкам по-умолчанию и настроить заново.

Либо подключиться к консольному порту на плате роутера и напрямую смотреть логи в момент перехода в такое состояние.

Ответ написан более трёх лет назад
Комментировать
Нравится Комментировать
Ответы на вопрос 2

MaxDukov

впишусь в проект как SRE/DevOps.

TTL — это «время» (в кавычках — потому что не в секундах, а в переходах) жизни пакета. сколько маршрутизаторов он сможет пройти, прежде чем «помрет».
поле 8-и битное, так что максимальный TTL = 255. Большой ttl на работоспособность сети влиять никак не должен — пакет в любом случае умрет, достигнув точки назначения. Стандартный TTL = 64.
изменение TTL скорее всего вызвано тем, что пингуете с разных устройств/ ОС.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *