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

ssh в маршрутизатор Cisco не работает

На маршрутизаторе серии 2800 я мог подключаться по ssh через два общедоступных интерфейса, но теперь, похоже, не могу. Один из этих двух общедоступных интерфейсов имеет ACL, а другой - нет. Когда я подключаюсь по ssh к тому, у которого есть ACL, я вижу, что счетчик увеличивается на разрешающем правиле для ACL. Однако я не могу подключиться к порту 22 ни на одном из интерфейсов. Я все еще могу подключиться к маршрутизатору по ssh, используя внутренние интерфейсы через туннели IPSEC VPN. Кто-нибудь знает, что может происходить?

Вот журнал отладки попытки telnet извне через Интернет, 12.12.12.12 - внешний компьютер, 13.13.13.13 - общедоступный интерфейс на маршрутизаторе, к которому я тоже подключился:

000263: *Sep 15 13:18:46.505 UTC: IP: tableid=0, s=12.12.12.12 (FastEthernet0/1/0), d=13.13.13.13 (FastEthernet0/1/0), routed via RIB
000264: *Sep 15 13:18:46.505 UTC: IP: s=12.12.12.12 (FastEthernet0/1/0), d=13.13.13.13 (FastEthernet0/1/0), len 60, rcvd 3
000265: *Sep 15 13:18:46.505 UTC:     TCP src=48143, dst=22, seq=1929678540, ack=0, win=5840 SYN
000266: *Sep 15 13:18:46.505 UTC: IP: tableid=0, s=13.13.13.13 (local), d=12.12.12.12 (FastEthernet0/1/0), routed via FIB
000267: *Sep 15 13:18:46.509 UTC: IP: s=13.13.13.13 (local), d=12.12.12.12 (FastEthernet0/1/0), len 44, sending
000268: *Sep 15 13:18:46.509 UTC:     TCP src=22, dst=48143, seq=3745978889, ack=1929678541, win=4128 ACK SYN
000269: *Sep 15 13:18:48.509 UTC: IP: tableid=0, s=13.13.13.13 (local), d=12.12.12.12 (FastEthernet0/1/0), routed via FIB
000270: *Sep 15 13:18:48.509 UTC: IP: s=13.13.13.13 (local), d=12.12.12.12 (FastEthernet0/1/0), len 44, sending
000271: *Sep 15 13:18:48.509 UTC:     TCP src=35, dst=48143, seq=3745978889, ack=1929678541, win=4128 ACK SYN
000272: *Sep 15 13:18:49.501 UTC: IP: tableid=0, s=12.12.12.12 (FastEthernet0/1/0), d=13.13.13.13 (FastEthernet0/1/0), routed via RIB
000273: *Sep 15 13:18:49.501 UTC: IP: s=12.12.12.12 (FastEthernet0/1/0), d=13.13.13.13 (FastEthernet0/1/0), len 60, rcvd 3
000274: *Sep 15 13:18:49.501 UTC:     TCP src=48143, dst=22, seq=1929678540, ack=0, win=5840 SYN
000275: *Sep 15 13:18:49.501 UTC: IP: tableid=0, s=13.13.13.13 (local), d=12.12.12.12 (FastEthernet0/1/0), routed via FIB
000276: *Sep 15 13:18:49.501 UTC: IP: s=13.13.13.13 (local), d=12.12.12.12 (FastEthernet0/1/0), len 40, sending
000277: *Sep 15 13:18:49.501 UTC:     TCP src=22, dst=48143, seq=3745978889, ack=1929678541, win=4128 ACK

Обновить:
Может, нат проблема?

Результат команды show ip nat trans из приведенного выше:

tcp 11.11.11.11:22     14.14.14.14:22      12.12.12.12:42884     12.12.12.12:42884

Где 14.14.14.14 - другой общедоступный интерфейс на маршрутизаторе.

Что нужно проверить:

На роутере делаем отладить ip ssh а потом терминальный монитор, затем попробуйте подключиться.
Используйте отладку на стороне клиента. Используя OpenSSH, запустите его с -v флаг. С помощью PuTTY перейдите в Logging и выберите Пакеты SSH прежде чем пытаться подключиться. Я предполагаю, что у других клиентов SSH также есть механизмы отладки, но я использую их чаще всего.

Комбинация того и другого должна дать вам некоторое представление о том, где застревает соединение.

Кроме того, убедитесь, что вы делаете отменить ошибку ip ssh когда вы закончите.

Кайл, Вероятна проблема с NAT, хотя сложно сказать, не видя конфиг.

Хороший способ помочь в устранении неполадок - создать список доступа с внешним IP-адресом маршрутизатора и затем включить отладку NAT для этого ACL. Например:

R> enable
R# conf t
! XXX is the number of an unused access-list
R(config)# access-list XXX permit 13.13.13.13 0.0.0.0
R(config)# ^Z
! XXX is the ACL defined above
R# debug ip nat XXX
R# term monitor

Когда закончите:

R# no access-list XXX
!Removing the ACP should automatically turn off NAT debugging for it but to be thorough
R# no debug ip nat XX