curl SSL, TLS & პროქსის კონფიგურაციის გზამკვლევი

Q: როგორ გამოვტოვო SSL სერტიფიკატის ვერიფიკაცია curl-ში?

გამოიყენეთ curl -k URL ან curl --insecure URL. ეს გამორთავს სერტიფიკატის ყველა შემოწმებას — ვადის გასვლა, ჰოსტის სახელის შეუთავსებლობა, არასანდო CA. გამოიყენეთ მხოლოდ ლოკალური განვითარებისთვის. პროდაქშენისთვის გამოიყენეთ --cacert ფაქტობრივი CA სერტიფიკატით.

Q: როგორ ვაიძულო curl-ს ენდოს თვით-ხელმოწერილ სერტიფიკატს?

გამოიყენეთ curl --cacert /path/to/ca.pem URL თქვენი თვით-ხელმოწერილი სერტიფიკატის CA სერტიფიკატის მისათითებლად. ეს უფრო უსაფრთხოა ვიდრე -k, რადგან სერტიფიკატის ჯაჭვი მაინც ვერიფიცირდება — მხოლოდ თქვენს კონკრეტულ CA-ს ენდობა.

Q: როგორ შევამოწმო curl რომელ TLS ვერსიას იყენებს?

გაუშვით curl -v URL და მოძებნეთ ხაზი * SSL connection using TLSv1.x / CipherSuite დეტალურ გამოსავალში. კონკრეტული ვერსიის იძულებისთვის გამოიყენეთ --tlsv1.2 ან --tlsv1.3.

Q: რა არის ორმხრივი TLS (mTLS) და როგორ გამოვიყენო curl-თან?

ორმხრივი TLS მოითხოვს, რომ სერვერმაც და კლიენტმაც ორივემ წარადგინონ სერტიფიკატები. გამოიყენეთ: curl --cert client.pem --key client-key.pem --cacert server-ca.pem URL. --cert/--key წყვილი კლიენტს ავთენტიფიცირებს; --cacert სერვერს ვერიფიცირებს.

Q: როგორ გამოვიყენო curl HTTP პროქსით?

გამოიყენეთ curl -x http://proxy:port URL. HTTPS პროქსისთვის: curl -x https://proxy:port URL. ალტერნატიულად, დააყენეთ http_proxy და https_proxy გარემოს ცვლადები — curl ავტომატურად წაიკითხავს მათ.

Q: როგორ გამოვიყენო curl SOCKS5 პროქსით?

ლოკალური DNS რეზოლუციისთვის გამოიყენეთ curl --socks5 host:port URL, ან პროქსით DNS-ის მოსაგვარებლად curl --socks5-hostname host:port URL (მნიშვნელოვანია კონფიდენციალურობისთვის/Tor-ისთვის). SSH ტუნელის მაგალითი: ssh -D 1080 user@bastion, შემდეგ curl --socks5 localhost:1080 URL.

Q: როგორ გავიარო ავთენტიფიკაცია პროქსი სერვერთან curl-ში?

გამოიყენეთ curl -x http://proxy:port -U user:password URL. -U (ან --proxy-user) ფლაგი სერთიფიკატებს პროქსისკენ აგზავნის. ეს განსხვავდება -u-სგან, რომელიც სამიზნე სერვერთან ავთენტიფიკაციას ახდენს.

Q: როგორ გამოვრიცხო კონკრეტული ჰოსტები პროქსიდან curl-ში?

გამოიყენეთ --noproxy "localhost,127.0.0.1,*.internal.com" ან დააყენეთ NO_PROXY გარემოს ცვლადი. მხარს უჭერს ჯოკერებს (*.example.com). ერთი მოთხოვნისთვის პროქსის სრულად გვერდის ასავლელად გამოიყენეთ --noproxy "*".

Q: როგორ ვატესტო HTTPS localhost-ზე curl-ით?

სწრაფი ტესტირებისთვის: curl -k https://localhost:8443/. სწორი ვალიდაციისთვის: curl --resolve myapp.local:443:127.0.0.1 --cacert local-ca.pem https://myapp.local/. --resolve მიდგომა საშუალებას აძლევს სერტიფიკატის ჰოსტის სახელს სწორად დაემთხვეს.

