СвязьПроект

Нужна помощь.
Поднимаю с интерфейса FE0/0 VPN-соединение с сервером. Хочу дать выход в интернет компьютеру (компьютерам) подключенным к интерфейсу FE0/1 с помощью NAT.
Не раздаётся отчего-то...

Вот конфиг:

version 8.41.042
!
hostname AP100
!
username root password router administrator
!
!
interface Loopback0
ip address 127.0.0.1 255.0.0.0
!
interface FastEthernet0/0
ip address XXX.XXX.XXX.XXX 255.255.255.0
speed auto
no qos-control
!
interface FastEthernet0/1
ip address 192.168.10.1 255.255.255.0
ip nat inside
speed auto
no qos-control
!
interface Dialer0
no ip address
encapsulation ppp
ppp ipcp default-router
ppp authentication chap callin
ppp chap hostname aaaaaa
ppp chap password bbbbbb
ip nat outside
!
interface Tunnel0
no ip address
ip mtu 1400
tunnel source FastEthernet0/0
tunnel destination YYY.YYY.YYY.YYY
tunnel mode gre ppp
tunnel pptp-client dial-pool-number 0
!
! ip route 0.0.0.0 0.0.0.0 ZZZ.ZZZ.ZZZ.ZZZ via ppp
ip route YYY.YYY.YYY.YYY 255.255.255.255 XXX.XXX.XXX.1
ip route VVV.VVV.VVV.0 255.255.255.0 XXX.XXX.XXX.1
!
access-list 100 permit ip 192.168.10.0 0.0.0.255 any
!
!
ip nat inside source list 100 interface Dialer0 overload
!
!
snmp name AP100_G2
!
!
ftp server
http server
!
!
! dns name-server VVV.VVV.VVV.VVV via ppp
!
!

Неужто никто не сталкивался?!

pptp-соединение устанавливается? Удаленная сторона туннеля пингуется?

Да, устанавливается. И пингуется.
Это, кстати, видно и из приведённого конфига: маршруты и адрес днс-сервера с впн-сервака прилетают.

Из конфига совсем не очевидно, что пингуется и откуда маршруты прилетают от роутера или вами вбиты руками. Дефолтный маршрут у вас вообще закомментирован, это у вас он уже таким прилетает от pptp-cервера?

Ну да. Это нормально для пака. Я одно время занимался их настройкой, и всегда так было: то что забито в конфиг не вручную, а прилетает от сервака - отображается в конфиге в закомментированном виде. В данном конфиге - это дефалтовый маршрут и dns name-server. Несмотря но то, что они как бы "закомментированы", эти строки работают.

Не видно ip routing в конфиге. За туннелем с AP что-нибудь пингуется? внутренние компы с ap пингуются?

ip routing не видно, потому что он есть
Если дать команду no ip routing, то тогда такая строка в конфиге отобразится. А по-умолчанию - включено.
С пака всё пингается в обе стороны. А вот из внутренней сетки только LAN1 и виден.
Посоветовался с бывшим коллегой, он говорит, что тоже в подобной ситуации намучался. Не хотел NAT работать. Потом как-то оставил на ночь включенным пак, пришёл с утра, а NAT уже работает. Постоял несколько часов - и поднялось. Но у него более простая схема - на нулевом езернете реальник стоял, а у меня - локальный адрес, а реальник сервером присваивается. Я пак сутками не выключал - чуда не случилось. Чувствую, это конструктивный баг. Устал бороться - настроил пак бриджом, а за ним поставил D-Link DI-604. Сразу и туннель заработал, и NAT...

Столкнулся с проблемой по настройке AP200B в конфигурации pptp + NAT.
Фрагмент конфига:



Периодически возникает вот такая картинка, если пинговать адпака с сервера, где он авторизуется по pptp:

