Het probleem van servers die je thuis draait die niet meer bereikbaar zijn, is makkelijk opgelost met
dyndns. Gewoon een programma'tje draaien daarvoor die steeds checkt of je IP nog klopt met je hostname. Zo niet, dan update hij hem. Zodra hij is geupdate, zit er geen vertraging in de doorvoering.
Het koppelen van je @Home domein aan één van je eigen subdomeinen is trouwens niet toegestaan volgens de algemene voorwaarden. Met dyndns heb je daar geen last van, omdat dat niet is terug te vinden in de reverse DNS. DynDNS levert ook alleen maar een alias; als ik mijzelf ping op die hostname, dan krijg ik gewoon antwoord van mijn ccxxxx-a.bla.home.nl host.
Die SSH beveiliging; je zou een iptables forward rule kunnen maken die al het verkeer op een alternatieve poort, als 33333, forward naar 22. Op die manier is alles op poort 22 IP gefilterd, en kan je via 33333 nog wel toegang krijgen. Het lijkt klunky, maar het werkt in de praktijk redelijk goed. Op mijn bak thuis krijg ik honderden pogingen per dag op poort 22, op de server op het werk, waar ssh op een alternatieve poort draait, krijg ik er 0.
Het probleem dat de vorige gebruiker een IP adres heeft misbruikt en dat hij ergens verbannen is, is eigenlijk het probleem van die dienst. IP adressen zijn nou eenmaal niet statisch. Ik neem @Home het opzich niet kwalijk dat ze het doen.
En als je overweegt naar ADSL over te stappen, neem dan ADSL zonder livebox. Dat ding kan je niets mee. En als ik de meeste van jullie zo hoor, wil je juist flexibiliteit, net als ik. Ik bijvoorbeeld, heb een Coyote Linux router, met complexe dingen als Quality of Service (eerlijk routen van verkeer). Ook heb ik een bootscript geschreven die de route voor het WAN subnet weggooit, zodat ik met mensen in mijn eigen subnet kan communiceren. Ik wil in ieder geval altijd, wat voor internet ik ook heb, dat de WAN kant van mijn Coyote Linux box mijn internet IP adres krijgt. Met een livebox krijg je dat niet voor elkaar, naar mijn weten. Hij kan dan alleen 192.168.x.x krijgen.