local IP address

Igor Savenko igor.bliss на gmail.com
Чт Фев 28 20:17:16 UTC 2019


Спасибо, но раз уж проблема понятна -- становится все проще. Надо
разобраться с redirect'ом, чтобы трафик приезжал туда, куда должен, а
дальше уже, как я уже понял, разрулимся через $server_addr.

чт, 28 февр. 2019 г. в 22:11, Fedor Dikarev <fe на hamilton.rinet.ru>:

> В общем я подумал еще раз, и понял что или не понимаю исходную задачу,
> или не понимаю пути ее решения.
>
> Но вдруг это поможет:
> у нас тоже есть задача, что разные сервисы должны слушаться на разных
> адресах: один адрес для public-сервисов, второй для ограниченного круга
> лиц, третий для другого круга и т.д.
>
> Решаем это так: в конфиге nginx-а для каждого сервера пишем listen ip:80
> для каждого уровня доступа свой ip адрес, дальше server_name нужный для
> сервиса. А сервисы уже в docker-е, и в nginx-е просто proxy_pass на
> expose-нутый порт. И все работает. (понятно что эти конфиги пишем не
> руками, но как идея. хотя могу и программой поделиться, если задача
> такая же)
>
> 28.02.19 23:00, Fedor Dikarev пишет:
> > А это точно тестируемый конфиг приведен? Может там еще что-то есть?
> >
> > Тут получается что nginx проксирует сам на себя, и я даже не поленился
> > это попробовать и получил ожидаемое:
> >> # cat localhost.conf server {
> >>         listen 80;
> >>
> >>         access_log /var/log/nginx/local-access.log;
> >>         location / { return 200 "$server_addr\n"; }
> >>         location /one {
> >>                 proxy_set_header    X-Server-IP $server_addr;
> >>                 proxy_pass          $scheme://$server_addr;
> >>         }
> >> }
> >
> >> # grep -c /one /var/log/nginx/local-access.log ; curl
> >> http://192.168.255.5/one ; grep -c /one /var/log/nginx/local-access.log
> >> 909
> >> <html>
> >> <head><title>502 Bad Gateway</title></head>
> >> <body>
> >> <center><h1>502 Bad Gateway</h1></center>
> >> <hr><center>nginx/1.15.8</center>
> >> </body>
> >> </html>
> >> 1813
> >
> >> grep -c /one /var/log/nginx/local-access.log ; curl
> >> http://192.168.255.5/one ; grep -c /one /var/log/nginx/local-access.log
> >> 1813
> >> <html>
> >> <head><title>502 Bad Gateway</title></head>
> >> <body>
> >> <center><h1>502 Bad Gateway</h1></center>
> >> <hr><center>nginx/1.15.8</center>
> >> </body>
> >> </html>
> >> 2820
> >
> >
> > 28.02.19 21:35, Igor Savenko пишет:
> >> Хм. Интересно получается.
> >> Интерфейсы на хосте (поскольку это, видимо, KVM guest, то все они,
> >> наверное, выставлены в один бридж, но это не имеет отношения к делу):
> >> [root на blissstagingserver1 imunify360-webshield]# ip -o -4 ad | grep eth
> >> 2: eth0    inet 10.0.0.143/26 <http://10.0.0.143/26> brd 10.0.0.191
> >> scope global eth0\       valid_lft forever preferred_lft forever
> >> 3: eth1    inet 10.0.0.146/26 <http://10.0.0.146/26> brd 10.0.0.191
> >> scope global eth1\       valid_lft forever preferred_lft forever
> >> 4: eth2    inet 10.0.0.147/26 <http://10.0.0.147/26> brd 10.0.0.191
> >> scope global eth2\       valid_lft forever preferred_lft forever
> >>
> >>      server {
> >>          listen *:80;
> >>          location / {
> >>              proxy_set_header    X-Server-IP $server_addr;
> >>              proxy_pass          $scheme://$server_addr;
> >>          }
> >>      }
> >>
> >> Бекэндом выступает питоновский http.server, который просто выводит в
> >> консоль заголовки Host и X-Server-IP
> >>
> >> $ curl -L -v http://10.0.0.146
> >> * Rebuilt URL to: http://10.0.0.146/
> >> *   Trying 10.0.0.146...
> >> * TCP_NODELAY set
> >> * Connected to 10.0.0.146 (10.0.0.146) port 80 (#0)
> >>  > GET / HTTP/1.1
> >>  > Host: 10.0.0.146
> >>  > User-Agent: curl/7.52.1
> >>  > Accept: */*
> >>  >
> >> < HTTP/1.1 200 OK
> >>
> >> На это питоновский сервер пишет
> >> Host: 10.0.0.146, IP: 10.0.0.143
> >>
> >> То есть $server_addr -- 10.0.0.143, a не 146, как ожидалось...
> >>
> >> То есть в $server_add
> >>
> >> чт, 28 февр. 2019 г. в 18:37, Fedor Dikarev <fe на hamilton.rinet.ru
> >> <mailto:fe на hamilton.rinet.ru>>:
> >>
> >>
> >>     28.02.2019 19:20, Igor Savenko пишет:
> >>      > Доброе время суток!
> >>      > Подскажите, есть ли вообще способ определить, на какой именно
> >>     адрес был
> >>      > послан запрос (хост имеет несколько интерфейсов с разными
> >>     адресами или
> >>      > несколько secondary адресов на одном интерфейсе), чтобы
> >> спроксировать
> >>      > этот запрос на корректный адрес upstream. который тоже слушает на
> >>     localhost.
> >>      > Схема проста:
> >>      > server {
> >>      >     listen *:80;
> >>      >     server_name _;
> >>      >     location / {
> >>      >         proxy_pass http://$server_addr;
> >>      >     }
> >>      > }
> >>      >
> >>      > При этом у хоста 2 адреса на интерфейсах, скажем, 1.2.3.4 и
> >> 5.6.7.8.
> >>      > Хотелось бы, чтобы при запросе на 5.6.7.8 в $server_addrбыл не
> >>     1.2.3.4
> >>      > (как первый и дефолтный адрес, а 5.6.7.8). Если можно это решить
> >>      > программно (в каком-нибудь модуле, то подскажите, пожалуйста.
> >>     Спасибо!
> >>
> >>     Про правильный server_addr не понял, а сейчас что не так?
> >>      > # ifconfig lo0
> >>      > lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
> >>      >         options=600003<RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6>
> >>      >         inet6 ::1 prefixlen 128
> >>      >         inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
> >>      >         inet 127.0.0.1 netmask 0xff000000
> >>      >         inet 192.168.255.1 netmask 0xffffffff
> >>      >         inet 192.168.255.2 netmask 0xffffffff
> >>      >         inet 192.168.255.3 netmask 0xffffffff
> >>      >         inet 192.168.255.4 netmask 0xffffffff
> >>      >         inet 192.168.255.5 netmask 0xffffffff
> >>      >         nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
> >>      >         groups: lo
> >>
> >>      > # cat localhost.conf
> >>      > server {
> >>      >         listen 80;
> >>      >
> >>      >         location / { return 200 "$server_addr\n"; }
> >>      > }
> >>
> >>      > # for h in 2 3 4; do curl 192.168.255.$h; done
> >>      > 192.168.255.2
> >>      > 192.168.255.3
> >>      > 192.168.255.4
> >>
> >>
> >>      >
> >>      > _______________________________________________
> >>      > nginx-ru mailing list
> >>      > nginx-ru на nginx.org <mailto:nginx-ru на nginx.org>
> >>      > http://mailman.nginx.org/mailman/listinfo/nginx-ru
> >>      >
> >>     _______________________________________________
> >>     nginx-ru mailing list
> >>     nginx-ru на nginx.org <mailto:nginx-ru на nginx.org>
> >>     http://mailman.nginx.org/mailman/listinfo/nginx-ru
> >>
> >>
> >> _______________________________________________
> >> nginx-ru mailing list
> >> nginx-ru на nginx.org
> >> http://mailman.nginx.org/mailman/listinfo/nginx-ru
> >>
> >
>
> --
> Fedor Dikarev
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
----------- следущая часть -----------
Вложение в формате HTML было извлечено…
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20190228/856dd284/attachment-0001.html>


Подробная информация о списке рассылки nginx-ru