the logging produces a lot of this, don't know if this is useful:
(the one with the problem,web2.com)
12839 Oct 31 01:34:39 www kernel: [11427688.839066] KLR LOG INPUT: IN=eth0
OUT=
MAC=00:19:99:23:07:a1:00:1d:71:9b:e9:c0:08:00 SRC=83.242.252.140
DST=xx.xx
x.xx.39 LEN=54 TOS=0x00 PREC=0x00 TTL=48 ID=9878 PROTO=UDP SPT=63440
DPT=5
3 LEN=34
12840 Oct 31 01:34:39 www kernel: [11427688.839380] KLR LOG OUTPUT: IN=
OUT=eth0
SRC=xx.xxx.xx.39 DST=83.242.252.140 LEN=54 TOS=0x00 PREC=0x00 TTL=64
ID=3
7760 PROTO=UDP SPT=53 DPT=63440 LEN=34
(the other one which works)
12841 Oct 31 01:34:39 www kernel: [11427689.127311] KLR LOG INPUT: IN=eth0
OUT=
MAC=00:19:99:23:07:a1:00:1d:71:9b:e9:c0:08:00 SRC=85.51.193.137
DST=xx.xxx
.xxx.50 LEN=100 TOS=0x00 PREC=0x00 TTL=47 ID=33959 DF PROTO=TCP
SPT=41330
DPT=22 WINDOW=661 RES=0x00 ACK PSH URGP=0
12842 Oct 31 01:34:39 www kernel: [11427689.133085] KLR LOG OUTPUT: IN=
OUT=eth0
SRC=xx.xxx.xxx.50 DST=85.51.193.137 LEN=100 TOS=0x10 PREC=0x00
TTL=64 ID=
55242 DF PROTO=TCP SPT=22 DPT=41330 WINDOW=185 RES=0x00 ACK PSH URGP=0
12843 Oct 31 01:34:39 www kernel: [11427689.205662] KLR LOG INPUT: IN=eth0
OUT=
MAC=00:19:99:23:07:a1:00:1d:71:9b:e9:c0:08:00 SRC=85.51.193.137
DST=xx.xxx
.xxx.50 LEN=52 TOS=0x00 PREC=0x00 TTL=47 ID=33960 DF PROTO=TCP
SPT=41330 D
PT=22 WINDOW=661 RES=0x00 ACK URGP=0
12844 Oct 31 01:34:40 www kernel: [11427689.333075] KLR LOG INPUT: IN=eth0
OUT=
MAC=00:19:99:23:07:a1:00:1d:71:9b:e9:c0:08:00 SRC=85.51.193.137
DST=xx.xxx
.xxx.50 LEN=100 TOS=0x00 PREC=0x00 TTL=47 ID=33961 DF PROTO=TCP
SPT=41330
DPT=22 WINDOW=661 RES=0x00 ACK PSH URGP=0
El miércoles, 31 de octubre de 2012 01:04:54 UTC+1, Karl escribió:
>
> DEV$ openssl s_client -connect web2.com:443
> connect: Connection refused
> connect:errno=111
>
>
> First one works, of course, iptables are the same for both
>
> DEV$ openssl s_client -connect web1.net:443
> CONNECTED(00000003)
> depth=1 C = IL, O = StartCom Ltd., OU = Secure Digital Certificate
> Signing, CN = StartCom Class 1 Primary Intermediate Server CA
> verify error:num=20:unable to get local issuer certificate
> verify return:0 etc etc
>
> **********
> iptables -t nat -A PREROUTING -p tcp -i eth0 -d xx.xxx.xxx.50 --dport 80 -j
> REDIRECT --to-port 3003
> iptables -t nat -A PREROUTING -p tcp -i eth0 -d xx.xxx.xx.39 --dport 80 -j
> R
> EDIRECT --to-port 3004
> # protocol conversion done with zappa ensure-https listening 3003 and 3004
> #also redirect direct hits on https 443 to 3443 ...
> iptables -t nat -A PREROUTING -p tcp -i eth0 -d xx.xxx.xx.50 --dport 443
> -j
> REDIRECT --to-port 3443
> iptables -t nat -A PREROUTING -p tcp -i eth0 -d xx.xxx.xx.39 --dport 443
> -j
> REDIRECT --to-port 3445
>
>
>
>
> El miércoles, 31 de octubre de 2012 00:16:28 UTC+1, Karl escribió:
>>
>> it's one interface with two ip-addresses set up by the provider
>> *******
>> *-network
>> description: Ethernet interface
>> product: MCP51 Ethernet Controller
>> vendor: nVidia Corporation
>> physical id: 14
>> bus info: pci@0000:00:14.0
>> logical name: eth0
>> version: a3
>> serial: 00:19:99:23:07:a1
>> size: 100MB/s
>> capacity: 1GB/s
>> width: 32 bits
>> clock: 66MHz
>> capabilities: pm bus_master cap_list ethernet physical mii 10bt
>> 10bt-fd 100bt 100bt-fd 1000bt-fd autonegotiation
>> configuration: autonegotiation=on broadcast=yes
>> driver=forcedeth driverversion=0.64 duplex=full ip=xx.xxx.xxx.50 latency=0
>> link=yes maxlatency=20 mingnt=1 multicast=yes port=MII speed=100MB/s
>> resources: irq:23 memory:f2202000-f2202fff ioport:8c38(size=8)
>> *********
>> PROD# ifconfig
>> eth0 Link encap:Ethernet HWaddr 00:19:99:23:07:a1
>> inet addr:xx.xxx.xxx.50 Bcast:xx.xxx.xxx.50
>> Mask:255.255.255.255
>> inet6 addr: xxxx::xxx:xxxx:fe23:7a1/64 Scope:Link
>> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
>> RX packets:39140493 errors:0 dropped:0 overruns:0 frame:0
>> TX packets:41299455 errors:0 dropped:0 overruns:0 carrier:0
>> collisions:0 txqueuelen:1000
>> RX bytes:5145305162 (4.7 GiB) TX bytes:25999465836 (24.2 GiB)
>> Interrupt:23 Base address:0x8000
>>
>> eth0:0 Link encap:Ethernet HWaddr 00:19:99:23:07:a1
>> inet addr:xx.xxx.xx.39 Bcast:xx.xxx.xx.255 Mask:255.255.255.0
>> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
>> Interrupt:23 Base address:0x8000
>>
>> lo Link encap:Local Loopback
>> inet addr:127.0.0.1 Mask:255.0.0.0
>> inet6 addr: ::1/128 Scope:Host
>> UP LOOPBACK RUNNING MTU:16436 Metric:1
>> RX packets:3113201 errors:0 dropped:0 overruns:0 frame:0
>> TX packets:3113201 errors:0 dropped:0 overruns:0 carrier:0
>> collisions:0 txqueuelen:0
>>
>>
>> El miércoles, 31 de octubre de 2012 00:05:38 UTC+1, Ben Noordhuis
>> escribió:
>>>
>>> On Tue, Oct 30, 2012 at 7:16 PM, Karl <[email protected]> wrote:
>>> > Hi,
>>> > (Debian 6, Node 8.10, express 3, zappa 4.10)
>>> > I have requested a second ip number for my remote box
>>> > and want two run a second nodejs app on that ip. The ip
>>> > runs on the same card I guess (remote box)
>>> >
>>> > So I have
>>> > web1.net on ip1
>>> > web2.com on ip2
>>> >
>>> > and use iptables to redirect from 80 and 443 to
>>> > my ports
>>> > PROD# iptables -L -t nat
>>> > Chain PREROUTING (policy ACCEPT)
>>> > target prot opt source destination
>>> > REDIRECT tcp -- anywhere www.web1.net tcp dpt:www
>>> redir
>>> > ports 3003
>>> > REDIRECT tcp -- anywhere www.web2.com tcp dpt:www
>>> redir
>>> > ports 3004
>>> > REDIRECT tcp -- anywhere www.web1.net tcp dpt:https
>>> redir
>>> > ports 3443
>>> > REDIRECT tcp -- anywhere www.web2.com tcp dpt:https
>>> redir
>>> > ports 3445
>>> >
>>> > and ensure-https to protocol change all 80 traffic to 443:
>>> >
>>> > var ensure=require('ensure-https');
>>> > var options={
>>> > 'forceHost':undefined, // If this is set then the destination URL
>>> is
>>> > forced to this hostname
>>> > 'host':'localhost', // This is the default host to use (for
>>> HTTP/0.9
>>> > clients) (default: localhost)
>>> > 'sslHost':443, // This is the port of your HTTPS server if
>>> it is
>>> > not 443 (default: 443)
>>> > 'statusCode':301 // This is the HTTP Status-Code to use
>>> > (default: 301)
>>> > };
>>> > var server=ensure.createServer(options);
>>> > server.listen(3004,'ip1...');
>>> >
>>> > and the same for the other one, ip2 (web2.com).
>>> >
>>> > My *problem*: web1.net works fine when users enter
>>> > www.web1.net or https://web1.net or even https://web1.net:3443
>>> > but web2.com will only work if I give the https://web2.net:3445format
>>> > otherwise I get "unable to connect"
>>> >
>>> > They have two separate certificates, they works with all browsers I
>>> tried.
>>> >
>>> > /etc/hostname has "www.bodywrappers.net"
>>> >
>>> > /etc/hosts has
>>> > 127.0.0.1 localhost.localdomain localhost
>>> > ip1... www.web1.net web1.net
>>> > ip1.. sxxxxxxx.online.de (this is a rented box)
>>> > ip2... www.web2.com web2.com
>>> > The A records are redirected <-> from a different provider but that
>>> works
>>> > with web1.net
>>> >
>>> > /etc/networks/interfaces
>>> > auto lo eth0
>>> > iface lo inet loopback
>>> >
>>> > iface eth0 inet dhcp
>>> >
>>> > auto eth0:0
>>> > iface eth0:0 inet static
>>> > address ip2...
>>> > netmask 255.255.255.0
>>> > network ip2....0
>>> > broadcast ip2....255
>>> >
>>> > Thanks, I'm a bit lost. Feel free to comment more compact solutions,
>>> too, of
>>> > course. Still a bit green here.
>>>
>>> What does `/sbin/ipconfig` print? If you have only one interface with
>>> one address, you can - realistically speaking - forget about
>>> multi-domain SSL.
>>>
>>
--
Job Board: http://jobs.nodejs.org/
Posting guidelines:
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