ping 192.168.10.13
PING 192.168.10.13 (192.168.10.13) 56(84) bytes of data.
64 bytes from 192.168.10.13: icmp_seq=1 ttl=255 time=7508 ms
64 bytes from 192.168.10.13: icmp_seq=2 ttl=255 time=6511 ms
64 bytes from 192.168.10.13: icmp_seq=3 ttl=255 time=5512 ms
64 bytes from 192.168.10.13: icmp_seq=4 ttl=255 time=6222 ms
64 bytes from 192.168.10.13: icmp_seq=5 ttl=255 time=5224 ms
64 bytes from 192.168.10.13: icmp_seq=6 ttl=255 time=4225 ms
64 bytes from 192.168.10.13: icmp_seq=7 ttl=255 time=3225 ms
64 bytes from 192.168.10.13: icmp_seq=8 ttl=255 time=2226 ms
64 bytes from 192.168.10.13: icmp_seq=9 ttl=255 time=4634 ms
64 bytes from 192.168.10.13: icmp_seq=10 ttl=255 time=3635 ms
64 bytes from 192.168.10.13: icmp_seq=11 ttl=255 time=2639 ms
64 bytes from 192.168.10.13: icmp_seq=12 ttl=255 time=1640 ms
64 bytes from 192.168.10.13: icmp_seq=13 ttl=255 time=643 ms
64 bytes from 192.168.10.13: icmp_seq=14 ttl=255 time=1.00 ms
64 bytes from 192.168.10.13: icmp_seq=15 ttl=255 time=0.890 ms
64 bytes from 192.168.10.13: icmp_seq=16 ttl=255 time=0.898 ms
64 bytes from 192.168.10.13: icmp_seq=17 ttl=255 time=0.866 ms
64 bytes from 192.168.10.13: icmp_seq=18 ttl=255 time=1449 ms
64 bytes from 192.168.10.13: icmp_seq=19 ttl=255 time=450 ms
64 bytes from 192.168.10.13: icmp_seq=20 ttl=255 time=2854 ms
64 bytes from 192.168.10.13: icmp_seq=21 ttl=255 time=1855 ms
64 bytes from 192.168.10.13: icmp_seq=22 ttl=255 time=855 ms
64 bytes from 192.168.10.13: icmp_seq=23 ttl=255 time=6664 ms
64 bytes from 192.168.10.13: icmp_seq=24 ttl=255 time=5665 ms
64 bytes from 192.168.10.13: icmp_seq=25 ttl=255 time=4666 ms
64 bytes from 192.168.10.13: icmp_seq=26 ttl=255 time=3670 ms
64 bytes from 192.168.10.13: icmp_seq=27 ttl=255 time=2671 ms
64 bytes from 192.168.10.13: icmp_seq=28 ttl=255 time=1674 ms
64 bytes from 192.168.10.13: icmp_seq=29 ttl=255 time=683 ms
64 bytes from 192.168.10.13: icmp_seq=30 ttl=255 time=3099 ms
64 bytes from 192.168.10.13: icmp_seq=31 ttl=255 time=2099 ms
64 bytes from 192.168.10.13: icmp_seq=32 ttl=255 time=1108 ms
64 bytes from 192.168.10.13: icmp_seq=33 ttl=255 time=108 ms
64 bytes from 192.168.10.13: icmp_seq=34 ttl=255 time=2529 ms
64 bytes from 192.168.10.13: icmp_seq=35 ttl=255 time=1538 ms

потом все нормализуется и работает как положено:

64 bytes from 192.168.10.13: icmp_seq=1 ttl=255 time=0.881 ms
64 bytes from 192.168.10.13: icmp_seq=2 ttl=255 time=1.12 ms
64 bytes from 192.168.10.13: icmp_seq=3 ttl=255 time=0.868 ms
64 bytes from 192.168.10.13: icmp_seq=4 ttl=255 time=0.850 ms
64 bytes from 192.168.10.13: icmp_seq=5 ttl=255 time=0.872 ms
64 bytes from 192.168.10.13: icmp_seq=6 ttl=255 time=1.03 ms
64 bytes from 192.168.10.13: icmp_seq=7 ttl=255 time=0.868 ms

Похоже, что проблема упиралась в mtu - этот параметр критичен для pptp-подключений. Установка на ethernet-интерфейсах значения 1452 вместо 1500 вроде исправила ситуацию. Вот только не пойму - надо ли менять mtu и на интерфейсе pptp0?