Een praktische volgorde voor de serverkant van een eigen proxy-IP: controleer eerst SSH-toegang, wijzig de poort en stap over op sleutelauthenticatie, voer basisverharding uit, installeer de proxydienst en open de poort, en verbind daarna de client en controleer alles.
Wie een cloudserver als proxy gebruikt, loopt zelden vast op de basisverbinding zelf. Meestal zit het probleem in de volgorde waarin de serverkant wordt voorbereid. Met de juiste volgorde maakt de client doorgaans meteen verbinding; met een verkeerde volgorde moet je telkens terug naar de terminal om instellingen aan te passen.
Hier gaat het alleen om de serverkant: de eerste login, het aanscherpen van de toegang, het starten van de proxydienst, het openzetten van poorten, verbinding maken vanaf de client en laag voor laag zoeken als de verbinding mislukt.
Controleer bij de eerste login eerst de toegang
Nadat de instantie is aangemaakt, log je eerst in via de webterminal in de console van de provider en vertrouw je niet meteen op een lokaal hulpprogramma. Deze stap is alleen bedoeld om te controleren of de machine draait en het netwerk bereikbaar is.
Schakel daarna over naar root met sudo -i en druk op Enter. Zodra de prompt van $ naar # verandert, is de privilegeverhoging geslaagd. Voer de volgende stappen uit onder deze identiteit.
Noteer vier gegevens: het openbare IP-adres, de inlognaam (standaard root op Linux), het wachtwoord en de SSH-poort (standaard 22). De client heeft precies deze vier waarden nodig; ontbreekt er één, dan lukt de verbinding niet.
Wijzig de standaardpoort en stap daarna over op sleutelauthenticatie
Poort 22 wordt dagelijks ontelbare keren gescand en geautomatiseerde inlogpogingen zijn normaal. Een andere poort maakt de server niet fundamenteel sterker, maar filtert wel het grootste deel van de automatische ruis weg.
De wijziging gebeurt in /etc/ssh/sshd_config. Open het bestand met vi, druk op i voor de bewerkingsmodus, zet de regels PermitRootLogin en PasswordAuthentication op yes en druk daarna op Esc gevolgd door :wq om op te slaan en af te sluiten. Als de provider sleutelauthenticatie ondersteunt, is het beter om je lokale openbare sleutel toe te voegen aan authorized_keys op de server en vervolgens PasswordAuthentication op no te zetten, zodat alleen sleutels worden geaccepteerd.
Sluit de huidige sessie niet meteen nadat je de configuratie hebt gewijzigd. Open eerst een tweede terminalvenster, log één keer in met de nieuwe poort en de nieuwe methode, controleer dat dit werkt en sluit pas daarna het oude venster. Anders kan een configuratiefout je buitensluiten en moet je via de providerconsole herstellen.
De SSH-poort staat op de regel Port. Start na de wijziging de SSH-dienst opnieuw zodat de configuratie actief wordt. Op Debian- en Ubuntu-systemen kun je /etc/init.d/ssh restart uitvoeren.
Voer basisverharding op de eerste dag uit
Naast een andere poort en sleutels zijn twee kleine taken verstandig om direct af te ronden. Stel ten eerste met passwd root een voldoende lang willekeurig wachtwoord in voor root en gebruik geen voorspelbare combinatie. Schakel ten tweede ongebruikte diensten en poorten uit. Hoe minder er op de machine draait, hoe kleiner het aanvalsoppervlak; de systeemfirewall moet alleen poorten toestaan die echt nodig zijn.
Als deze server op lange termijn slechts vanaf een paar vaste bronlocaties wordt gebruikt, beperk dan in de security group de bronadressen tot die locaties. Dat is veel veiliger dan toegang vanaf het hele internet toestaan.
Installeer de proxydienst en configureer authenticatie
Zodra de serverinitialisatie klaar is, komt de proxy zelf aan de beurt.
Eén optie is direct een SSH-tunnel gebruiken. Op de server hoeft niets extra te worden geïnstalleerd; de client gebruikt de ingebouwde SSH-dienst van het systeem voor forwarding en dezelfde serverreferenties. Dat is eenvoudig, maar de prestaties zijn gemiddeld en veel gelijktijdige verbindingen worden zwaar. Het past daarom vooral bij tijdelijk gebruik of weinig accounts.
De andere optie is een speciale proxydienst op de server installeren. Vaak kan dat met één installatiecommando, waarna je zelf de authenticatiemethode en luisterpoort instelt. Schakel automatisch starten bij het opstarten in, anders verdwijnt de proxy zodra de server opnieuw wordt gestart.
Er zijn drie gangbare authenticatieniveaus met oplopende veiligheid: gebruikersnaam en wachtwoord zijn het eenvoudigst, maar bij een lek is de proxy feitelijk weggegeven; wachtwoord plus een allowlist voor bron-IP's is meestal voldoende voor dagelijks gebruik; sleutel- of certificaatauthenticatie is het sterkst, maar vraagt wat meer configuratie en is de moeite waard voor accounts die langdurig draaien.
Open de poort op twee afzonderlijke plaatsen
Hier gaat het vaak mis. De luisterpoort van de proxydienst moet zowel in de systeemfirewall als in de security group van de provider worden toegestaan. Beide zijn onafhankelijk; alleen één van de twee openzetten is niet genoeg.
Ook het luisteradres van de dienst wordt vaak vergeten. Sommige diensten binden standaard alleen aan 127.0.0.1. Als een lokale test op de server werkt maar externe toegang niet, is dat vaak de oorzaak. Wijzig het luisteradres naar het privé-adres van de server of naar 0.0.0.0.
Maak verbinding vanaf de lokale client
Maak in de omgevingbeheertool een nieuwe omgeving aan en kies het proxytype dat je daadwerkelijk gebruikt. Bij een SSH-tunnel is het adres het openbare IP van de server, de poort de SSH-poort en zijn gebruikersnaam en wachtwoord die van de server. Voer daarna de verbindingstest uit.
Een geslaagde test bewijst alleen dat het pad werkt. Open de omgeving en controleer nog drie zaken: het uitgaande IP moet het openbare IP van de server zijn; DNS moet ook via de proxy lopen, omdat lokale DNS-resolutie een regio kan onthullen die niet bij het uitgaande IP past; en tijdzone en taal moeten overeenkomen met de uitgaande regio. Pas als alle drie kloppen, is de omgeving bruikbaar.
Wanneer het aantal accounts toeneemt, houd je de koppeling tussen omgeving en uitgang vast om te voorkomen dat meerdere accounts één omgeving delen. Hulpmiddelen zoals PurpleMark kunnen voor elk account een afzonderlijke uitgang koppelen en zijn daarmee betrouwbaarder dan een handmatig bijgehouden tabel.
Als de verbinding mislukt, controleer van buiten naar binnen
Begin aan de buitenkant: staat de security group open? Staat de systeemfirewall open? Bevestig beide voordat je verder gaat.
Controleer daarna de dienst zelf: draait het proces nog, vooral na een herstart van de server? Is het luisteradres alleen lokaal gebonden?
Kijk vervolgens naar de authenticatielaag: zijn gebruikersnaam of wachtwoord onjuist? Zijn de rechten van het sleutelbestand te ruim? SSHD weigert de sleutel direct als de rechten niet kloppen. Controleer pas daarna de client: heb je het openbare IP ingevuld of per ongeluk het privé-IP? Die verwisseling komt vaak voor.
Met deze volgorde vind je meestal binnen twee of drie rondes de laag waar het probleem zit, in plaats van de dienst steeds opnieuw te installeren.
Afronding
De voorbereiding aan de serverkant kost minder dan een half uur, maar bepaalt hoeveel onderhoud de machine de komende maanden vraagt. Beperk de toegang, open de juiste poorten en configureer de authenticatie duidelijk; daarna blijft alleen regulier onderhoud over.
