Зазвичай це означає, що ви перенаправили порт на неправильну IP-адресу в локальній мережі.
За замовчуванням Ubuntu не фільтрує вхідні спроби підключення за допомогою брандмауера. Отже, якщо ви не змінили налаштування брандмауера в Ubuntu, спроба відкрити з'єднання з будь-яким портом TCP, від 1 до 65535, буде:
Це викликає саме ситуацію, яку ви описали. Таким чином, ви можете скоріше це виправити, переконавшись, що порт пересилається на правильну IP-адресу в локальній мережі.
... тоді вам доведеться зайнятися усуненням неполадок.
Чи правильно вказаний порт для сторони локальної мережі? Тобто, якщо припустити, що ви не змінили конфігурацію сервера SSH, чи встановлений порт 57757 на стороні WAN для переадресації на порт 22 на сервері OpenSSH? (Ви можете перевірити це ще раз.)
Можливо, є проблема з конкретним портом, який ви вибрали (57757). Спробуйте інший і подивіться, чи працює це краще.
(Якщо цього немає, і ви продовжуєте виконувати ці вказівки, або змініть його назад, або замініть "57757" нижче на новий номер.)
Спробуйте перезапустити сервер OpenSSH. Це може допомогти, якщо є проблема з мережею. Якщо це не допомагає, спробуйте перезапустити маршрутизатор та кабельний / DSL / ISDN модем.
Якщо з якоїсь причини ви не можете перезапустити всі три пристрої, рекомендую перезапустити все, що тільки можете. Якщо ви не можете перезапустити службу OpenSSH, принаймні ви можете перезапустити службу і (швидше за все, це виправити), зняти інтерфейс і знову його відновити.
Щоб перезапустити сервер OpenSSH:
sudo restart ssh
Щоб збити мережевий інтерфейс, спочатку з’ясуйте, на якому інтерфейсі він працює:
ifconfig
Як правило, для машини з однією карткою Ethernet та / або однією бездротовою карткою Ethernet є, eth0а бездротовим є wlan0.
Якщо провідне з'єднання Ethernet - це те, що ви хочете зняти та перезапустити, запустіть:
sudo ifdown eth0
Потім запустіть:
sudo ifup eth0
Можна також запустити:
sudo ifconfig eth0 down
Далі:
sudo ifconfig eth0 up
Якщо машина використовує NetworkManager для управління інтерфейсом, на якому працює сервер OpenSSH, я все-таки рекомендую спробувати перераховані вище способи, але ви також можете спробувати відключити та знову підключитись до NetworkManager.
Для підключення до Ethernet також спробуйте від'єднати кабель та підключити його назад. Для бездротового з'єднання спробуйте вимкнути його апаратним перемикачем (якщо він є) та знову ввімкніть його знову.
Тут відбувається щось дивне, і нічого з цього не триває дуже довго - варто бути ретельним, перш ніж вживати більш кропітких кроків щодо усунення несправностей.
Як ви намагаєтесь отримати доступ до нього з боку WAN? Якщо для цього використовується машина в локальній мережі (просто підключення від локальної мережі до WAN IP вашого маршрутизатора), це підтримується лише для деяких маршрутизаторів. Зрештою, завдання маршрутизатора - маршрутизувати трафік між сторонами WAN та LAN, а не здійснювати маршрутизацію з однієї сторони до себе. Підтримка підключення до переадресованих портів IP-адреси WAN зсередини локальної мережі - це фактично виняток, а не правило, хоча у багатьох домашніх / офісних маршрутизаторів є ця особливість.
Отже, якщо ви не тестуєте порт вперед від хоста на стороні WAN, вам слід зробити це. Ваші варіанти цього:
Підключіть себе з боку WAN. Це працює, якщо у вас там є доступ до машини, наприклад, доступ SSH до віддаленої машини в школі, на роботі, в будинку друзів тощо.
Підключіть тестовий апарат між маршрутизатором і тим, що забезпечує його інтернет-з'єднання. Якщо у вас є кабельний / DSL / ISDN-модем з портом Ethernet і ваш маршрутизатор підключений до цього, ви можете підключити комутатор до модему і підключити маршрутизатор до комутатора. Підключіть комп'ютер до комутатора. По-перше, подивіться, чи отримує цей апарат просто доступ до Інтернету - в наші дні багато провайдерів надають дві або більше окремих IP-адрес. Якщо цього не відбувається , перейдіть на сторінку налаштування вашого маршрутизатора і перевірте його маску підмережі WAN IP та WAN , а потім статично призначте IP-адресу машині з підключенням, що знаходиться в одній підмережі.
Цей метод має деякі недоліки. Це біль! Крім того, теоретично можливо, щоб ISP неправильно налаштував свою мережу, щоб тестова машина, підключена до комутатора, могла мати доступ до Інтернету. (Якщо тільки ваш намір провайдера не дозволить вам з'єднатися з більш ніж одним IP-адресою WAN іви, мабуть, вибрали IP-адресу WAN для тестової машини, яку вам призначив ваш провайдер, трафік між нею та справжнім хостом WAN повинен бути заблокований / відмовлений провайдером. Але деякі провайдери мають дивні практики, тож хто знає?) Якщо це станеться, це, швидше за все, не спричинить у когось серйозних проблем (і навіть якщо це сталося, у вас підключено лише кілька хвилин) Однак це потенційно може розглядатися як спроба отримати додатковий доступ поза межами вашої підписки, і що ще важливіше - якщо інший користувач має той самий IP, він може заважати їх з'єднанню. Тому, якщо ви хочете спробувати цей метод, не намагайтеся отримати доступ до Інтернету з тестової машини, негайно зупиняйтеся, якщо виявите, що тестова машина може отримати доступ до Інтернету, і не намагайтеся це робити взагалі, якщо це заборонено чи не рекомендується провайдером. (І не використовуйте це, якщо сторона WAN вашого маршрутизатора - це офісна локальна мережа, попередньо не проконсультувавшись з мережевим адміністратором. Це не Інтернет-провайдер і немає припущення, що ресурси передбачені для запобігання небажаного доступу.)
Існує різниця у цій техніці, яка іноді є більш доречною. Ваш маршрутизатор, ймовірно, отримує свою інформацію про з'єднання - IP-адресу, маску підмережі, IP-адресу шлюзу (маршрутизатора) в WAN, яку він використовує, коли він не знає, куди щось надіслати, та інформацію про DNS-сервери - від вашого ISP, через DHCP, через кабельний / DSL / ISDN модем. Ось чому ви повинні мати маршрутизатор підключений до модему, щоб надати йому необхідну конфігурацію, щоб зробити результати тестування на стороні WAN значущими. Але маршрутизатор зазвичай запам'ятовує цю інформацію, доки вона фактично підключена до мережі з боку WAN. Таким чином, ви можете підключити маршрутизатор, модем і тестову машину, але потім, швидко іперш ніж робити що-небудь з тестовою машиною, окрім того, щоб переконатися, що комутатор вважає його підключеним , відключіть модем.
Скористайтесь безкоштовним сервісом в Інтернеті для тестування своїх портів. Оскільки вставлення тестової машини між інтерфейсом WAN вашого маршрутизатора та Інтернетом (вище) дуже сильно задіяно, і оскільки воно покаже порт як доступний, навіть якщо він недоступний через його блокування провайдером (що також стосується підключення до WAN IP маршрутизатора з боку локальної мережі) - зазвичай краще скористатися веб-сервісом сканування портів.
Існує багато послуг сканування портів. (Деякі споживають фразу "перевірити брандмауер" з думкою, що більшість людей намагаються заблокувати, а не полегшити доступ.) Це одне. Якщо ви вирішили скористатися цим, натисніть « Продовжити» , введіть 57757 у текстове поле та натисніть « Використовувати визначений спеціальний зонд для порту» . Для того, щоб сервер запустився, ви хочете, щоб він був "відкритим". "Закритий" означає, що порт доступний, але сервер не працює (і тому спроба з'єднання була відхилена). "Стелс" означає, що порт був недоступний - це так, ніби жодна машина не знаходилася там (або як би порт пересилався там, де немає машини).
Гаразд, ви визначили, що це дійсно недоступно з Інтернету. Потенційно ви можете сканувати його (в ідеалі з боку WAN), щоб отримати детальну інформацію, хоча часто це не дає корисної інформації.
Якщо ви хочете це зробити, то на стороні WAN ви можете запустити:
sudo nmap -sS -sV -p57757 -vv WAN-IP
Якщо порт показаний як відфільтрований, це підтверджує, що надіслані туди пакети, ймовірно, нікуди не потрапляють (або блокуються / відкидаються по дорозі).
Варто перевірити, чи проблема виникає в тому, що порт, який піддається впливу WAN, відрізняється від порту, який насправді слухає сервер. Переадресація порту 55757 по WAN до порту 22 на машині локальної мережі повинна зробити щось нормальним, але, можливо, десь (сервер, клієнт) щось припускає, що номер порту однаковий з точки зору сервера та клієнта.
Імовірно, ви не можете переслати порт 22 через маршрутизатор. Можливо, ваш провайдер блокує цей порт. Але якщо ти можеш це зробити, зроби це!
В іншому випадку ви можете змусити сервер OpenSSH насправді слухати на порту 57757.
Для цього слід створити резервну копію файлу конфігурації сервера:
cd /etc/ssh
sudo cp sshd_config sshd_config.old
Потім відредагуйте його:
gksu gedit sshd_config
Або скористайтеся редактором тексту консолі, якщо на пристрої немає графічного інтерфейсу:
sudo nano -w sshd_config
У верхній частині файлу з'являється цей блок тексту:
# What ports, IPs and protocols we listen for
Port 22
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes
Просто замініть Port 22рядок у верхній частині, щоб сказати Port 57757замість цього.
Ви можете додати порт, а не змінювати його. Я рекомендую протестувати з найпростішою ефективною конфігурацією.
Докладніше man sshd_configпро налаштування сервера OpenSSH див.
Збережіть файл, закрийте текстовий редактор та перезавантажте SSH-сервер за допомогою:
sudo restart ssh
Тепер змініть порт вперед на маршрутизаторі, щоб порт 57757 перейшов до порту 57757 (не 22) на сервері OpenSSH, і подивіться, чи доступний він з Інтернету.
Якщо це все ще не працює, подивіться, чи можливо, брандмауер Ubuntu насправді блокує трафік, що надходить з-за меж локальної мережі.
(Це малоймовірно, якщо ви не налаштували його таким чином самостійно, але якщо всі ваші налаштування є правильними, і жоден з перерахованих вище кроків нічого не виявив про проблему, варто перевірити.)
Виконати:
sudo iptables -L
За замовчуванням в Ubuntu висновок виглядає так:
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Це проста дозвільна політика, по суті еквівалентна тому, що не працює брандмауер. (Дійсно, якби модуль брандмауера netfilter не був скомпільований у вашому ядрі, ваша система поводитиметься так само, як і вищевказані налаштування, хоча iptablesкоманда, яка запитує netfilterналаштування, не працювала б, звичайно.)
Якщо ваша конфігурація не виглядає таким чином, прочитайте, man iptablesщоб зрозуміти, що вони роблять, та / або відредагуйте своє запитання (або, якщо ви інша людина, яка має подібну проблему, читаючи це, напишіть нове запитання), щоб включити їх. Зауважте, що, можливо, ваші iptablesправила можуть розкривати конфіденційну інформацію про вашу конфігурацію. На практиці це, як правило, не так - з можливим винятком правил щодо конкретних хостів, які заблоковані, або якщо ваша конфігурація дуже погана / незахищена - зазвичай корисність цієї інформації для зловмисника, особливо для машини на домашня / офісна локальна мережа за NAT-роутером мінімальна.