Van server- en regiokeuze tot basisbeveiliging, proxy-installatie, authenticatie en poorten, clientkoppeling, controle en een vaste volgorde voor probleemoplossing.
Server en regio kiezen
Een proxy gebruikt zelf nauwelijks CPU of geheugen. Die specificaties zijn daarom niet het belangrijkste bij het kiezen van een configuratie.
Je hoeft niet meteen een zware server te nemen. Bundelpakketten zoals lichte applicatieservers met vaste bandbreedte en maandelijks dataverkeer zijn meestal voldoende voor een persoonlijke proxy met één of enkele accounts en zijn goedkoop. Pas wanneer je meerdere instanties nodig hebt of duidelijke eisen aan de bandbreedte hebt, is een algemene instance met afzonderlijk instelbare resources interessanter.
De regio verdient meer aandacht dan de hardware, omdat het exit-IP hoort bij de locatie waar de node staat. De logica is eenvoudig: zet de node in de markt waarin het account actief is. Veel mensen kiezen op snelheid. Een node in Hongkong kan vanuit het Chinese vasteland snel zijn, maar als het accountprofiel de Verenigde Staten vermeldt terwijl de exit in Azië ligt, is die inconsistentie belangrijker dan snelheid. Snelheid is secundair; consistentie komt eerst.
Schat de bandbreedte op basis van het werkelijke gebruik. Voor dashboards en dagelijks beheer is weinig bandbreedte meestal genoeg; voor beeld- en videowerk is meer nodig; en hoe meer accounts tegelijk online zijn, hoe hoger de behoefte. Bij twijfel begin je met het kleinste pakket, bekijk je een maand lang het verbruik en pas je daarna aan.
Doe deze stappen direct na het opstarten
Kies een Linux-systeemimage. Zulke distributies hebben standaard SSH, zodat je geen extra dienst voor externe toegang hoeft te installeren. Bij aanschaf is een zelfgekozen wachtwoord in plaats van een sleutelbestand praktisch, omdat je later bij het instellen van de proxy een conversiestap bespaart.
Noteer na ontvangst van de server eerst vier gegevens: openbaar IP-adres, gebruikersnaam (standaard root op Linux), wachtwoord en SSH-poort (standaard 22). Dit zijn de gegevens die je in de client invoert.
Regel daarna de basisbeveiliging. Door de standaardpoort 22 te wijzigen, voorkom je een groot deel van geautomatiseerde scans. Als de provider inloggen met een sleutel ondersteunt, configureer dat dan en schakel daarna wachtwoordlogin uit. Sta in zowel de security group als de systeemfirewall alleen de echt benodigde poorten toe en sluit de rest. Deze stappen kosten maar enkele minuten en verminderen langdurige scans en pogingen met gestolen of hergebruikte inloggegevens.
Twee manieren om de proxydienst te gebruiken
De eerste is rechtstreeks een SSH-tunnel gebruiken. Op de server hoeft niets extra's te worden geïnstalleerd: de client gebruikt de bestaande SSH-dienst voor forwarding, met poort 22 en de normale servergegevens. Het nadeel is de gemiddelde prestatie; langdurig gebruik of veel gelijktijdige verbindingen kan zwaar worden. Dit past daarom beter bij tijdelijk gebruik of zeer weinig accounts.
De tweede optie is een aparte proxydienst op de server installeren. Vaak gebeurt dat met één installatiecommando, waarna je zelf de authenticatiemethode en poort instelt. Deze aanpak biedt betere prestaties en meer controle en is geschikter voor langdurig gebruik. Schakel na de installatie automatisch starten bij boot in, anders verdwijnt de proxy na een serverherstart.
Authenticatie en poorten
Je kunt drie niveaus onderscheiden, met oplopende veiligheid: gebruikersnaam en wachtwoord is het eenvoudigst, maar een gelekt wachtwoord geeft feitelijk toegang tot de proxy; wachtwoord plus een allowlist voor bron-IP's is voor dagelijks gebruik meestal voldoende; authenticatie met sleutel of certificaat is het sterkst, maar vraagt meer configuratie en is de moeite waard voor langdurig gebruikte accounts.
Voor poorten is alleen de luisterpoort van de dienst instellen niet genoeg. Je moet die poort afzonderlijk toestaan in de systeemfirewall én in de security group van de provider. Deze twee lagen zijn onafhankelijk; slechts één ervan openen is een veelvoorkomende oorzaak van verbindingsproblemen. Bind het luisteradres ook niet alleen aan de lokale loopback-interface. Werkt een test op de server zelf wel maar van buitenaf niet, dan is dit vaak de oorzaak.
Verbinden vanuit de client en controleren
Maak in de omgevingsbeheertool een nieuwe omgeving aan, geef die een naam en notitie en neem liefst accountdoel en doelregio in de naam op. Vul vervolgens, afhankelijk van het proxytype, serveradres, poort, gebruikersnaam en wachtwoord in bij de proxy-instellingen en voer de test uit. Een succesmelding betekent dat de route bereikbaar is. De exacte veldnamen hangen af van de interface van de tool.
Een geslaagde test is slechts de eerste stap. Open daarna de omgeving en controleer drie zaken.
Controleer eerst of het exit-IP het openbare IP van de server is. Open een pagina die je huidige IP toont; pas als daar het serveradres staat, loopt het verkeer correct via de proxy.
Controleer vervolgens of DNS ook via de proxy loopt. Als DNS nog lokaal wordt opgelost, kan de zichtbare geografische informatie afwijken van het exit-IP en heeft de ingestelde accountregio weinig waarde.
Controleer ten slotte of tijdzone en taal overeenkomen met de exit-regio. Een Amerikaans IP gecombineerd met een Chinese tijdzone en Chinese taal is een duidelijke inconsistentie.
Pas als alle drie de controles slagen, is de omgeving klaar voor gebruik.
Controleer in deze volgorde als verbinding niet lukt
Mislukt de proxytest direct, begin dan bij de bereikbaarheid: controleer of de poort in zowel de security group als de systeemfirewall is toegestaan. Kijk daarna of de proxydienst draait, vooral na een herstart van de server. Controleer vervolgens gebruikersnaam en wachtwoord en kijk of het serveradres klopt. Een openbaar en intern IP door elkaar halen komt vaak voor.
Slaagt de test maar openen pagina's niet, dan zit het probleem meestal aan de kant van de omgeving. Controleer of de juiste proxy eraan is gekoppeld en of DNS niet terug op lokale resolutie is gezet.
Is de verbinding traag, bepaal dan eerst of afstand of bandbreedte de oorzaak is. Open de doelsite rechtstreeks vanaf de server. Is de server zelf al traag, dan ligt het aan de node-regio of netwerkroute; is de server snel maar de client traag, dan is de bandbreedte waarschijnlijk te klein of zijn te veel accounts tegelijk online.
Opschalen als het aantal accounts groeit
Meerdere accounts op één server is goedkoper, maar alle accounts delen hetzelfde exit-IP. Als het platform relaties herkent op basis van IP-bereiken, kan er nog steeds een koppeling tussen accounts bestaan. Eén server per account kost meer, maar houdt de omgevingen volledig gescheiden en is een robuustere keuze voor waardevollere accounts.
Met een omgevingsbeheertool zoals PurpleMark kun je voor elk account een aparte exit betrouwbaarder koppelen dan met een handmatig bijgehouden tabel. Bij de gebruikelijke prijzen van lichte servers is één exit per account in veel gevallen betaalbaar en voorkom je mogelijk later het opnieuw opbouwen van accounts wegens onderlinge koppeling. Houd bovendien een aparte server voor tests. Zet niet alle accounts op één machine, want één storingspunt kan ze dan allemaal tegelijk treffen.
