Mensaje archivado #895 de la Lista ecs-isp@2rosenthals.com

De:	"Lewis G Rosenthal" <ecs-isp@2rosenthals.com>	Encabezados Completos Mensaje no decodificado
Asunto:	Re: [eCS-ISP] FTP problem
Fecha:	Mon, 30 Sep 2024 22:54:07 -0400
Para:	eCS ISP Mailing List <ecs-isp@2rosenthals.com>

Hi... On 09/30/24 07:40 pm, Steven Levine wrote: In <list-11054999@2rosenthals.com>, on 09/30/24 at 06:23 PM, "Lewis G Rosenthal" <ecs-isp@2rosenthals.com> said: Hi there, True, however, it won't reveal where along the line the connection is failing, which was Doug's question. telnet, like FTP, will only show whether a connection can be made, but not where (or why) it may be failing. True, but if the problem is really some router in the middle of the path there might be nothing that can be fixed or even identfied as the source of the problem. While it is true that nothing may be done to adjust that router, I have an interesting tale to tell. Some years ago, I had a rather lucrative deal in place for a monthly fee to host a remote desktop on a server in my rack, which proxied an incoming VPN connection through a series of static IPs in my block. To make matters more diverse, I added site-to-site VPN connections to several other geographically disparate locations, each with multiple public IPv4 addresses, and the hosted desktop's browser had the option of selecting which one to use. The request was made by a client physically located in India, who was engaged in something he termed "web arbitrage," which essentially was reselling g--gle ad services. To do this, g--gle would only allow US addresses t be used, and the same address could only be used for a certain number of transactions per day. I didn't pretend to understand the business model, as my job was only to land the traffic and relay it outbound. In the beginning, we found that the client would have intermittent difficulty negotiating a VPN connection to New York from his office in Mumbai. Dave Saville and I set about to try some different traceroute scans, and we determined that there was apparently *one* router along the way which stubbornly refused to properly forward the traffic. The router's owner was rather unresponsive, so I built a static routing table around it, implemented it on my end of the connection, and explained to the client how to do the same on his end. That solved the problem. There was always a chance that a failure along the way could end up with us traversing the very router we sought to avoid, but it never actually happened. In this case, Doug could do something similar in the future if the need arose and he was reasonably sure that the source network would remain constant. I was thinking that tracerte from both ends might be end might be an interesting test. How useful it might be for providing additional information, who knows? Indeed. In our case, I ran a traceroute from NY and Dave ran one from his place, outside London. I noted where my traffic stopped and where his continued (at a certain point in the testing, when I could get traffic to go through, we could see where our paths merged closer to Mumbai), and I then backed up to work out a static route to one of the routers he was hitting farther (hopefully) along the way, bypassing the uncooperative one. It took a bit more finagling, including multiple test runs (again, routers are so darned intelligent that they don't always route the same way twice in succession - because they're also so budget conscious - thanks OSPF), but we ended up with a useful, reliable path. I had that deal in place for almost two years, bouncing traffic out of 18 IPs at my place in NY (13 over fiber, 5 over DOCSIS 3 cable), 5 out of Brooklyn, 5 out of Jeff Race's place in Boston, and 5 out of my office down here in Leesburg. It was quite the thing, and required very little attention on my part once the setup was in place and running. Much of the internal setup relied on iptables on the Linux side, necessary to get the firewall to cooperate and recognize the traffic coming out of the box as coming from different local IPs, even though the MAC was the same, allowing me to get the firewall to handle the different local IPs differently for outbound traffic routing. It was fun stuff. I should have taken more detailed notes of the setup. I always wanted to write a paper on it. the far side), iptrace won't reveal much on the server side. If the SYN packets don't make it through, again, sadly, it won't reveal where the packets were dropped. Agreed. I'm not smart enough to diagnose problems in stuff that is effectively invisible. For example, if I try to access one of Dan's servers with tracerte dnacih.com tracete hangs at 12.83.97.113, which appears to be an AT&T router. We know that 12.83.97.113 is working fine in the sense that I can access any of the services running on dnacih.com. However, attempting to access 12.83.97.113 by any the typical ports gets no response. However, if I could not access the server, the tracerte results would tell me nothing because the result are the same whether or not I can access Dan's server. The trick is in having someone else try the same thing from a different source network, and then see if you can suss out a better router farther along the path from where your traffic is stopping. Clearly, this has been made more difficult in recent years as more router operators blackhole more traffic (for reasons of their own). I recall when AT&T decided at one time that they were going to block all ICMP from their networks. That brought a smile to my face (and that strategy didn't last very long, either). -- Lewis ------------------------------------------------------------- Lewis G Rosenthal, CNA, CLP, CLE, CWTS, EA Rosenthal & Rosenthal, LLC www.2rosenthals.com visit my IT blog www.2rosenthals.net/wordpress -------------------------------------------------------------

Suscribirse: Todos, Compendio, Indice.
Desuscribirse
Correo al dueño de la Lista