Ну, начнем с того, что я считаю, что точность и простота - залог надежности.
Цитата Isotonic:
|
Когда возникает необходимость 'втыкать NAT' (кроме приведённых мною случаев)?»
|
При необходимости поднять безопасность или использовать дополнительные адресные пространства без возможности или желания переписывать конфигурацию существующей сети. Ну вообще, случай 'втыкания' NAT на границе с WAN это и есть частный пример подобной необходимости.
Цитата Isotonic:
|
А когда 'NAT втыкают' не из необходимости?»
|
По желанию? Извините, вопрос больше фиолософский. Чем ваше 'не из необходимости' отличается от 'необходимости'?
Цитата Isotonic:
|
И что значит 'эффективны в совокупности'? »
|
Означает что они используются повсеместно, и представить себе глобальную сеть без первого или второго немыслимо.
Цитата Kiber:
Так и тут, нельзя построить сеть из одних NAT'ов. Это бессмысленно.
Как и нельзя построить всю сеть только на маршрутизации. Рано или поздно воткнёшь NAT. »
|
Цитата Isotonic:
|
Я ведь думал над другими адресами, но несколько иначе: IP 172.x.x.x назначается только серверам, клиентам обоих сетей по DHCP рассылается маршрут (192.168.x.x - через роутер, 10.x.x.x. - on-link) и, конечно, маршруты на роутерах. »
|
Решение задачи в большей степени зависит от постановки. В данном случае нам нехватает данных по обеим сетям. Что это за сети? Для чего используются? Какие перечислимые виды отношений и ресурсов внутри сети? Как в будующем может потребоваться связать их?
Насколько я понял, 10.0.0 - сеть с полными правами, 192.168.1 - сеть только для интернета, плюс ограниченный набор пользователей должен иметь доступ к ресурсам 10 сети.
В таком случае легче всего воткнуть в шлюз сети 192.168 еще одну сетевушку. Выдать ей 172.16.1.1/24, линк воткнуть в оборудование 192.168.1. Перевести нужных пользователей из 192.168.1 в 172.16.1. Затем прописать фильтры для каждого пользователя с маской 32 из 172.16.1 в 10.0.0 и обратно. И фильтр между 192.168 и 172.16.1.
Если не планируете понижать маску сети 192.168.1, то можно вместо 172.16.1 использовать 192.168.128 (например).
Цитата Isotonic:
|
При доступе по имени *.static.local могут возникнуть сложности из-за того, что на самом деле сервер имеет другое имя. И т.д.»
|
Не соглашусь. Без разницы, какое имя имеет сервер. Если вы про доступ к виндовым шарам, то насколько я знаю, токен безопасности основывается на имени, по которому ты обращаешься, а не под которым себя видит сервер. А глубже всё резолвится в ip, а транспорт к имени не имеет никакого отношения.
Цитата Isotonic:
|
С группой фильтров непредвиденных сложностей нет: сформировать список фильтров, исключить на DHCP и загнать сервера в этот диапазон. »
|
Вообще никогда не понимал каким образом DHCP, сервис, который по сути не гарантирует защищенность адресных пространств, может использоваться для безопасноти.
Допустим, падает DHCP. Сыпятся звонки - ничего не работает. И тут уж либо исправлять в кратчайшие сроки, либо каждого перенастраивать вручную. Это, кстати, один из минусов использования DNS. Хотя, на моей памяти, ни один нормально настроенный DNS не падал.
Цитата Isotonic:
|
Ну, что ж сразу бред? ... А полезность стоит под всем сообщением. Я решил не оставлять полезность на том, где далеко не всё разумно. »
|
Да, я так и подумал. Revoke'нул плюс - готовь approve! :D
Цитата Isotonic:
|
всё про юзеров (доступ нужен всем)»
|
Не понял.
Цитата Isotonic:
|
неоднозначность при обработке (сервер будет отвечать с того же IP по-любому)»
|
Подразумевалась обработка пакета от пользователя фильтрами на маршрутизаторе. У пользователя 2 IP на одном интерфейсе. Адрес отправителя в данном случае вещь неоднозначная.
Цитата Isotonic:
|
'забавная схема' не кажется правильной организацией»
|
Это лишь пример того, как _может_ работать сеть, а не того, как _надо_, остаточный эффект миграции. Надеюсь, это было очевидным. Предположим, есть Сервер и Админ (не я). Админ написал Прогу для своей БД. Прога используется _КЛИЕНТАМИ_ для доступа к этой БД. В Прогу зашит IP Сервера. Админ очень дорожит своими _КЛИЕНТАМИ_ и не хочет ни на секунду отрывать их от работы (или себя, тут уж непонятно - такой Админ). Как вы понимаете, дальнейший мув только за Админом, и чувствую, что скоро ему будет поставлен deadline, после которого Серверу будет удален старый ip.
Собственно, сам пример весьма рабочий, если вы, например, имели дело со спутником.
Покажите, где написано, что трассы от клиента до сервера и от сервера до клиента должны быть симметричны.
Цитата Isotonic:
|
'можно не прописывать второй ip для сервера' - совсем не верно (сервер не будет принимать пакеты на тот IP, который ему не назначен)).»
|
Вы совсем неправильно поняли предложенные схемы.
