Can't Get Samba Permissions Correct
-
@Dashrender said:
Hairpin still requires the use of Pertino. The difference from what I read, Scott will undoubtedly correct me if I'm wrong ;), is that the linux box that you're Pertino'ing to does nothing more than pass traffic from the Pertino client to the desired IP.
Like a firewall with port forwarding/NAT enabled, the linux box would simply get a request for the IP/port of the NAS and forward that request to the NAS.
Oh ok, so if you use a Linux box as a hairpin, you can only use it to one IP?
-
@thanksaj said:
@Dashrender said:
Hairpin still requires the use of Pertino. The difference from what I read, Scott will undoubtedly correct me if I'm wrong ;), is that the linux box that you're Pertino'ing to does nothing more than pass traffic from the Pertino client to the desired IP.
Like a firewall with port forwarding/NAT enabled, the linux box would simply get a request for the IP/port of the NAS and forward that request to the NAS.
Oh ok, so if you use a Linux box as a hairpin, you can only use it to one IP?
Great question - I guess that would depend... I know Linux can be multi-homed (i.e. have more than IP address) but the question is, will Pertino see all local IPs and route traffic for those IPs as such? If yes, then you can probably get away with one linux box, otherwise you'll need multiple.
-
I haven't actually used Pertino yet so this brings a question to mind.
When you are on a remote machine using Pertino to say a server in your office, when you connect to that server, what IP are you using? The servers real IP or the Pertino one?
Like the above mentioned hairpinning, it's my understanding the Pertino kinda does the same thing - The Pertino client on the server has it's own IP address which is registered into the Pertino cloud, Does the Pertino client have a translation list of Pertino IPs to actual device IPs, and all the end user has to use are the real IPs? I also THINK (but could be wrong) that Pertino allows the use of your own DNS servers, so if you ping server.company.com it will check your internal DNS server in the office for the real IP of the server and Pertino acts like an invisible switch just making sure the traffic gets to the correct box.
Is that right?
-
@Dashrender said:
I haven't actually used Pertino yet so this brings a question to mind.
When you are on a remote machine using Pertino to say a server in your office, when you connect to that server, what IP are you using? The servers real IP or the Pertino one?
Like the above mentioned hairpinning, it's my understanding the Pertino kinda does the same thing - The Pertino client on the server has it's own IP address which is registered into the Pertino cloud, Does the Pertino client have a translation list of Pertino IPs to actual device IPs, and all the end user has to use are the real IPs? I also THINK (but could be wrong) that Pertino allows the use of your own DNS servers, so if you ping server.company.com it will check your internal DNS server in the office for the real IP of the server and Pertino acts like an invisible switch just making sure the traffic gets to the correct box.
Is that right?
Pertino has to be on both the source and destination device. Every Pertino network uses the 50.203.224.0 network, so the Pertino adapter, either in Windows or Linux or whatever, uses that IP. You can go by hostname or the Pertino IP. So if I ping plex-server from my work computer, which has Pertino on it, it will ping the Pertino adapter of the remove device. It's a split-stack method of VPN.
-
I realize that Pertino has to be on both sides. If you're on your remote device and you ping the real internal IP of the server in your office (assuming Pertino is installed there as well) will you get a response? I thought you would.
-
From my understanding a hairpin is basically a network bridge like a router. It just takes all info going in and passes it to the appropriate point on the other side.
On your linux server does the Pertino connection appear as an independent interface?
-
@coliver said:
From my understanding a hairpin is basically a network bridge like a router. It just takes all info going in and passes it to the appropriate point on the other side.
On your linux server does the Pertino connection appear as an independent interface?
This is not the case for a router like an ASA. A hairpin for an ASA is in interface and back out that same interface. No bridging at all.
-
@Dashrender said:
@coliver said:
From my understanding a hairpin is basically a network bridge like a router. It just takes all info going in and passes it to the appropriate point on the other side.
On your linux server does the Pertino connection appear as an independent interface?
This is not the case for a router like an ASA. A hairpin for an ASA is in interface and back out that same interface. No bridging at all.
Alright, well then I will look into it a bit. I always like new networking topics.
-
While the general idea might be what Scott is meaning, I really don't see the solution to AJ's problem as a hairpin - it's really just routing, actually NATing....but it wouldn't really be NATing (or would it) if you're pointing to the real IP on the linux box and the linux box is just forwarding that traffic to another internal source - I guess it would NAT doesn't mean you have to change IP schemes...
-
@Dashrender said:
I realize that Pertino has to be on both sides. If you're on your remote device and you ping the real internal IP of the server in your office (assuming Pertino is installed there as well) will you get a response? I thought you would.
No, when you're remote, you ping the Pertino IP or the hostname, which never changes. When you're internal, you can ping either.
-
@coliver said:
From my understanding a hairpin is basically a network bridge like a router. It just takes all info going in and passes it to the appropriate point on the other side.
On your linux server does the Pertino connection appear as an independent interface?
Yes.
ifconfig results:
eth0 Link encap:Ethernet HWaddr 00:0c:29:4b:35:b2
inet addr:172.16.255.20 Bcast:172.16.255.255 Mask:255.255.255.0
inet6 addr: fe80::20c:29ff:fe4b:35b2/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:127046 errors:0 dropped:0 overruns:0 frame:0
TX packets:283744 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:33435018 (33.4 MB) TX bytes:436448592 (436.4 MB)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:65536 Metric:1
RX packets:193 errors:0 dropped:0 overruns:0 frame:0
TX packets:193 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:29941 (29.9 KB) TX bytes:29941 (29.9 KB)pertino0 Link encap:Ethernet HWaddr 7e:a6:0f:81:df:5f
inet addr:50.203.224.9 Bcast:50.203.224.255 Mask:255.255.255.0
inet6 addr: fe80::7ca6:fff:fe81:df5f/64 Scope:Link
inet6 addr: 2001:470:813b::1bcf:0:f02/48 Scope:Global
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2717 errors:0 dropped:0 overruns:0 frame:0
TX packets:1765 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:261357 (261.3 KB) TX bytes:464420 (464.4 KB)
