Вот такая задача для ip-богов, я что-то не соображу. Есть сервер, у него два интерфейса. eth0 смотрит в локалку, eth1 в интернеты. Сеть в интернетах /30, т.е. ровно один клиентский айпишник и один шлюз. Требуется этот вот айпишник выдать машине в локалке, чтобы он роутился в интернет. Если было б больше адресов в интернетной сети, я бы не морочился, но тут надо как-то прокинуть единственный адрес. Разные GRE не подходят. Пробовал сделать роутами, чтобы router-ip dev eth1 и client-ip dev eth0, а самому серверу не давать этот адрес, но роутер пытается найти мак клиента и не может, потому как клиент в нашей локалке, ARP не проходит. Идеально было б выставить серверу этот адрес на eth1 и машине в локалке на её интерфейсе, а потом сделать как-то так, чтобы сервер весь трафик, приходящий на этот адрес на eth1 зеркалировал на свой eth0 и слал в нашу локалку и наоборот, что приходит с этого адреса из eth0, должно зеркалироваться на eth1. Или же, на крайняк, чтобы он просто отвечал на ARP для клиентского адреса, не имея его физически, но я не уверен, что так возможно сделать.
25 comments
recommend
bookmark
subscribe
Повесь оба адреса на внешний интерфейс и весь трафик с одного из них направляй в локалку. Не пойму в чем проблема.
У меня нет обоих адресов, только выданный «провайдером». Вот как мне всё, что идёт на этот адрес, прокинуть в локалку за роутер, но без NAT? Т.е. чтобы авайка в локалке имела на своём интерфейсе этот WAN-адрес, который мне дали, и полноценно с ним работала?
Я нихуя не понял. Из твоих слов я сделал вывод, что у тебя есть два адреса из подсети /30 и один из них надо прокинуть в локалку. А теперь уже нету.
так тебе второй виртуальный wan надо создать что ли?
Два адреса в подсети /30 — один мой, другой провайдерский роутер. Надо этот вот мой дать компу в моей локалке, а не моему шлюзу. Может, это и есть второй виртуальный wan.
удали этот адрес у себя и пропиши на компе в твоей локалке. Или ты сам шлюз?
В том-то и дело, что я. Схема такая: авайка (которой нужно присвоить адрес) ⇒ мой сервер, стоящий между локалкой и сетью провайдера ⇒ роутер провайдера (второй адрес из /30)
ну дык маршрутизируй все входящее к тебе на локальный адрес этой авайки, который она от тебя получит, только я не вижу в этой схеме какой-либо смысл
Проблема в том, что на интерфейсе сервера уже есть адрес в локальной сети провайдера для совсем других целей, и теперь на тот же линк выдали WAN-адрес. А я не знаю, как можно отмаршрутизировать в обе стороны то, что приходит на этот конкретный. Если я повешу этот адрес на сервер, то сам сервер будет принимать пакеты, а он должен их роутить дальше на авайку, по задумке. Если я не повешу на сервер адрес, роутер вообще до него не достучится, т.к. он с этим адресом в одном диапазоне (сегменте сети), и потому пытается его найти по ARP.
повесь на этот же интерфейс и маршрутизируй по ip адресу в обе стороны.
Объясни, как мне входящие на пекарню пакеты превратить в транзитные, которые идут на точно такой же IP, но лежащий за другим интерфейсом?
а железке той дай адрес из своей локалки
Дык железка сама должна иметь этот WAN, вот в чём задача-то. Это надо IPSec поднять просто на внешних адресах, он NAT не любит.
хочешь сказать железке нельзя выдать адрес из своей локалки, чтобы в дальнейшем на него маршрутизировать весь трафик? По-моему говно какоето это, а не железка.
Адрес выдать можно. Но нужно, чтобы она отсылала пакеты с этого WAN-адреса и принимала ответ на него же.
пакет приходит с внешки на твой сервер, дальше идет на локальный адрес твоей железки, который ты ей выдашь. В обратную сторону точно так же, твой сервер принимает пакет от локального адреса железки и отправляет его во внешку с внешним адресом. Обычный НАТ, железка про него может даже не знать, так как этим займется твой сервер.
Есть мнение, что внутрь IPsec эти адреса тоже заносятся, а т.к. протокол шифрованный, то случится жопа с несоответствием фактических адресов и инкапсулированных. Я хотел наиболее прозрачный вариант без всякого NAT, чтобы у железки был прямо на интерфейсе прописан WAN-адрес.
а для чего там IPsec? может можно эту железку вообще выкинуть из цепочки при наличии сервера?
Для шифрованной телефонии по SIP. Это авайка, АТС же.
а конечная точка шифрования где находится? Где-то во внешке? Если так, то тоже хз как поведет себя в таком случае. Я бы проверил на практике.
Конечная точка в Питере, там циска. Завести IPsec с прыщей не удалось, не согласовывает вторую фазу никак. Авайка, говорят, должна.
Ты слишком мудришь. По описанию ясно, что кадр, пришедший на eth1, надо без изменений передать в локалку, и так, чтобы он оказался точнёхонько на нужной машине; потом то же самое в обратную сторону. Простым перекладыванием пакетов занимается мост.
В локалке для этих данных делаешь отдельный VLAN — либо по порту свитча, либо тэгируя на самой машине назначения, как оборудование и требования безопасности позволят, — и на сервере поднимаешь в нём субинтерфейс eth0. Если в сети железо странное или конфигурация сумасшедшая, и VLAN без бубна не сделать — бери любой L2 туннель и опять же получай виртуальные интерфейсы на двух машинах. Потом сбрасываешь настройки с eth0.2 и eth1 (tap0 и eth1, ppp0 и eth1 и т. д.), создаёшь мост и добавляешь в него оба интерфейса. Всё, между интерфейсом назначения и модемом бегают пакеты, нигде не задерживаясь и ни с чем не контактируя, на нём можно ставить нужный адрес или включать dhcp.
Если в локальной сети провайдера у сервера есть другой, независимый адрес, то можно просто задать его на интерфейсе моста. Тогда сервер будет принимать и обрабатывать пакеты, подходящие этому интерфейсу, а остальное будет пересылаться туда-сюда.
http://xgu.ru/wiki/Linux_Bridge
Спасибо, про мост-то я и не подумал. Не думаю, что авайка может поднимать какие-либо туннели, там всё узкоспециализировано. Но попробовать покопать в этом направлении можно.
а тупо nat eth0→eth1 не считается?
Боюсь, не выйдет. Ну, попробовать можно, но этот говёный IPsec не факт что выдержит NAT. Потому что он реально говёный.