Подключение PPPoE уже активно, закрываем предыдущее.

Всем привет! Я настроил RG750 с LAN Pool и VPN Pool. Но когда подключаемся к VPN, IP отображается как в LAN, а шлюз — 0.0.0.0, а маска подсети показана 255.255.255.255. Нам нужно, чтобы маска подсети была 255.255.255.0, как в нашей LAN. Пожалуйста, подскажите. Заранее спасибо!

Выполнение NAT (а на самом деле любого действия, связанного с отслеживанием соединений) на другом роутере — это только один из возможных источников нагрузки на процессор, но есть и другие причины. Главная проблема в том, что разрыв и установление PPPoE-соединения — это задача, требующая большой загрузки CPU, и, похоже, при этом не происходит приоритизации обработки управляющих пакетов PPPoE по сравнению с другим трафиком. Поэтому, когда случается «что-то серьёзное», это так сильно влияет на обработку управляющих пакетов, что соединения считаются мёртвыми, процесс разрыва запускается, еще больше загружая CPU, и ещё больше соединений считается мёртвыми, в итоге все соединения обрываются и начинают медленно восстанавливаться. И если нагрузка на процессор близка к пределу, то это «что-то серьёзное» вовсе не обязательно такое уж большое — оно просто чуть-чуть превышает границу, и эффект самоблокировки делает остальное.

Так что перенос «NAT» с PPPoE-сервера просто снижает базовую нагрузку и даёт больше возможностей справляться с пиковыми всплесками трафика без катастрофы. Однако если вы перенесёте «NAT» с PPPoE-сервера, но при этом сохраняете отслеживание соединений на нем, выгоды не будет — настоящая нагрузка, связанная с NAT, заключается в сопоставлении каждого пакета с полным списком существующих соединений, независимо от того, подвергается ли соединение NAT или нет. Переписывание исходного и/или адреса назначения пакета использует гораздо меньше ресурсов CPU, чем собственный поиск.

В некоторых случаях это «что-то серьёзное» может быть удалением замаскированных соединений из отслеживания, но это происходит только тогда, когда меняется IP-адрес, под которым эти соединения маскируются. Поэтому разрыв одного PPPoE-соединения запускает удаление на клиенте, а не на сервере (если только клиент не играет роль uplink для сервера, но в реальных условиях такого не бывает). На стороне сервера это происходит только в мульти-WAN-средах с правилами masquerade, когда отключение WAN-интерфейса запускает удаление замаскированных соединений, но это особый случай, который обычно не характерен, если ваши WAN-IP статичны и вы можете использовать обычный src-nat вместо masquerade.

Кроме того, иногда забывают добавить blackhole-маршруты к подсетям, из которых PPPoE-клиенты получают свои адреса. Когда клиент отключается, ответы на открытые им соединения продолжают идти, но так как клиент отключён, связанный маршрут /32 к его адресу больше не существует, и пакеты идут по умолчанию, то есть обратно к вышестоящему роутеру. В зависимости от TTL, эти пакеты могут болтаться между PPPoE-сервером и вышестоящим роутером, создавая дополнительную нагрузку на процессор. Blackhole-маршрут к подсети пула адресов с расстоянием больше 0 предотвращает такую ситуацию.