ஆல் Ollama API பாதுகாப்பை உறுதி செய்வது எப்படி?
Ollama server-ல் இயல்பாகவே கடவுச்சொல் பாதுகாப்பு இல்லை. 11434 port வழியாக எவரும் உங்கள் models-ஐ இயக்க முடியும். இதைத் தடுக்க மூன்று எளிய பாதுகாப்பு வழிமுறைகளை இங்கே காணலாம்.
Ollama API-க்கு கடவுச்சொல் இல்லை
Ollama API-ல் எந்தவிதமான அங்கீகாரமும் (authentication) இல்லை. நீங்கள் இயக்கும் server-ல் பயனர், கடவுச்சொல், key சரிபார்ப்பு அல்லது allowlist என எதுவுமே கிடையாது. 11434 port-க்கு TCP connection ஏற்படுத்தக்கூடிய எவரும் உங்கள் models-ஐ பட்டியலிடலாம், இயக்கலாம், புதியவற்றைத் தரவிறக்கலாம் மற்றும் ஏற்கனவே உள்ளவற்றை நீக்கலாம்.
இதன் அதிகாரப்பூர்வ ஆவணங்கள் இதைத் தெளிவாகக் கூறுகின்றன: "Ollama-வின் API-ஐ http://localhost:11434 வழியாக உள்ளூர் அளவில் அணுகும்போது எந்த அங்கீகாரமும் தேவையில்லை." உள்ளூர் அளவில் (locally) என்ற வார்த்தையே முழு பாதுகாப்பு மாதிரியையும் குறிக்கிறது. Ollama இயல்பாகவே 127.0.0.1-ல் பிணைக்கப்படுவதால் (bind), ஒரு laptop-ல் loopback interface மட்டுமே அணுகல் கட்டுப்பாடாகச் செயல்படுகிறது. அந்த listener-ஐ ஒரு public address-க்கு மாற்றினால், அணுகல் கட்டுப்பாடு நீங்கிவிடும்; ஏனெனில் அதற்குப் பதிலாக வேறு எந்தப் பாதுகாப்பும் அங்கு இல்லை.
இதனால்தான் VPS (virtual private server)-ல் இது முக்கியத்துவம் பெறுகிறது. இயல்புநிலை அமைப்பு பாதுகாப்பானது. பெரும்பாலானோர் செய்யும் முதல் மாற்றமான, மற்றொரு machine-ஐ model-ஐப் பயன்படுத்த அனுமதிப்பதற்காக listener-ஐத் திறப்பது, ஒரே நேரத்தில் அனைத்துப் பாதுகாப்புகளையும் நீக்கிவிடும்.
திறந்திருக்கும் 11434 port எதை வெளிப்படுத்துகிறது
ஒவ்வொரு endpoint-ம் வெளிப்படும். இதில் read-only mode கிடையாது, தனிப்பட்ட admin port-ம் இல்லை. இவை localhost-க்கு பதிலாக server முகவரியை இலக்காகக் கொண்ட உண்மையான கோரிக்கைகள் (requests):
# List every model on the box
curl http://SERVER_IP:11434/api/tags
# See what is loaded into memory right now
curl http://SERVER_IP:11434/api/ps
# Run a prompt on your hardware
curl http://SERVER_IP:11434/api/generate -d '{"model":"llama3.2","prompt":"Why is the sky blue?"}'
# Write several gigabytes to your disk
curl http://SERVER_IP:11434/api/pull -d '{"model":"llama3.2"}'
# Remove a model
curl -X DELETE http://SERVER_IP:11434/api/delete -d '{"model":"llama3.2"}'நிர்வாக ரீதியாக, நான்கு சிக்கல்கள் ஏற்படுகின்றன:
- உங்கள் CPU அல்லது GPU மற்றவருக்காக inference-ஐ இயக்குகிறது. நியாயமான பயன்பாட்டு (fair-use) CPU வரம்பு கொண்ட திட்டத்தில், தொடர்ச்சியான சுமை என்பது ஒரு அந்நியர் உங்கள் வரம்பைச் செலவழிப்பதாகும். நீங்கள் மட்டுமே பயன்படுத்துபவர் அல்லாதபோது, VPS-ல் AI பணிச்சுமை செலவுகளைக் கட்டுப்படுத்துவது மிகவும் கடினமாகிறது.
/api/pullஉங்கள் வட்டில் (disk) எழுதும். ஒவ்வொரு மாதிரியும் (model) இரண்டு முதல் நாற்பது gigabytes வரை இருக்கும். தொடர்ச்சியான pull செயல்பாடுகள் வட்டை நிரப்பிவிடும். வட்டு முழுமையாக நிரம்பினால், Ollama மட்டுமல்லாமல் அந்த server-ல் உள்ள மற்ற அனைத்து service-களும் செயலிழக்கும்.- கோரிக்கைகள் உங்கள் process-க்குள் வந்து பதிவாகின்றன. இயல்புநிலை log நிலையில் Ollama metadata-வை மட்டுமே பதிவு செய்கிறது. எனவே, prompt உரை கிடைக்காது, ஆனால் endpoint, status, latency மற்றும் client முகவரி ஆகியவை கிடைக்கும். உங்கள் server-ஐ யார் பயன்படுத்தினார்கள், எதற்காகப் பயன்படுத்தினார்கள் என்பதற்கான பதிவு உங்கள் journal-ல் இருக்கும்; இதை நீங்கள் சேகரிக்க விரும்பவில்லை என்றாலும் இது நடக்கும்.
/api/deleteமாதிரிகளை நீக்கும். அவற்றை மீண்டும் பெற, உங்கள் சொந்த bandwidth-ஐப் பயன்படுத்தி மீண்டும் பதிவிறக்கம் செய்ய வேண்டியிருக்கும்.
இதற்கு எந்த exploit-ம் தேவையில்லை. இது வடிவமைக்கப்பட்டபடியே செயல்படும் ஆவணப்படுத்தப்பட்ட API ஆகும்.
Ed25519 key என்பது ஒரு access control அல்ல
"Ollama API key" என்று தேடினால், நீங்கள் இரண்டு வெவ்வேறு விஷயங்களைக் காண்பீர்கள். இவை இரண்டுமே உங்கள் server-க்கான கடவுச்சொல் (password) அல்ல. இவற்றைத் தெளிவாகப் புரிந்துகொண்டால் குழப்பம் நீங்கும்.
முதலாவது, identity key pair. Ollama முதல்முறை இயங்கும்போது ஒரு Ed25519 key pair-ஐ உருவாக்குகிறது. Linux-ல், install script ஆனது ollama என்ற பெயரில் ஒரு system user-ஐ உருவாக்கி, அதன் home directory-ஐ /usr/share/ollama-ல் அமைக்கும். எனவே, அந்த key pair இங்கே இருக்கும்:
/usr/share/ollama/.ollama/id_ed25519
/usr/share/ollama/.ollama/id_ed25519.pubஇந்த key வெளிப்புறத்தை நோக்கியது. ollama signin, அதன் public பகுதியை உங்கள் ollama.com கணக்குடன் பதிவு செய்கிறது. ஒரு model-ஐ registry-க்கு push செய்ய அல்லது private model-ஐ pull செய்ய இதுவே உங்களை அங்கீகரிக்கிறது. இது உங்கள் machine-ஐ ollama.com-க்கு உறுதிப்படுத்துகிறது. உங்கள் machine-உடன் இணையும் clients-க்கு இது எவ்விதக் கட்டுப்பாட்டையும் விதிக்காது. இதை நீக்குவதோ, மாற்றுவதோ அல்லது உருவாக்காமல் இருப்பதோ உங்கள் API-ஐ யார் அழைக்கலாம் என்பதில் எந்த மாற்றத்தையும் ஏற்படுத்தாது.
இரண்டாவது, OLLAMA_API_KEY. இந்த variable, நீங்கள் https://ollama.com/settings/keys-ல் உருவாக்கும் ஒரு key-ஐ வைத்திருக்கும். நீங்கள் https://ollama.com/api-ல் உள்ள hosted API-ஐ அழைக்கும்போது, உங்கள் client அதை Authorization: Bearer $OLLAMA_API_KEY-ஆக அனுப்பும். இது அவர்களின் service-க்கான ஒரு credential ஆகும், இதை நீங்கள் client-ஆகப் பயன்படுத்துகிறீர்கள். உங்கள் சொந்த ollama serve இதை ஒருபோதும் வாசிப்பதில்லை. உங்கள் VPS-ல் OLLAMA_API_KEY-ஐ அமைப்பது உங்கள் VPS-க்கு கடவுச்சொல்லைப் பாதுகாப்பாக வைக்காது.
எனவே, இதைச் செயல்படுத்த எந்த அமைப்பும் (setting) இல்லை. கீழே உள்ள மூன்று பாதுகாப்பு முறைகளும் ஒரே விதமாகவே செயல்படுகின்றன: port-ஐ அணுக முடியாதபடி வைத்திருங்கள், மேலும் அதைச் சரிபார்க்கும் ஒரு கருவியை அதற்கு முன்னால் நிறுத்துங்கள்.
உங்கள் server தற்போது எதைக் கவனிக்கிறது (listening) என்பதைச் சரிபார்க்கவும்
sudo ss -tlnp | grep 11434பாதுகாப்பான முடிவானது loopback முகவரியைக் காட்டும்:
LISTEN 0 4096 127.0.0.1:11434 0.0.0.0:* users:(("ollama",pid=812,fd=3))வெளிப்படுத்தப்பட்ட முடிவானது அனைத்து interface-களையும் காட்டும்:
LISTEN 0 4096 0.0.0.0:11434 0.0.0.0:* users:(("ollama",pid=812,fd=3))0.0.0.0 என்பது server-ல் உள்ள அனைத்து IPv4 முகவரிகளையும் குறிக்கும், இதில் public முகவரியும் அடங்கும். *:11434 மற்றும் [::]:11434 ஆகியவை IPv6-உடன் சேர்த்து அதே அர்த்தத்தைத் தருகின்றன.
இப்போது வெளியிலிருந்து உறுதிப்படுத்தவும். இதை server-ல் இயக்க வேண்டாம், உங்கள் laptop-ல் இயக்கவும்:
curl -m 5 http://YOUR_SERVER_IP:11434/api/versioncurl: (28) Connection timed out after 5001 milliseconds என்பது நீங்கள் எதிர்பார்க்கும் பதில், curl: (7) Failed to connect ... Connection refused என்பதும் அதேதான். version field-ஐக் கொண்ட ஒரு JSON object என்பது, அந்த API-ஐ யார் வேண்டுமானாலும் அணுக முடியும் என்று அர்த்தம். Server-லேயே curl மூலம் சோதிப்பது எதையும் நிரூபிக்காது, ஏனெனில் loopback எப்போதும் பதிலளிக்கும்.
பொதுவாக இரண்டு வழிகளில் வெளிப்பாடு (exposure) நிகழ்கிறது. முதலாவது, வேண்டுமென்றே செய்யப்படும் திருத்தம்; ஏனெனில் மற்றொரு machine-லிருந்து அந்த model-ஐ அணுக வேண்டிய தேவை ஏற்பட்டிருக்கலாம்:
sudo systemctl edit ollama.service[Service]
Environment="OLLAMA_HOST=0.0.0.0:11434"அந்த ஒரு வரிதான் முழு வெளிப்பாட்டிற்கும் காரணமாகிறது. இரண்டாவது வழி Docker ஆகும், இது எதையும் திருத்தச் சொல்லாது. அதற்கென கீழே தனிப் பகுதி உள்ளது.
பாதுகாப்பு முறை 1: localhost-ல் வைத்துக்கொண்டு tunnel மூலம் அணுகுதல்
முதலில் இதை முயற்சி செய்யவும். இதற்குப் புதிய மென்பொருள் தேவையில்லை, கசியக்கூடிய எந்தவொரு நற்சான்றிதழும் (credential) உருவாக்கப்படுவதில்லை. இந்த port பொதுவான interface-ல் இருக்காது என்பதால், scanning மூலம் இதைக் கண்டறிய முடியாது.
இயல்பான அமைப்பைச் சார்ந்திருக்காமல், bind address-ஐ நேரடியாகக் குறிப்பிடவும்:
sudo systemctl edit ollama.service[Service]
Environment="OLLAMA_HOST=127.0.0.1:11434"இது /etc/systemd/system/ollama.service.d/override.conf-ஐ எழுதும். இதைச் செயல்படுத்திச் சரிபார்க்கவும்:
sudo systemctl daemon-reload
sudo systemctl restart ollama
sudo ss -tlnp | grep 11434ss இப்போது 127.0.0.1:11434-ஐக் காட்ட வேண்டும். ஒருவேளை அது இன்னும் 0.0.0.0-ஐக் காட்டினால், வேறொரு drop-in file முன்னுரிமை பெறுகிறது என்று அர்த்தம். systemctl cat ollama.service-ஐ இயக்கி, அந்த unit மற்றும் அதன் அனைத்து drop-in கோப்புகளையும் பாதையுடன் பட்டியலிட்டு, தேவையற்றதை நீக்கவும்.
உங்கள் மடிக்கணினியிலிருந்து இந்த மாதிரியைப் பயன்படுத்த, SSH மூலம் port-ஐ forward செய்யவும்:
ssh -N -L 11434:127.0.0.1:11434 you@your-server-L 11434:127.0.0.1:11434 உங்கள் மடிக்கணினியில் 11434 port-ஐத் திறந்து, அங்கு வரும் அனைத்தையும் server-ன் பார்வையில் 127.0.0.1:11434-க்கு அனுப்பும். -N என்பது remote command-ஐ இயக்க வேண்டாம் என்று SSH-க்குக் கட்டளையிடுகிறது, எனவே அந்த process tunnel-ஐத் தொடர்ந்து திறந்தே வைத்திருக்கும். இது இயங்கும்போது, உங்கள் மடிக்கணினியில் பின்வருவது வேலை செய்யும்:
curl -s http://localhost:11434/api/tagsநீங்கள் இரண்டு தோல்விகளைச் சந்திக்க நேரிடலாம். bind [127.0.0.1]:11434: Address already in use என்பது உங்கள் மடிக்கணினியில் ஏற்கனவே அந்த port-ல் Ollama இயங்குகிறது என்று பொருள், எனவே -L 11500:127.0.0.1:11434 மூலம் வேறு ஒரு local port-ஐத் தேர்ந்தெடுத்து, உங்கள் client-ஐ 11500-க்கு மாற்றவும். tunnel சரியாக இணைக்கப்பட்டும் பதில் வரவில்லை என்றால், SSH வேலை செய்கிறது ஆனால் server பக்கத்தில் Ollama இயங்கவில்லை என்று பொருள், எனவே SSH கட்டளையைத் தொடுவதற்கு முன் அங்கு ss-ஐச் சரிபார்க்கவும்.
பல client கணினிகள் இருந்தால், ஒவ்வொருவருக்கும் ஒரு tunnel அமைப்பதை விட ஒரு private network சிறந்தது. கணினிகளை WireGuard அல்லது Tailscale-ல் இணைத்து, Ollama-வை 0.0.0.0-க்கு பதிலாக அந்த network-ன் முகவரியில் bind செய்யவும்:
[Service]
Environment="OLLAMA_HOST=10.8.0.1:11434"இந்த port நீங்கள் key வைத்திருக்கும் interface-ல் மட்டுமே இருக்கும். இது firewall-ல் தவறு நடந்தாலும் பாதுகாக்கும், ஏனெனில் தவறுதலாக பொதுமக்களுக்கு அனுமதி அளித்தாலும், public interface-ல் இல்லாத listener-ஐ யாராலும் அணுக முடியாது.
பாதுகாப்பு 2: bearer token-ஐ சரிபார்க்கும் reverse proxy
பொது இணையத்திலிருந்து ஏதேனும் ஒன்று model-ஐ அழைக்க வேண்டியிருக்கும் போது, Ollama-வை loopback-ல் வைத்துக்கொண்டு, அதற்கு முன்னால் ஒரு proxy-ஐ அமைக்கவும். இந்த proxy TLS (transport layer security)-ஐ முடித்து, சரியான header இல்லாத கோரிக்கைகளை நிராகரிக்கிறது. Ollama தொடர்ந்து 127.0.0.1-லிருந்து வரும் இணைப்புகளை மட்டுமே ஏற்பதால், இந்த proxy மட்டுமே உள்ளே செல்வதற்கான ஒரே வழியாகும்.
முதலில் ஒரு உண்மையான token-ஐ உருவாக்கவும். நீங்களாகவே எதையும் உருவாக்க வேண்டாம்:
openssl rand -base64 36அதைச் சரிபார்க்கும் ஒரு nginx தளம்:
map $http_authorization $ollama_ok {
default 0;
"Bearer PASTE_YOUR_GENERATED_TOKEN_HERE" 1;
}
server {
listen 443 ssl;
server_name llm.example.com;
ssl_certificate /etc/letsencrypt/live/llm.example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/llm.example.com/privkey.pem;
location = /api/pull { return 403; }
location = /api/delete { return 403; }
location = /api/push { return 403; }
location / {
if ($ollama_ok = 0) { return 401; }
proxy_pass http://127.0.0.1:11434;
proxy_set_header Host 127.0.0.1:11434;
proxy_buffering off;
proxy_read_timeout 600s;
}
}அதில் உள்ள ஐந்து வரிகள் உண்மையான வேலையைச் செய்கின்றன, ஒவ்வொன்றும் நீங்கள் சந்திக்கக்கூடிய ஒரு தோல்வியைத் தடுக்கின்றன.
nginx-ல் ஒரு location தொகுதிக்குள் if இருப்பது பொதுவாக நல்லதல்ல, ஆனால் சரியாக return அளவுள்ள body, கணிக்கக்கூடிய வகையில் செயல்படும் இரண்டு வடிவங்களில் ஒன்றாகும், எனவே இந்த பயன்பாடு பாதுகாப்பானது.
location = /api/pull என்பது துல்லியமான பொருத்தம் (exact match), மேலும் nginx துல்லியமான பொருத்தங்களை location / முன்னொட்டை விட உயர்வாகக் கருதுகிறது, எனவே அந்த மூன்று endpoints-களும் token பரிசீலிக்கப்படுவதற்கு முன்பே நிராகரிக்கப்படுகின்றன. ஒரு செல்லுபடியாகும் token உங்களுக்கு inference-ஐ மட்டுமே வழங்கும், உங்கள் disk-ஐ நிரப்பும் திறனை அல்ல.
proxy_set_header Host 127.0.0.1:11434; முக்கியமானது, ஏனெனில் Ollama உள்வரும் Host மற்றும் Origin headers-ஐ ஆய்வு செய்கிறது. proxy-ன் public hostname-ஐ அப்படியே கடத்துவது, nginx-லிருந்து வராமல் Ollama-விலிருந்து வரும் ஒரு 403 Forbidden-ஐ உருவாக்கலாம், இது பிழைத்திருத்தத்திற்கு குழப்பத்தை ஏற்படுத்தும். OLLAMA_ORIGINS என்பது மற்றொரு கருவி, இது ஒரு குறிப்பிட்ட origin அனுமதிக்கப்பட வேண்டிய browser client-க்காகப் பயன்படுகிறது.
proxy_buffering off; முக்கியமானது, ஏனெனில் Ollama தனது பதிலை token வாரியாக stream செய்கிறது. buffering செயல்பாட்டில் இருந்தால், nginx stream-ஐத் தடுத்து வைத்து, இறுதியில் முழுமையாக வழங்குகிறது, இதனால் generation முடியும் வரை உங்கள் client உறைந்து போனது போலத் தோன்றும்.
proxy_read_timeout 600s; முக்கியமானது, ஏனெனில் nginx இயல்பாகவே 60 வினாடிகளை காலாவதி நேரமாக (timeout) கொண்டுள்ளது. CPU-வில் நீண்ட generation நடக்கும்போது அந்த நேரத்தை எளிதாகக் கடந்துவிடும், client-க்கு 504 Gateway Time-out கிடைக்கும், மேலும் /var/log/nginx/error.log-ல் upstream timed out (110: Connection timed out) while reading response header from upstream என்று பதிவாகும். கோரிக்கை இன்னும் செயல்பட்டுக்கொண்டிருக்கும், ஆனால் nginx அதைக் கைவிட்டுவிட்டது.
Reload செய்து இரண்டு பாதைகளையும் சோதிக்கவும்:
sudo nginx -t && sudo systemctl reload nginx
curl -s -o /dev/null -w '%{http_code}\n' https://llm.example.com/api/tags
curl -s -H "Authorization: Bearer YOUR_TOKEN" https://llm.example.com/api/tagsமுதலாவது 401-ஐ அச்சிட வேண்டும். இரண்டாவது உங்கள் model பட்டியலை அச்சிட வேண்டும். முதலாவது கூட model பட்டியலைத் திருப்பித் தந்தால், map தொகுதி தவறான scope-ல் உள்ளது. அது http மட்டத்தில் இருக்க வேண்டும், எனவே அதை /etc/nginx/conf.d/-க்குக் கீழே உள்ள கோப்பிலோ அல்லது server தொகுதிக்கு மேலோ வைக்கவும், ஒருபோதும் server-க்குள் வைக்க வேண்டாம்.
Caddy இதே வேலையை நான்கு வரிகளில் basic authentication மூலம் செய்கிறது, இது bearer token-ஐ விட browser client-க்கு மிகவும் பொருத்தமானது:
llm.example.com {
basic_auth {
apiuser PASTE_BCRYPT_HASH_HERE
}
reverse_proxy 127.0.0.1:11434
}அது எதிர்பார்க்கும் bcrypt hash-ஐ உருவாக்க caddy hash-password-ஐ இயக்கவும். ஒரு பெயரிடல் சிக்கல்: Caddy v2.8-க்கு முன்பு இந்த directive basicauth என்று இருந்தது, இப்போது basic_auth என்று உள்ளது, எனவே பழைய வழிகாட்டிகளிலிருந்து நகலெடுக்கப்பட்ட config ஏற்றப்படாது, மேலும் Caddy தான் அடையாளம் காணாத directive-ன் பெயரைத் தெரிவிக்கும்.
நீங்கள் எந்த proxy-ஐத் தேர்ந்தெடுத்தாலும், இது அனைவருக்கும் பகிரப்பட்ட ஒரு ரகசியமாகும். அதை வைத்திருக்கும் ஒவ்வொரு client-க்கும் ஒரே மாதிரியான அணுகல் இருக்கும், அதை ரத்து செய்வது என்பது config-ஐத் திருத்தி, அனைத்து பயனர்களிடமும் ஒரே நேரத்தில் புதுப்பிப்பதைக் குறிக்கும்.
பாதுகாப்பு 3: ஒவ்வொரு client-க்கும் தனித்தனி key வழங்கும் gateway
ஒன்றுக்கும் மேற்பட்ட நபர்கள் அல்லது application-கள் model-ஐ அழைக்கும்போது, பகிரப்பட்ட (shared) token-ன் பயன்பாடு வரம்பை எட்டிவிடும். எந்த client சுமையை (load) ஏற்படுத்துகிறது என்பதை உங்களால் கண்டறிய முடியாது; அனைவரையும் துண்டிக்காமல் ஒரு குறிப்பிட்ட client-ஐ மட்டும் உங்களால் தடுக்க முடியாது. Proxy இருந்த இடத்தில் ஒரு gateway-ஐ அமைக்க வேண்டும். இது OpenAI-compatible API-ஐப் பின்பற்றும், ஒவ்வொரு client-க்கும் தனித்தனி key வழங்கும் மற்றும் ஒவ்வொரு key-ன் பயன்பாட்டையும் பதிவு செய்யும். சுயமாக இயங்கும் LiteLLM gateway இதற்குச் சிறந்த தீர்வாகும். இது access control-உடன் சேர்த்து, ஒவ்வொரு key-க்கும் தனித்தனி வரவு-செலவுத் திட்டம் (budget) மற்றும் request logs-ஐயும் சேர்க்கிறது.
பாதுகாப்பு 1-ல் உள்ள விதி மாறாது. Ollama-வை 127.0.0.1-ல் bind செய்ய வேண்டும். அந்த gateway மட்டுமே அதனுடன் தொடர்பு கொள்ளும், மேலும் அந்த gateway மட்டுமே public listener-ஐக் கொண்ட ஒரே service-ஆக இருக்க வேண்டும். port 11434 உலகிற்குத் திறந்திருக்கும் ஒரு server-ல் gateway-ஐ அமைப்பது பயனற்றது, ஏனெனில் அழைப்பாளர்கள் (callers) எளிதாக அதைத் தவிர்த்துவிட்டு நேரடியாகச் செல்ல முடியும்.
Firewall சிக்கல்: வெளியிடப்பட்ட container port UFW-ஐத் தவிர்க்கிறது
சரியான firewall விதிகளை அமைத்திருந்தும், server-ல் உள்ள instances ஏன் வெளி உலகிற்குத் திறந்த நிலையில் இருக்கின்றன என்பதற்கு இதுவே காரணம்.
UFW (uncomplicated firewall) தனது விதிகளை kernel-ன் INPUT chain-ல், filter table-ல் எழுதுகிறது. INPUT, host-ஐ நோக்கி வரும் பாக்கெட்டுகளைக் கையாளுகிறது. Docker-ன் -p flag, destination NAT (network address translation) விதியை nat table-ன் PREROUTING chain-ல் எழுதுகிறது. பாக்கெட் எங்கு செல்ல வேண்டும் என்று kernel தீர்மானிக்கும் முன்பே, இந்த விதியை அது மதிப்பீடு செய்கிறது. Routing முடிவு எடுக்கும்போது, பாக்கெட்டின் இலக்கு ஏற்கனவே container-ன் முகவரிக்கு மாற்றப்பட்டிருக்கும். எனவே, பாக்கெட் உள்ளூர் பயன்பாட்டிற்கு வராமல், நேரடியாக forward செய்யப்படுகிறது; இது INPUT-க்கு பதிலாக FORWARD வழியாகச் செல்கிறது. UFW-ன் INPUT விதிகள் ஒருபோதும் சரிபார்க்கப்படுவதில்லை, இதனால் பாக்கெட் firewall-ஐத் தவிர்த்துச் செல்கிறது.
இதன் காரணமாகவே, பின்வரும் வரிசைமுறை port 11434-ஐ இணையத்திற்குத் திறந்து விடுகிறது:
sudo ufw default deny incoming
sudo ufw enable
docker run -d -v ollama:/root/.ollama -p 11434:11434 --name ollama ollama/ollamaமேலும், sudo ufw status கட்டளை firewall இயங்குவதையும், default deny நிலையில் இருப்பதையும் காட்டுகிறது. இரண்டு தகவல்களும் ஒரே நேரத்தில் உண்மையாக இருப்பதால், பயனர்கள் தவறான தகவலை நம்பி விடுகின்றனர். இந்தச் சிக்கலை உண்டாக்கும் விதியை நீங்கள் இவ்வாறு பார்க்கலாம்:
sudo iptables -t nat -L DOCKER -nஇதற்கான தீர்வு, publish flag-ல் ஒரு முகவரியைச் சேர்ப்பதுதான்:
docker rm -f ollama
docker run -d -v ollama:/root/.ollama -p 127.0.0.1:11434:11434 --name ollama ollama/ollama-p 11434:11434 என்பது -p 0.0.0.0:11434:11434 என்பதன் சுருக்கமாகும். 127.0.0.1 என்று குறிப்பிடுவது, mapping-ன் host பகுதியை loopback-ல் பிணைக்கிறது (bind). இதனால் உங்கள் SSH tunnel மற்றும் reverse proxy மூலம் மட்டுமே இதை அணுக முடியும், இணையத்தால் முடியாது. Container-ஐ மீண்டும் உருவாக்குவது பாதுகாப்பானது, ஏனெனில் மாதிரிகள் (models) container-க்குள் இல்லை, பெயரிடப்பட்ட ollama volume-ல் உள்ளன.
இரண்டு பார்வைகளும் ஒத்துப்போவதை உறுதிப்படுத்தவும்:
docker port ollama
sudo ss -tlnp | grep 11434docker port ollama கட்டளை 11434/tcp -> 127.0.0.1:11434 என்று காட்ட வேண்டும். அது 0.0.0.0:11434 என்று காட்டினால், உங்கள் server இன்னும் பாதுகாப்பற்ற நிலையில் உள்ளது. இந்த நுட்பத்தை ஒருமுறை கற்றுக்கொண்டால், நீங்கள் வெளியிடும் அனைத்து container-களுக்கும் இது பொருந்தும்: Docker வெளியிடப்பட்ட ports ஏன் UFW-ஐத் தவிர்க்கின்றன என்ற கட்டுரை DOCKER-USER chain மற்றும் Docker restart-க்குப் பிறகும் நீடிக்கும் விதிகளை விளக்குகிறது. நீங்கள் இன்னும் host policy-ஐ உருவாக்கி வருகிறீர்கள் என்றால், புதிய VPS-க்குத் தேவையான UFW விதிகள் என்ற கட்டுரை இதற்கான அடிப்படை அமைப்புகளை விளக்குகிறது.
இந்த process எந்த பயனர் கணக்கில் இயங்குகிறது
Linux install script ஒரு பிரத்யேக கணக்கை உருவாக்கி, அதன் கீழ் service-ஐ இயக்குகிறது:
useradd -r -s /bin/false -U -m -d /usr/share/ollama ollama/etc/systemd/system/ollama.service-ல் உள்ள unit, User=ollama மற்றும் Group=ollama ஆகியவற்றை அமைக்கிறது. அதை மாற்ற வேண்டாம். terminal-ல் கைமுறையாகத் தொடங்கப்படும் ஒரு ollama serve, நீங்கள் login செய்துள்ள பயனர் கணக்கிலேயே இயங்கும். அது root ஆக இருந்தால், அங்கீகரிக்கப்படாத API ஒன்று root உரிமையுடன் கோப்புகளை எழுதும். எது இயங்குகிறது என்பதைச் சரிபார்க்கவும்:
ps -o user= -C ollamaஇதற்கான விடை ollama என்று இருக்க வேண்டும். வேறு ஏதேனும் விடை வந்தால், unit-க்கு பதிலாகவோ அல்லது அதனுடன் இணைந்தோ கைமுறையாகத் தொடங்கப்பட்ட process ஒன்று இயங்குகிறது என்று அர்த்தம். நீங்கள் பின்னர் சேர்க்கும் ஒவ்வொரு daemon-க்கும் இதே சிந்தனை பொருந்தும், மேலும் குறைந்தபட்ச அதிகாரமுள்ள பயனர்களாக services-ஐ இயக்குவது இதைப் பற்றி விரிவாக விளக்குகிறது.
Ollama API endpoint பாதுகாப்பாக உள்ளதா என்பதைச் சரிபார்ப்பது எப்படி
நீங்கள் எதைத் தேர்ந்தெடுத்திருந்தாலும், ஒரு சோதனை மூலம் இதை உறுதிப்படுத்தலாம். இதை மற்றொரு கணினியிலிருந்து இயக்க வேண்டும்:
curl -m 5 http://YOUR_SERVER_IP:11434/api/version
curl -m 5 http://YOUR_SERVER_IP:11434/api/tagsஇவை இரண்டுமே time out ஆக வேண்டும் அல்லது நிராகரிக்கப்பட வேண்டும். நீங்கள் ஒரு proxy-ஐ உருவாக்கியிருந்தால், proxy hostname-ல் உள்ள அதே இரண்டு பாதைகளும், credentials இல்லாமல் 401-ஐத் தர வேண்டும்; credentials இருந்தால் சரியான JSON-ஐத் தர வேண்டும்.
பிறகு, access log-ஐ ஒருமுறை வாசிக்கவும். ஏனெனில், port திறந்திருந்தபோது யாராவது அதைக் கண்டறிந்தார்களா என்பதை இது தெரிவிக்கும்:
journalctl -u ollama --since "-30 days" | grep GIN | grep -v 127.0.0.1Ollama ஒவ்வொரு கோரிக்கைக்கும் ஒரு வரியை எழுதுகிறது மற்றும் அதில் client முகவரியையும் உள்ளடக்குகிறது:
[GIN] 2026/08/12 - 14:01:10 | 200 | 103.965898ms | 127.0.0.1 | POST "/api/generate"Ollama loopback-ல் பிணைக்கப்பட்டவுடன் (bound), ஒவ்வொரு வரியிலும் 127.0.0.1 காட்டப்பட வேண்டும். ஏனெனில், அந்த முகவரியிலிருந்து மட்டுமே இணைப்பு வர முடியும். அந்த நெடுவரிசையில் ஒரு பொது முகவரி (public address) இருந்தால், அது வெளியிலிருந்து வந்த கோரிக்கை என்று அர்த்தம்; timestamp மூலம் அது எப்போது நடந்தது என்பதை அறியலாம். அந்த command-லிருந்து எந்த வெளியீடும் வராததே நீங்கள் எதிர்பார்க்கும் முடிவு. இந்த model சார்ந்த விஷயங்கள் உங்களுக்குப் புதியவை என்றால், VPS-ல் Ollama-வை இயக்குவது குறித்த பகுதி, நிறுவல், model அளவு மற்றும் எதை ஏற்றலாம் என்பதைத் தீர்மானிக்கும் memory வரம்புகள் பற்றி விளக்குகிறது.
FAQ
Ollama-வில் API key அல்லது password உள்ளதா?
இல்லை. நீங்கள் இயக்கும் server-ல் எந்தவிதமான authentication-ம் இல்லை. API-ஐ அணுக எந்த authentication-ம் தேவையில்லை என்று அதிகாரப்பூர்வ ஆவணங்கள் குறிப்பிடுகின்றன. "Ollama API key" என்று அழைக்கப்படுபவை இரண்டும் வேறு நோக்கங்களுக்காகப் பயன்படுபவை. /usr/share/ollama/.ollama/-ல் உள்ள Ed25519 ஜோடி, உங்கள் கணினியை ollama.com-உடன் இணைத்து, நீங்கள் models-ஐ பதிவேற்றவும் (push), தனிப்பட்ட models-ஐ பதிவிறக்கவும் (pull) உதவுகிறது. OLLAMA_API_KEY என்பது https://ollama.com/api-ல் உள்ள hosted API-க்கு உங்கள் client அனுப்பும் ஒரு credential ஆகும். உங்கள் சொந்த ollama serve இவை இரண்டையுமே வாசிப்பதில்லை, எனவே access control-ஐ network மூலமாகவோ அல்லது முன்னால் உள்ள ஒரு proxy மூலமாகவோதான் நீங்கள் நிர்வகிக்க வேண்டும்.
என்னிடம் firewall இருந்தால் OLLAMA_HOST=0.0.0.0 பாதுகாப்பானதா?
அந்த server-ல் வேறு யாரும் firewall விதிகளை மாற்றாத வரை மட்டுமே இது பாதுகாப்பானது. 0.0.0.0 என்பது listener பொதுவான interface-ல் இயங்குகிறது என்பதைக் குறிக்கிறது. அதை அணுக முடியாதபடி தடுக்க firewall-ஐ மட்டுமே நீங்கள் நம்பியிருக்கிறீர்கள். Docker ஒரு port-ஐ publish செய்யும் தருணத்தில் இந்த நம்பிக்கை உடைந்துவிடும். ஏனெனில், Docker சேர்க்கும் DNAT விதி nat table-ல், UFW இருக்கும் INPUT chain-க்கு முன்பே செயல்படுத்தப்படும். இதனால் packet நேரடியாக அனுப்பப்பட்டுவிடும், UFW அதை கவனிக்காது. 127.0.0.1 அல்லது ஒரு private tunnel address-ல் bind செய்வதன் மூலம், listener-ஐ பொதுவான interface-லிருந்து நீக்கலாம். இதனால் firewall-ல் தவறு நடந்தாலும், வெளிப்படையாக எதுவும் இருக்காது.
எனது Ollama port இணையத்திற்குத் திறந்திருக்கிறதா என்பதை எப்படிச் சரிபார்ப்பது?
Server-ல் sudo ss -tlnp | grep 11434-ஐயும், வேறொரு கணினியிலிருந்து curl -m 5 http://YOUR_SERVER_IP:11434/api/version-ஐயும் இயக்கவும். ss-ல் 127.0.0.1:11434 காட்டப்பட்டு, remote curl-க்கு பதில் கிடைக்காமல் (timeout) இருந்தால், அதுவே சரியான பாதுகாப்பு நிலை. ss-ல் 0.0.0.0:11434 அல்லது *:11434 காட்டப்பட்டு, remote curl JSON பதிலை அளித்தால், முழு API-யும் அணுகக்கூடிய நிலையில் உள்ளது என்று அர்த்தம். Server-லேயே curl வைத்து ஒருபோதும் சோதிக்க வேண்டாம், ஏனெனில் loopback முகவரி bind செய்யப்பட்ட முகவரியைப் பொருட்படுத்தாமல் பதிலளிக்கும்.
Port-ஐ 11434-லிருந்து வேறு ஏதேனும் random port-க்கு மாற்றலாமா?
கூடாது, இதற்கான காரணத்தைப் புரிந்துகொள்வது அவசியம். ஒரு port-ஐ மாற்றுவது, அந்த ஒரு குறிப்பிட்ட port-ஐ மட்டும் scan செய்வதைத் தாமதப்படுத்துமே தவிர, பாதுகாப்பைத் தராது. Scanners முழு range-ஐயும் சோதிக்கும், மேலும் /api/tags-க்கு வரும் ஒரு request, எந்த port-ல் வந்தாலும் அது என்ன service என்பதைக் காட்டிவிடும். Port-ஐ மாற்றுவது அனைத்து client-களின் default அமைப்புகளையும் பாதிக்கும், மேலும் உங்கள் setup-ஐப் புரிந்துகொள்வதையும் கடினமாக்கும். அதற்குப் பதிலாக loopback-ல் bind செய்யவும்; இது listener-ஐ இடமாற்றம் செய்வதற்குப் பதிலாக, பொது அணுகலிலிருந்து நீக்கிவிடும்.
யாரோ எனது திறந்திருக்கும் Ollama-வை அணுகிவிட்டார்கள். நான் எதைச் சரிபார்க்க வேண்டும்?
முதலில் அதை 127.0.0.1-ல் bind செய்து service-ஐ restart செய்யவும், இதனால் விசாரணை தொடங்கும் முன்பே அணுகல் நிறுத்தப்படும். பிறகு, எந்தெந்த வெளி முகவரிகள், எந்த endpoints-ஐ, எப்போது அணுகின என்பதைப் பார்க்க journalctl -u ollama --since "-30 days" | grep GIN | grep -v 127.0.0.1-ஐ இயக்கவும். ollama list-ஐ நீங்கள் வைத்திருக்கும் models-உடன் ஒப்பிட்டுப் பார்க்கவும். /api/pull-ல் authentication இல்லாததால், நீங்கள் பதிவிறக்காத ஒரு model அங்கு இருந்தால், அது disk இடத்தை ஆக்கிரமிப்பதோடு, ஊடுருவலுக்கான ஆதாரமாகவும் இருக்கும். df -h மூலம் மீதமுள்ள disk இடத்தை சரிபார்க்கவும். Ollama அதன் default log level-ல் prompt உரையைச் சேமிப்பதில்லை, எனவே யார் எந்த model-ஐக் கேட்டார்கள் என்ற பதிவு மட்டுமே உங்களிடம் இருக்கும், என்ன பதில் உருவாக்கப்பட்டது என்ற பதிவு இருக்காது.