Afdrukvoorbeeld
TS heeft aangegeven (in #10 ) dat er geen IP per klant(domein) beschikbaar is.Citaat:
Oorspronkelijk geplaatst door The-BosS
Dan zie ik niet hoe je met een loadbalancer ssh sessies domein gebaseerd kunt laten redirecten naar de juiste interne server.
Ik reageerde ook even enkel op @24x7hosting zijn post dat het onmogelijk was om loadbalancers te gebruiken voor ssh.Citaat:
Oorspronkelijk geplaatst door visser
Naast het feit dat een vhost per klant eigenlijk geen moeilijkheid op zich is (klant.ssh.provider.tld of sftp.klantdomein.tld) je moet het gewoon even aanmaken ;). En aangezien de TS toch een ssh server (zou) installeren voor dit doeleind kun je net zo makkelijk dat IP en/of VPS gebruiken om de loadbalancing (nat forwarding) te doen.
@24x7hosting : Geen werkend voorbeeld uit praktijk voor HAproxy, maar wel voor zenloadbalancer ;), wat ik wel gevonden heb is: https://confluence.atlassian.com/dis...ort+forwarding & http://jpmorris-iso.blogspot.be/2013...h-haproxy.html
Wel, je schreef ook al over een loadbalancer in je reactie #7 .Toen kon je de startpost van TS nog net interpreteren met aanwezigheid van een IP-per-klantdomein, hoewel dat al redelijk vergezocht was.Citaat:
Oorspronkelijk geplaatst door The-BosS
In de context van SSH loadbalancen mag je er best bij zeggen dat dat (slechts) HA of balancing van de gezamelijke load aan sessies betreft, zonder domein-specifieke afhandeling zoals je dat bij HTTP kunt doen.
Met de term vhost mag er al helemaal bijgezegd worden dat je voor SSH geen name-based virtual hosting kunt doen zoals voor http, want een hack daarvoor is wat TS uiteindelijk aan het zoeken is.
Dat vereist dus een uniek (publiek) IP adres per klant. Als je dat hebt, zijn er natuurlijk een hoop opties hoe je dan de ssh poort beschikbaar maakt.Citaat:
Naast het feit dat een vhost per klant eigenlijk geen moeilijkheid op zich is (klant.ssh.provider.tld of sftp.klantdomein.tld) je moet het gewoon even aanmaken ;). En aangezien de TS toch een ssh server (zou) installeren voor dit doeleind kun je net zo makkelijk dat IP en/of VPS gebruiken om de loadbalancing (nat forwarding) te doen.
Dat vereist totaal geen IP adres per klant, iedere vhost verwijs je gewoon naar het ip adres van de loadbalancer (in mijn geval dus zenloadbalancer), daar kun je perfect opgeven dat per vhost zowel http, https, ssh, dns, ... eigenlijk elke tcp of udp poort doorverwezen wordt naar een intern of extern ip adres op een andere poort (of zelfde poort). Je geeft dus voor ssh per vhost eigenlijk maar 1 doel server op in plaats van een rij aan servers (clusters). Je kunt zelfs zeggen dat domein.tld op poort 80 naar server1 & server2 gaat, domein.tld op poort 443 naar server2 & server3 gaat, domein.tld op ssh bvb enkel naar server4 gaat, domein.tld op imaps naar server1 & server2 & server6 gaat, .... Dus mogelijk is het zeker want ik heb het hier op mijn office vdsl gewoon draaien zodat ik op sommige van mijn kantoor servers kan inloggen via vhost op 1 extern ip adres.Citaat:
Oorspronkelijk geplaatst door visser
Dat moet je toch een beetje uitleggen.Citaat:
Oorspronkelijk geplaatst door The-BosS
Je hebt
jansen.tld IN A <loadbalancer ip>
pietersen.tld IN A <loadbalancer ip>
En je wilt bereiken dat een ssh sessie (tcp/22) naar jansen.tld uitkomt op de één backend server, en ssh (ook tcp/22) naar pietersen.tld op een andere backend server.
En daarvan zie ik niet hoe dat kan.
Ik zou zeggen download zenloadbalancer even en test het, ze maken gebruik van layer7 of layer4 (dnat/snat) om het voor elkaar te krijgen.Citaat:
Oorspronkelijk geplaatst door visser
Zeg nu eens duidelijk of bij jou de situatie die ik in #20 noemde dan inderdaad werkt ?Citaat:
Oorspronkelijk geplaatst door The-BosS
Heb je dus twee domeinen met één publiek IP waarbij SSH op een verschillende backend server uitkomt afhankelijk van naar welke domein naam je de sessie opzet ?
Niet HTTP of HTTPS maar SSH , en voor beide domeinen gebruik je tcp/22 als ssh poort ?
Waar Visser op doelt; met http(s) is dit niet zo moeilijk, je kan daar in de http headers kijken om het domein te vinden en daarop te content switchen / loadbalancen. Ik vraag me echter wel af hoe je dit met ssh doet, gezien er gewoon een dns resolutie in zit naar uiteindelijk hetzelfde IP adres.Citaat:
Oorspronkelijk geplaatst door visser
Ik heb nog even gekeken naar ZenLB maar het is niet mogelijk om op 1 IP met meerdere DNS namen naar verschillende interne SSH servers te verbinden.Citaat:
Oorspronkelijk geplaatst door The-BosS
Sent from my GT-I9505 using webhostingtalk mobile app
Jullie hebben helemaal gelijk, ik had even over het hoofd gezien dat ik dit met mijn watchguard geregeld had op source ip en daar redirect naar het interne ip zoals visser eerst al voorstelde, maar dan moet je uiteraard wel fixed ip adressen van de klanten weten.
Maar ik ben even verder gaan zoeken op het probleem en heb misschien wel een eenvoudige oplossing, vroeger had ik iets gelijkaardigs maar dan voor console connecties. Waar je bvb kon inloggen op ssh met user1 en dan kreeg je directe verbinding met com1, user2 kreeg verbinding met com2 etc (uiteraard waren de usernames niet user1 & user2 & ... maar daadwerlijke namen).
Ik heb het dus even getest of dit ook kon voor ssh door te lussen en dat blijkt dus ook te gaan, ik ga even de stappen uitleggen:
1) Ik heb een user aangemaakt (test) op de edge ssh server, zoals je een normale user aanmaakt
2) Inloggen als user (test)
3) Ssh-keygen aangemaakt voor test user
4) De public key gecopieerd naar de doelserver onder gebruiker test (die je al zou moeten hebben)
5) Getest of ik zonder wachtwoord kon inloggen op de doelserver
6) Op de edge ssh server het bestand sshd_config aangepast met volgende zaken:
7) Getest of ik geredirect werd via de edge server:Code:Match User test
ForceCommand /usr/bin/ssh -l test 172.16.0.57
AllowTCPForwarding no
X11Forwarding no
8) Getest of scp werkt en die doet het ook ;)Code:[admin@VPSNODE1 ~]# ssh -l test 172.16.5.21
The authenticity of host '172.16.5.21 (172.16.5.21)' can't be established.
RSA key fingerprint is 4e:24:ae:22:2e:2a:52:f1:24:83:f7:43:80:d4:5e:42.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '172.16.5.21' (RSA) to the list of known hosts.
test@172.16.5.21's password:
Last login: Sun Jun 8 16:45:40 2014 from 172.16.5.21
[test@dev-box2 ~]$ ifconfig eth0 | grep "172"
inet addr:172.16.0.57 Bcast:172.16.255.255 Mask:255.255.0.0
[test@dev-box2 ~]$ exit
uitgelogd
Connection to 172.16.0.57 closed.
Connection to 172.16.5.21 closed.
[admin@VPSNODE1 ~]#
Dit lijkt mij dus de simpelste optie te zijn.
Enig idee of dat ook werkt met sFTP?Citaat:
Oorspronkelijk geplaatst door The-BosS
Verwacht het wel (zie zo niet direct een reden waarom het niet zou werken).Citaat:
Oorspronkelijk geplaatst door Cakkie
Dit is vrij simpel op te lossen met iptables. Je kunt per source IP-adres een port-nat-translation configureren, zodat bijvoorbeeld verkeer vanaf 10.1.1.1 naar SSH op poort 2222 gaat, verkeer vanaf 10.2.2.2 gaat naar SSH op poort 3333, etc, etc. Dit werkt dus wel alleen als de requests voor de verschillende servers vanaf verschillende source IP's komen, maar zou dan een prima oplossing zijn.