дак белый ip вешают на ифейс клиента? или как то вам по-другому надо?

Непонятно. Белый IP должен висеть на интерфейсе клиента и маршрутизироваться наружу. При чем здесь NAT.

Что-то не очень понятно. Они предлагают сделать алиас на интерфейсе edgerouter с тем же IP адресом, что и у клиента?

Надо так, чтобы на интерфейсе клиента был серый ip, но при выходе наружу становился белым. Сейчас у нас так работают два других провайдера. Правда нам они выделил для интерконнекта /31 блок, мы на edgerouter'е настраиваем один из адресов этого /31, а они в свою очередь на своем второй адрес из этого /31 блока, и этот адрес для нашего является гейтвеем. Затем нам выделяют отдельный /28 блок и все прекрасно натится - у клиентов внутри сети белые ip, при выходе наружу он становится белым в соответствии с настройками dnat/snat на edgerouter'е.

Да. Точнее с тем же адресом, который я собрался натить на клиента.

читай [nat] кто не прав? (комментарий)

grouzen

Надо так, чтобы на интерфейсе клиента был серый ip

типа у клиента будет 10.1.2.3, если смотреть с других клиентов и из его ipconfig, но на шлюзе он станет 192.0.1.2?

Про NAT: все равно непонятно. По-моему, вам не NAT нужен, а нормальная маршрутизация. С NAT вам вообще нужен только один белый IP для внешнего роутера, а всем остальным в своей сети можете присвоить что угодно из немаршрутизируемых адресов (серый IP). NAT при выходе пакета наружу подставит в пакет ыадрес edgerouter'а и пакет обретет «реальный» (белый) IP.

А вот если вы настроите маршрутизацию нормально, то у всех машин в вашей сети будут реальные IP и при выходе через edgerouter они не изменятся. Для этого, насколько я понимаю, на edgerouter надо прописать маршрут до хоста freebsd через устройство, которое на этот фрибсд смотрит, и маршрут до выделенного вам диапазона IP через gw <адрес фрибсд>.

Примерно про это вам хотел сказать и thesis.

ваш провайдер дал вам /28 подсеть и вы повесили ее на сты с ним же ?

если это так, дело в том,что роутер провайдера ищет ип,в который отнатился клиет, в этом же подсети что и изначальная /28. Можете посмотреть tcpdum на интерфейсе, там должны быть arp запросы с поиском этого ip от имени роутера провайдера.

есть несколько решений:

1. И как вам ответил провайдер повесить алиасами эти ip - тогда ваш роутер будет отвечать на arp, и трафик будет прилетать к нему и следовательно обрабатываться contract-ом

2. Настроить arp proxy для этой подсети на интерфейсе стыка с провадером, результат как в П1

3. Попросить нормальный стык /30 и пусть пров пропишет /28 роут на вас (так же возможные производные варианты с роутингом)

Вот остальные два провайдера, как я уже писал выше, работают через /31 + /28 на клиентов. Правда я не совсем понимаю как это работает. Было бы хорошо, если бы вы объяснили механизм. Алсо, они говорят, что они не могут выделить /31, так как у них там стоит freebsd, которая не умеет /31. Правда как я понял есть возможность проключить через другую железку, но возможность выделения /31 нужно обсуждать уже с начальством.

да, именно так, этим занимается как раз SNAT, если я правильно все понимаю.

Kiborg

С NAT вам вообще нужен только один белый IP для внешнего роутера

нет. один максимум на 10..20К клиентов. И то наверное это слишком много клиентов... Учтите, на каждое соединение нужен свой порт, а портов всего 63К.

Учтите, на каждое соединение нужен свой порт, а портов всего 63К.

А разве нельзя иметь более одного соединения на один локальный порт? Входящих то соединений на один порт у веб сервера может быть более 65к.

azure

А разве нельзя иметь более одного соединения на один локальный порт? Входящих то соединений на один порт у веб сервера может быть более 65к.

без понятия. Может как-то и можно. Знаю лишь то, что в IPv4 пакете выделено 16 бит для порта отправителя пакета, что составляет ровно 64К портов. Однако 1К портов выделен для серверов, и т.о. остаётся 63К портов. С другой стороны, если порт уже занят, то соединение по таймауту переустанавливается, для юзера это выглядит так, что у него «странички медленно открываются», причём, если занято 32К портов, то вероятность этого равна 50%. Ну а учитывая, что даже страничка лора и то на 5..10 соединений сразу претендует, то 32К клиента - это гарантированная «тупизна» веба.

Как вешать 2 соединения на один порт - я не знаю. Протокол TCP/IP и соотв. rfc не дают ответа(точнее дают - никак). Если есть ссылка - давайте.

tcp Соединение идентифицируется 2-мя параметрами - srcport и dstport (плюс srcip и dstip для ip-протокола).

Итого:

Сервер:80 <-- client:33333, client:44444, client:55555 (на каждое соединение по одному порту на клиенте), но у сервера много соединений с одного клиента на одном порту сервера, но с многими разными портами клиента

Кроме того, мне кажется что не исключено использование одного локального порта для доступа к разным серверам\портам:

Server1:80 <-\ Server1:8080 <--|- client:55555 Server2:80 <-/

tcp Соединение идентифицируется 2-мя параметрами - srcport и dstport (плюс srcip и dstip для ip-протокола).

Итого:

Сервер:80 <-- client:33333, client:44444, client:55555

(на каждое соединение по одному порту на клиенте), но у сервера много соединений с одного клиента на одном порту сервера, но с многими разными портами клиента

