Назад | Перейти на главную страницу

Тайм-аут подтверждения SSH с NAT на Cisco 881W

У меня возникли проблемы с настройкой переадресации портов с использованием статического NAT на Cisco 881W ISR. Я подтвердил, что демон ssh работает из окна Linux внутри файла nat. Мой вопрос касается того факта, что любые входящие ssh-соединения могут открывать сокет, но похоже, что время установления связи ssh истекло или ему мешает конфигурация NAT на маршрутизаторе. Я подумал, что это странно, и потерпел многочасовые поиски в Google, но безрезультатно. У меня есть другие переадресации портов на маршрутизаторе, и они работают нормально - HTTP и Subversion на портах 8080 и 8081 соответственно.

Вот мои настройки NAT, ACL и интерфейса:

interface Dialer0
  description WAN-ADSL
  ip address negotiated
  no ip redirects
  no ip unreachables
  no ip proxy-arp
  ip mtu 1452
  ip flow ingress
  ip nat outside
  ip virtual-reassembly
  zone-member security out-zone
  encapsulation ppp
  dialer pool 1
  dialer-group 1
  ppp authentication chap callin
  ppp chap hostname user@adsl.provider
  ppp chap password 7 HERPADERPADERP
  no cdp enable


ip nat translation timeout 30
ip nat inside source list 101 interface Dialer0 overload
ip nat inside source static tcp 10.10.10.10 22 interface Dialer0 22
ip nat inside source static tcp 10.10.10.10 8080 interface Dialer0 8080
ip nat inside source static tcp 10.10.10.10 8081 interface Dialer0 8081

access-list 101 permit ip any any
access-list 101 permit tcp any any established

Какие-нибудь мудрые слова, которые помогли бы мне заставить SSH правильно рукопожатить и действительно открыть соединение? я ДЕЙСТВИТЕЛЬНО не хотят прибегать к telnet для удаленного доступа, и (как указано выше) Google оказывается пустым.

РЕДАКТИРОВАТЬ:

Поскольку HTTP работает нормально, мне интересно, не проблема ли это конфигурации с SSH. Для записи я использую ванильный демон openssh из репозитория debian. Я также тестировал это с помощью демона ssh, запущенного на моем Macbook, с теми же результатами.

Включите подробную отладку на ssh-клиенте, пытающемся подключиться, и опубликуйте результаты. Также взгляните на журнал sshd, который должен помочь определить причину проблемы.