Given the following situation:
PC --- |aa RTR1 bb| --- |aa RTR2 bb| --- |aa RTR3 bb| etc
Each of the |aa rtr bb| is meant to be a router with two ports aa and bb.
When I do a trace route from my PC, which router port address should respond with time to live exceeded in transit message?
I seem to remember being taught to think of the router as being in as many parts as ports, so that in my scenario when aa is forwarding the packet to bb and decrements the TTL to 0, it will be the address of the aa port in the failure message. I am trying to find the definitive answer.
Since each router sends you the ICMP packet using aa and not using bb, the packet it sends will have aa's address and not bb's.
The router generates an ICMP packet and sends it to you. The source address the packet will have is the source address that this packet is sent from, aa's address.
Related
I have deployed my node js project on Heroku but I am not able to point my domain (purchased from ionos.ca) to the Heroku dns target. I have made two domains in heroku dashboard:
*.mysite.com, DNS Target: aqueous-jay-p8wmra8eyzlv3gzckdhj99je.herokudns.com
www.mysite.com, DNS Target:
experimental-turnip-ha25x6iwdwmb4xzxtsdrhj3k.herokudns.com
Then in my ionos.ca domain portal, I changed the CNAME to
aqueous-jay-p8wmra8eyzlv3gzckdhj99je.herokudns.com
But whenever I visit www.mysite.com I get an error saying
This site can’t provide a secure connection
www.mysite.com sent an
invalid response.
Visiting mysite.com gives me this error:
This site can’t be reached
mysite.com’s server IP address could not be found.
Any idea how I could fix this? I have been trying to make it work since last 1 hour :(
Something is wrong with your SSL/TLS setup. Fiddler4/Wireshark is showing Internal Error (80) I found some references that may help here: https://stackoverflow.com/questions/43436412/openssl-connection-alert-internal-error If you are using NGINX then post your config I can help with that.
Frame 138: 61 bytes on wire (488 bits), 61 bytes captured (488 bits) on interface 0
Ethernet II, Src: Fortinet_d4:fd:97 (70:4c:a5:d4:fd:97), Dst: Dell_b3:a3:f6 (b8:85:84:b3:a3:f6)
Internet Protocol Version 4, Src: 52.73.16.193, Dst: 192.168.1.40
Transmission Control Protocol, Src Port: 443, Dst Port: 63037, Seq: 1, Ack: 221, Len: 7
Transport Layer Security
TLSv1.2 Record Layer: Alert (Level: Fatal, Description: Internal Error)
Content Type: Alert (21)
Version: TLS 1.2 (0x0303)
Length: 2
Alert Message
Level: Fatal (2)
Description: Internal Error (80)
I'm on google cloud compute engine with a go webserver (no apache or nginx). I want to forward all http requests to https. My go code has ListenAndServe on port 8080 and the binary runs on port 3000 as https. This was accomplished using below.
gcloud compute forwarding-rules create pgurus --global --address
xxx.xxx.xxx.xxxx --ip-protocol TCP --ports=3000 --target-http-proxy
TARGET_HTTP_PROXY
Thanks in advance!
You can send back a 301 response when you receive an HTTP request. Google Cloud load balancer will set the X-Forwarded-Proto HTTP header with either the value HTTP or HTTPS. See this answer for details:
https://serverfault.com/a/735223
The HTTP response status code 301 Moved Permanently is used for
permanent URL redirection, meaning current links or records using the
URL that the response is received for should be updated. The new URL
should be provided in the Location field included with the response.
Trying to set up mailgun through nullmailer for email delivery from a box (let's call it a.example.com).
After some experimenting I found out that this works well for my /etc/nullmailer/remotes:
smtp.mailgun.org smtp --port=587 --user=postmaster#mg.example.com --pass=PASSWORD
But this only works on b.example.com, not on a.example.com that I wanted to set this up on. Looking further into this it looks as if mailgun is blocking my server.
On my laptop and b.example.com this works:
$ telnet smtp.mailgun.org 587
Trying 52.38.21.43...
Connected to smtp.mailgun.org.
Escape character is '^]'.
220 ak47 ESMTP ready
But on a.example.com it stops:
$ telnet smtp.mailgun.org 587
Trying 52.38.21.43...
Now I wonder if Mailgun is blocking a.example.com? And if so, if this is only temporary. And if not, what is going on here?
Found out that Scaleway.com (where a.example.com is) decided to block outgoing SMTP traffic by default.
What is the purpose of the "destination address" for a TAP/TUN device?
Pytun lets you easily set parameters of a tap/tun device:
tun = TapTunDevice(name='mytun')
tun.addr = '10.66.66.1'
tun.dstaddr = '10.66.66.2'
tun.netmask = '255.255.255.0'
tun.up()
Doing this will result in a device configured as such:
$ ifconfig mytun
mytun: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1500
inet 10.66.66.1 netmask 255.255.255.0 destination 10.66.66.2
unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 500 (UNSPEC)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
I understand that the system now has a virtual interface with IP 10.66.66.1. And it's presumable that in this scenario, the TUN device would be "connected" to a (e.g. VPN gateway) device whose IP address is 10.66.66.2.
But what purpose specifically, does it serve for the kernel to know that this is a "point-to-point" interface, and the IP address of the destination? Does it impact routing in some way that simply configuring the route table would not achieve?
Setting the dstaddr property results in a SIOCSIFDSTADDR ioctl.
The netdevice(7) man page simply says:
SIOCGIFDSTADDR, SIOCSIFDSTADDR
Get or set the destination address of a point-to-point device
using ifr_dstaddr. For compatibility, only AF_INET addresses
are accepted or returned. Setting the destination address is
a privileged operation.
I don't care about all this I want to configure my interface
You don't need to set a destination address. If you want to configure 10.66.66.1/24 on the interface, you can do:
tun = TapTunDevice(name='mytun')
tun.addr = '10.66.66.1'
tun.netmask = '255.255.255.0'
tun.up()
This interface only connects two hosts, so you don't actually need a whole /24. You can only say that 10.66.66.1 is connected to 10.66.66.2 (10.66.66.1 peer 10.66.66.2):
tun = TapTunDevice(name='mytun')
tun.addr = '10.66.66.1'
tun.dstaddr = '10.66.66.2'
tun.netmask = '255.255.255.255'
tun.up()
In this setup, the two IP addresses do not need to be in the same range at all.
Alternatively, you could use a /31, RFC3021:
tun = TapTunDevice(name='mytun')
tun.addr = '10.66.66.2'
tun.dstaddr = '10.66.66.3'
tun.netmask = '255.255.255.254'
tun.up()
Notice, how I had to change the IP addresses in order for them to be in the same /31.
What is a POINTOPOINT device?
The POINTOPOINT means that on this interface there is no Layer 2 addressing (no MAC address) on this interface:
no ARP requests (IPv4);
no NDP requests (IPv6);
the neighbour table is useless for this interface (ip neighbour);
in routing table entries for this interface the via directive is ignored;
packets on this interface are always send to the same (only) next-hop.
Examples of POINTOPOINT devices
PPP interfaces: There is not Layer 2 address for PPP as this type of interface connects a single host to another host (hence the name "point-to-point protocol")
TUN interfaces: They are IP only interfaces without a Layer 2.
POINTOPOINT means that this is a point-to-point interface (surprise!) which means that there can be only one peer connected at the other-side of the interface: you have one neighbor on this interface and you do not need to use ARP/NDP for mapping IP address to link-layer address (and you do not have link layer address at all).
In contrast, an Ethernet device is not a point-to-point interface because multiple hosts can be directly reacheable via this interface. When you send an IP packet to such a device, the network stack has to find a layer 2 identifier (using ARP, NDP) for the intended IP address and send the message to this link-layer address.
Say this, is your routing table (in Ethernet):
default via 192.0.2.1 dev eth0 proto static metric 100
192.0.2.0/24 dev eth0 proto kernel scope link src 192.0.2.2 metric 100
Multiple hosts can be directly connected to you via the eth0 interface. If you want to send a packet to 198.51.100.1, this route is selected:
default via 192.0.2.1 dev eth0 proto static metric 100
which means that among all your neighbors on the eth0 device, you have to send the packet to 192.0.2.1. In order to to that, your network stack has to find the MAC address of 192.0.2.1 by using ARP.
On a POINTOPOINT device, there is always only one neighbor so you don't need to do ARP, you only need to send the packet.
TUN and PPP interfaces are POINTOPOINT devices. Ethernet, Ethernet TAP devices and Wifi interfaces are not POINTOPOINT.
What is the destination (peer) address?
Usually the IP configuration of an interface is in the form: 192.0.2.1/24. This means that the ip address of this interface is 192.0.2.1 and that all IP in the 192.0.2.0/24 subnet are directly reachable via this interface: this adds a routing rule 192.0.2.0/24 dev tun0.
The Linux kernel supports another type of configuration when the local IP address and the peer address does not belong to the same IP subnet: 192.0.2.1 peer 198.51.100.1. This means that the IP address of this interface is 192.0.2.1 and that the IP address of the peer is 198.51.100.1: this adds a routing rule 198.51.100.1 dev tun0. A more general form can be used: 192.0.2.1 peer 198.51.100.1/24.
$ ip address show tun0
14: tun0: mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 500
link/none
inet 192.0.2.1 198.51.100.1/24 scope global tun0
valid_lft forever preferred_lft forever
The dstaddr parameter (and the SIOCSIFDSTADDR) can be used to set such as destination address.
This is useful if you don't want to allocate a common subnet for the two peers. You don't have to use a special destination address with point to point interface. You could use a standard IP subnet. Or you could allocate a /31. Using the destination address/peer configuration, you can avoid allocating a subnet for this point-to-point link.
What is the relation between the peer/destination address and POINTOPOINT devices?
These are independant. You don't have top set a destination address on a POINTOPOINT interface. You can set a destination address on a POINTOPOINT and you can do it on a normal one as well.
However, using a peer destination address is especially/mostly useful for POINTOPOINT interfaces.
If you add an interface with
inet 10.66.66.1 netmask 255.255.255.0
No matter if you create it as point to point, or not- a new routing entry will be added to the kernel for 10.66.66.1/24 with destination of the new interface.
So I don't think that there is a difference there.
I have a local SMTP email server I use for testing purposes running on my machine. It listens for SMTP on port 25. I am able to send and receive emails to it using a regular email client.
When I build a Node-RED flow that contains an e-mail output node and configure its properties with:
to: <email address>
server: localhost
port: 25
and submit a flow, I get the error:
25 Feb 16:43:24 - [error] [e-mail:<email address>] Error: 101057795:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:openssl\ssl\s23_clnt.c:794:
I am at a loss on how to proceed. Looking at the messages, it almost appears that there is some form of SSL negotiation/test at play here. Switching on trace on my SMTP server, I find the following logs each time I try and run a flow:
"TCPIP" 10708 "2016-02-25 16:43:08.294" "TCP - 127.0.0.1 connected to 127.0.0.1:25."
"DEBUG" 10708 "2016-02-25 16:43:08.298" "Creating session 22"
"SMTPD" 10708 22 "2016-02-25 16:43:08.298" "127.0.0.1" "SENT: 220 WIN7-X64 ESMTP"
"DEBUG" 9772 "2016-02-25 16:43:08.299" "Ending session 22"
It appears that the Node-RED node is sending a connection request, getting back the SMTP 220 response and then failing immediately after that.
I came across the same problem and have a nasty hack that will enable mail to go via my local exchange server's plain SMTP, with no auth.
Edit the .../61-email.js file and change it thusly:
var smtpTransport = nodemailer.createTransport({
host: node.outserver,
port: node.outport,
secure: false,
ignoreTLS: true //,
// auth: {
// user: node.userid,
// pass: node.password
// }
});
I see Dave has replied to the github issue but just to close the loop on this question.
At this time (Feb 2016) the node assumes SSL is always available and enabled, at some point we need to go back to the email node and find a simple way to expose a lot more of the nodemailer options to allow connections to a wider range of email providers both public and private.