Q: როგორ გადავფარო DNS რეზოლუცია კონკრეტული ჰოსტისთვის curl-ში?

გამოიყენეთ curl --resolve host:port:IP URL. მაგალითი: curl --resolve api.example.com:443:192.168.1.100 https://api.example.com/. ეს DNS-ს გვერდს უვლის მხოლოდ ამ host:port წყვილისთვის — /etc/hosts-ის რედაქტირება საჭირო არ არის.

HTTPS სერტიფიკატების, TLS ვერსიების, პროქსებისა და მორგებული DNS რეზოლუციის კონფიგურაცია curl-ში აუცილებელია უსაფრთხო API კომუნიკაციისთვის, CI/CD პაიპლაინებისთვის და ქსელის პრობლემების დიაგნოსტიკისთვის. ეს გზამკვლევი მოიცავს SSL, TLS, პროქსისა და ქსელის ყველა ფლაგს — ლოკალური განვითარებისთვის -k-ით სერტიფიკატის შემოწმების გამორთვიდან, --cert-ით ორმხრივი TLS-ის დაყენებამდე და SOCKS5 პროქსებში ტრაფიკის მარშრუტიზაციამდე. თითოეული პარამეტრი მოიცავს მკაფიო ახსნას, უსაფრთხოების მოსაზრებებს და კოპირებისთვის მზა მაგალითს.

SSL & პროქსის ფლაგების სწრაფი მითითება

ფლაგი	კატეგორია	აღწერა
-k	SSL/TLS	არაუსაფრთხო კავშირების დაშვება — ყველა SSL ვერიფიკაციის გამოტოვება
--cacert	SSL/TLS	სერვერის სერტიფიკატის ვერიფიკაცია კონკრეტული CA ფაილის მიმართ
--cert	SSL/TLS	კლიენტის სერტიფიკატის მიწოდება ორმხრივი TLS ავთენტიფიკაციისთვის
--key	SSL/TLS	კლიენტის სერტიფიკატის პრივატული გასაღების ფაილის მიწოდება
--tlsv1.2	SSL/TLS	კავშირისთვის TLS ვერსია 1.2 ან უფრო მაღლის გამოყენება
--tlsv1.3	SSL/TLS	კავშირისთვის TLS ვერსია 1.3 ან უფრო მაღლის გამოყენება
--ssl-reqd	SSL/TLS	კავშირისთვის SSL/TLS-ის მოთხოვნა (მიუწვდომლობისას წარუმატებლობა)
--ciphers	SSL/TLS	კავშირისთვის SSL შიფრების მითითება
--cert-type	SSL/TLS	კლიენტის სერტიფიკატის ტიპის მითითება (PEM, DER, ENG, P12)
--pinnedpubkey	SSL/TLS	სერვერის საჯარო გასაღების ფიქსაცია და ვერიფიკაცია (HPKP სტილი)
-x	პროქსი	ყველა ტრაფიკის მარშრუტიზაცია მითითებული პროქსი სერვერით
--socks5	პროქსი	კავშირის მარშრუტიზაცია SOCKS5 პროქსით
--proxy-user	პროქსი	პროქსი სერვერისთვის username:password-ის მიწოდება
--noproxy	პროქსი	ჰოსტების სია, რომლებიც პროქსის გავლით არ უნდა წავიდნენ
--socks5-hostname	პროქსი	SOCKS5 პროქსი DNS რეზოლუციით პროქსის მეშვეობით
--proxy-cacert	პროქსი	CA სერტიფიკატი თავად HTTPS პროქსის ვერიფიკაციისთვის
--resolve	ქსელი	კონკრეტული host:port წყვილის მორგებულ IP მისამართზე მიბმა
--connect-to	ქსელი	URL-ში მითითებულისგან განსხვავებულ host:port-ზე დაკავშირება
--local-port	ქსელი	კავშირის ლოკალური პორტის ნომრის ან დიაპაზონის დაყენება
--interface	ქსელი	კავშირის კონკრეტულ ქსელის ინტერფეისზე მიბმა
--dns-servers	ქსელი	სისტემის ნაგულისხმევი DNS სერვერების ნაცვლად მორგებულის გამოყენება (c-ares)

-kSSL/TLS

არაუსაფრთხო კავშირების დაშვება — ყველა SSL ვერიფიკაციის გამოტოვება

