Если вы не включите шлюз по умолчанию в Srv A, то никто, кто не имеет прямого подключения к серверу, не сможет подключиться к нему.
1 & 1a) Если кто-либо за пределами подсети (который не подключен напрямую) трафик, вероятно, попадет на сервер, но без шлюза по умолчанию, сервер не будет знать, как вернуть трафик на удаленный хост, и отбросить пакеты.
2) если данные не отправляются на сервер в первую очередь, это не должно влиять на соединение с другими хостами, только на соединение с сервером. Если все данные отправляются на этот сервер и с него, прежде чем он покинет подсеть A, то он будет эффективно отключен по причинам, указанным в # 1
3) «установленное соединение» прошло какое-то рукопожатие, сообщающее, что 2 хоста будут передавать трафик. IE, трехстороннее рукопожатие TCP (я здесь, я вижу вас, пропускает трафик), просто простое соединение немного расплывчато, но я думаю, вы можете сказать, что оно будет охватывать все виды соединений, как «установленные соединения», так и без протоколы, такие как UDP («в одну сторону, не волнует, если вы получаете подключение для передачи данных»)
Теперь я предлагаю добавить маршрут по умолчанию обратно. Вы просто наносите себе вред в долгосрочной перспективе без него. Попробуйте найти в Google некоторую информацию о размещении списков ACL (access-lists) на вашем роутере.
с помощью ACL вы можете указать, что «эта подсеть не может перейти на этот IP-адрес или подсеть», IP-адрес вашего сервера.
не цитируйте меня, но это было бы что-то вроде
ip access-list 1
отрицать все
разрешить любой любой
затем вы применяете его к интерфейсу, идущему на сервер A, с чем-то вроде этого:
ip access-list 1 out
это будет выглядеть примерно так (извините за неиспользование блоков кода)
это запретит пользователям в подсети B отправлять трафик OUT на сервер A, не влияя на какой-либо другой трафик
Это, вероятно, предпочтительный метод.
Я СИЛЬНО ПРЕДЛАГАЮ, ЧТОБЫ НЕ СЛЕДОВАТЬ ЗА ОТВЕТОМ, КОТОРЫЙ ВЫ ИМЕЕТЕ В ВАШЕМ ВОПРОСЕ
это принесет гораздо больше вреда, чем пользы. Я надеюсь, что это помогает