Praktikal na pagkakasunod-sunod sa paghahanda ng server para sa sariling proxy IP: tiyakin muna ang SSH access, palitan ang port at gumamit ng key authentication, gawin ang pangunahing hardening, i-install ang proxy service at buksan ang port, saka kumonekta at mag-validate mula sa client.
Kapag bumili ka ng cloud server para gawing proxy, bihirang ang mismong connectivity ang tunay na problema. Mas madalas, nasa pagkakasunod-sunod ng paghahanda sa server side ang aberya. Kapag tama ang pagkakasunod, kadalasang nakakakonekta agad ang client; kapag magulo, paulit-ulit kang babalik sa terminal para magpalit ng configuration.
Server side lang ang saklaw dito: mula sa unang login at paghigpit ng access, hanggang sa pagpapatakbo ng proxy service, pagbubukas ng port, pagkonekta ng client, at paghanap ng problema nang paisa-isang layer kapag hindi makakonekta.
Sa unang login, tiyakin muna na gumagana ang access
Pagkatapos malikha ang instance, mag-login muna gamit ang web terminal na kasama sa console ng provider at huwag agad umasa sa lokal na tool. Ang layunin ng hakbang na ito ay kumpirmahin lang na buhay ang makina at naaabot ang network.
Pagkapasok, lumipat sa root sa pamamagitan ng pagtakbo ng sudo -i at pagpindot sa Enter. Kapag nagbago ang prompt mula $ tungo sa #, matagumpay ang privilege escalation. Gawin ang mga susunod na hakbang gamit ang identity na ito.
Itala ang apat na impormasyon: public IP, login username (root ang default sa Linux), password, at SSH port (22 ang default). Ito mismo ang apat na value na kailangan ng client; kung may kulang kahit isa, hindi makakakonekta.
Palitan ang default port, saka lumipat sa key-based login
Hindi mabilang na beses na sini-scan araw-araw ang port 22 at normal ang mga automated na pagtatangkang mag-login. Hindi awtomatikong nagpapalakas sa server ang pagpapalit ng port, pero nasasala nito ang malaking bahagi ng automated noise.
Ginagawa ang pagbabago sa /etc/ssh/sshd_config. Buksan ito gamit ang vi, pindutin ang i para pumasok sa edit mode, gawing yes ang mga linyang PermitRootLogin at PasswordAuthentication, pagkatapos ay pindutin ang Esc at ilagay ang :wq para mag-save at lumabas. Kung sinusuportahan ng provider ang key-based login, mas matibay na paraan ang pagdagdag ng lokal mong public key sa authorized_keys ng server at pagkatapos ay gawing no ang PasswordAuthentication para keys lang ang tanggapin.
Huwag agad isara ang kasalukuyang session matapos baguhin ang configuration. Magbukas muna ng isa pang terminal window, mag-login nang isang beses gamit ang bagong port at bagong paraan, tiyaking gumagana, at saka lang isara ang lumang window. Kung mali ang configuration, maaari mong ma-lock ang sarili mo sa labas at mapilitan kang bumalik sa provider console para mag-recover.
Nasa linyang Port ang SSH port. Pagkatapos itong baguhin, i-restart ang SSH service para magkabisa ang configuration. Sa Debian at Ubuntu systems, puwedeng patakbuhin ang /etc/init.d/ssh restart.
Gawin ang pangunahing hardening sa unang araw pa lang
Bukod sa pagpapalit ng port at paggamit ng keys, may dalawang maliit na bagay na magandang matapos sa unang araw. Una, magtakda ng sapat na mahaba at random na password para sa root gamit ang passwd root at iwasan ang kombinasyong madaling hulaan. Ikalawa, patayin ang mga serbisyo at port na hindi kailangan. Mas kaunti ang tumatakbo sa makina, mas maliit ang attack surface; dapat payagan lamang ng system firewall ang mga port na talagang kailangan.
Kung pangmatagalan na ilang nakapirming source location lang ang gagamit sa server, limitahan sa security group ang source addresses sa mga lokasyong iyon. Mas ligtas ito kaysa buksan ang access sa buong internet.
I-install ang proxy service at i-configure ang authentication
Kapag tapos na ang server-side initialization, saka ayusin ang mismong proxy.
Isang paraan ang direktang paggamit ng SSH tunnel. Walang kailangang dagdag na i-install sa server; gagamitin ng client ang built-in SSH service ng system para sa forwarding at ang parehong server credentials. Maginhawa ito, pero katamtaman ang performance at nahihirapan kapag maraming sabay-sabay na koneksyon, kaya bagay sa pansamantalang gamit o kakaunting account.
Ang isa pang paraan ay mag-install ng dedicated proxy service sa server. Kadalasan, isang installation command lang ang kailangan, at pagkatapos ay ikaw ang magse-set ng authentication method at listening port. Huwag kalimutang paganahin ang automatic startup; kung hindi, isang server restart lang at mawawala rin ang proxy.
May tatlong karaniwang antas ng authentication, pataas ang seguridad: username at password ang pinakasimple, pero kapag na-leak ay para mo na ring ibinigay ang proxy; password kasama ang source-IP allowlist ay kadalasang sapat sa araw-araw; key o certificate authentication ang pinakamatibay, bagama't mas matrabaho ang setup at sulit para sa mga account na pangmatagalan.
Buksan ang port sa dalawang magkahiwalay na lugar
Ito ang isa sa pinakakaraniwang dahilan ng problema. Kailangang payagan ang listening port ng proxy service sa system firewall at sa security group ng provider. Magkahiwalay ang dalawang kontrol; hindi sapat na isa lang ang buksan.
Madali ring makaligtaan ang listening address ng serbisyo. May ilang service na naka-bind lang sa 127.0.0.1 bilang default. Kung gumagana ang local test sa server pero hindi mula sa labas, ito ang madalas na dahilan. Palitan ang listening address sa private address ng server o sa 0.0.0.0.
Kumonekta mula sa lokal na client
Gumawa ng bagong environment sa environment-management tool at piliin ang aktuwal na proxy type. Kung SSH tunnel ang gamit, ang address ay public IP ng server, ang port ay SSH port, at ang username at password ay ang server credentials. Pagkatapos, patakbuhin ang connection test.
Ang pagpasa sa test ay nagpapatunay lang na bukas ang path. Buksan ang environment at tiyakin ang tatlong bagay: ang exit IP ay dapat public IP ng server; dapat dumaan din sa proxy ang DNS, dahil kung lokal pa rin ang DNS resolution ay maaaring magpakita ito ng rehiyong hindi tugma sa exit IP; at dapat tugma sa exit region ang time zone at language. Kapag pasado ang tatlo, saka pa lang handa ang environment.
Kapag dumami ang accounts, panatilihing nakapirmi ang ugnayan ng environment at exit para hindi maraming account ang gumamit ng iisang environment. Ang mga tool gaya ng PurpleMark ay maaaring mag-bind ng hiwalay na exit sa bawat account, na mas maaasahan kaysa mano-manong pag-maintain ng mapping table.
Kapag hindi makakonekta, mag-check mula labas papasok
Magsimula sa pinakalabas na layer: pinapayagan ba ng security group? Pinapayagan ba ng system firewall? Kumpirmahin ang dalawa bago lumalim.
Sunod, tingnan ang mismong serbisyo: tumatakbo pa ba ang process, lalo na pagkatapos ng server restart? Naka-bind ba sa local address lang ang listening address?
Pagkatapos ay authentication layer: mali ba ang username o password? Masyado bang maluwag ang permissions ng key file? Direktang tatanggihan ng SSHD ang key kapag mali ang permissions. Huli nang tingnan ang client side: public IP ba ang nailagay o aksidenteng private IP? Madaling mapagpalit ang dalawang ito.
Kapag sinunod ang pagkakasunod na ito, karaniwan ay dalawa o tatlong ikot lang para matukoy kung saang layer ang problema sa halip na paulit-ulit na mag-reinstall ng serbisyo.
Pangwakas
Wala pang kalahating oras ang paghahanda sa server side, pero dito nakasalalay kung gaano kadaling alagaan ang makina sa mga susunod na buwan. Higpitan ang access, buksan nang tama ang mga port, at linawin ang authentication; pagkatapos niyan, regular na maintenance na lang ang natitira.