--cacertSSL/TLS

სერვერის სერტიფიკატის ვერიფიკაცია კონკრეტული CA ფაილის მიმართ

--certSSL/TLS

კლიენტის სერტიფიკატის მიწოდება ორმხრივი TLS ავთენტიფიკაციისთვის

--keySSL/TLS

კლიენტის სერტიფიკატის პრივატული გასაღების ფაილის მიწოდება

--tlsv1.2SSL/TLS

კავშირისთვის TLS ვერსია 1.2 ან უფრო მაღლის გამოყენება

--tlsv1.3SSL/TLS

კავშირისთვის TLS ვერსია 1.3 ან უფრო მაღლის გამოყენება

--ssl-reqdSSL/TLS

კავშირისთვის SSL/TLS-ის მოთხოვნა (მიუწვდომლობისას წარუმატებლობა)

--ciphersSSL/TLS

კავშირისთვის SSL შიფრების მითითება

--cert-typeSSL/TLS

კლიენტის სერტიფიკატის ტიპის მითითება (PEM, DER, ENG, P12)

--pinnedpubkeySSL/TLS

სერვერის საჯარო გასაღების ფიქსაცია და ვერიფიკაცია (HPKP სტილი)

-xპროქსი

ყველა ტრაფიკის მარშრუტიზაცია მითითებული პროქსი სერვერით

--socks5პროქსი

კავშირის მარშრუტიზაცია SOCKS5 პროქსით

--proxy-userპროქსი

პროქსი სერვერისთვის username:password-ის მიწოდება

--noproxyპროქსი

ჰოსტების სია, რომლებიც პროქსის გავლით არ უნდა წავიდნენ

--socks5-hostnameპროქსი

SOCKS5 პროქსი DNS რეზოლუციით პროქსის მეშვეობით

--proxy-cacertპროქსი

CA სერტიფიკატი თავად HTTPS პროქსის ვერიფიკაციისთვის

--resolveქსელი

კონკრეტული host:port წყვილის მორგებულ IP მისამართზე მიბმა

--connect-toქსელი

URL-ში მითითებულისგან განსხვავებულ host:port-ზე დაკავშირება

--local-portქსელი

კავშირის ლოკალური პორტის ნომრის ან დიაპაზონის დაყენება

--interfaceქსელი

კავშირის კონკრეტულ ქსელის ინტერფეისზე მიბმა

--dns-serversქსელი

სისტემის ნაგულისხმევი DNS სერვერების ნაცვლად მორგებულის გამოყენება (c-ares)

curl -k: SSL სერტიფიკატის შეცდომების იგნორირება

რას აკეთებს: -k (ან --insecure) ფლაგი გამორთავს SSL/TLS სერტიფიკატის ყველა ვერიფიკაციას. curl არ შეამოწმებს, ხელმოწერილია თუ არა სერვერის სერტიფიკატი სანდო CA-ს მიერ, ემთხვევა თუ არა ჰოსტის სახელი, ან ვადა გასულია თუ არა სერტიფიკატს.
როდის გამოვიყენოთ: გამოიყენეთ მხოლოდ ლოკალური განვითარებისთვის თვით-ხელმოწერილ სერტიფიკატებთან ან სატესტო გარემოებში. სტეიჯინგ/პროდაქშენისთვის გამოიყენეთ --cacert ფაქტობრივი CA სერტიფიკატით — ეს უფრო უსაფრთხო და მკაფიოა.

$ curl -k https://localhost:8443/api/health

არასოდეს გამოიყენოთ -k პროდაქშენ სკრიპტებში ან CI/CD პაიპლაინებში. ის გამორთავს ყველა სერტიფიკატის ვალიდაციას, რაც თქვენს კავშირს შუა-კაცის შეტევისთვის დაუცველს ხდის. გამოიყენეთ --cacert კონკრეტული CA-ს სანდოდ მისაჩნევად.

curl --cacert: მორგებული CA სერტიფიკატის გამოყენება

