Openwrt обход блокировки tor
Варианта я видел два: 1-й попроще - поднять прокси-сервер на VPS, и как-нибудь через iptables на роутере завернуть на него нужный трафик. 2-й - поднять на роутере tor, и перенаправлять на него то, что нужно. После небольших раздумий, решил попробовать настроить по второму варианту, о чем тут и напишу, он все-таки более универсальный (хоть и более тормозной). Однако, следует учесть, что тор довольно требователен к ресурсам роутера.
В интернете куча статей по настройкам, но там в основном о полном проксировании отдельной wifi точки, а мне не хотелось забивать себе голову, поэтому пошел по знакомой схеме (tor+privoxy).
Итак в openwrt ставим пакеты tor и privoxy:
opkg install tor privoxy
tor в состоянии работать из коробки, поэтому можно сразу запускать (и делать enable если нужен автостарт):
/etc/init.d/tor start
/etc/init.d/tor enable
Тут нужно заменить строку с параметром listen-address:
И добавить еще одну в конец конфига:
192.168.1.1 - адрес роутера, если у вас другая подсеть нужно будет поменять и опцию permit-access;
9050 - стандартный порт tor-a
Обратите внимание, что если у вас нет такой папки с конфигом privoxy, значит у вас другая версия, см. на вики.
Запускаем все это дело:
/etc/init.d/privoxy start
/etc/init.d/privoxy enable
Далее я с переменным успехом гуглил и читал статьи о iptables, прокси-серварах и так далее и выяснил в итоге лишь то, что нужно создавать pac файл с настройками прокси для разных доменов. Сказано - сделано:
function FindProxyForURL(url, host) if (shExpMatch(host, "*.nyaa.se"))
return "PROXY 192.168.1.1:8118";
>
return "DIRECT";
>
Файл нужно назвать proxy.pac. Я повесил его отдавать на апач, чтобы если что, можно было использовать на разных машинах и системах. В .htaccess нужно добавить строку:
AddType application/x-ns-proxy-autoconfig .pac
/.config/chromium-flags.conf строку выше (вместе с двумя черточками вначале) и voila, все работает.
Нужно простое и прозрачное для пользователей решение, которое, будучи единожды настроенным, позволит просто пользоваться интернетом, не задумываясь, что же сегодня заблокировали по заявкам очередных копирастов-плагиаторов.
Сама собой напрашивается мысль о том, чтобы обходить блокировку уже на домашнем маршрутизаторе.
Собственно, поднять на маршрутизаторе и гонять весь траффик через VPN несложно, а у некоторых VPN-провайдеров есть даже пошаговые инструкции по настройке OpenWrt на работу с ними.
Но скорости VPN сервисов все же отстают от скоростей доступа в интернет, да и VPN-сервис либо стоит денег, либо имеет массу ограничений, либо необходимость регулярного получения новых логинов. С точки зрения оптимизации затрат, как финансовых, так и временных, предпочтительней выглядит Tor, но его скорость еще хуже, а гонять через Tor торренты и вовсе идея не лучшая.
Выход — перенаправлять в VPN/Tor только траффик блокируемых ресурсов, пропуская остальной обычным путем.
Внимание: данная схема не обеспечивает анонимности просмотра заблокированных сайтов: любая внешняя ссылка раскрывает ваш настоящий IP.
Конкретная реализация на OpenWrt приведена в конце статьи. Если не интересуют подробности и альтернативные варианты решения, то можно листать сразу до нее.
Туннелирование и перенаправление траффика в туннель
Настройка VPN или Tor'а сложностей представлять не должна. Tor должен быть настроен, как прозрачный proxy (либо настроить связку из tor и tun2socks). Т.к. конечной целью явлется обход блокировок ркн, то в конфиге Tor'а целесообразно запретить использование выходных узлов на территории РФ ( <ExcludeExitNodes ).
В Tor’а траффик перенаправляется правилом с REDIRECT ’ом на порт прозрачного прокси в цепочке PREROUTING таблицы nat netfilter’а.
Для перенаправления в VPN (или Tor + tun2socks) траффик маркируется в таблице mangle , метка затем используется для выбора таблицы маршрутизации, перенаправляющей траффик на соответствующий интерфейс.
В обоих случаях для классификации траффика используется ipset с хостами, подлежащими (раз)блокировке.
Формирование ipset c (раз)блокируемыми хостами
К сожалению, вариант «загнать все IP из реестра» в ipset не работает как хотелось бы: во-первых в списках присутствуют не все IP адреса блокируемых хостов, во-вторых в попытке уйти от блокировки IP адрес у ресурса может измениться (и провайдер об этом уже знает, а мы – еще нет), ну и в третьих – false positives для находящихся на том же shared hosting’е сайтов.
Городить огород с dpi того или иного вида не очень хочется: как-никак работать это должно на довольно слабом железе. Выход достаточно прост и в какой-то степени элегантен: dnsmasq (DNS сервер, который на маршрутизаторе скорее всего уже установлен) умеет при разрешении имен добавлять ip-адреса в соответствующий ipset (одноименная опция в конфиге). Как раз то, что нужно: вносим в конфиг все домены, которые необходимо разблокировать, и дальше по необходимости dnsmasq сам добавляет в ipset именно тот ip адрес, по которому будет идти обращение к заблокированному ресурсу.
У меня были сомнения, что dnsmasq запустится и будет нормально работать с конфигом в полдесятка тысяч строк (примерно столько записей в реестре после усушки и утряски), однако они к счастью оказались безосновательны.
Ложка дегтя в том, что при обновлении списка dnsmasq придется перезапускать, т.к. по SIGHUP он конфиг не перегружает.
Составление списка доменов
Должно происходить автоматически, насколько это возможно.
Теперь еще об одной ложке дегтя: некоторое провайдеры замечены за тем, что помимо включенных в список ркн сайтов самодеятельно блокируют и официально в списках не значащиеся. При этом блокируют тихой сапой и заглушки не выводят. Так что совсем без ручного привода не обойтись.
Дополнительные замечания
Реализация на OpenWrt (15.05)
Сам маршрутизатор должен быть не самый плохой, особенно при использовании Tor’а. MIPS 400MHz@32MB RAM это тот минимум, который стоит рассматривать.
При наличии USB-порта недостаток встроенного флеша можно компенсировать USB-флешкой (вообще мне представляется достаточно здравой идея не использовать встроенный флеш для регулярно перезаписываемых данных).
Штатно в прошивках OpenWrt содержится урезанный dnsmasq, не умеющий ipset. Необходимо заменить его на dnsmasq-full.
Если вы собираете пакеты для себя вручную, либо хотите встроить этот пакет прямо в прошивку то на этапе конфигурации прошивки OpenWRT нужно выбрать:
для сборки в виде пакета, или
для того чтобы встроить пакет прямо в прошивку. Затем собираете прошивку способом аналогичным описанному в моей предыдущей статье .
Несколько подводных камней, которые могут возникнуть после инсталляции пакета.
1. Обязательно настройте и синхронизируйте время чеpез ntp. Tor использует системное время для каких то своих действий. Неправильная дата может привести к проблемам при старте tor или к его не корректной работе.
2. При установке tor должен создать пользователя tor и группу tor. При создании группы инсталлятор у меня допустил ошибку и в файле /etc/group не поставил перенос строки для группы tor. Скорее всего это у меня единичный баг, однако будьте внимательны.
3. Проверьте все права на файлы необходимые tor они должны иметь маску 755 и принадлежать tor:tor
Настройка TOR.
Открываем конфигурационный файл /etc/tor/torrc и правим:
3. Если по каким то причинам tor не стартует воспользуетсь опцией Log для выяснения проблемы.
Собственно больше никаких настроек не нужно, и можно запускать tor.
Запуск Tor
Запускаем тор следующей командой:
Если tor уже запущен либо при старте возникают ошибки вида:
[warn] Could not bind to 127.0.0.1:9050: Address already in use. Is Tor already running?
необходимо остановить tor:
И запустить его заново как написано выше.
Если лог включен, то признаком успешного запуска и подключения к сети tor будет строка:
Feb 21 19:12:17.034 [notice] Tor has successfully opened a circuit. Looks like client functionality is working.
Feb 21 19:12:17.035 [notice] Bootstrapped 100%: Done.
Далее достаточно прописать адрес и порт указанный опцией SocksListenAddress как socks сервер в браузере или любой другой программе на вашем ПК.
Однако есть ряд программ которые не умеют работать с socks протоколом. Эту проблему можно решить средствами самого tor + iptables. Для этого необходимо включить в tor режим прозрачного проксирования. В таком случае на подключенных к роутеру машинах вообще никаких настроек делать не нужно. Весь трафик будет сразу проходить через tor.
Использование прозрачного прокси в Tor
Для этого в конфигурационном файле /etc/tor/torrc правим:
AutomapHostsOnResolve 1
TransPort 9040
DNSPort 53
Тем самым прозрачный прокси будет слушать порт 9040.
killall -9 tor
/etc/init.d/tor start
iptables v1.4.6: unknown option `--to-ports'
Установить пакет можно тривиально выполнив
opkg install kmod-ipt-nat-extra
А можно собрать в своем репозитории или включить этот пакет сразу в прошивку. В конфигураторе OpenWrt этот пакет находится в
-> Network
-> iptables
<M> iptables-mod-nat-extra
iptables -t nat -A PREROUTING -p tcp -d ! 192.168.120.1 --dport 80 -j REDIRECT --to-ports 9040
Тоже делаем и для dns запросов:
iptables -t nat -A PREROUTING -p udp --dport 53 -j REDIRECT --to-ports 53
Остальной udp трафик прийдется либо пропускать без анонимизации, либо резать.
Редактируем конфиги:
/etc/config/firewall
config zone
option name 'tor'
option network 'tor'
option input 'REJECT'
option forward 'REJECT'
option output 'ACCEPT'
config forwarding
option src 'tor'
option dest 'wan'
config rule
option name 'Allow DNS Queries'
option src 'tor'
option dest_port '53'
option proto 'tcpudp'
option target 'ACCEPT'
config rule
option name 'Allow DHCP request'
option src 'tor'
option src_port '67-68'
option dest_port '67-68'
option proto 'udp'
option target 'ACCEPT'
/etc/config/network
config interface 'tor'
option ifname 'wlan0-1'
option proto 'static'
option ipaddr '192.168.2.1'
option netmask '255.255.255.0'
/etc/config/wireless
config wifi-iface
option device 'radio0'
option network 'tor'
option mode 'ap'
option macaddr '00:01:4a:9f:6f:3c'
option encryption 'psk2'
option key '123456'
option ssid 'Tor_trans'
/etc/tor/torrc
VirtualAddrNetworkIPv4 10.192.0.0/10
AutomapHostsOnResolve 1
TransPort 9040
TransListenAddress 192.168.2.1
DNSPort 53
DNSListenAddress 192.168.2.1
iptables -F
iptables -t nat -F
iptables -t nat -A PREROUTING -i $_int_if -p udp --dport 53 -j REDIRECT --to-ports 53
iptables -t nat -A PREROUTING -i $_int_if -p tcp --syn -j REDIRECT --to-ports $_trans_port
So that's why I'm doing it, but I guess there are lots of other situations where a transparent tor proxy can be usefull.
info about Tor: http://www.torproject.org/
info about the transparent proxy feature of Tor: https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/TransparentProxy I set up an "Anonymizing Middlebox" Setup:
I used a wgt634u with a recent backfire-svn checkout (r24007) it's a broadcom chip and I run a linux-2.6 kernel. I guess the stable backfire-release and any other architekture should work too but your router should have at least 32MB RAM (my tor-daemon needs about 13MB RAM) and enough Flash (8MB are enough).
I use only the wifi ("ath0") interface with own firewall-zone "tor" and restricted the access to the dhcp-server and tor-proxy only. But it will work with "br-lan" as well. so here are the relevant sections of my config files: So everything is working so far.
The next thing I want to achieve is running a open captive portal an this device so that I can give the users some information. About Tor, Openwrt and about why I'm running this hotspot.
I took a look at nodogsquash but its firewall-rules doesn't seem to work with the redirections for the transparent proxy. So any feedback on the HOWTO, or ideas about setting up a captive portal in this case, are appreciated!
Нужно простое и прозрачное для пользователей решение, которое, будучи единожды настроенным, позволит просто пользоваться интернетом, не задумываясь, что же сегодня заблокировали по заявкам очередных копирастов-плагиаторов.
Сама собой напрашивается мысль о том, чтобы обходить блокировку уже на домашнем маршрутизаторе.
Собственно, поднять на маршрутизаторе и гонять весь траффик через VPN несложно, а у некоторых VPN-провайдеров есть даже пошаговые инструкции по настройке OpenWrt на работу с ними.
Но скорости VPN сервисов все же отстают от скоростей доступа в интернет, да и VPN-сервис либо стоит денег, либо имеет массу ограничений, либо необходимость регулярного получения новых логинов. С точки зрения оптимизации затрат, как финансовых, так и временных, предпочтительней выглядит Tor, но его скорость еще хуже, а гонять через Tor торренты и вовсе идея не лучшая.
Внимание: данная схема не обеспечивает анонимности просмотра заблокированных сайтов: любая внешняя ссылка раскрывает ваш настоящий IP.
Конкретная реализация на OpenWrt приведена в конце статьи. Если не интересуют подробности и альтернативные варианты решения, то можно листать сразу до нее.
Туннелирование и перенаправление траффика в туннель
Настройка VPN или Tor'а сложностей представлять не должна. Tor должен быть настроен, как прозрачный proxy (либо настроить связку из tor и tun2socks). Т.к. конечной целью явлется обход блокировок ркн, то в конфиге Tor'а целесообразно запретить использование выходных узлов на территории РФ ( <ExcludeExitNodes ).
Для перенаправления в VPN (или Tor + tun2socks) траффик маркируется в таблице mangle , метка затем используется для выбора таблицы маршрутизации, перенаправляющей траффик на соответствующий интерфейс.
В обоих случаях для классификации траффика используется ipset с хостами, подлежащими (раз)блокировке.
Формирование ipset c (раз)блокируемыми хостами
Городить огород с dpi того или иного вида не очень хочется: как-никак работать это должно на довольно слабом железе. Выход достаточно прост и в какой-то степени элегантен: dnsmasq (DNS сервер, который на маршрутизаторе скорее всего уже установлен) умеет при разрешении имен добавлять ip-адреса в соответствующий ipset (одноименная опция в конфиге). Как раз то, что нужно: вносим в конфиг все домены, которые необходимо разблокировать, и дальше по необходимости dnsmasq сам добавляет в ipset именно тот ip адрес, по которому будет идти обращение к заблокированному ресурсу.
У меня были сомнения, что dnsmasq запустится и будет нормально работать с конфигом в полдесятка тысяч строк (примерно столько записей в реестре после усушки и утряски), однако они к счастью оказались безосновательны.
Ложка дегтя в том, что при обновлении списка dnsmasq придется перезапускать, т.к. по SIGHUP он конфиг не перегружает.
Составление списка доменов
Должно происходить автоматически, насколько это возможно.
Теперь еще об одной ложке дегтя: некоторое провайдеры замечены за тем, что помимо включенных в список ркн сайтов самодеятельно блокируют и официально в списках не значащиеся. При этом блокируют тихой сапой и заглушки не выводят. Так что совсем без ручного привода не обойтись.
Дополнительные замечания
Реализация на OpenWrt (15.05)
При наличии USB-порта недостаток встроенного флеша можно компенсировать USB-флешкой(вообще мне представляется достаточно здравой идея не использовать встроенный флеш для регулярно перезаписываемых данных).
Штатно в прошивках OpenWrt содержится урезанный dnsmasq, не умеющий ipset. Необходимо заменить его на dnsmasq-full.
Последняя версия: OpenWrt 21.02.0
В данной теме необходимо размещать изображения и логи под спойлером
OpenWrt — встраиваемая операционная система, основанная на ядре Linux, и предназначенная, в первую очередь, для домашних маршрутизаторов. Основные компоненты включают в себя ядро Linux, util-linux, uClibc или musl и BusyBox. Исходный код открытый. Распространяется под лицензией GNU GPL
Проект LEDE разработан на основе линукса, встраиваемый мета-дистрибутив базирующийся на OpenWRT, ориентирован на широкий спектр беспроводных маршрутизаторов SOHO и не-сетевых устройств. “Linux Embedded Development Environment” (Встраиваемая среда разработки линукс).
LEDE отвернулся от материнского проекта в мае 2016 года, с целью продолжить разрабатывать лучшее программное обеспечение в открытой модели управления и поощрение новых разработчиков внести свой вклад и усилия в области развития.
- Данная тема предназначена для обсуждения настроек, процесса установки на ваш маршрутизатор и всего что связано с прошивкой OpenWrt/LEDE.
- В данной теме не обсуждают компиляцию из исходных кодов и пересборку, для этого есть тема Сборка OpenWrt/LEDE из исходных кодов
Настройка TFTP-сервера tftpd-hpa
Установим пакет tftpd-hpa:
содержащий настройки сервера. Приведём его к следующему виду:
TFTP_USERNAME="tftp"TFTP_DIRECTORY="/var/tftp"
TFTP_ADDRESS="0.0.0.0:69"
TFTP_OPTIONS="--ipv4 --secure --create --umask 027 --permissive"
В настройках указаны дополнительные опции:
create разрешает серверу создавать новые файлы,
ipv4 предписывает ему ожидать подключений только на адресах IPv4,
umask предписывает сбрасывать бит записи для группы и все биты доступа для остальных пользователей,
permissive предписывает не проводить никаких проверок прав доступа к файлу сверх производимых операционной системой.
Создадим каталог для tftp-сервера, дадим серверу доступ к каталогу:
sudo mkdir /var/tftp
sudo chown tftp:tftp /var/tftp
Можно также поменять домашний каталог пользователя tftp в файле /etc/passwd на /var/tftp.
Теперь просто прописываем нужные нам ip адреса через gnome network manager и все.
Осталось перезапустить демона, чтобы он начал работу с новым каталогом:
Где найти прошивку для TP-Link TL-WR941N/ND v3.1
На данный момент
Мощность датчика на максимум. Перебрал все каналы. На телефон выдает почему то максимум 65.0 Mbit/s хотя он поддерживает 72 Mbit/s. Родная прошивка выдает ему всегда скорость 130. У DD-WRT тоже с этим проблемы!
Тем устройствам которым положено в режиме N на 40hz работать на всю катушку - присваивается ограниченная скорость. Пока что не могу понять в чем дело.
Убедитесь что в /etc/config/igmpproxy
config phyint
option network wan
option zone wan
option direction upstream
list altnet 192.168.0.0/16
list altnet 172.16.0.0/12
list altnet 10.0.0.0/8
config phyint
option network lan
option zone lan
option direction downstream
А в /etc/config/firewall
config rule
option name 'Allow-IPTV-IGMPPROXY'
option src 'wan'
option proto 'udp'
option dest_ip '224.0.0.0/4'
option target 'ACCEPT'
option family 'ipv4'
option dest 'lan'
config rule
option name 'Allow-IGMP'
option src 'wan'
option proto 'igmp'
option family 'ipv4'
option target 'ACCEPT'
Еще проблема может быть из-из появившейся поддержки IGMP snooping.
/etc/config/network
В разных темах замечал что люди интересовались как выключать wifi в OpenWrt в заданное время, собственно вот небольшая инструкция.
Есть два варианта.
Вариант 1 - через cron.
Для этого нужно перейти в Cистема -> Запланированные задания
И вписать нужную команду в это окно
Вариант 2 - через веб интерфейс.
Это вот такая штука
Но ее нужно установить. Интернет должен быть настроен, чтобы роутеру было откуда качать и устанавливать :)
Понадобятся пакеты: wifischedule, luci-app-wifischedule и luci-i18n-wifischedule-ru
Для установки из веб интерфейса идем в Cистема -> Программное обеспечение
Или через консоль, подключаемся по ssh и даем команды opkg update (обновляем список пакетов) и ставим opkg install luci-app-wifischedule (все остальные пакеты должны сами подтянуться, если не подтянутся, доустановите вручную opkg install wifischedule и opkg install luci luci-i18n-wifischedule-ru)
Вот и все :) Теперь можно переходить в Сервисы -> Wi-Fi планировщик и настраивать расписание работы WIFI
1) Подготовить USB-флешку. На флешке два раздела. Первый на 1 ГБ с файловой системой ext4. Второй — на всё оставшееся пространство тоже с файловой системой ext4.
2) Воткнуть флешку в роутер. Обновить список пакетов и установить необходимые:
opkg install kmod-usb-storage block-mount kmod-fs-ext4
4) Нажать Edit возле sda1, включить Enable this mount, в качестве Mount point выбрать /overlay. Точно так же включить автомонтирование sda2 в качестве /data
В /data можно закачивать торренты и т. п. Это просто раздел под ваши нужды. У меня туда статистика использования трафика собирается, например.
5) Скопировать содержимое /overlay на флешку. В терминале:
mount /dev/sda1 /tmp/extoverlay
tar -C /overlay -cvf - . | tar -C /tmp/extoverlay -xf -
umount /tmp/extoverlay
6) Перезагрузить роутер (если всё получилось, то на странице Software должно прибавиться количество свободного места)
Для любителей микрооптимизации: во-первых, читать это
Если желание оптимизировать ещё не пропало, можно заменить ext4 на F2FS (соответственно вместо kmod-fs-ext4 ставить kmod-fs-f2fs)
Если к использованию F2FS вы не готовы, а желание сэкономить ресурс флешки сильнее страха приключений на пятую точку, то:
— в п.1 после создания на флешке разделов выполнить в терминале:
sudo tune2fs -o journal_data_writeback /dev/sdb1
sudo tune2fs -O ^has_journal /dev/sdb1
sudo e2fsck -f /dev/sdb1
sudo umount /dev/sdb2
sudo tune2fs -o journal_data_writeback /dev/sdb2
sudo tune2fs -O ^has_journal /dev/sdb2
sudo e2fsck -f /dev/sdb2
— в п.4 на вкладке Advanced Settings для обоих разделов вписать в строчку Mount options:
Лично мне такие манипуляции с тюнингом грошовой флешки делать лень.
Настройка обхода блокировок в России и Украине Обход блокировок в России, направляем трафик до заблокированных сайтов через VPN
Предварительные требования:
— прошита OpenWrt 18.06
— установлен веб-интерфейс LuCi
— роутер имеет доступ в Интернет
Впрочем, будет работать и openvpn-openssl. Если вы используете что-то более ранее, чем OpenWrt 18.06, то жизненно необходимо установить openvpn-openssl вместо openvpn-mbedtls.
Отредактировать этот файл, дописав куда-нибудь в его середину строку:
config openvpn antizapret
option enabled 1
option config /etc/openvpn/antizapret-tcp.ovpn
(опять же, способ редактирования конфига оставлен на усмотрение читателя: одному удобно через vi, другому через тот же WinSCP). antizapret-tcp.ovpn — это файл, который вы на прошлом шаге копировали. Если его название изменилось, то, соответственно, исправьте его и тут в конфиге.
то необходимо открыть antizapret-tcp.ovpn текстовым редактором и добавить строкуизменить с 1 на 0
Плюсы:
— через VPN идёт лишь трафик до заблокированных доменов, остальной трафик идёт "напрямую" (нет потери скорости, у вас не меняется IP)
— следствие из предыдущего: трафик небольшой и поддержание бесплатного сервиса не бьёт по карману владельца
Предварительные требования:
— прошита OpenWrt 18.06
— установлен веб-интерфейс LuCi
— роутер имеет доступ в Интернет
Впрочем, будет работать и openvpn-openssl. Если вы используете что-то более ранее, чем OpenWrt 18.06, то жизненно необходимо установить openvpn-openssl вместо openvpn-mbedtls.
3) Заменить содержимое /etc/config/openvpn на:
config openvpn zaborona
option enabled 1
option config /etc/openvpn/zaborona-help.ovpn
(опять же, способ редактирования конфига оставлен на усмотрение читателя: одному удобно через vi, другому через тот же WinSCP). zaborona-help.ovpn — это файл, который вы на прошлом шаге копировали. Если его название изменилось, то, соответственно, исправьте его и тут в конфиге.
то необходимо открыть antizapret-tcp.ovpn текстовым редактором и добавить строкуПлюсы:
— через VPN идёт лишь трафик до заблокированных доменов, остальной трафик идёт "напрямую" (нет потери скорости, у вас не меняется IP)
— следствие из предыдущего: трафик небольшой и поддержание бесплатного сервиса не бьёт по карману владельца
Не забудьте перезапустить dnsmasq:
1) задать пароль администратора (через LuCI)
3) с помощью WinSCP подключиться со следующими параметрами:
Host name: 192.168.1.1
Login: root
Password: пароль_который_вы_установили_на_шаге_1
1) задать пароль администратора (через LuCI)
3) с помощью SFTP-плагина для TC/DC (этот плагин, вопреки своему названию, умеет работать и по SCP) подключиться со следующими параметрами:
Connect to: 192.168.1.1
User name: root
Password: пароль_который_вы_установили_на_шаге_1
Если вы создаёте или редактируете файл в Windows, а затем копируете его на роутер, то перед копированием убедитесь, что переносы строк в файле UNIX-овские, а не Windows-овские! Для этого достаточно открыть файл в Notepad++ и в статусной строке внизу справа найти "Unix (LF)". Если там "Windows (CR LF)", то щёлкните правой кнопкой по надписи, выберите "Unix (LF)" и сохраните файл. Всё это нужно повторять после каждого редактирования, поэтому сначала редактируете как душе угодно, а затем уже проверяете переносы и заливаете на роутер.
Читайте также: