|
Grex > Agora > #4: Grex System Problems - Fall 2015/Winter 2016 | |
|
| Author |
Message |
| 12 new of 223 responses total. |
lar
|
|
response 212 of 223:
| 
Mar 24 02:06 UTC 2020 |
re#211
thanks!
How can I validate my account?
|
tfurrows
|
|
response 213 of 223:
|
Mar 24 18:49 UTC 2020 |
#200, cross, what would Grex use instead of OpenBSD?
|
kentn
|
|
response 214 of 223:
|
Mar 24 19:14 UTC 2020 |
Re 212: I think you might mean "verify" your account. Your account is
already validated. To verify an account on Grex, you need to provide
acceptable identification. This can, for example, be a copy of a
state-issued valid ID like a driver's license or by using a validated
PayPal account to purchase a minimal membership (e.g. $1). Validated
PayPal accounts are determined by PayPal. As you might expect that
generally means they know your real identity and there is a bank account
or credit card connected with the PayPal account. Since verified users
have more access to the internet, verification allows Grex to identify
people who cause problems, if an agency, like the FBI, come calling (and
believe me they have contactd grex before about particular users).
|
cross
|
|
response 215 of 223:
|
Mar 25 18:47 UTC 2020 |
resp:213 Probably FreeBSD.
|
kentn
|
|
response 216 of 223:
|
Nov 14 22:58 UTC 2020 |
I noted today that one of my computers wouldn't connect to grex via
ssh while another would. They are different versions of FreeBSD (11.4
worked, 12.1 didn't). Same setups of ssh_config.
Anyway changing the MTU for 12.1 fixed it, which is a bit weird. I had
to edit /etc/dhclient.conf and supersede the interface-mtu setting that
normally is set to 1500 by DHCP and setting it to 1400 helped. Probably
this is due to the ciphers that get picked in the ssh connection.
Each computer picks a different one (using the same setup). So more
investigations to do.
I had noted someone else had seen something similar in the past couple
weeks.
|
papa
|
|
response 217 of 223:
|
Nov 16 00:02 UTC 2020 |
resp:216
I've posted more details on the trouble here: item:garage:60
|
kentn
|
|
response 218 of 223:
|
Nov 16 01:49 UTC 2020 |
Thanks, papa.
|
tonster
|
|
response 219 of 223:
|
Nov 16 19:04 UTC 2020 |
My guess is that it might have to do with the method now used for
accessing Grex. I recently canceled my AT&T service, which allowed me to
have static IP's at home. With that now gone, I've established a VPN
between my servers in Azure and home, and am routing grex (and m-net)
via static IP's I've got in Azure and home over that VPN tunnel. Exactly
why this is working without incident for some ssh clients and not others
I'm unsure, but that is the change that was made in the past week when
this started.
|
tod
|
|
response 220 of 223:
|
Nov 18 02:18 UTC 2020 |
re #219
This is excellent - curious how that is setup.
I have a nat behind a nat at my office and want the pi there available
for sshd from home and elsewhere. Not sure how to go about it.
|
tonster
|
|
response 221 of 223:
|
Dec 5 22:10 UTC 2020 |
resp:220: What I did was created a vm at home to route the tunnel, and
established a strongswan tunnel between the two sites. I then created an
iptables rule to create a route to my network via the tunnel:
-A POSTROUTING -s 10.0.0.0/24 -d 192.168.0.0/20 -j MASQUERADE
and the opposite on the other end of the tunnel:
-A POSTROUTING -s 192.168.0.0/20 -d 10.0.0.0/24 -j MASQUERADE
For the Azure side, I also route the additional bound IP's over the
tunnel back home via:
-A PREROUTING -d 10.0.0.9/32 -j DNAT --to-destination 192.168.0.110
-A POSTROUTING -d 192.168.0.110/32 -j SNAT --to-source 10.0.0.9
strongswan starts on boot, and I've put the iptables rules in the
appropriate file for the OS (ubuntu/centos), so everything comes up on
boot and strongswan monitors the tunnel so it automatically restarts
should it drop. It ended up working out quite well, and it was much
easier to get it running than I'd expected.
|
tod
|
|
response 222 of 223:
|
Dec 12 05:40 UTC 2020 |
re #221
Very tidy, indeed. Thanks for the rundown!
|
kentn
|
|
response 223 of 223:
|
Feb 21 16:19 UTC 2023 |
The machine grex is running on had more disk space added yesterday. That
took it offline and made it appear the SSH security info had changed.
It's back up now and everything should be back the way it was before the
changes. Thanks go to Tony for keeping grex going.
|