რას აკეთებს: --cacert ფლაგი curl-ს ეუბნება შეამოწმოს სერვერის SSL სერტიფიკატი სისტემის ნაგულისხმევი სანდო საცავის ნაცვლად კონკრეტული CA (სერტიფიკაციის ორგანო) ფაილის მიმართ PEM ფორმატში.
როდის გამოვიყენოთ: გამოიყენეთ, როდესაც თქვენი სერვერი იყენებს სერტიფიკატს, რომელიც ხელმოწერილია პრივატული ან შიდა CA-ს მიერ, რომელიც არ არის სისტემის სანდო საცავში. ეს გავრცელებულია კორპორაციულ გარემოებში, Kubernetes კლასტერებში და Docker-ის შიდა PKI-ის კონფიგურაციებში.

$ curl --cacert /path/to/corporate-ca.pem https://internal-api.example.com/data

curl --cert: კლიენტის სერტიფიკატი (ორმხრივი TLS)

რას აკეთებს: --cert ფლაგი უზრუნველყოფს კლიენტის მხარის სერტიფიკატს ორმხრივი TLS (mTLS)-ისთვის. mTLS-ში სერვერიც და კლიენტიც წარადგენენ სერტიფიკატებს ერთმანეთის ვინაობის დასადასტურებლად. სერტიფიკატის ფაილი უნდა იყოს PEM ან PKCS#12 ფორმატში.
როდის გამოვიყენოთ: საჭიროა, როდესაც სერვერი მოითხოვს კლიენტის სერტიფიკატით ავთენტიფიკაციას — გავრცელებულია საბანკო API-ებში, სახელმწიფო სერვისებში, IoT მოწყობილობების კომუნიკაციაში და ნულოვანი ნდობის არქიტექტურებში. ყოველთვის დააწყვილეთ --key-სთან, თუ გასაღები სერტიფიკატის ფაილში ჩადგმული არ არის.

$ curl --cert client.pem --key client-key.pem https://mtls-api.example.com/secure

curl --key: კლიენტის სერტიფიკატის პრივატული გასაღები

