> 66.249.90.x and 66.249.91.x were indeed blocked.
Ahh... that explains a lot!
> I don't know how among many possible ways that those addresses got
> on the blocking list, as it was too long ago for the current logs
> to reflect it.
Maybe there was "a lot" of traffic? Possibly also "a lot" in terms of those days.
But of course everyone running a website on an IPIP tunneled ampr.org site has some
responsibility in this. Make sure when you have areas with lots of data, those large
files are not indexed. This can be done using robots.txt files, headers in the page
content, etc.
E.g. you run a site with equipment schematics. You have some text pages with indexes
and a lot of huge PDF files with the scanned schematics themselves. It is not difficult
to make Google (and other crawlers) index only the text index files and not the PDFs.
Or you have a local amateur group site and it has lots of photographs and maybe even
video of the fieldday or other events. It is possible to make the huge 30-megapixel
photographs and the video not being indexed and only index the text content and maybe
the thumbnails.
When this is done in a responsible manner, indexing the websites that are behind IPIP
tunnels should not cause much more "useless traffic" than there already is due to
jerks like shodan.io, stretchoid.com and the like.
(those are scanning the entire IP range, not just websites that have been announced
to Google or are linked from other sites)
Rob
Hi All!
I wanted to thank everyone for their help with the google issue I’m having. It is not resolved but I’ve made some discoveries. It looks like a fair number of the ampr.org sites that come up on google may in fact be done via BGP. Rob’s is and the others that I did a traceroute on, terminate on an address that is not 44.
But that said, I now think this is a 100% Google issue. I don’t know what kind of stupidity they are up to but Yandex and Bing, have no problems indexing my site. I have read of others having similar issues. Bing and Yandex actually use Google’s same system for verification and they crawl just fine.
73
Roger
VA7LBB
On May 9, 2019, at 02:09, Rob Janssen <pe1chl(a)amsat.org> wrote:
>> Now that I know where to look.. PMTU has caused me a lot of headache
>> lately. I believe it could be the problem. Sending large packets to
>> 44.135.179.28 yields no reply. tracepath does send back need to frag,
>> but when TTL expires at amprgw.ucsd.edu. I believe amprgw.ucsd.edu
>> should send back need-to-frag for higher TTLs as well.
>
> That is always a bit tricky, often those packets *are* sent back but they
> are blocked somewhere closer to the client, and/or the TCP stack of the
> system does not process them in a reasonable way.
>
> It is possible to work around that by adjusting the MSS of a TCP SYN
> passing the point where outgoing MTU is smaller than incoming MTU
> (incidentally something that I invented and implemented in NET in 1995,
> but later almost any router and routing software started to support it)
> so as a result the TCP segments sent by the endpoints will be smaller and
> won't need to be fragmented.
>
> Roger can do that on his own server, e.g. like this:
>
> iptables -t mangle -A INPUT -p tcp --syn -j TCPMSS --set-mss 1400
> iptables -t mangle -A OUTPUT -p tcp --syn -j TCPMSS --set-mss 1400
>
> Or on a router/gateway along the path (using FORWARD instead of INPUT/OUTPUT).
>
> However, I'm not convinced that this is the problem as the site works OK
> for me over internet. Why wouldn't it work for Google then?
>
> Rob
>
>
> we have a very similar system here in Italy.
Nice!
> looking at the high number of access requests, in the end,
> the actual number of OMs whom is using the system is very low.
> Many of them looses interest or request the access just as a "nice to
> have".
That is always a bit of a problem. People ask for a certificate, connect to
the server and then they think "well, what do I do next?" or "what can I do
now that I cannot do on internet?".
There are some information sites having small lists of sites that can be
visited and some search engines, and I have proposed to setup a more standardized
and automated website to find running services and a description what they offer,
but I do not consider it my task (as an address coordinator and admin for part of
the systems) to build and maintain that. Others can pick up that part of the work.
Without a clear description of what we can do with the network, it is not
surprising that not everybody keeps using it.
But it looks like you have quite some connected users too! Good!
Rob
Thanks everyone for the MTU discussion/ suggestions on the google issues. I’ll try adjusting the MTU.
The https issue only just started. I had a letsencrypt certificate and auto-renew screwed up and I haven’t had a chance to fix it. That wasn’t a problem when I started this google thread, so won’t be the main issue with google.
Roger.
VA7LBB
On May 9, 2019, at 04:35, Scott Nicholas <scott.nicholas(a)scottn.us> wrote:
>> However, I'm not convinced that this is the problem as the site works OK
>> for me over internet. Why wouldn't it work for Google then?
>
> We have to speculate somewhat..I don't know what the crawler uses for
> TCP stack. I know each OS is different in the ways it deals with MTU
> and blackholes.
> I did a wireshark capture on my Windows desktop and show a lot of
> black/red. I lowered my MTU by 40 and re-tried and there was lots of
> green.
> The TCP MSS coming from the web server was already lowered by 20. I
> don't know what it looks like on the far end. I'm also speculating
> that it's not getting ICMP or seeing a lower MSS for me.
>
> Another reason I saw red -- a few links point to HTTPS and it is not
> enabled. Fix that, and set a lower MTU on the host, and we'll at
> least fix *some* problem. Maybe not the Googling indexing one. :)
>
> Regards,
> Scott
>
Nate,
Sorry, I'll have to update that page to make it more clear. The
purpose of it for setting up your own Open VPN server that uses LoTW
certificates to mimic what Heikki is doing.
When you are running a sever then obviously you are in control of the
address range it offers as part of the dynamic assignment. When you
are the client/ end-user then obviously no.
Steve, KB9MWR
On Fri, May 10, 2019 at 7:27 PM Nate Sales via 44Net
<44net(a)mailman.ampr.org> wrote:
>
>
>
>
> ---------- Forwarded message ----------
> From: Nate Sales <nate.wsales(a)gmail.com>
> To: AMPRNet working group <44net(a)mailman.ampr.org>
> Cc:
> Bcc:
> Date: Fri, 10 May 2019 17:24:47 -0700
> Subject: Re: [44net] VPN Question
> Thank you for explaining, I totally misunderstood the purpose. Either way,
> thanks for the quick responses, I really appreciate it. I was mainly
> looking at https://qsl.net/k/kb9mwr//wapr/tcpip/lotw-vpn.html which led me
> to believe that was possible.
> -Nate
>
>
> On Fri, May 10, 2019 at 2:28 PM Heikki Hannikainen <hessu(a)hes.iki.fi> wrote:
>
> >
> > Hi,
> >
> > No. If you're using ipencap to join the amprnet tunnel mesh, you don't
> > need to use my VPN service.
> >
> > If you use the VPN, you can't use ipencap at the same time.
> >
> > With the VPN you get a single tunnel to the Amprnet, and you'll be
> > assigned a dynamic 44.139.11.x IP address during the VPN session.
> >
> > It is not possible to route your own 44.x.y.z subnet via this VPN. You're
> > limited to communicating with the dynamic 44.139.11.x address assigned to
> > you by the VPN server. Sorry!
> >
> >
> > On Fri, 10 May 2019, Nate Sales wrote:
> >
> > > Ok thank you! So the ip in the 44.139.11.x range becomes the gateway,
> > then
> > > just set up ipencap like normal?
> > > -Nate
> > >
> > > On Fri, May 10, 2019 at 8:29 AM Heikki Hannikainen <hessu(a)hes.iki.fi>
> > wrote:
> > >
> > >> On Thu, 9 May 2019, Ruben ON3RVH wrote:
> > >>
> > >>> If the subnet is routed to the openvpn server, the openvpn server can
> > >>> route that network to the endpoint.
> > >>
> > >> This particular openvpn server (that I run) does not offer such a
> > service.
> > >> It allows you to get connected to AMPRnet, but I don't have the time to
> > do
> > >> custom configurations to route subnets or do other per-user manual
> > >> tweaking at this time.
> > >>
> > >> So, Rob's "You can't" answer is correct. You'll get the dynamic
> > >> 44.139.11.x IP address and you can use that to communicate with the
> > >> amprnet. Sorry!
> > >>
> > >> - Hessu
> > >>
> > >>
> > >>> On 9 May 2019, at 11:14, Rob Janssen <pe1chl(a)amsat.org> wrote:
> > >>>
> > >>>>> I cant figure out where to go
> > >>>>> from here. Can anyone point me in the right direction in how to get
> > the
> > >>>>> routes set up for my little subnet?
> > >>>>
> > >>>> You can't.
> > >>>> Such a VPN offers you a connection, with an IP, and routes traffic for
> > >> that IP to you.
> > >>>> You cannot route arbitrary subnets over that because you cannot setup
> > >> routes on the VPN server
> > >>>> pointing to your subnet.
> > >>>>
> > >>>> If that is what you want, you need to setup a gateway on the IPIP
> > >> tunnel mesh.
> > >>>> Or, find someone else who has done that and arrange for some VPN
> > >> between you two.
> > >>>>
> > >>>> Rob
> > >>
> > >> _________________________________________
> > >> 44Net mailing list
> > >> 44Net(a)mailman.ampr.org
> > >> https://mailman.ampr.org/mailman/listinfo/44net
> > >>
> > >
> >
> > - Hessu
> >
> > _________________________________________
> > 44Net mailing list
> > 44Net(a)mailman.ampr.org
> > https://mailman.ampr.org/mailman/listinfo/44net
> >
>
>
>
> ---------- Forwarded message ----------
> From: Nate Sales via 44Net <44net(a)mailman.ampr.org>
> To: AMPRNet working group <44net(a)mailman.ampr.org>
> Cc: Nate Sales <nate.wsales(a)gmail.com>
> Bcc:
> Date: Fri, 10 May 2019 17:24:47 -0700
> Subject: Re: [44net] VPN Question
> _________________________________________
> 44Net mailing list
> 44Net(a)mailman.ampr.org
> https://mailman.ampr.org/mailman/listinfo/44net
> Correct. Your approach saves you a lot of work in maintaining custom
> configs. They are a lot of work, if you have a lot of users.
Indeed. We offer OpenVPN connectivity to our local hams (the Netherlands) using certificates
created especially for that. The users get their fixed IP derived from the certificate subject
name (looked up in DNS/hosts) so they also can run services under their own callsign.
There are 220 valid certificates at this time, and always about 20 systems connected plus those
that connect when required.
Those that want to route subnets can get a GRE(6) or L2TP/IPsec tunnel and run BGP over that.
There currently are 34 users of that service, 30 of them are connected.
This mode is also used to provide connectivity to regional clusters of systems that are not yet
connected by radio all over our country.
It requires some one-time setup but at least there is no maintenance when users want to announce
more subnets etc.
Of course more systems like this could be setup in other countries/regions to serve those that
are on dynamic IP, are behind CGNAT, can only use IPv6, etc.
A "cloud" hosted Linux (virtual) machine with a fixed IP is all that you really require, a
service from the ISP to BGP-announce a subnet and route that to you is a good addition.
Alternatively you could use something like a MikroTik, Edgerouter or Juniper instead of the
Linux VM. A little less flexible in some areas but easier to setup and maintain.
Rob
> I cant figure out where to go
> from here. Can anyone point me in the right direction in how to get the
> routes set up for my little subnet?
You can't.
Such a VPN offers you a connection, with an IP, and routes traffic for that IP to you.
You cannot route arbitrary subnets over that because you cannot setup routes on the VPN server
pointing to your subnet.
If that is what you want, you need to setup a gateway on the IPIP tunnel mesh.
Or, find someone else who has done that and arrange for some VPN between you two.
Rob
Hello,
I have obtained the certificates and have openvpn all set up. I am able to
connect, and I see the interface like so:
3: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc
pfifo_fast state UNKNOWN group default qlen 100
link/none
inet 44.139.11.14 peer 44.139.11.13/32 scope global tun0
valid_lft forever preferred_lft forever
inet6 fe80::302f:bedc:d77a:c5d6/64 scope link flags 800
valid_lft forever preferred_lft forever
Now I'm a bit stuck. I've consulted a few posts, both
www.qsl.net/kb9mwr/wapr/tcpip/lotw-vpn.html and
www.qsl.net/kb9mwr/wapr/tcpip/oh7lzb.html but I cant figure out where to go
from here. Can anyone point me in the right direction in how to get the
routes set up for my little subnet?
Thanks so much and 73,
-Nate
> While both my node software and my servers are all dual stacked as well,
> the issue with using IPv6 on RADIO (UHF/VHF/HF) is a bit of a challenge
> but do-able.
Of couse "over radio" is not the same thing as "over AX.25"...
These days, radio links on our net-44 network are mostly/all WiFi links and
they would have no issue with IPv6.
AX.25 and IPv6 have other incompatibilities than ARP. The minimum MTU requirement
and the concern about efficiency at low bitrates are other things to worry about.
But what is mainly holding me back to deploy IPv6 now is:
- double effort of network administration for dual-stack
- limited support in our favourite routers (MikroTik)
- lack of immediate need, because we have not run out of IPv4 space and can
still assign usable subnets to everyone who wants them (so no NAT required)
So while I do have IPv6 deployed here at home, I while I don't rule out the
deployment of IPv6 on our radio network, I don't consider it a high-priority
thing.
When doing it, I would get a /48 from our ISP, and then make a 1:1 mapping
between already assigned IPv4 addresses within 44.137.0.0/16 and /64 nets
within that space. So everyone who has a single address gets a corresponding
/64 net and everyone who has a /28 subnets gets a /60 from that, without
requiring any mechanism other than a simple document explaining the mapping.
All places where IPv4 addresses and networks have been configured would get the
corresponding IPv6 address. Probably I would go with encoding callsigns and
service names into the lower 64 bits as proposed by Daniel EA4GPZ.
And for distributing a "list of valid prefixes" amongst those that would like
to be able to classify addresses as "within AMPRnet" or "outside AMPRnet"
(now done by checking for 44.0.0.0/8, which of course does not really work
as Brian Kantor already mentioned), I would propose setting up multihop BGP
peering using private AS numbers between gateway hosts that want to advertise
(and receive) the list of prefixes.
But again, it is not on my list of things to do this year. Keeping everyone
focused on building a working and expanding IPv4 network is more important, IMHO.
Rob
