traceroute и ping из школьной сети
Использовать su , дополнительно с - опция (также известный как -l или --login) заставить оболочку вести себя как оболочка входа в систему (другая инициализация).
Вы не можете действительно отправить его в фон, так как оболочка того пользователя ловит сигнал SIGTSTP, который используется для перемещения его в фон и выходы (обычно). Вместо этого Вы могли бы интересоваться оконечным мультиплексором как tmux или screen
Вы могли бы также хотеть использовать vlock на консолях, когда Вы не используете их в течение более длительного времени.
Да, вполне возможно, что ваш брандмауэр блокирует успешное выполнение трассировки. Чтобы понять, почему это не удается, лучше обратиться к справочной странице traceroute .
отрывок
Эта программа пытается отследить маршрут, по которому IP-пакет будет следовать к некоторому интернет-хосту, запуская пробные пакеты с небольшим ttl (время жизни), а затем ожидая ответа ICMP «время истекло» от шлюза.
Мы начинаем наши пробы с ttl, равным единице, и увеличиваем на единицу, пока не получим ICMP «порт недоступен» (или сброс TCP), что означает, что мы добрались до «хоста» или достигли максимального значения (по умолчанию 30 хмель).
Три зонда (по умолчанию) отправляются при каждой настройке ttl, и печатается строка, показывающая ttl, адрес шлюза и время приема-передачи каждого зонда. По запросу после адреса может быть указана дополнительная информация. Если ответы на зондирование поступают от разных шлюзов, будет напечатан адрес каждой отвечающей системы. Если нет ответа в течение 5,0 секунд (по умолчанию), для этого зонда печатается «*» (звездочка).
Звездочки, которые вы видите, - это серверы, через которые маршрутизируются ваши пакеты, через которые истекает время ожидания (5,0+ секунд), и поэтому traceroute по умолчанию выводит * .
Другая вещь, которая мешает работе traceroute , - это когда сервер / маршрутизатор настроен на то, чтобы не отвечать на пакеты ICMP (также известные как ping).Без ответа на эхо-запросы уловка `traceroute, заставляющая каждый сервер увеличивать TTL (время жизни) для каждого пакета, который он отправляет фактическому месту назначения, не удастся.
ПРИМЕЧАНИЕ: Об этом даже есть предупреждение на странице руководства traceroute .
выдержка
В современной сетевой среде традиционные методы трассировки не всегда могут быть применимы из-за широкого распространения межсетевых экранов. Такие межсетевые экраны фильтруют «маловероятные» порты UDP или даже эхо ICMP. Чтобы решить эту проблему, реализованы некоторые дополнительные методы трассировки (включая tcp), см. СПИСОК ДОСТУПНЫХ МЕТОДОВ ниже. Такие методы пытаются использовать определенный протокол и порт источника / назначения, чтобы обойти брандмауэры (чтобы брандмауэры видели, что это только начало разрешенного типа сетевой сессии).
Таким образом, в зависимости от того, как вы настроили traceroute , он может использовать пакеты ICMP, UDP или даже TCP для получения ответа от различных систем, которые обрабатывают маршрутизацию ваших пакетов из точки A в точку B. .
Снова проконсультируясь со страницей руководства traceroute , обратите внимание на эти 3 опции:
-I, --icmp
Use ICMP ECHO for probes
-T, --tcp
Use TCP SYN for probes
-U, --udp
Use UDP to particular destination port for tracerouting (instead
of increasing the port per each probe). Default port is 53 (dns).
Конечно, есть и другие, см. СПИСОК ДОСТУПНЫХ МЕТОДОВ для полного списка.
Так что насчет curl?
Как это часто бывает с пограничными межсетевыми экранами, например, в бизнесе или университете, разрешен исходящий трафик только через порты 80 (HTTP) и 443 (HTTPS).Вполне вероятно, что пакеты ICMP ECHO_REQUEST отбрасываются университетским межсетевым экраном, что объясняет, почему вы получаете звездочки, когда начинаете попадать на серверы за пределами университетской сети.
При выходе пакетов через порт 80 вы можете воспользоваться этим и указать traceroute использовать TCP через конкретный порт, в данном случае 80, чтобы получить то, что вы хотите.
Пример
$ sudo traceroute -T -p 80 www.google.com
traceroute to www.google.com (173.194.46.81), 30 hops max, 60 byte packets
1 byers.bubba.net (192.168.1.6) 3.265 ms 3.236 ms 3.213 ms
2 * * *
3 24.93.10.17 (24.93.10.17) 21.359 ms 35.414 ms 48.045 ms
4 rdc-72-230-153-79.wny.east.twcable.com (72.230.153.79) 48.064 ms 48.044 ms 54.523 ms
5 rdc-72-230-153-243.wny.east.twcable.com (72.230.153.243) 70.067 ms 70.013 ms 73.312 ms
6 be35.cr0.chi10.tbone.rr.com (107.14.19.104) 73.201 ms be45.cr0.chi10.tbone.rr.com (107.14.19.106) 62.289 ms be35.cr0.chi10.tbone.rr.com (107.14.19.104) 65.485 ms
7 ae0.pr1.chi10.tbone.rr.com (107.14.17.192) 62.056 ms 48.685 ms ae1.pr1.chi10.tbone.rr.com (107.14.17.194) 32.193 ms
8 * * *
9 209.85.254.130 (209.85.254.130) 42.624 ms 45.159 ms 42.777 ms
10 * * *
11 ord08s11-in-f17.1e100.net (173.194.46.81) 48.036 ms 42.543 ms 44.751 ms
Ваш школьный брандмауэр, вероятно, блокирует большую часть исходящего трафика на портах, отличных от TCP / 80, который является IP-портом по умолчанию для веб-трафика.
В частности, ping и (в большинстве случаев) traceroute отправляют пакет ICMP ECHO_REQUEST , и многие компании и учебные заведения блокируют весь трафик ICMP через свои брандмауэры, поскольку его можно использовать для получения информации о сетевых устройствах. за брандмауэром.
Итак, насколько я понимаю, брандмауэр моей школьной сети блокирует мой сервер от связи с внешним миром. Это правильно?
Нет, я думаю, он может блокировать почти весь трафик, но разрешить хотя бы TCP-порт 80 . traceroute в Linux по умолчанию используется UDP , ping использует ICMP , поэтому, как вы видите, этот трафик был заблокирован брандмауэр.
Как работает сценарий оболочки, если брандмауэр блокирует доступ внешнего мира к моему серверу?
Как указано выше, когда вы можете получить результат от curl www.gooogle.com , Я уверен, что межсетевой экран разрешает хотя бы TCP-порт 80 и UDP-порт 53 (для работы DNS). Вы можете выполнить простую проверку, чтобы подтвердить это, используя traceroute , но используя TCP :
traceroute -T -p 80 www.google.com
Вот мой результат:
$ sudo traceroute -T -p 80 www.google.com
[sudo] password for cuonglm:
traceroute to www.google.com (74.125.128.103), 30 hops max, 60 byte packets
1 172.16.50.253 (172.16.50.253) 0.133 ms 0.133 ms *
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 XXX.XXX (Y.Y.Y.Y) 13.954 ms XXX.XXX (Y.Y.Y.Y) 14.198 ms X.X.X.X (123.29.10.110) 14.140 ms
9 unknown.telstraglobal.net (134.159.208.165) 85.353 ms 85.349 ms 85.338 ms
10 i-0-2-0-3.hkth-core01.bi.telstraglobal.net (202.84.153.234) 85.780 ms 85.765 ms 85.748 ms
11 i-0-0-0-3.hkth12.bi.telstraglobal.net (202.84.153.182) 85.723 ms i-0-0-0-1.hkth12.bi.telstraglobal.net (202.84.153.150) 86.731 ms i-0-0-0-2.hkth12.bi.telstraglobal.net (202.84.153.178) 85.305 ms
12 72.14.221.126 (72.14.221.126) 51.635 ms 51.535 ms 51.177 ms
13 209.85.241.58 (209.85.241.58) 51.137 ms 51.372 ms 51.086 ms
14 209.85.253.71 (209.85.253.71) 51.601 ms 209.85.253.69 (209.85.253.69) 52.172 ms 51.888 ms
15 * * *
16 hg-in-f103.1e100.net (74.125.128.103) 51.639 ms 52.632 ms 51.670 ms
Урок для изучения
При создании правила для брандмауэра (или аналогичных устройств безопасности), золотое правило: « Запретить все, разрешить особенности »