რას აკეთებს: --key ფლაგი მიუთითებს პრივატული გასაღების ფაილს, რომელიც წყვილდება --cert-ით მოწოდებულ კლიენტის სერტიფიკატთან. გასაღები უნდა ემთხვეოდეს სერტიფიკატს. თუ გასაღები პაროლით დაცულია, curl მოითხოვს პასფრაზას (ან გამოიყენეთ --pass).
როდის გამოვიყენოთ: ყოველთვის გამოიყენეთ --cert-თან ერთად. თუ პრივატული გასაღები უკვე ჩადგმულია სერტიფიკატის ფაილში (გავრცელებულია PKCS#12 / .p12 ფაილებში), --key-ის გამოტოვება შეიძლება.

$ curl --cert client.pem --key client-key.pem --cacert server-ca.pem https://api.example.com/secure

curl --tlsv1.2: TLS 1.2 მინიმუმის იძულება

რას აკეთებს: --tlsv1.2 ფლაგი აიძულებს curl-ს გამოიყენოს TLS 1.2, როგორც SSL/TLS ხელჩამორთმევის მინიმალური მისაღები ვერსია. ძველი პროტოკოლები (TLS 1.0, 1.1, SSLv3) უარყოფილია.
როდის გამოვიყენოთ: გამოიყენეთ უსაფრთხოების მინიმალური სტანდარტის დასაწესებლად. TLS 1.2 საჭიროა PCI-DSS შესაბამისობისთვის და მხარდაჭერილია ყველა თანამედროვე სერვერის მიერ. curl-ის თანამედროვე ბილდების უმეტესობა უკვე ნაგულისხმევად TLS 1.2+-ს იყენებს, მაგრამ ეს ფლაგი მას ცხადად აქცევს.

$ curl --tlsv1.2 -v https://secure.example.com/api 2>&1 | grep 'SSL connection'

curl --tlsv1.3: TLS 1.3 მინიმუმის იძულება

რას აკეთებს: --tlsv1.3 ფლაგი აიძულებს curl-ს გამოიყენოს TLS 1.3 — ყველაზე სწრაფი და უსაფრთხო TLS ვერსია. TLS 1.3 აღმოფხვრის დამატებით ტურს ხელჩამორთმევაში (0-RTT მხარდაჭერა) და წაშლის ყველა მოძველებულ შიფრის კომპლექტს.
როდის გამოვიყენოთ: გამოიყენეთ, როდესაც იცით, რომ სერვერი მხარს უჭერს TLS 1.3-ს და გსურთ საუკეთესო წარმადობა და უსაფრთხოება. შენიშვნა: TLS 1.3 მოითხოვს OpenSSL 1.1.1+ ან თავსებად TLS ბიბლიოთეკას. ჯერ არ არის ყველა სერვერის მიერ მხარდაჭერილი.

$ curl --tlsv1.3 https://modern-api.example.com/data

SSL/TLS-ის დამატებითი პარამეტრები

ფლაგი	აღწერა
--ssl-reqd	კავშირისთვის SSL/TLS-ის მოთხოვნა (მიუწვდომლობისას წარუმატებლობა)
--ciphers	კავშირისთვის SSL შიფრების მითითება
--cert-type	კლიენტის სერტიფიკატის ტიპის მითითება (PEM, DER, ENG, P12)
--pinnedpubkey	სერვერის საჯარო გასაღების ფიქსაცია და ვერიფიკაცია (HPKP სტილი)

--ssl-reqd

კავშირისთვის SSL/TLS-ის მოთხოვნა (მიუწვდომლობისას წარუმატებლობა)

--ciphers

კავშირისთვის SSL შიფრების მითითება

--cert-type

კლიენტის სერტიფიკატის ტიპის მითითება (PEM, DER, ENG, P12)

--pinnedpubkey

სერვერის საჯარო გასაღების ფიქსაცია და ვერიფიკაცია (HPKP სტილი)

curl -x: HTTP/HTTPS პროქსის გამოყენება

რას აკეთებს: -x (ან --proxy) ფლაგი curl-ის ყველა ტრაფიკს მარშრუტიზებს მითითებული პროქსი სერვერით. ფორმატია [protocol://]host[:port]. მხარდაჭერილი პროქსი პროტოკოლები: HTTP, HTTPS, SOCKS4, SOCKS5.
როდის გამოვიყენოთ: გამოიყენეთ კორპორაციული პროქსი სერვერებისთვის, Fiddler, Charles ან mitmproxy-ით დიაგნოსტიკისთვის, გეოგრაფიული შეზღუდვების ტესტირებისთვის ან როდესაც პირდაპირი ინტერნეტი მიუწვდომელია. ასევე შეგიძლიათ დააყენოთ http_proxy / https_proxy გარემოს ცვლადები.

$ curl -x http://proxy.example.com:8080 https://api.example.com/data

curl --socks5: SOCKS5 პროქსის გამოყენება

რას აკეთებს: --socks5 ფლაგი curl-ს ეუბნება გამოიყენოს SOCKS5 პროქსი TCP კავშირისთვის. HTTP პროქსებისგან განსხვავებით, SOCKS5 მუშაობს TCP დონეზე და შეუძლია ნებისმიერი პროტოკოლის დამუშავება — არა მხოლოდ HTTP. DNS რეზოლუცია ნაგულისხმევად ლოკალურად ხდება; გამოიყენეთ --socks5-hostname პროქსით DNS-ის მოსაგვარებლად.
როდის გამოვიყენოთ: გამოიყენეთ SSH ტუნელებისთვის (ssh -D), Tor ქსელზე წვდომისთვის ან როდესაც პროქსიმ უნდა დაამუშაოს არა-HTTP პროტოკოლები. SOCKS5 მხარს უჭერს UDP-ს და სურვილისამებრ DNS-ს — HTTP პროქსებზე უფრო მოქნილია.

$ curl --socks5 localhost:1080 https://api.example.com/data

curl --proxy-user: პროქსის ავთენტიფიკაცია

რას აკეთებს: --proxy-user (ან -U) ფლაგი პროქსი სერვერისთვის ავთენტიფიკაციის სერთიფიკატებს აგზავნის. ფორმატია user:password. ეს ცალკეა სერვერის ავთენტიფიკაციისგან (-u).
როდის გამოვიყენოთ: საჭიროა, როდესაც პროქსი სერვერი ავთენტიფიკაციას მოითხოვს — გავრცელებულია კორპორაციულ და საწარმოო ქსელურ გარემოებში. სერთიფიკატები იგზავნება პროქსისკენ, არა სამიზნე სერვერისკენ.

$ curl -x http://proxy.corp.com:3128 -U user:pass https://external-api.com/data

curl --noproxy: კონკრეტული ჰოსტებისთვის პროქსის გვერდის ავლა

რას აკეთებს: --noproxy ფლაგი მიუთითებს მძიმით გამოყოფილ ჰოსტების, დომენების ან IP მისამართების სიას, რომლებმაც პროქსი უნდა გვერდი აუარონ და პირდაპირ დაუკავშირდნენ. მხარს უჭერს ჯოკერებს: *.example.com ემთხვევა ყველა ქვედომენს.
როდის გამოვიყენოთ: გამოიყენეთ localhost-ის, შიდა სერვისების ან კონკრეტული დომენების პროქსიდან გამოსარიცხად. ეს მნიშვნელოვანია, როდესაც პროქსი გლობალურად არის დაყენებული გარემოს ცვლადებით, მაგრამ ზოგიერთ ჰოსტს (როგორიცაა ლოკალური სერვისები) პირდაპირი წვდომა ჭირდება. ყველა ჰოსტისთვის პროქსის გვერდის ასავლელად გამოიყენეთ *.

$ curl -x http://proxy:8080 --noproxy "localhost,127.0.0.1,*.internal.com" https://localhost:3000/api

პროქსის დამატებითი პარამეტრები

ფლაგი	აღწერა
--socks5-hostname	SOCKS5 პროქსი DNS რეზოლუციით პროქსის მეშვეობით
--proxy-cacert	CA სერტიფიკატი თავად HTTPS პროქსის ვერიფიკაციისთვის

--socks5-hostname

SOCKS5 პროქსი DNS რეზოლუციით პროქსის მეშვეობით

--proxy-cacert

CA სერტიფიკატი თავად HTTPS პროქსის ვერიფიკაციისთვის

curl --resolve: მორგებული DNS რეზოლუცია

რას აკეთებს: --resolve ფლაგი უზრუნველყოფს მორგებულ IP მისამართს კონკრეტული host:port წყვილისთვის, DNS მოძიების სრული გვერდის ავლით. ფორმატია host:port:address. რამდენიმე --resolve ჩანაწერის მითითებაა შესაძლებელი.
როდის გამოვიყენოთ: აუცილებელია DNS გავრცელებამდე ტესტირებისთვის, დატვირთვის ბალანსერის უკან კონკრეტული ბექენდის დადასტურებისთვის ან ლოკალური განვითარებისთვის, სადაც SSL სერტიფიკატის ვალიდაციისთვის რეალური ჰოსტის სახელი გჭირდებათ. /etc/hosts-ის რედაქტირებისგან განსხვავებით, ეს არის მოთხოვნის დონეზე და პორტ-სპეციფიკური.

$ curl --resolve api.example.com:443:127.0.0.1 https://api.example.com/health

curl --connect-to: კავშირის სხვა ჰოსტზე გადამისამართება

რას აკეთებს: --connect-to ფლაგი TCP კავშირს გადამისამართებს სხვა host:port წყვილზე, HTTP მოთხოვნისთვის (მათ შორის Host ჰედერი და SNI) ორიგინალური URL-ის შენარჩუნებით. ფორმატი: HOST1:PORT1:HOST2:PORT2.
როდის გამოვიყენოთ: გამოიყენეთ დატვირთვის ბალანსერის უკან კონკრეტული ბექენდ სერვერის სატესტოდ DNS-ის ან /etc/hosts-ის შეცვლის გარეშე. --resolve-ისგან განსხვავებით, ეს host:port-ს host:port-ზე (არა IP-ზე) მიბმავს, რაც სასარგებლოა, როდესაც სამიზნესაც აქვს ჰოსტის სახელი.

$ curl --connect-to api.example.com:443:backend1.internal:8443 https://api.example.com/health

ქსელის დამატებითი პარამეტრები

ფლაგი	აღწერა
--local-port	კავშირის ლოკალური პორტის ნომრის ან დიაპაზონის დაყენება
--interface	კავშირის კონკრეტულ ქსელის ინტერფეისზე მიბმა
--dns-servers	სისტემის ნაგულისხმევი DNS სერვერების ნაცვლად მორგებულის გამოყენება (c-ares)

--local-port

კავშირის ლოკალური პორტის ნომრის ან დიაპაზონის დაყენება

--interface

კავშირის კონკრეტულ ქსელის ინტერფეისზე მიბმა

--dns-servers

სისტემის ნაგულისხმევი DNS სერვერების ნაცვლად მორგებულის გამოყენება (c-ares)

რეალური SSL & პროქსი სცენარები

ეს მაგალითები აერთიანებს რამდენიმე ფლაგს განვითარების, CI/CD და პროდაქშენ გარემოებში გავრცელებული უსაფრთხოებისა და ქსელის ამოცანების შესასრულებლად.

HTTPS-ის ტესტირება Localhost-ზე

თვით-ხელმოწერილი სერტიფიკატით ლოკალური განვითარებისას დააკავშირეთ --resolve --cacert-თან (ან -k სწრაფი ტესტირებისთვის). ეს საშუალებას გაძლევთ გამოიყენოთ რეალური ჰოსტის სახელი სწორი SSL/SNI-სთვის hosts ფაილის შეცვლის გარეშე.

$ curl --resolve myapp.local:443:127.0.0.1 --cacert local-ca.pem https://myapp.local/api/status

ორმხრივი TLS (კლიენტის სერტიფიკატით ავთენტიფიკაცია)

ზოგიერთი API მოითხოვს, რომ სერვერმაც და კლიენტმაც წარადგინონ სერტიფიკატები. მიაწოდეთ --cert, --key და --cacert სრულად ვერიფიცირებული ორმხრივი TLS კავშირის დასამყარებლად.

$ curl --cert client.pem --key client-key.pem --cacert server-ca.pem https://mtls-api.example.com/data

კორპორაციული პროქსი ავთენტიფიკაციით

კორპორაციულ ქსელებში სავალდებულო პროქსი სერვერებით, დააკავშირეთ -x -U-სთან პროქსის სერთიფიკატებისთვის. შიდა სერვისების პროქსიდან გამოსარიცხად დაამატეთ --noproxy.

$ curl -x http://proxy.corp.com:3128 -U user:pass --noproxy "*.internal.corp" https://external-api.com/data

Docker კონტეინერი შიდა CA-ით

როდესაც Docker-ში სერვისები შიდა CA-ს სერტიფიკატებს იყენებენ, CA სერტიფიკატი დაამონტაჟეთ კონტეინერში და მიუთითეთ --cacert-ით. ეს უფრო უსაფრთხოა ვიდრე -k, რადგან სერტიფიკატის ჯაჭვი მაინც ვერიფიცირდება.

$ curl --cacert /etc/ssl/certs/internal-ca.crt https://service.docker.internal:8443/health

SOCKS5 პროქსი SSH ტუნელით

შექმენით SOCKS5 პროქსი ssh -D-ით და curl-ის ტრაფიკი გაატარეთ მასში --socks5-ით. სასარგებლოა შიდა სერვისებზე ბასტიონ ჰოსტის მეშვეობით წვდომისთვის.

$ curl --socks5 localhost:1080 https://internal-api.example.com/status

ხშირად დასმული კითხვები curl SSL & პროქსის შესახებ

როგორ გამოვტოვო SSL სერტიფიკატის ვერიფიკაცია curl-ში?

გამოიყენეთ curl -k URL ან curl --insecure URL. ეს გამორთავს სერტიფიკატის ყველა შემოწმებას — ვადის გასვლა, ჰოსტის სახელის შეუთავსებლობა, არასანდო CA. გამოიყენეთ მხოლოდ ლოკალური განვითარებისთვის. პროდაქშენისთვის გამოიყენეთ --cacert ფაქტობრივი CA სერტიფიკატით.

როგორ ვაიძულო curl-ს ენდოს თვით-ხელმოწერილ სერტიფიკატს?

გამოიყენეთ curl --cacert /path/to/ca.pem URL თქვენი თვით-ხელმოწერილი სერტიფიკატის CA სერტიფიკატის მისათითებლად. ეს უფრო უსაფრთხოა ვიდრე -k, რადგან სერტიფიკატის ჯაჭვი მაინც ვერიფიცირდება — მხოლოდ თქვენს კონკრეტულ CA-ს ენდობა.

როგორ შევამოწმო curl რომელ TLS ვერსიას იყენებს?

გაუშვით curl -v URL და მოძებნეთ ხაზი * SSL connection using TLSv1.x / CipherSuite დეტალურ გამოსავალში. კონკრეტული ვერსიის იძულებისთვის გამოიყენეთ --tlsv1.2 ან --tlsv1.3.

რა არის ორმხრივი TLS (mTLS) და როგორ გამოვიყენო curl-თან?

ორმხრივი TLS მოითხოვს, რომ სერვერმაც და კლიენტმაც ორივემ წარადგინონ სერტიფიკატები. გამოიყენეთ: curl --cert client.pem --key client-key.pem --cacert server-ca.pem URL. --cert/--key წყვილი კლიენტს ავთენტიფიცირებს; --cacert სერვერს ვერიფიცირებს.

როგორ გამოვიყენო curl HTTP პროქსით?

გამოიყენეთ curl -x http://proxy:port URL. HTTPS პროქსისთვის: curl -x https://proxy:port URL. ალტერნატიულად, დააყენეთ http_proxy და https_proxy გარემოს ცვლადები — curl ავტომატურად წაიკითხავს მათ.

როგორ გამოვიყენო curl SOCKS5 პროქსით?

ლოკალური DNS რეზოლუციისთვის გამოიყენეთ curl --socks5 host:port URL, ან პროქსით DNS-ის მოსაგვარებლად curl --socks5-hostname host:port URL (მნიშვნელოვანია კონფიდენციალურობისთვის/Tor-ისთვის). SSH ტუნელის მაგალითი: ssh -D 1080 user@bastion, შემდეგ curl --socks5 localhost:1080 URL.

როგორ გავიარო ავთენტიფიკაცია პროქსი სერვერთან curl-ში?

გამოიყენეთ curl -x http://proxy:port -U user:password URL. -U (ან --proxy-user) ფლაგი სერთიფიკატებს პროქსისკენ აგზავნის. ეს განსხვავდება -u-სგან, რომელიც სამიზნე სერვერთან ავთენტიფიკაციას ახდენს.

როგორ გამოვრიცხო კონკრეტული ჰოსტები პროქსიდან curl-ში?

გამოიყენეთ --noproxy "localhost,127.0.0.1,*.internal.com" ან დააყენეთ NO_PROXY გარემოს ცვლადი. მხარს უჭერს ჯოკერებს (*.example.com). ერთი მოთხოვნისთვის პროქსის სრულად გვერდის ასავლელად გამოიყენეთ --noproxy "*".

როგორ ვატესტო HTTPS localhost-ზე curl-ით?

სწრაფი ტესტირებისთვის: curl -k https://localhost:8443/. სწორი ვალიდაციისთვის: curl --resolve myapp.local:443:127.0.0.1 --cacert local-ca.pem https://myapp.local/. --resolve მიდგომა საშუალებას აძლევს სერტიფიკატის ჰოსტის სახელს სწორად დაემთხვეს.

როგორ გადავფარო DNS რეზოლუცია კონკრეტული ჰოსტისთვის curl-ში?

გამოიყენეთ curl --resolve host:port:IP URL. მაგალითი: curl --resolve api.example.com:443:192.168.1.100 https://api.example.com/. ეს DNS-ს გვერდს უვლის მხოლოდ ამ host:port წყვილისთვის — /etc/hosts-ის რედაქტირება საჭირო არ არის.

როგორ გამოვასწორო 'SSL certificate problem: certificate has expired' curl-ში?

სერვერის სერტიფიკატს ვადა გაუვიდა. გადაწყვეტილებები: (1) განაახლეთ სერტიფიკატი სერვერზე, (2) განაახლეთ CA ფაილი: curl --cacert /path/to/updated-ca.pem URL, (3) მხოლოდ ტესტირებისთვის: curl -k URL. ვადის შემოწმება: curl -v URL 2>&1 | grep expire.

უსაფრთხოა curl --insecure (-k)-ის გამოყენება პროდაქშენში?

არა. -k ფლაგი გამორთავს სერტიფიკატის ყველა ვალიდაციას — ვადის გასვლა, ჰოსტის სახელი და ნდობის ჯაჭვი. ეს თქვენს კავშირს შუა-კაცის შეტევისთვის დაუცველს ხდის. პროდაქშენსა და CI/CD პაიპლაინებში ყოველთვის გამოიყენეთ --cacert კონკრეტული CA სერტიფიკატით.