Кроме того, мне кажется что не исключено использование одного локального порта для доступа к разным серверам\портам:

Server1:80   <-\ 
Server1:8080 <--|--> client:55555 
Server2:80   <-/

я понимаю, но ему все равно выдали, фактически, всего 2^(32-28)-2 адресов, т. е. 14. Это не 10..20К клиентов )

Но я, видимо, не совсем верно понял задачу. Для того, чтобы работал доступ к клиенту извне через NAT, нужен либо проброс портов, либо UPnP (но тогда обращаться будут по адресу edgerouter, а не по тому адресу, который ТС хочет дать клиенту). А тут придумали какую-то хитрую схему с алиасами таким образом, что любой пакет, приходящий на алиас (адрес алиаса = адрес, который ТС хочет выдать клиенту), будет перенаправляться на внутренний адрес, под которым клиент виден во внутренней сети.

azure

Сервер:80 <-- client:33333, client:44444, client:55555 (на каждое соединение по одному порту на клиенте), но у сервера много соединений с одного клиента на одном порту сервера, но с многими разными портами клиента

тут вся проблема в шлюзе. Когда от первого (33333) клиента уходит пакет на 80й порт сервера, то шлюз это запоминает. И когда от этого сервера, приходит пакет на шлюз, причём не просто на шлюз, а на порт 33333, то в этом(и только в этом) случае, шлюз понимает, что данный пакет надо направить первому клиенту, на его внутренний IP и на порт 33333. Порт тут является своего рода ключом, для выбора нужного клиента. Причём ключ (порт) обязан быть уникальным, для данного внутреннего IP.

azure

Кроме того, мне кажется что не исключено использование одного локального порта для доступа к разным серверам\портам:

да, в принципе... да. На практике мы имеем 100500 клиентов, и ВСЕМ нужен 80й порт. Опять-таки, наш ключ становится длиннее, это уже не 16 бит, а 32. Оборудование дорожает ровно вдвое, но клиентов мы берём больше всего на 5..15%. Кому это надо? И да, ещё и клиента надо модернизировать, что-бы он по одному порту слушал два сервера. В линуксе это конечно просто... Ну вы поняли...

Kiborg

я понимаю, но ему все равно выдали, фактически, всего 2^(32-28)-2 адресов, т. е. 14. Это не 10..20К клиентов )

дык на ОДИН ip можно повесить 10..20К клиентов. Сколько их можно повесить на 14? Кстати, не на 14, а на 16. Клиенты (которых может быть как минимум 150К) могут висеть в локалке класса А (10/8), там же иметь броадкаст. А 16 внешних IP будут использоваться исключительно для выхода наружу. Вот мой пров так и сделал - я получаю адрес 10.хх.хх.хх (фиксированный, белый в пределах локалки), а далее он либо натится через один из коммунальных IP, либо, за доп. плату, через персональный IP. Если адрес натится через коммунальный IP, то он является серым, ибо шлюз не в курсе, кому отправлять запрос, который пришёл на 192.0.1.2:33333 - вариантов как клиентов, тысячи их. Но если IP лично мой, то вариантов ессно нет. Это для меня.

Kiborg

Но я, видимо, не совсем верно понял задачу. Для того, чтобы работал доступ к клиенту извне через NAT, нужен либо проброс портов, либо UPnP

не. можно обслужить максимум 15 клиентов с белым IP(и 16й ip оставить как коммунальный).

Хотя вообще, не очень понятно, сколько и каких клиентов у ТС?

Kiborg

А тут придумали какую-то хитрую схему с алиасами таким образом, что любой пакет, приходящий на алиас

как я понял, это никакие не алиасы, а обычный SNAT. лично я сам использую такой NAT, для своих внутренних целей (у меня дома несколько компьютеров). SNAT натит на выходе, и ему нужно знать ip источника. Причём этот IP должен быть жёстко вбит в код iptables-скрипта. В принципе я доволен этой схемой, она достаточно надёжна и неприхотлива. (лучше DNAT, который натит прямо на входе, а потом внутри netfilter нет возможности догадаться, что это, и откуда)

/31 or /30 ?

Да без разницы. Мне не понятно, как пакеты от вышестоящего провайдера доходят до нашего бордера, если на интерфейсе не назначены ip из /28 блока.

Linux ни на что не годен. Его можно выбросить из схемы.

IPFW тоже не нужен.

На FreeBSD в PF есть чудная штука, называется binat (Bidirectional Mapping), которая отображает выделенный блок внешних «белых» IP на серые IP клиентов за NAT по типу один-к-одному.

что тут можно еще сказать - учите матчасть. Почему так происходит я написал.

вы бы хоть внимательно почитали проблемы ТС, чем постить ересь.

знаю я про эту штуку, одно время пользовался, но потом схема сети поменялась на ту, что сейчас. Так, что не вариант.

Нет, я вас спрашиваю, как так получается, что схема /31 + /28 вообще работает(интересует техническая сторона вопроса, как работает в данном случае arp и ip роутинг)? То есть как интерфейс вышестоящего провайдера видит белые адреса клиентов(которые фактически не назначены ни на один из интерфейсов, а есть лишь в конфигах iptables'а).

Нет, я вас спрашиваю, как так получается...

повторю еще раз, изучайте матчасть, это достаточно простые вещи. Как можно админить провайдера и задавать подобные вопросы ?

Ок, поизучаю матчать. Я админю, потому что, больше некому.