Messages posted by: facialz

Tui trước đây dùng desktop Fedora Core, nay thì desktop Ubuntu. Toàn là bị bắt dùng chứ không tự nguyện -- tui làm IT doanh nghiệp, user dùng gì thì mình cũng dùng cái nấy cho quen. Về server thì trước đây CentOS, giờ Ubuntu, cũng vì lý do tui nghĩ rằng cái nào quen thuộc nhất thì dùng. Tui thấy trên Ubuntu desktop dễ hơn FC và Ubuntu server thì dễ hơn CentOS => công việc thuận lợi hơn.

Mà nếu đã làm server với console tại sao lại là Linux mà không phải là FreeBSD nhỉ?

FreeBSD:

-- rất nhỏ gọn, rất nhẹ, yêu cầu hardware rất ít.

-- rất đơn giản, dễ dùng. Đặc biệt, cài đặt chương trình, upgrade, update dễ dàng và đáng tin cậy.

Nói chung tui đụng vào *nix là công việc đòi hỏi và luôn phải chịu sức ép về tiến độ công việc nên thích sự đơn giản, dễ sử dụng và về mặt này tui nghĩ rằng FreeBSD là số 1. Nếu không có lý do gì ngăn cản thì tui luôn lựa chọn FreeBSD để làm server. Linux và OpenSolaris tất nhiên cũng là cần thiết nhưng tui chỉ dùng chúng khi không có lựa chọn khác mà thôi.

Michael_Scotfield wrote:

178.125.31.64 . 178.125.35.128 , 178.125.41.192 lúc đầu em cứ nghĩ nó là 1 ip address
vậy làm cách nào phân biệt dc 1 ip address và 1 network address ,dựa vào subnet mask của nó?.

Ví dụ, với địa chỉ 172.125.41.192:

172.125.41.192 = 10101100 01111101 00101001 11000000

và với subnet mask /28:

255.255.255.240 = 11111111 11111111 11111111 11110000

Lấy mặt nạ (mask) che đi phần đầu của địa chỉ, ta được:

172.125.41.192 = xxxxxxxx xxxxxxxx xxxxxxxx xxxx0000

Phần lộ ra là 0000 = 0, chứng tỏ địa chỉ là một địa chỉ mạng.

Nhưng vẫn địa chỉ ấy, với mặt na /24:

255.255.255.0 = 11111111 11111111 11111111 00000000

sau khi lấy mặt na che đi phần đầu ta được

172.125.41.192 = xxxxxxxx xxxxxxxx xxxxxxxx 11000000

Phần lộ ra là 11000000 != 0, chứng tỏ địa chỉ ấy là một địa chỉ host.

Michael_Scotfield wrote:

Với cách chia ở trên thì với facialz ta có 3 subnet mask còn với win0611 thì chỉ có 1 subnet vậy thì cách là là tôí ưu và hiệu quả nhất

Tui xác định subnet mask cho từng mạng con (được /26) còn bác kia tính subnet mask cho cả mạng lớn (và được /21). Khoan nói đúng sai thế nào, nhưng hai phép tính khác nhau nhằm hai mục đích khác nhau, không thể so sánh với nhau được.

win0611 wrote:

cảm ơn bác facialz, nhưng em đọc đi đọc lại câu trả lời của bác vẫn chưa hiểu đc hết ý bác muốn nói. Em không biết ở đây tính mặt nạ mạng cho mỗi mạng như thế nào mới đúng ?

Chào bác. Chắc là tui viết vắn tắt quá. (Sorry.) Đây tui cố gắng viết lại rõ ràng hơn:

Mạng nhỏ nhất chứa được 60 máy là mạng có mặt nạ /26. Thật vậy:

11111111 11111111 11111111 11111111 (= 255.255.255.254 = /32, tức là mạng 1 địa chỉ)
11111111 11111111 11111111 11111110 (= 255.255.255.254 = /31, tức là mạng 2 địa chỉ)
11111111 11111111 11111111 11111100 (= 255.255.255.252 = /30, tức là mạng 4 địa chỉ)
11111111 11111111 11111111 11111000 (= 255.255.255.248 = /29, tức là mạng 8 địa chỉ)
11111111 11111111 11111111 11110000 (= 255.255.255.240 = /28, tức là mạng 16 địa chỉ)
11111111 11111111 11111111 11100000 (= 255.255.255.224 = /27, tức là mạng 32 địa chỉ)
11111111 11111111 11111111 11000000 (= 255.255.255.192 = /26, tức là mạng 64 địa chỉ)
11111111 11111111 11111111 10000000 (= 255.255.255.128 = /25, tức là mạng 128 địa chỉ)
11111111 11111111 11111111 00000000 (= 255.255.255.0 = /24, 256 địa chỉ)
...

Xét mạng thứ nhất 178.125.27.0, viết lại địa chỉ này thành dạng nhị phân:

(1) 178.125.27.0 = xxxxxxxx xxxxxxxx xxxxxxx1 00000000

(Bác có có thể tính hết cả 32 bit, nhưng thật ra không cần thiết. Từ thấp lên cao:
-- Số 0 thì chắc chắn là 0000 0000 rồi.
-- Số 27 là số lẻ nên dạng nhị phận của nó tận cùng bằng 1.
-- Còn tất cả phần đứng trước bit 1 thì không cần phải quan tâm nữa.)

Một địa chỉ mạng có dạng xxx....x000...0, trong đó xxx...x bất kỳ. Mặt nạ mạng tương ứng có dạng 111....1000...0 trong đó phần 000...0 trùng với phần 000...0 của địa chỉ mạng. Bởi vậy đối với địa chỉ mạng (1) thì mặt nạ mạng chỉ có thể là /32, /31,..., /24 chứ không thể là /23, /22,... được. Và như vậy là đã quá đủ rồi: địa chỉ (1) là 1 địa chỉ thích hợp cho 1 mạng tối đa 256 địa chỉ, cho nên thừa sức chứa 64 địa chỉ.

Tương tự như vậy, bác sẽ thấy địa chỉ mạng thứ hai và thứ tư thích hợp cho mạng tối đa 64 địa chỉ, nghĩa là vừa đủ đạt yêu cầu, còn địa chỉ mạng thứ ba thích hợp cho mạng tối đa 128 địa chỉ, nghĩa là vượt yêu cầu.

win0611 wrote:

Sắp thi mạng máy tính mà hôm nay ôn lại lại không nhớ gì nữa rồi, các bác giúp em giải bài này chi tiết với ạ :
" Với địa chỉ IP 178.125.0.0 kết nối vào mạng Internet được cấp cho mạng của mình,một công ty dự định thiết kế 4 mạng con có tối đa 60 máy tính/mạng.Giả thiết các mạng con có địa chỉ 178.125.27.0 , 178.125.31.64 . 178.125.35.128 , 178.125.41.192.
a,Xác định mặt nạ, dải địa chỉ IP và địa chỉ broadcast của mỗi mạng con
b,Hãy phân tích và đưa ra cấu hình thiết kế nối mạng Internet cho công ty với các mạng con đã cho,biết rằng công ty sử dụng hai router với 2 giao diện mạng và một router với 3 giao diện mạng.Nếu mỗi mạng con có 2 máy tính kết nói vào, hãy định địa chỉ IP phù hợp cho mỗi máy tính đó."
Em cảm ơn !

Câu a, Thử viết các địa chỉ ra dạng nhị phân, để ý 9 bit thấp:

(1) 178.125.27.0 = ... 1 00000000
(2) 178.125.31.64 = ... 1 01000000
(3) 178.125.35.128 = ... 1 10000000
(4) 178.125.41.192 = ... 1 11000000

Vì một địa chỉ mạng đều phải có dạng xxx...x000...0, nghĩa là một chuỗi bit gì đó theo sau là chuỗi những bit 0, và một mặt nạ sẽ cho biết số bit 'x' của phần "gì đó" kia, nên mặt nạ lớn nhất cho phép đối với mạng (1) là /24, đối với mạng (2) là /26, đối với mạng (3) là /25 và đối với mạng (4) là /26. Mặt nạ này là hợp lý đối với mạng (2) và (4) còn đối với mạng (1) và (3) thì lớn quá, hợp lý cũng chỉ là /26 thôi. Với mặt nạ /26, mạng có 64 địa chỉ, trừ đầu đuôi còn 62, đủ để chứa số máy tính theo yêu cầu của đề bài.

nguyendinhtuanit wrote:

Em đã phân vùng cache như vậy thì có hợp lý như anh nói chưa. Squid của em cấu hình RAID0.

#######################################################################
cache_mem 1024 MB
maximum_object_size 3 MB
maximum_object_size_in_memory 512 KB
cache_dir ufs /opt/squid/cache/d1 20000 16 256
cache_dir ufs /opt/squid/cache/d2 20000 16 256
#######################################################################

Anh có thể nói thêm vài option để quản lý tối ưu phần cứng cho việc sử dụng squid!

Thân.

Chào bác. Tui cũng mới dùng squid một thời gian ngắn (>1 năm nay) tui cảm thấy rằng 2 cache_dir 20000 12 256 như vậy là hợp lý với d1 d2 là 2 ổ cứng 36 - 72 GB. Nói chung L1 L2 chỉ cần làm sao đảm bảo trong mỗi thư mục cache L2 không chứa quá nhiều file. Chừng 200 - 300 file thì hợp lý.

Còn maximum_object_size thì tui nghĩ nên cho lớn hơn nữa để nó cache được file lớn, và maximum_object_size_in_memory thì nên cho nhỏ hơn để bắt nó cache file lớn ra đĩa không cho để trong RAM.

Bác để cache_mem 1024 MB hợp lý khi bác có 8GB RAM còn nếu ít hơn thì nên xem xét lại. Squid dùng nhiều RAM để cache cho ổ cứng (cache của disk cache) nhưng lượng RAM này được cấp tự động và tính vào kernel chứ không tính vào cache_mem; còn cache_mem là dung lượng của mem cache tui nghĩ chỉ nên để chừng 10-20 % dung lượng RAM thôi.

Muốn biết đã tối ưu chưa thì phải từ từ chỉnh và theo dõi hiệu quả. Tui nghĩ nếu có chừng 100 users thì chỉnh chừng đó thông số là đủ nếu có chừng 1000 users thì có thể xem thêm vài thông số khác như replacement_policy, cache_swap, memory_pools, buffered_logs, client_db, half_closed_client,...

Ngoài ra, squid dùng nhiều file và mở nhiều socket nên bác đừng quên chỉnh các thông số kernel để thích ứng. Tui có viết 1 bài ngắn về thiết lập squid cho FreeBSD, gửi trên HVA vài tháng trước, bác tự tìm nhé.

Thân!

Làm cache thì ổ cứng là quan trọng nhất, vì cache ghi đĩa rất nhiều. Nếu có thể, bác nên dùng vài ổ cứng, hơn là 1 ổ, không những để cho nhanh hơn mà còn để kéo dài tuổi thọ ổ cứng. Không cần làm RAID0. Dùng RAID lỡ chết 1 ổ thì chết cả. Để phân bổ tải đều lên các ổ cứng chỉ cần khai báo vài cache_dir, mỗi cái đặt trên 1 ổ cứng rồi squid sẽ tự biết cách cân bằng tải, lỡ chết 1 ổ ngoài ổ hệ thống thì không sao. smilie

Nếu có >= 1GB RAM, bác nên dùng hệ thống file ZFS để tăng độ sẵn sàng. Khi mất điện ZFS luôn khởi động lại được vì không bao giờ bị hỏng, và khởi động rất nhanh vì không bao giờ cần check disk.

THIẾT LẬP DNS SERVER
với DJBDNS trên nền FreeBSD

1 Vì sao, khi nào dùng DJBDNS

Gói djbdns, gói phần mềm DNS server nổi tiếng của Daniel J. Bernstein, có nhiều ưu điểm:

Nhanh: trong một benchmark [6], djbdns mất bình quân 327 ms để giải xong một tên miền, trong khi BIND mất 5179 ms.
Gọn: djbdns chỉ có 7000 lệnh, BIND có 100000 [6, 8].
Yêu cầu thấp: djbdns chỉ chiếm dụng khoảng 2 MB khi mới khởi động và khoảng 10 MB sau nửa triệu truy vấn, trong khi ở BIND con số tương ứng lần lượt là 30 MB và 57 MB [6].
Bảo mật cao: trong suốt lịch sử 19 năm của mình (1991 – 2009) djbdns chỉ có 2 lỗi đã được phát hiện. Còn BIND chỉ trong 19 năm (1983 – 2002) đã có 672 lỗi [9].
Thông dụng: theo một thống kê tháng 11/2008, Internet có 78,1 triệu tên miền .com, trong đó ít nhất 4,6 triệu được đặt trên các máy chủ sử dụng djbdns. Với số lượng đó, djbdns đứng thứ tư về độ thông dụng, chỉ sau BIND (20,6 triệu), MyDNS (17,8 triệu), và PowerDNS (6,6 triệu) [7].

Với các ưu điểm đó, djbdns có thể dùng được trong mọi trường hợp, và đặc biệt thích hợp trong trường hợp phần cứng thấp và tải lớn.

2 Cấu hình tổng thể

Gói phần mềm djbdns có vài chương trình, trong đó chúng ta sẽ cài đặt hai chương trình chính: tinydns và dnscache. Tinydns là chương trình chuyên dùng để làm DNS server có thẩm quyền (authoritative), nghĩa là có nhiệm vụ công bố các địa chỉ Internet của miền nào đó mà chúng ta sở hữu, ví dụ, mycompany.com.Dnscache là chương trình chuyên dùng để làm DNS cache, nghĩa là có nhiệm vụ tìm hộ địa chỉ Internet của mọi miền, kể cả mycompany.com.

Hai chương trình này sẽ được cài đặt lên cùng một máy tính có 1 NIC, mà chúng ta sẽ gọi là máy chủ DNS, và sẽ được cấu hình cùng lắng nghe trên cổng 53 nhưng phải là trên các interface khác nhau (nói chính xác hơn, trên các địa chỉ IP khác nhau). Chương trình dnscache sẽ được cấu hình lắng nghe trên interface chính (ví dụ, 192.168.12.10) và chỉ phục vụ các client cục bộ (ví dụ, 192.168.0.0/16 và 10.0.0.0/24). Chương trình tinydns sẽ được cấu hình lắng nghe trên loopback interface (ví dụ, 127.0.0.1).

Mọi DNS client cục bộ, kể cả resolver (DNS client của chính bản thân máy chủ DNS), sẽ được cấu hình để truy vấn địa chỉ Internet ở interface chính. Tại đó, dnscache sẽ tìm kiếm câu trả lời trong cache và nếu không tìm thấy, sẽ lần lượt truy vấn theo dây chuyền bắt đầu từ các DNS server có thẩm quyền giải tên miền gốc (root) lần đến tận DNS server có thẩm quyền giải tên miền cần hỏi để có câu trả lời cuối cùng.

Có một ngoại lệ mà chúng ta sẽ thực hiện là nếu tên miền cần tìm thuộc mycompany.com hoặc nếu địa chỉ IP cần giải (ngược) là địa chỉ IP mạng cục bộ (ví dụ, 192.168.18.10), dnscache sẽ không lần theo dây chuyền các DNS server có thẩm quyền mà sẽ lập tức chuyển truy vấn sang loopback interface (127.0.0.1) cho tinydns giải đáp ngay. Ngoại lệ như thế là không cần thiết nếu như tinydns của chúng ta đã được uỷ quyền (delegated) của nhà đăng ký DNS cho phép quản lý miền mycompany.com. Nhưng thực tế do hợp đồng với nhà đăng ký, chúng ta không được uỷ quyền quản lý miền mycompany.com. Tinydns của chúng ta không tồn tại trong cơ sở dữ liệu của nhà đăng ký và do đó, chính thức mà nói thì nó không phải là DNS server có thẩm quyền giải tên mycompany.com cho bất kỳ DNS client nào. Muốn tinydns có thể phục vụ được thì phải làm ra ngoại lệ. Cũng vì lý do đó, tinydns chỉ phục vụ riêng cho những client trong mạng cục bộ chứ không thể phục vụ công chúng được. Ngoại lệ trên đây là duy nhất. Ta sẽ không cấu hình dnscache dùng bất cứ DNS forwarder nào khác, dù là server của ISP hay là server có uy tín như OpenDNS,...

Do tính năng đã được lập trình sẵn, dnscache sẽ lưu lại mọi câu trả lời trong cache để phục vụ cho những truy vấn về sau và để bảo mật, cache này chỉ nằm trong RAM và sẽ bị xoá khi khởi động. Tuy vậy, trong trường hợp (hết sức đặc biệt) nào đó ta vẫn có thể cho dnscache lưu cache ra đĩa cứng bằng miếng vá tính năng PERSISTENT CACHE.

Bài này ghi chép quy trình cài đặt và cấu hình djbdns v.1.05 trên hệ điều hành FreeBSD v.8. Các lý giải sâu về cấu hình tổng thể, các giải thích chi tiết từng bước của quá trình cài đặt, hay các phương pháp kiểm tra và giải quyết trục trặc có thể tìm thấy ở trong những nguồn trực tuyến, rất đầy đủ và phong phú, kể cả bằng tiếng Việt (xem danh mục tài liệu tham khảo).

3 Cài đặt và cấu hình chi tiết

3.1. Cài đặt, tạo môi trường

1. Cập nhật port collection.
Code:

portsnap fetch install

2. Biên dịch và cài đặt gói hỗ trợ ucspi-tcp.
Code:

cd /usr/ports/sysutils/ucspi-tcp/; make install clean

3. Biên dịch và cài đặt gói hỗ trợ daemontools.
Code:

cd /usr/ports/sysutils/daemontools/; make install clean

4. Biên dịch và cài đặt djbdns.
Code:

cd /usr/ports/dns/djbdns
make install clean

Chú ý, khi make config, có thể chọn một số miếng vá bổ sung tính năng cần thiết. Chẳng hạn như PERSISTENT NMAP, SRV RECORD (hỗ trợ SRV record), PERSISTENT CACHE (hỗ trợ DNS cache trên ổ cứng), IPV6 (hỗ trợ giao thức IP v.6), v.v... mà chúng ta có thể chọn thêm, nếu cần. Bài này hướng dẫn này thực hiện với cấu hình mặc định, không có miếng vá thêm nào.

5. Cấu hình svscan – bộ quản lý service trong gói phụ trợ daemontools.
Code:

mkdir /var/service
fetch -o /usr/local/etc/rc.d/services.sh \
 http://www.tnpi.biz/internet/mail/toaster/start/services.txt
chmod 755 /usr/local/etc/rc.d/services.sh
ln -s /usr/local/etc/rc.d/services.sh /usr/local/sbin/services
rehash

6. Khởi động các dịch vụ. Chú ý hiện thời ta chưa cài đặt dịch vụ nào. Lệnh “khởi động” này thuần túy chỉ để kiểm tra rằng svscan đã thực sự hoạt động được. Sau khi kiểm tra ta lại tắt các dịch vụ. Nếu gặp trục trặc với svscan thì giải quyết trục trặc trước khi đi tiếp.
Code:

services start
ps -aux | grep sv
services stop

7. Các service sẽ sử dụng ba account khác nhau, mà ta sẽ đặt tên là dnscache, tinydns, dnslog. (Không nhất thiết phải đặt tên account như thế này mà có thể chọn những tên khác bất kỳ.) Mỗi account thuộc nhóm riêng của nó, với tên nhóm cùng tên với account. Hãy tạo ba nhóm này trước, bằng cách viết thêm trong file /etc/group ba dòng
Code:

dnscache:*:54:
tinydns:*:55:
dnslog:*:56:

rồi tạo ba account tương ứng bằng lệnh adduser.

Trong đó, 54, 55, 56 là các số hiệu GID và UID mà chúng ta chọn đặt cho các account và nhóm mới. Nếu các số này đã bị chiếm dụng thì chúng ta có thể dùng số khác bất kỳ.

9. Tạo thư mục làm việc cho djbdns.
Code:

mkdir /var/dns

3.2. Cấu hình dnscache

1. Cấu hình dnscache để nó dùng hai trong số ba account vừa tạo (dnscache và dnslog), làm việc trong thư mục con /var/dns/dnscache (mà nó sẽ tự tạo ra), và lắng nghe trên interface chính (192.168.12.10).
Code:

dnscache-conf dnscache dnslog /var/dns/dnscache 192.168.12.10

Chú ý. dnscache-conf là lệnh ngoại trú nằm trong /usr/local/bin. Nếu thư mục đó không nằm trong PATH thì hãy gõ lệnh trên đầy đủ đường dẫn.

2. Đưa dnscache vào danh mục service quản lý bởi svscan bằng cách tạo trong /var/service một soft link đến /var/dns/dnscache.
Code:

ln -s /var/dns/dnscache /var/service

3. Trong thư mục /var/dns/dnscache/root/ip đã có một file rỗng tên là 127.0.0.1. Ý nghĩa của file này là dnscache đã (mặc định) được phép phục vụ localhost (127.0.0.1). Để cho phép nó phục vụ các client thuộc mạng cục bộ, ví dụ, 192.168.0.0/16 và 10.0.0.0/24, ta cũng tạo ra các file rỗng tương tự như thế.
Code:

touch /var/dns/dnscache/root/ip/192.168
touch /var/dns/dnscache/root/ip/10.0.0

4. Cấu hình resolver (tức DNS client trên chính bản thân máy chủ DNS) để nó sử dụng dịch vụ của dnscache bằng cách viết lại file /etc/resolv.conf với nội dung mới như sau.
Code:

nameserver 192.168.12.10

5. Khởi động dịch vụ bằng lệnh services start hoặc services restart. Kiểm tra khẳng định rằng dnscache đã hoạt động đúng, nghĩa là đã giải được các tên Internet ngoại trừ các tên mycompany.com và giải ngược được các địa chỉ IP Internet ngoại trừ các địa chỉ IP cục bộ bằng các lệnh như ping, host, dig,... hay các client chuyên dùng khác trong bộ djbdns như dnsip, dnsname,... chạy trên máy chủ DNS và trên mọi máy khác trong mạng cục bộ.

3.3. Cấu hình tinydns

1. Cấu hình tinydns để nó dùng hai trong ba account dịch vụ vừa tạo (tinydns và dnslog), làm việc trong thư mục con /var/dns/tinydns (mà nó sẽ tự tạo ra), và lắng nghe trên loopback interface (127.0.0.1).
Code:

tinydns-conf tinydns dnslog /var/dns/tinydns 127.0.0.1

Chú ý. Tương tự như ở đoạn trên, tinydns-conf là lệnh ngoại trú trong /usr/local/bin. Nếu thư mục ấy không nằm trong PATH thì hãy gõ lệnh trên có đường dẫn.

2. Đưa tinydns vào danh mục dịch vụ quản lý bởi svscan bằng cách tạo trong /var/service một softlink đến /var/dns/tinydns.
Code:

ln -s /var/dns/tinydns /var/service

3. Soạn thảo file dữ liệu chứa các địa chỉ DNS, có tên là /var/dns/tinydns/root/data. Ví dụ một file dữ liệu sẽ được trình bày trong đoạn tiếp theo.
Code:

cd /var/dns/tinydns/root
le data

Chú ý. FreeBSD v.8 được cài đặt mặc định với các trình biên tập vi và ee. Còn le là một trong số hàng trăm trình biên tập khác mà muốn dùng thì phải cài riêng.

4. Dịch file dữ liệu dạng văn bản nói trên thành một file cơ sở dữ liệu dạng nhị phân có tên là data.cdb cất trong cùng thư mục.
Code:

make

5. Khởi động dịch vụ bằng lệnh services restart. Kiểm tra khẳng định rằng tinydns đã hoạt động đúng, nghĩa là đã giải được các tên của mycompany.com và giải ngược được các địa chỉ IP tương ứng của miền này bằng một client chạy ngay trên máy chủ DNS.

3.4. Một file dữ liệu cho tinydns

Đây là file /var/dns/tinydns/root/data soạn thảo ở bước 3 trong thủ tục 3.3 nói trên. Thay vì viết ra các luật cú pháp dài dòng, ta đưa ra một ví dụ so sánh một BIND zone file với một file dữ liệu tương đương cho tinydns.

Nếu giả sử dùng BIND để thiết lập DNS server cho một vùng mycompany.com mà file dữ liệu /etc/namedb/mycompany.com.hosts có nội dung
Code:

$ttl 38400
mycompany.com. IN SOA ns1.mycompany.com. itdept.mycompany.com. (
1245253211
10800
3600
604800
38400 )
mycompany.com. IN NS ns1.mycompany.com.
mycompany.com. IN MX 10 mx1.mycompany.com.
ns1.mycompany.com. IN A 127.0.0.1
mx1.mycompany.com. IN A 192.168.12.16
dc1.mycompany.com. IN A 192.168.10.11
dc2.mycompany.com. IN A 192.168.10.12
...
web.mycompany.com. IN A 192.168.18.10
www.mycompany.com. IN CNAME web.mycompany.com
ntp.mycompany.com. IN CNAME mx1.mycompany.com

thì khi dùng tinydns để thiết lập DNS server có thẩm quyền cho miền này, file dữ liệu /var/dns/tinydns/root/data tương đương sẽ có nội dung sau đây.
Code:

.mycompany.com::ns1.mycompany.com:604800
.0.168.192.in-addr.arpa::ns1.mycompany.com:604800
.1.168.192.in-addr.arpa::ns1.mycompany.com:604800
...
.18.168.192.in-addr.arpa::ns1.mycompany.com:604800
@mycompany.com::mx1.mycompany.com:86400
=ns1.mycompany.com:127.0.0.1
=mx1.mycompany.com:192.168.12.16
=dc1.mycompany.com:192.168.10.11
=dc2.mycompany.com:192.168.10.12
...
=web.mycompany.com:192.168.18.10
+www.mycompany.com:192.168.18.10
+ntp.mycompany.com:192.168.12.16

Trong ví dụ trên, file dữ liệu của djbdns đã chứa cả danh sách các mạng mà tinydns có thẩm quyền giải ngược địa chỉ IP.

3.5. Cấu hình dnscache để chuyển truy vấn mycompany.com sang tinydns

1. Ta sẽ cấu hình dnscache để forward sang tinydns mọi truy vấn liên quan đến các miền mà tinydns phụ trách. Hãy xác định thư mục làm việc.
Code:

cd /var/dns/dnscache/root/servers

2. Để forward các truy vấn về tên, ta tạo ra trong thư mục này một file có tên là tên miền cần giải (mycompany.com) và có nội dung là địa chỉ IP của tinydns (127.0.0.1).
Code:

echo 127.0.0.1 > mycompany.com

3. Để forward các truy vấn về địa chỉ IP, ta tạo ra trong thư mục này các file có tên là tên miền cần giải ngược và có cùng nội dung như trên. Chú ý rằng mỗi tên file như thế tận cùng bằng dấu chấm.
Code:

echo 127.0.0.1 > 0.168.192.in-addr.arpa.
echo 127.0.0.1 > 1.168.192.in-addr.arpa.
...
echo 127.0.0.1 > 18.168.192.in-addr.arpa.

4. Khởi động các dịch vụ bằng lệnh services restart. Kiểm tra rằng cơ chế forward dnscache → tinydns đã hoạt động đúng, tức là đã giải được các tên của miền mycompany.com và giải ngược được các địa chỉ IP tương ứng của miền này cho tất cả các client trong mạng cục bộ.

4 Tài liệu tham khảo

[1] FreeBSD handbook: 29.6 Domain Name System (DNS)
[2] ISC: BIND 9 Administrator Reference Manual (9.3.2)
[3] Simerson M.: DJBDNS on FreeBSD HOW-TO
[4] Wagner G.: Installing djbdns on a FreeBSD server
[5] Hoàng Ngọc Diêu: Thay thế BIND với djbdns
[6] Steniger J.: BIND v DJBDNS: Comparison of Performance, Ease of Config and Security
[7] Bernstein D.J.: DJBDNS Blurbs
[8] Bernstein D.J.: DJBDNS Security
[9] Bernstein D.J.: BIND, the Buggy Internet Name Daemon

kiengiaphat wrote:

Chào mọi người,
Mình muốn xin tư vấn về đường truyền internet 1 chút.
Ví dụ công ty mình có khoảng 100 người. Cty có phòng mạng riêng và có khoảng 10 Server cần ra và internet.
Bây giờ mình sử dụng đường truyền internet Leadline của VDC tốc độ 5Mbps. và cấu hình toàn bộ Server và người sử dụng truy cập internet qua đường truyền này.
- Như vậy đường truyền có đáp ứng được không mọi người?
- Sếp mình lại muốn chia 512K để ngườisử dụng cho internet như vậy có ổn không? và về măt kỹ thuật có đáp ứng được ko vậy?
Bác nào biết thì tư vấn giúp em nhé!
Verry thanks,

Chào bác, bác nên thuê riêng 1 đường FTTH cho users (các ISP lớn như VNPT, Viettel, FPT,... đều có dịch vụ này), khoảng 10 mbps đủ cho 100 người rồi. Còn server thì tùy lượng truy cập, không thể biết trước được.

Tui xin đóng góp 2 dạng VPN nữa giữa m0n0 v.1.3 với thiết bị ipsec khác: Draytek Vigor 29xx và Fortinet Fortigate w/FortiOS v.4

1. m0n0 - Vigor

192.168.0.1/24 m0n0 111.0.0.1 --- INTERNET --- 222.0.0.2 Vigor 172.16.0.1/16

1.1. m0n0

Interface: WAN
Enable NAT-T: No
DPD Interval: bỏ trống
Local subnet: LAN subnet
Remote subnet: 172.16.0.0/16
Remote gateway: 222.0.0.2

Phase 1 proposal:
Nego mode: main
My Identifier: My IP address
Encryption Algo: AES
Hash Algo: SHA1
DH key group: 2
Lifetime: 86400 seconds
Auth method: Pre-shared key
Pre-Share Key: 0123456789ABCDEFGHIJKLMN

Phase 2 proposal:
Protocol: ESP
Encryption Algo: 3DES, Rijndael (AES)
Hash Algo: SHA1, MD5
PFS key group: 2
Lifetime: 3600 seconds

1.2. Vigor

LAN to LAN

Common settings

Enable this profile: yes
VPN Dial-Out through: WAN1 only (hoặc WAN2 only)
Call Direction: Both
Always on: yes
Enable ping to keep alive: yes
PING to the IP: 192.168.0.1

Dial-Out settings

Type of server I'm calling: IPSec tunnel
Server IP/hostname: 111.0.0.1
IKE auth method: Pre-shared key
Pre-shared key: 0123456789ABCDEFGHIJKLMN
IPsec security method: High (ESP) - AES with auth
Advanced:
IKE phase 1 mode: main mode
IKE phase 1 proposal: AES128_SHA1_G2
IKE phase 2 proposal: AES_SHA1
IKE phase 1 key lifetime: 86400
IKE phase 2 key lifetime: 3600
Perfect Forward Secret: Enable
Local ID: 222.0.0.2

Dial-In settings

Allowed Dial-In type: IPSec tunnel
Specify remote VPN gateway: yes
Peer VPN server IP: 111.0.0.1
IKE auth method: Pre-shared key
IKE pre-shared key: 0123456789ABCDEFGHIJKLMN
IPSec Security method: 3DES, AES

TCP/IP Network settings

My WAN IP: 222.0.0.2
Remote gateway IP: 111.0.0.1
Remote network IP: 192.168.0.0
Remote network mask: 255.255.255.0
Local network IP: 172.16.0.0
Local network mask: 255.255.0.0
RIP direction: disable

2. m0n0 - Fortigate

192.168.0.1/24 m0n0 111.0.0.1 --- INTERNET --- 222.0.0.2 Fortigate 172.16.0.1/16

2.1. m0n0

Interface: WAN
Enable NAT-T: No
DPD Interval: bỏ trống
Local subnet: LAN subnet
Remote subnet: 172.16.0.0/16
Remote gateway: 222.0.0.2

Phase 1 proposal:
Nego mode: main
My Identifier: My IP address
Encryption Algo: AES
Hash Algo: SHA1
DH key group: 5
Lifetime: 86400 seconds
Auth method: Pre-shared key
Pre-Share Key: 0123456789ABCDEFGHIJKLMN

Phase 2 proposal:
Protocol: ESP
Encryption Algo: 3DES, Rijndael (AES)
Hash Algo: SHA1, MD5
PFS key group: 5
Lifetime: 3600 seconds

2.2. Fortigate

Phase 1

Name: My Home
Remote gateway: Static IP address
IP address: 111.0.0.1
Local interface: WAN1 (hoặc WAN2, WAN3,...)
Mode: Main (ID protection)
Auth method: preshared key
Pre-shared key: 0123456789ABCDEFGHIJKLMN
Advanced...
Enable IPsec Interface mode: yes
IKE version: 1
Local gateway IP: Main Interface IP
P1 proposal: 1-Encryption: AES128, Authentication: SHA1
DH group: 5
Keylife: 86400
Local ID: bỏ trống
XAUTH: disable
NAT Traversal: no
Keepalive frequency: 10
Dead Peer Detection: no

Phase 2

P2 proposal:
1-Encryption: AES128, Authentication: SHA1
2-Encryption: AES128, Authentication: MD5
3-Encryption: 3DES, Authentication: SHA1
4-Encryption: 3DES, Authentication: MD5
Enable replay detection: no
Enable perfect forward secrecy (PFS): yes
DH group: 5
Keylife: seconds 3600
Autokey Keep Alive: enable

Quick mode selector:
Source addr: 172.16.0.0/16
Source port: 0
Destination addr: 192.168.0.0/24
Destination port: 0
Protocol: 0

Lưu ý:

Trường hợp sau Vigor/Fortigate có nhiều subnet (192.168...., 172...., 10....), muốn cho bao nhiêu subnet vào VPN thì:

-- trên Vigor/Fortigate tạo bấy nhiêu phase 2 (trong một phase 1 duy nhất),

-- trên m0n0 tạo bấy nhiêu VPN profile đầy đủ cả phase 1 lẫn phase 2 nhưng các phase 1 đều giống nhau, kể cả pre-shared key cũng phải trùng nhau; mỗi phase 2 cho 1 local subnet.

Hôm nay tui moi lại topic cũ này vì vừa tìm được 2 cách khác muốn chia sẻ cùng mọi người.

Vấn đề: Làm sao đổi hướng port từ Draytek Vigor 28xx, 29xx vào một server đặt trong mạng nội bộ không liên thông trực tiếp với Vigor mà liên thông gián tiếp qua một gateway/firewall nữa (G) đứng sau con Vigor.

Giải pháp:

Cách 1 (cũ, đã thảo luận ở trên.) NAT tại Vigor và NAT tại G. Như thế sẽ có 2 lần NAT.

Internet ----- (131.0.0.1) Vigor (.1.1) ---- (.1.2) G (.2.1) ---- (.2.10) server

Cách 2 (mới.) Dùng tính năng True-DMZ của Vigor. Và trên G khai báo IP cho interface ngoài trùng với IP ngoài của Vigor.

Internet ----- (131.0.0.1) Vigor (.1.1) ---- (131.0.0.1) G (.2.1) ---- (.2.10) server
trong đó, tại Vigor chỉ route, không NAT.

Ưu điểm: chuẩn mực, dùng tính năng được hỗ trợ bởi thiết bị.

Nhược điểm: không dùng được nếu có 2 đường truyền Internet và G không hỗ trợ khai báo 2 địa chỉ IP cho 1 interface.

Cách 3 (mới.) Trên Vigor khai báo subnet cho LAN interface bao hàm cả mạng nội bộ liên thông trực tiếp lẫn gián tiếp với Vigor

Internet ===== (131.0.0.1, 132.0.0.2) Vigor (.1.1) ---- (.1.2) G (.2.1) ---- (.2.10) server
trong đó, tại G ta khai báo subnet trong .2.0/24 và subnet ngoài .1.0/24, nhưng tại Vigor ta không khai báo subnet trong .1.0/24 như thường lệ, mà khai báo .0.0/22 (bao gồm .0.0/24, .0.1/24, .0.2/24 và .0.3/24). Nhờ vậy ta lừa được Vigor ngon lành. Tại G chỉ route, không NAT.

Ưu điểm: dùng được khi có 2 đường truyền Internet (131.0.0.1 và 132.0.0.2).

Nhược điểm: không chuẩn mực, rất là bá đạo, sẽ có thể gây trở ngại khác.

bln102 wrote:

Link trực tiếp là static? Linh gián tiếp là shared?

Phải đó.

bln102 wrote:

Tôi có tìm hiểu một số bản quyền mã nguồn mở. Có phải các giấy phép sau đây là có thể sử dụng để thương mại và chỉnh sửa tùy ý:
- Public domain
- BSD
- MIT
- Apache
- LGPL

Đối với GPL thì khi sử dụng, nếu có chính sửa trong mã thì phải open source nó ra?

Public domain, (Free)BSD, Apache cho phép sửa mã nguồn và phân phối lại bằng giấy phép khác bất kỳ. (Ví dụ, phân phối lại chỉ binary không kèm mã nguồn.) GPL và LGPL thì không cho phép như vậy. Còn MIT thì hình như là không có một license nhất định nào.

bln102 wrote:

Liệu bán đĩa CD chứa phần mềm QT thì có vi phạm không?

Không sao cả.

bln102 wrote:

Hiện giờ thì bản quyền trả phí của QT có tác dụng gì? Vì mình thấy LGPL đã có thể thương mại hóa được.

Bác cần mua license nếu viết mã nguồn đóng và link trực tiếp vào QT. Còn nếu bác viết mã nguồn mở hoặc mã nguồn đóng link gián tiếp (dynamic link) thì không cần mua.

B 0 0 B wrote:

Mình muốn tạo ra các seft sertificate dựa trên các công cụ có sẵn trên windows mà chưa biết làm cách nào? bạn nào có kinh nghiệm việc xây dựng server giúp mình với

Cái này mình thử làm trên linux với mod openssl thì đc với khoảng vài dòng lệnh thôi, mà trên windows tìm ko thấy.

Bác thử cái http://ziggurat29.com/PortableApps/xcaportable.htm này xem.

Chú ý khi tạo cert, tham số nào chưa rõ nghĩa thì để mặc định thôi, đừng khai báo linh tinh mà gặp lỗi exception đấy.

Cảm ơn bác mrro đã động viên và chia xẻ kinh nghiệm. Tôi sẽ tìm hiểu dspam và sẽ ứng dụng nó trong những môi trường thích hợp.

Tôi hiểu và đồng tình với bác ở vài điểm. Không hiểu vài điểm khác.

Về DKIM như một công cụ diệt spam không có khả năng cá nhân hóa cho từng người sử dụng cuối, tôi không hiểu. Là một phương pháp xác thực, DKIM không thể là công cụ diệt spam mà chỉ có thể hỗ trợ các công cụ diệt spam (và chỉ hỗ trợ hiệu quả khi DKIM đã được dùng rộng rãi). DKIM không có khả năng cá nhân hóa cho từng người sử dụng cuối vì nó là một phương pháp xác thực miền. Nhưng khi so sánh với các phương pháp xác thực cá nhân, như chữ ký số SMIME hay PGP, thì tôi không thấy chúng có gì hơn DKIM trong việc hỗ trợ chống spam.

Về con gà và quả trứng, tôi đồng tình. Tôi cũng nghĩ rằng DKIM nếu muốn hỗ trợ chống spam hiệu quả thì trước hết phải được dùng rộng rãi. Rộng rãi đến mức mà khi đó, một miền không DKIM hoặc không có chính sách ký DKIM triệt để sẽ có thể được coi như không đứng đắn, có thể lọc bỏ hoàn toàn.

Về tính tất yếu của spam, tôi đồng tình. Dù cá nhân tôi không thích nhận spam và cũng không spam người khác, nhưng đã làm IT ở các công ty một thời gian tôi cũng thấy nhiều người có suy nghĩ "thoáng" hơn, họ chấp nhận quảng cáo, tin đồn, tin vô thưởng vô phạt, tin không liên quan,... ở mức độ nhất định, và họ cũng dùng e-mail để truyền bá các thông tin loại đó. Tôi chỉ có thể khuyên họ không nên spam quá độ chứ không thể khuyên họ tuyệt đối không spam được. Càng không thể cấm họ được. Đó là một phần của công việc, của business.

THÊM TÍNH NĂNG DKIM
cho Postfix với dkim-milter trên nền FreeBSD

1. DKIM là gì

DKIM (DomainKeys Identified Mail) là một phương pháp xác thực e-mail bằng chữ ký số của miền gửi thư, trong đó khóa công khai thường được công bố trên DNS dưới dạng một TXT record.

Khi gửi thư, bộ ký thư sẽ chèn lên đầu thư một trường DKIM-Signature [1] có nội dung đại khái như sau:
Code:

DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mycompany.com; s=sitec; t=1250425543;
bh=qQxSOEYYHCCISqVJ6pi/vUuNCr0EqMNkRSnD0B0TNFQ=;
h=Message-ID:From:To:Subject: Date:MIME-Version:Content-Type;
b=aiL+F+rqOdVxmR1V0bdfwsVOvMpwv1eMcCrX5I2C6U9CX+mkyepL3t0PwkW8pLSFc
CpJ5NvsBGqgOK4f2h89IubyYMFU0BkqZmtlBFlL+wyximVXLtHxO95WOxJX380tCet
XwofYIOK7tx45K41hG4T7+5ylNSuO1HHMpM/WfOM=

Trong đó có mọi thông tin cần thiết như phiên bản DKIM (v), thuật toán ký (a), thuật toán chuẩn hóa xâu ký tự đưa đi ký ( c ), tên miền ký (d), tên cặp khóa, hay còn gọi là selector (s), dấu ấn thời gian (t), thời hạn hiệu lực của chữ ký (x), phương thức truy vấn để lấy khóa công khai (q), danh sách các trường của phần đầu thư được ký (h), độ dài phần thân thư được ký (l), giá trị hash của nội dung được ký (bh), và chữ ký (b).

Khi nhận thư, bộ kiểm thư sẽ xác định khóa công khai theo phương pháp q (trong ví dụ trên, vốn dĩ không chỉ rõ q, phương pháp mặc định là truy vấn DNS tìm TXT record có tên là sitec._domainkey.mycompany.com.), dựa vào đó kiểm tra chữ ký rồi chèn kết quả kiểm tra vào trường Authentication-Results [2] của thư. Chẳng hạn, kết quả tốt được viết như sau:
Code:

Authentication-Results: ... dkim=pass header.i=@mycompany.com

Kết quả này xác thực các trường của phần đầu thư đã kể trong mục h (tức Message-ID, From, To, Subject, Date, MIME-Version và Content-Type trong ví dụ trên) cùng với phần thân thư có độ dài kể trong mục l (tức toàn bộ phần thân thư trong ví dụ trên, vốn dĩ với mục l mặc định).

Trong dây chuyền nộp – chuyển – phát thư, bộ ký thư thường đặt tại sending MTA và bộ kiểm thư thường đặt tại receiving MTA. Khi đó DKIM thực chất chỉ xác nhận thư được bảo toàn trên suốt chặng đường chuyển thư. Việc đảm bảo một lá thư From:alice@mycompany.com chắc chắn thuộc về Alice nằm ngoài trách nhiệm của DKIM.

Ngoài ra, tùy theo chính sách kiểm tra chữ ký DKIM của mình, bộ kiểm thư có thể tìm hiểu chính sách ký DKIM (tức ADSP, Author Domain Signing Practices [3]) của mycompany.com bằng cách truy vấn DNS tìm TXT record tên là _adsp._domainkey.mycompany.com., căn cứ vào đó (và tùy theo kết quả kiểm tra chữ ký) để quyết định có chấp nhận lá thư hay không.

2. Vì sao, khi nào dùng DKIM

Nói một cách vắn tắt, nên dùng DKIM bởi vì một lá thư không có chữ ký DKIM dễ bị hiểu là spam.

DKIM là một phương pháp xác thực chứ không phải là một phương pháp chống spam. Nhưng nó hỗ trợ việc chống spam bởi vì nó đảm bảo thư là thật (địa chỉ người gửi, hay ít nhất tên miền gửi thư là thật) trong khi thực tế đa số spam đều là thư giả mạo (mạo tên người khác, tên miền khác). Với DKIM, ai muốn spam thì cứ thoải mái, nhưng phải spam một cách quang minh chính đại; bạn không thể gửi thư từ một tên miền không thuộc sở hữu của mình được.

Phát triển từ phương pháp DK của Yahoo và phương pháp IM của Cisco, với việc được cơ quan IETF cấp tư cách Standards Track, DKIM đã từ một phương pháp xác thực email trẻ nhất trở thành phương pháp có tiềm năng nhất.

Với việc xác thực nội dung hơn là xác thực phong bì, trong các tình huống mà phong bì thay đổi, chẳng hạn, thư được forward qua một đường chuyển thư phức tạp, DKIM cho những lá thư cơ hội sống sót cao hơn so với các phương pháp xác thực địa chỉ server như là SPF hay SIDF. (Nhưng tất nhiên, trong những tình huống nội dung thay đổi, chẳng hạn qua bộ quét virus, các phương pháp kia có thể cho cơ hội sống sót cao hơn.)

Với việc triển khai trên server hơn là trên client, và không đòi hỏi một hạ tầng khóa công khai phức tạp, DKIM gọn nhẹ hơn so với các phương pháp xác thực từ đầu đến cuối như là S/MIME hay PGP. (Nhưng tất nhiên, ý nghĩa xác thực cũng nhẹ hơn, DKIM không thể thay thế hoàn toàn cho các phương pháp kia.)

Hiện nay DKIM chưa được dùng phổ biến. Thư có chữ ký DKIM chỉ mới thấy chủ yếu từ các ngân hàng, tổ chức tài chính (Paypal, eBay,...) và một số nhà cung cấp email (Google, Yahoo, Hotmail,...).

Vì thế, chính sách dùng DKIM tốt nhất hiện nay là ký triệt để mọi lá thư gửi đi từ miền mình và chỉ từ chối những lá thư không hợp lệ đến từ những miền khác có chính sách ký thư triệt để.

Cơ chế an ninh nào cũng có giá của nó. Việc tạo ra một chữ ký hay kiểm tra một chữ ký tiêu tốn hàng triệu clock cycle. Với DKIM, một server có xung nhịp cỡ GHz sẽ tiêu tốn thêm chừng 1 ms cho mỗi lá thư đến hay đi.

3. Phần mềm

Các thành phần chính của mail server gồm

FreeBSD operating system v.7.2 – GENERIC kernel.
Postfix SMTP server v.2.6.
Gói milter của sendmail, mặc định được cài đặt sẵn (cùng với sendmail) trong FreeBSD.
Dkim milter v. 2.8.3 với libdkim 1.0.17.

4. Môi trường và cấu hình tổng thể

Trên cùng một máy với Postfix đã cài đặt và hoạt động như một sending MTA đồng thời như một receiving MTA, ta sẽ cài đặt dkim-milter và cấu hình nó thành bộ ký thư đồng thời thành bộ kiểm thư, nghĩa là có nhiệm vụ ký các lá thư gửi đi, kiểm tra chữ ký những lá thư nhận được và chặn chúng nếu không hợp lệ.

Trước khi cài đặt dkim-milter, cần có các điều kiện sau.

FreeBSD đã cài đặt và cập nhật những miếng vá mới nhất.
Ports collection đã cập nhật bản mới nhất.
Postfix đã cài đặt và hoạt động.
Firewall cục bộ phải mở một cổng trên lookback interface để qua đó Postfix liên lạc với dkim-milter. Chúng ta sẽ giả sử là cổng 8891 TCP.

5. Cài đặt và cấu hình chi tiết

1. Cài đặt libdkim và dkim-milter
Code:

cd /usr/ports/mail/libdkim
make install clean
cd /usr/ports/mail/dkim-milter
make install clean

Các chương trình đã cài vào gồm có
Code:

/usr/local/bin/dkim-genkey #chương trình tạo khóa
/usr/local/bin/dkim-testkey #chương trình thử khóa
/usr/local/bin/dkim-testssp
/usr/local/libexec/dkim-filter #chương trình chính
/usr/local/etc/rc.d/milter-dkim #script chạy chương trình chính
/usr/local/share/doc/dkim-milter #tài liệu

2. Tạo account dịch vụ, tức là một account không có home và shell, thuộc một group tương ứng cùng tên, chúng ta sẽ đặt tên account này là dkim. Chi tiết của việc này được bỏ qua.

3. Tạo các thư mục để chứa khóa. Nên đặt tên theo tên miền mail cần xác thực. Chúng ta sẽ giả sử rằng ta có một miền mail cần xác thực là mycompany.com.
Code:

mkdir /etc/mail/dkim
mkdir /etc/mail/dkim/keys
mkdir /etc/mail/dkim/keys/mycompany.com
cd /etc/mail/dkim/keys/mycompany.com

4. Tạo một cặp khóa công khai/bí mật cho miền này.
Code:

dkim-genkey -d mycompany.com -s sitec -t

Trong đó -d (domain) là tên miền mail, -s (selector) là một từ bất kỳ tùy ý, chúng ta đặt là sitec, có tác dụng báo danh cặp khóa, nhờ nó mà có thể tạo ra và dùng đồng thời nhiều cặp khóa cho một miền mail, và -t nói rằng cặp khoá tạo ra dùng để test thử nghiệm; khi làm chính thức thì tạo cặp khoá mới cũng bằng lệnh này nhưng không có tham số -t. Lệnh này sẽ tạo ra trong thư mục hiện thời hai file
Code:

sitec.private
sitec.txt

File thứ nhất, sitec.private, chứa khóa bí mật. Ta hãy đổi chủ và phân quyền truy cập nó.
Code:

chown dkim:dkim sitec.private
chmod 600 sitec.private
chown dkim:dkim /etc/mail/dkim/keys/mycompany.com
chmod 700 /etc/mail/dkim/keys/mycompany.com

File thứ hai, sitec.txt, chứa khóa công khai. File này có nội dung đại khái như sau.
Code:

sitec._domainkey IN TXT "v=DKIM1; g=*; k=rsa;
p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC/tmJXY+kdhPLEIzy8C6Etl+PXlr3zJ8ElX
DUIyT7bBHE9z69igqffuIZ42eXTeJJBXNdrWlO4QBQ6H0knnpIvZid+VwG2GVfO98FT1F4YZGx4Np
plZqebT6YCQLF/T9JGctjsAN197KrCT0ilChgVmekyeT5g8f1iXBWUE4kFXwIDAQAB" ; ----- DKIM sitec for mycompany.com

5. Công bố khoá công khai lên DNS bằng cách tạo trong DNS forward lookup zone mycompany.com một TXT record có tên là sitec._domainkey.mycompany.com. và có giá trị là đoạn văn bản v=DKIM1; g=*; k=rsa; p=MIGfM...IDAQAB trong file nói trên. Nếu DNS server của chúng ta là BIND, việc này thực hiện đơn giản bằng cách copy paste toàn bộ nội dung của file trên vào forward lookup zone file; còn nếu là DJBDNS, việc này có thể thực hiện bằng cách copy paste từng phần của file trên vào một trang web có sẵn trên mạng Internet tên là djbdns / tinydns Record Builder (người đọc tự tìm), sau đó copy paste dòng kết quả từ trang web này vào file dữ liệu của DJBDNS.

Ngoài ra, ta hãy công bố chính sách ký lên DNS. Hãy tạo tương tự như trên một TXT record có tên là _adsp._domainkey.mycompany.com. và có giá trị là dkim=all hoặc dkim=discardable; all tuyên bố rằng mọi lá thư của mycompany.com đều được ký, discardable tuyên bố rằng mọi lá thư từ mycompany.com không có chữ ký hợp lệ đều đáng vứt đi.

6. Sửa file cấu hình của Postfix. Trong file /etc/postfix/main.cf (hoặc /usr/local/etc/postfix/main.cf), viết thêm vài dòng như sau.
Code:

milter_default_action = accept
milter_protocol = 2 # hoặc 3
smtpd_milters = inet:localhost:8891
nonsmtpd_milters = inet:localhost:8891

7. Tạo file cấu hình /etc/mail/dkim-filter.conf. Ta có thể sao chép từ cấu hình mẫu /usr/local/etc/mail/dkim-filter.conf.sample rồi sửa đổi vài tham số như sau.
Code:

KeyFile /etc/mail/dkim/keys/mycompany.com/sitec.private
Socket inet:8891@localhost
Domain mycompany.com
Selector sitec

8. Sửa file cấu hình boot /etc/rc.cf, viết thêm vài dòng như sau.
Code:

milterdkim_enable="YES"
milterdkim_uid="dkim"
milterdkim_profiles=""
milterdkim_cfgfile="/etc/mail/dkim-filter.conf"

9. Khởi động dkim-milter.
Code:

/usr/local/etc/rc.d/milter-dkim start

10. Khởi động lại Postfix và DNS server.

Nếu mọi bước trên đều làm chính xác, DKIM sẽ hoạt động. Ta có thể thử kiểm tra bằng cách gửi thư đến một địa chỉ chuyên dùng để thử nghiệm DKIM (người đọc tự tìm), hoặc đến một account của bản thân ở gmail.com hay yahoo.com.

6. Các việc nên làm thêm

Chúng ta đã cấu hình dkim-milter để ký và kiểm tra chữ ký, nhưng không cản lọc. Ta có thể chỉnh sửa file cấu hình dkim-filter.conf để lọc và cản các thư không có chữ ký DKIM hợp lệ đến từ những miền nhất định (chẳng hạn, những miền có chính sách discardable).

7. Tài liệu tham khảo

[1] Allman E. và một số tác giả khác: DomainKeys Identified Mail (DKIM) Signatures. RFC 4871. IETF Standards Track. 2007.
[2] Kucherawy M.: Message Header Field for Indicating Message Authentication Status. RFC 5451. IETF Standards Track. 2009.
[3] Allman E. và một số tác giả khác: DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP) . RFC 5617. IETF Standards Track. 2009.
[4] Sendmail: FreeBSD man pages: dkim-filter(8), dkim-filter.conf(5), dkim-genkey(8).
[5] Postfix: Postfix before-queue Milter support.

rs wrote:

to myquartz, facialz:
Con draytek2820 không cho phép wwwect port đến mạng bên trong (10.x.x.x), chỉ wwwect đến 192.168.2.2, phần còn lại là do con R2800 xử lý. Tớ nghĩ hai bạn nhầm chỗ này nên cho rằng không có route vào mạng bên trong?

Host(10.x.x.x) <------> SW <--------> R2800(192.168.2.2)<-------->(192.168.2.1)DrayTek2820

Một thiết bị cho phép tạo route vào mạng trong mà không cho phép NAT (map port, wwwect port,...) vào mạng trong thì kỳ cục thật... Nhưng thôi, giả sử cái đoạn màu cam kia là đúng, tức là con Vigor đó không phù hợp cho cấu trúc mạng của bác. Và bác có 2 lựa chọn:

a. NAT trên Vigor tới Cisco rồi NAT trên Cisco tới PC (cách của bác tmd).

b. Hoặc disable routing trên Vigor và chỉ dùng nó như modem thôi. Còn NAT sẽ thực hiện trên Cisco.

Cách a như thế là NAT hai lần NAT. Tôi đã vài lần bị đau khổ với sơ đồ NAT hai lần kiểu này vì vậy tôi không nghĩ đó có thể là một giải pháp lâu dài. Có thể nó giải quyết vấn đề này cho bác nhưng còn những vấn đề khác sẽ phát sinh thì chưa chắc.

Còn cách b thì tôi không biết có thực hiện được trên các thiết bị của bác không. Tôi chưa làm việc với những thiết bị Vigor và Cisco như của bác lần nào.

Tôi cũng nghĩ giống như bác PXMMRF và myquartz. Chắc chắn routing table của Vigor bị thiếu cái route đi vào mạng trong.

Bác OP thử copy gửi cái routing table lên xem nào.

Bác pnco quá khen rồi.

Thật ra, có vài điểm mà tôi vẫn chưa hiểu rõ, vẫn cứ thắc mắc hoài. (Tôi là newbie, mới dùng FreeBSD được khoảng 1/2 năm nay thôi.) Nên tôi gửi bài lên để chia xẻ chút kinh nghiệm nhưng cũng đồng thời để mọi người cho ý kiến chỉ giáo thêm:

- Hai tham số net.inet.ip.forwarding=1 trong /etc/sysctl.conf và gateway_enable=”YES” trong /etc/rc.conf có tác dụng như nhau hay là khác nhau? Nếu khác thì khác như thế nào?

- Chế độ diskd (+soft updates) được xem là an toàn hơn aufs. Chúng thật ra hoạt động như thế nào? Khác nhau như thế nào?

- Cứ 1 GB HDD cache thì cần 32 MB RAM để duy trì cache. Con số 32 MB là không thống nhất, có người cho rằng 10 MB và có người khác cho rằng 100 MB. Vậy rút cuộc, bao nhiêu MB mới là đúng?

- Lượng RAM dùng cho squid không nên lớn hơn 50% (hay 100%) lượng RAM của máy. Vì sao 50% (hay 100%) mà không phải là 60% hay 90%?

- FreeBSD tôi chỉ cài đặt phần giao diện text, không cài đặt giao diện đồ họa nào cả. Trong điều kiện đó, nên cài đặt thêm những tiện ích nào để hỗ trợ cho việc quản trị squid?

THIẾT LẬP INTERCEPTING WEB CACHE PROXY
với Squid trên nền FreeBSD

1. Intercepting web cache proxy là gì

Một proxy là một chương trình mạng hoạt động ở tầng ứng dụng chen ngang vào một loại lưu thông giữa client với server. Proxy chen ngang vào loại lưu thông nào thì sẽ được đặt tên theo loại lưu thông đó, chẳng hạn, DNS proxy, POP3 proxy, FTP proxy, Web proxy, v.v. Vì hoạt động ở tầng ứng dụng, proxy luôn hiểu thấu nội dung của lưu thông và có nhiều tác dụng hỗ trợ lưu thông: kiểm soát truy nhập, giám sát (theo dõi) lưu thông, caching (để tăng hiệu quả khai thác đường truyền). Cache proxy là loại proxy có tác dụng caching. Proxy chặn bắt (intercepting) là proxy có khả năng chặn bắt các gói tin trên đường lưu thông giữa client với server mà không cần sự hợp tác của client – nói cách khác, client không cần biết và không biết đến sự tồn tại của proxy.

Nếu hơn nữa proxy có khả năng chặn bắt không cần sự hợp tác của server thì nó được gọi là proxy trong suốt (transparent). Sở dĩ có tên gọi này vì proxy là trong suốt đối với client và server: cả hai đều không nhìn thấy proxy, client chỉ nhìn thấy server và server chỉ nhìn thấy client. Theo nghĩa này, một proxy chặn bắt có thể được xem như trong suốt một chiều: client nhìn xuyên qua proxy thấy server, nhưng server không nhìn thấy client mà chỉ nhìn thấy proxy.

2. Vì sao, khi nào dùng intercepting web cache proxy

Vì hoạt động không cần sự hợp tác của client, một web cache proxy chặn bắt có thể dùng để thực hiện caching mọi lưu thông Web, không phụ thuộc vào chương trình ứng dụng cụ thể tại client: Internet Explorer, Mozilla Firefox, Opera, Safari, Windows Update, Linux Update, F-Secure Antivirus Update,... bất kể ứng dụng nào hễ đã dùng giao thức HTTP là đều đi qua cache cả. Vì vậy, web cache proxy chặn bắt được dùng để áp đặt chính sách web caching.

Có những trường hợp mà proxy chặn bắt không thể dùng được. Ví dụ, khi ta muốn áp đặt chính sách định hình lưu thông (traffic shaping) trên đường truyền Internet lên từng user trong mạng cục bộ của mình. Khi đó, bộ định hình lưu thông, vốn dĩ đặt ở phía ngoài proxy, phải nhận biết chính xác từng client. Với một proxy chặn bắt thì ta không thể nào nhìn xuyên thấu qua nó từ bên ngoài. Khi đó, ta phải dùng đến proxy trong suốt.

Tuy vậy, bản thân Squid, phần mềm web cache proxy mà ta sẽ sử dụng, cũng đã có sẵn một bộ định hình lưu thông web khá ổn. Nhờ vậy ta không cần phải lo ngại về vấn đề định hình lưu thông kể cả khi chạy Squid ở chế độ chặn bắt.

3. Phần mềm và phần cứng

Phần mềm được dùng gồm Squid v.3.0 chạy trên nền hệ điều hành FreeBSD v.7.2 – GENERIC kernel. FreeBSD được dùng vì đây là hệ điều hành có network stack và thread scheduler nhanh nhất. Squid được dùng vì đây là phần mềm web cache proxy thông dụng nhất.

Phần cứng, để phục vụ cho 100 – 400 người dùng, cần một máy vi tính PC với 1 NIC, 500 – 2000 MHz CPU, 256 – 1024 MB RAM và 20 – 80 GB HDD.

4. Cấu hình tổng thể

Web cache proxy chặn bắt không đặt chen giữa đường truyền Internet mà được đặt ở một nơi bất kỳ trong mạng cục bộ. Một router/firewall chắn ngang đường truyền Internet sẽ được cấu hình để nhận biết mọi lưu thông web và chuyển hướng các lưu thông này sang proxy. Mọi gói tin đổi hướng được truyền nguyên vẹn (không thay đổi) đến proxy bằng WCCP v.2 xuyên qua một GRE tunnel.

Giao thức WCCP v.2 là một kỹ thuật mới của Cisco hỗ trợ hoàn hảo việc đổi hướng IP, tránh được mọi trục trặc và sự cố tắc mạng gây ra bởi các kỹ thuật đổi hướng trước đây. Cấu hình với WCCP này có hai lợi điểm. Thứ nhất, chỉ lưu thông Web phải đi qua proxy còn các lưu thông khác có thể đi thẳng ra Internet, như thế nhanh hơn và ít trở ngại hơn. Thứ hai, nếu vì lý do nào đó mà proxy ngừng hoạt động thì router/firewall sẽ phát hiện được ngay và sẽ cho lưu thông web đi thẳng ra Internet (thay vì đổi hướng sang proxy), nhờ thế mà lưu thông web cũng không bị gián đoạn vì những sự cố proxy nếu có.

Mọi gói tin (web) ra khỏi GRE tunnel ở phía máy proxy sẽ đổ bộ vào interface gre0 của máy này. Firewall pf của máy này sẽ được cấu hình chuyển hướng các gói đó đến cổng 3128 TCP trên loopback interface lo0, nơi Squid sẽ lắng nghe, đón nhận và xử lý.

Như vậy, quy trình cài đặt cấu hình gồm có: cấu hình router/firewall đổi hướng lưu thông web đến máy proxy, cấu hình gre0 interface và GRE tunnel trên máy proxy, cấu hình pf firewall trên máy proxy đổi hướng lưu thông web đến Squid, cài đặt và cấu hình Squid cơ bản để cache bắt đầu hoạt động và cuối cùng, theo dõi hoạt động và tinh chỉnh cấu hình Squid để giảm tiêu thụ tài nguyên, tăng năng lực xử lý.

5. Cấu hình chi tiết

Giả sử máy proxy, nơi sẽ cài đặt Squid, có 1 interface duy nhất tên là fxp0 và có địa chỉ IP là 172.16.0.2/24. Trên máy này, FreeBSD phải được cập nhật bản mới nhất và ports collection cũng phải được cập nhật bản mới nhất. (Tuy vậy, ta sẽ sẽ dùng bản mới nhất của Squid v.3.0 chứ không dùng Squid v.3.1.) Máy này phải truy vấn được một DNS server và phải truy cập được Internet.

Giả sử router/firewall chen giữa đường truyền Internet là 1 thiết bị Fortigate firewall với FortiOS firmware v.4, vốn dĩ hỗ trợ giao thức WCCP v.2. Thiết bị này đã có sẵn vài interface, trong đó

U1, U2,..., Un là các interface nối vào các mạng cục bộ của người sử dụng.
V1, V2,..., Vm là các interface nối vào các đường truyền Internet.
W là một interface liên thông với cache proxy. W không được trùng với bất cứ Ux, Vy nào. W có địa chỉ IP là 192.168.0.1/24.

Chú ý

Giao thức WCCP, thiết bị Fortigate và Squid hỗ trợ cả proxy cluster, nhưng trong ví dụ này ta chỉ làm 1 proxy cho đơn giản.
Trong suốt tài liệu này, từ interface bao hàm cả trường hợp VLAN interface, nhưng không bao hàm trường hợp vlink interface, tức interface ảo kết nối giữa các thiết bị ảo (VDOM) trong một thiết bị Fortigate vật lý. Các vlink interface không cho phép truyền WCCP.
Trong ví dụ này, hai interface W và fxp0 không cùng subnet, ngụ ý rằng firewall có thể liên thông gián tiếp chứ không nhất thiết phải liên thông trực tiếp với proxy.

5.1. Cấu hình Fortigate firewall

Ta sẽ cấu hình từ console hay cửa sổ telnet tới Fortigate firewall.

Trước hết, cấu hình WCCP v.2.
Code:

config system wccp
edit 0
set server-list 172.16.0.2 255.255.255.255
next
end

Tiếp đó, bật WCCP v.2 trên interface W.
Code:

config system interface
edit W
set wccp enable
next
end

Cuối cùng, bật WCCP v.2 trên các firewall policy cần cache. Ví dụ, nếu muốn cache lưu thông web vào các interface U1, U2 ra interface V3 và biết rằng các firewall policy cho phép lưu thông web từ U1 sang V3, từ U2 sang V3 có số thứ tự (ID) lần lượt là 13 và 23, ta dùng lệnh
Code:

config firewall policy
edit 13
set wccp enable
next
edit 23
set wccp enable
next
end

5.2. Cấu hình máy Squid proxy

Trước hết, chỉnh tham số FreeBSD kernel để phù hợp với chức năng cache của máy. Chức năng này cũng đòi hỏi máy phải hoạt động như một router (nghĩa là forward IP giữa các interface). Viết thêm vào file /etc/sysctl.conf như sau.
Code:

net.inet.ip.forwarding=1 # Enable IP routing (?)
net.inet.icmp.icmplim=0 # Don't rate limit incoming TCP connections
net.inet.icmp.icmplim_output=0
net.inet.tcp.msl=3000 # Tweak MSL to 30 seconds
net.inet.tcp.recvspace=16384 # Receive TCP window = 16kB
net.inet.tcp.sendspace=16384 # Send TCP window = 16kB
kern.maxfilesperproc=65536 # How many files per process...
kern.maxfiles=262144 # ...and per system?
kern.ipc.maxsockets=131072 # How many sockets?
kern.ipc.somaxconn=1024 # How deep is the incoming queue?
kern.ipc.nmbclusters=32768 # How many mbuf clusters to allow?

Và viết thêm vào file /etc/rc.conf như sau.
Code:

gateway_enable=”YES” # Enable IP routing (?)

Thứ hai, chỉnh cấu hình boot để gre0 interface được tự động tạo ra ngay từ khi boot và nhận biết giao thức WCCP v.2. Viết thêm vào file /etc/rc.conf hai dòng như sau.
Code:

ifconfig_gre0=“inet 10.0.0.2/32 10.0.0.1 link0 link2 \
tunnel 172.16.0.2 192.168.0.1 up“
cloned_interfaces=”gre0”

Trong đó 10.0.0.2 và 10.0.0.1 là hai địa chỉ IP đặt ra tùy ý cho hai đầu GRE tunnel. Phía Squid được đặt địa chỉ là là .0.2 còn phía Fortigate được đặt là .0.1. Đặc tả inet 10.0.0.2/32 10.0.0.1 có thể viết là inet 10.0.0.2 10.0.0.1 netmask 255.255.255.255. Subnet /32 có thể thay bằng /30 hoặc thậm chí /24.

Thứ ba, bật pf firewall và cấu hình cho nó chuyển hướng các gói tin (web) từ gre0 interface đến cổng 3128 TCP trên loopback interface. Trong file /etc/rc.conf, viết thêm
Code:

pf_enable=”YES”
pf_rules=”/etc/pf.conf”
pf_flags=””
pflog_enable=”YES”
pflog_logfile=”/var/log/pflog”
pflog_flags=””

rồi tạo file bộ luật lưu thông /etc/pf.conf, ở dạng đơn giản nhất, như sau.
Code:

rdr on gre0 inet proto tcp from any to any port www->127.0.0.1 port 3128
pass all
pass in on fxp0 inet proto tcp from any to 127.0.0.1 port 3128 keep state
pass out on fxp0 inet proto tcp from any to any port www keep state

Chú ý

Luật pass all chỉ là luật tạm, sau này nên bỏ đi và thay thế bằng các luật kiểm soát truy nhập khác chặt chẽ hơn. Đổi hướng không có nghĩa là cho phép, nên luật thứ ba (cho phép đi vào cổng 3128 của loopback interface) là cần thiết. Tuy nhiên luật này chỉ thật sự có tác dụng khi ta loại bỏ luật pass all.
Ta có thể nạp lại bộ luật lưu thông và khởi động lại firewall pf mà không cần phải reboot bằng câu lệnh

Code:

/sbin/pfctl -nf /etc/pf.conf && /etc/rc.d/pf reload

Thứ tư, biên dịch, cài đặt và cấu hình Squid cơ bản. Từ root shell lần lượt gõ các lệnh như sau.
Code:

cd /usr/ports/www/squid30
make config # cấu hình biên dịch
make # biên dịch
make install # cài đặt
make clean # dọn dẹp thư mục tạm
squid -z # khởi tạo cache

File cấu hình hoạt động của Squid là /usr/local/etc/squid/squid.conf. Trong file này, tìm và sửa hai tham số http_port và wccp2_router như sau.
Code:

http_port 127.0.0.1:3128 transparent
wccp2_router 192.168.0.1

Trong file /etc/rc.conf, viết thêm 1 dòng cho phép squid khởi động ngay từ khi boot.
Code:

squid_enable=”YES”

Sau khi reboot, nếu các bước trên đều làm chính xác, web cache proxy sẽ bắt đầu hoạt động.

Chú ý

Khi cấu hình biên dịch ta phải chọn WCCP v.2 (bỏ chọn WCCP v.1) và chọn enable pf transparent. Ngoài ra nên chọn enable diskd/aufs, enable delay pools, enable removal policies, những hỗ trợ rất có ích cho việc tinh chỉnh cấu hình Squid sau này.
Các lệnh để khởi động, dừng và khởi động lại squid mà không cần reboot là
Code:

/usr/local/etc/rc.d/squid [start|stop|restart]

Lệnh để kiểm tra file cấu hình Squid
Code:

squid -f /usr/local/etc/squid/squid.conf -k parse

Vài lệnh thường dùng để kiểm tra rằng cache proxy hoạt động.
Code:

netstat -i # có lưu thông trên các interface hay không?
tcpdump -n -i gre0 # có lưu thông trên gre0 hay không?
tcpdump port 80 # có lưu thông web hay không?
ps -aux | grep squid # squid có chạy hay không?
dmesg # xem log hệ thống
pftop # xem tình trạng firewall pf

Vài lệnh thường dùng để kiểm tra rằng cache proxy hoạt động bình thường, không quá tải, không bị nghẽn cổ chai.
Code:

squidclient mgr:info # xem tình trạng cache
uptime # xem tải
top # xem tổng hợp tình trạng hệ thống

Squid log vào các file /usr/local/squid/logs. Trong các log file, access.log chứa đặc biệt nhiều thông tin giúp cho việc gỡ rối.

Cuối cùng, sau khi Squid đã bắt đầu hoạt động, ta cần phải hoàn thiện cấu hình để tăng hiệu quả và giảm tải. Dưới đây là vài tham số cấu hình đã được chỉnh theo các giá trị được xem là tối ưu cho máy có 1 GB RAM và 72 GB HDD.
Code:

cache_replacement_policy heap LFUDA # thuật toán cache đĩa
memory_replacement_policy heap GDSF # thuật toán cache RAM
cache_swap_low 90
cache_swap_high 95
maximum_object_size_in_memory 32 KB # file lớn nhất có thể RAM cache
cache_dir aufs /usr/local/squid/cache 30000 16 256
# I/O không đồng bộ và
# cache tối đa 30000 MB
cache_mem 80 MB # lượng bộ nhớ bổ sung
memory_pools off
maximum_object_size 1000 MB # file lớn nhất có thể cache
quick_abort_min 0 KB
quick_abort_max 0 KB
log_icp_queries off
client_db off
buffered_logs on
half_closed_client off

Chú ý

Các thuật toán heap LFUDA và heap GDSF làm tăng hiệu quả cache lên rất nhiều lần so với thuật toán LRU mặc định.
Chế độ aufs, HDD I/O không đồng bộ với xử lý đa luồng, cũng làm tăng tốc độ truy xuất HDD lên nhiều lần so với chế độ ufs mặc định; aufs nguyên thủy được lập trình trên Linux nhưng trên các phiên bản mới của FreeBSD chạy cũng rất tốt.
Một chế độ non-blocking HDD I/O khác, hoàn toàn FreeBSD, là chế độ diskd. Khi dùng chế độ này, nên kết hợp với soft updates (mặc định bật sẵn khi cài đặt, xem tài liệu FreeBSD manual) để đạt được hiệu quả tối đa. Chế độ diskd + soft updates bảo toàn dữ liệu tốt hơn chế độ aufs trước các sự cố mất điện.
Độ lớn cache_dir bao nhiêu là tối ưu còn tùy thuộc vào kích thước RAM của máy. Cứ 1 GB HDD cache thì cần 32 MB RAM để duy trì cache. (Con số 32 MB là không thống nhất, có người cho rằng 10 MB và có người khác cho rằng 100 MB.) Lượng RAM đòi hỏi bởi Squid không nên lớn hơn 50% (có người đưa ra con số 100%) lượng RAM của máy. Do đó cache_dir nên thỏa
Code:

độ lớn cache_dir * 32/1024 + cache_mem + 20 = 0.5 * lượng RAM của máy [MB]

Trong đó, vế trái chính là lượng RAM yêu cầu cho Squid. Nếu cache_dir làm vế trái lớn hơn kích thước bộ nhớ RAM của máy thì bộ nhớ ảo sẽ bắt đầu swap, khiến cache chậm lại.
Ngoài ra, độ lớn cache_dir còn tùy thuộc vào dung lượng HDD. Cache_dir không nên lớn hơn 50% dung lượng HDD. (Con số này cũng không thống nhất, một số người cho rằng 60%, số khác 70% và một số khác nữa kể cả tác giả của squid.conf cho rằng 80%.)
Maximum_object_size (kích thước đối tượng lớn nhất cho phép cache) bao nhiêu là tối ưu tùy thuộc dung lượng cache. Nói chung, khi đã dùng cache_replacement_policy là một dạng heap nào đó, dùng maximum_object_size thật lớn thì sẽ hiệu quả hơn.
Giữa maximum_object_size_in_memory và dung lượng RAM cũng có mối liên quan tương tự như thế.
Khi thay đổi giá trị các tham số của cache, phải chờ một thời gian để nội dung cache thay đổi được một cách đáng kể thì mới thấy tác dụng.
Mặc định, Squid cache vào vào các thư mục con trong /usr/local/squid/cache. Nếu có nhiều HDD, nên dành riêng HDD cho cache để cải thiện năng lực xử lý. Và HDD nên format bằng một file system có khả năng xử lý tốt rất nhiều file nhỏ.

6. Các việc nên làm thêm

Sau khi đã cài đặt, cấu hình để Squid chạy chúng ta nên xem xét làm thêm một số việc như sau.

Điều chỉnh lại bộ luật firwall pf.conf, chỉnh lại cấu hình squid.conf để thêm an ninh.
Thiết đặt delay_pools để định hình lưu thông Web ngay trong Squid.
Sử dụng module quản trị squid trong Webmin và vài phần mềm phân tích log khác (chẳng hạn Calamaris) để lấy số liệu thống kê, trên cơ sở đó tiếp tục chỉnh cấu hình.
Cài đặt một số tiện ích khác để hỗ trợ cho việc quản trị Squid.

7. Tài liệu tham khảo

[1] Fortinet: FortiGate Administration Guide
[2] squid team: Configuring Transparent Interception with FreeBSD and WCCPv2
[3] Deckle: New Squid User Guide
[4] ViSolve: Squid 3.0 Configuration Manual
[5] Duane Wessels: Squid - The Deffinitive Guide
[6] FreeBSD: Kernel Interface Manual - gre(4)
[7] nofee: Setting up Squid in FreeBSD
[8] tony: Squid Optimization Guide

moonlight_farewell wrote:

quỷ lệ wrote:

moonlight_farewell wrote:

Ví dụ địa chỉ 10.243.100.56 là một địa chỉ IP lớp A vì octet đầu được biểu diễn dưới dạng nhị phân thành 00001010. Bit đầu tiên là 0 nên địa chỉ đó thuộc về lớp A.

Hic,em mù tịt cái này ,mong các bác giải thích dùm !

Theo qui định lớp A từ 1--> 126, lớp B từ 128-->191, lớp C từ 192-->223
Đổi sang nhị phân lớp A bắt đầu là 0, lớp B bất đầu là 10, lớp C bắt đầu là 110

Hic em biết các lớp IP là vậy,nhưng chia làm sao mà octet đầu tiên của 10.243.100.56 lại ra 00001010 . Giúp em với

Bạn cần phải tìm hiểu:
1. Octet là gì.
2. Đâu là octet đầu tiên của một địa chỉ IP được viết ở dạng thập phân.
3. Cách dùng calculator để đổi cơ số.

Hiểu xong 3 vấn đề trên thì sẽ tự giải thích được thôi.

Không chỉ FPT cung cấp dịch vụ cáp quang, VNPT cũng có. Ai ở TP HCM có thể liên hệ với công ty điện thoại (Đông, Tây) để hỏi chi tiết.

bachduong051 wrote:

Xin chào anh em trong HVA!
Mình vừa nhập môn môn Mạng có vấn đề xin anh em chỉ giáo giùm!
Mình có một phòng gồm 20 máy.Mình muốn thành lập một mạng máy chủ và máy trạm trong phòng này.Có thể cài Win server 2003 cho các máy(hoặc Xp cũng được).Vấn đề mình cần hỏi như sau,mong anh e chỉ giáo để mình hình dung rõ cách thiết lập mạng cho phòng máy này:
1.Làm thế nào để thiết lập phân biệt giữa máy trạm và máy chủ.Máy chủ sẽ quản lí mọi tài nguyên,mỗi máy trạm sẽ cung cấp cho mỗi thành viên một user đăng nhập .Và tất nhiên mỗi user đó khi đăng nhập sẽ sử dụng đựoc tài nguyên chung của mạng do administrator quy định,ma không đựoc phép chỉnh sữa nó.
2.Với một lượng user lớn (vài chục người chẳng hạn)thì làm thế nào để creat toàn bộ user đó một cách nhanh nhất.
Mình vừa nhập môn winserver 2003.Và thử creat dạng quản lí đó(tức là thành lập các user trong một group và login các user )nhưng chỉ làm trên một máy thôi.Còn nhiều máy với nhau thì mình vẫn chưa hình dung ra cách làm thế nào.
Anh em chỉ giáo cho người mới nhập môn nhé!
Thanks nhìu!Xin chỉ giáo!

Bác nên dùng mô hình domain thay vì workgroup. Khi đó chỉ cần tạo mỗi user một account thôi còn bao nhiêu máy trạm, bao nhiêu máy chủ cũng mặc.

Tui nghĩ thế này:

sunrise_vn wrote:

Thứ nhất: Sự khác biệt giửa SDK và trình biên dich ra HĐH là gì?
Thứ hai: Giả sử đã viết ra được HĐH rồi vậy SDK cho nó dùng cái gì để viết?
Thứ ba: Có sự khác biệt như thế nào giửa SDK và trình biên dich ra HĐH?

Trình biên dịch để biên dịch, còn SDK bao gồm các công cụ hỗ trợ khác.

sunrise_vn wrote:

Thứ tư: Ngày xưa khi mới chế tạo ra được máy tính, lúc đó ko có HĐH hay ngôn ngữ lập trình gì hết vậy làm sao mà dùng máy?

H Đ H có thì tốt, nhưng không nhất thiết phải có mới được. Có bộ xử lí tức là có ngôn ngữ máy, có thể lập trình được rồi.

sunrise_vn wrote:

Đục như thế nào nhỉ? Rồi nguyên vật liệu là gì?

Đục bằng 1 cái máy giống như máy chữ. Vật liệu là những tấm bìa có nhiều hàng nhiều cột. Mỗi cột nhiều ô, mỗi ô là 1 bit, không đục là 0, đục là 1. Như thế mỗi cột viết 1 kí tự, mỗi bìa dùng để viết 1 dòng (lệnh hay số liệu). Nếu lỡ tay làm rớt tập bìa thì file chương trình hay số liệu sẽ bị xáo trộn lộn tùng phèo. smilie

Tic.Tac wrote:

ngắn gọn là vầy, nhà mình có 2 máy, 1 máy đang sử dụng cước trọn gói megaYOU của FPT, 1 máy ko lên net dc, bây h mình muốn cả 2 máy đều có thể kết nối adsl dưới tài khoản của mình nhưng ko sử dụng mạng nội bộ, nói trắng ra là do máy đang sử dụng adsl dc dat trong phòng kín, đi dây âm tường nên ko thể đi dây đến máy kia (chẳng lẽ khoan tường để nối dây, nhà mới xây mới ngu chứ ), ko bik còn cách nào ko nữa , mình cũng đã tham khảo qua việc lắp đặt thiết bị wireless nhưng ko bik là sử dụng loại này có đảm bảo tốc độ hay ko, vả lại 2 máy cách nhau khá là xa ( 20m ), mong mọi ng` cho ý kiến

thx for reading

Muốn có thêm 1 máy tính nối mạng Internet thì cách dễ nhất là dùng mạng nội bộ. Nếu trong cùng 1 tầng lầu và không cách nhau quá nhiều bức tường, thiết bị wireless đảm bảo tốc độ đủ để dùng Internet.

Để có thêm 1 kết nối ADSL bác không thể dùng lại tài khoản vì 1 tài khoản chỉ cho phép 1 kết nối ADSL. Bác cần đăng ký tài khoản khác.

Tưởng trong sơ đồ này, một trong hai DHCP server sẽ tự động rút lui (không khởi động) chứ nhỉ.

seraphpl wrote:

hêhê, tui ghi

Code:
plaintext+key+f() = ciphertext (Với f() là một hàm để mã hóa)
nghĩa là dùng hàm f() rồi xào nấu cái key với cái plaintext thế nào đó để ra ciphertext

Hì hì, bây giờ thì rõ rồi.

Nếu định diễn đạt rằng bác định "xào nấu cái key với plaintext thế nào đó để ra ciphertext", bác đừng viết như thế kia. Hãy viết thế này

f( plaintext, key) == ciphertext

hoặc thế này

f( plaintext, key, ciphertext) == 0.

Chỉ là phương trình tượng trưng, ký hiệu tượng trưng, nhưng nếu viết không chính xác thì sẽ gây hiểu lầm.

Bác seraphl, tui cũng sẽ noi gương bác, cắt bỏ hết những đoạn trên. Đã nói hết ý của mình, tranh luận cũng không còn gì mới.

seraphpl wrote:

facialz wrote:

seraphpl wrote:

Và tui nghĩ là
plaintext+key+f() = ciphertext (Với f() là một hàm để mã hóa)

Kẻ tấn công biết hàm f. Và f không có đối số thì chỉ là một hằng số. Và nếu giả sử f có đối số mà đối số ấy không phải là key thì kẻ tấn công cũng biết luôn đối số này. Hi vọng bác đã tính đến những điều đó khi phát biểu ý nghĩ trên.

Tại sao kẻ tấn công biết hàm f()?
Cái f() ở bài trước là tui chỉ giả sử đơn giản thôi, còn lại thì có muôn vàn cách để làm ra f(),
Tui đâu có pâhn tích gì cái f(). Tui chưa hiểu rõ ràng ý của bạn về phần này?

Tui đã đề cập 1 lần trước đây. Kẻ tấn công chỉ không biết toàn bộ key, còn lại biết tuốt.

Đây là giả thiết mẫu mực và duy nhất được xét khi sơ bộ tiếp xúc với một thuật toán. Tui không nhớ rõ lắm nhưng chắc chắn đây là một nguyên lý có tên hẳn hoi (hình như là Kirhoff hay Bishop gì đó).

Thực tế, kẻ tấn công có thể biết hay không biết điều này điều nọ. Cho nên an toàn nhất là giả sử hắn biết tuốt mọi điều (ngoại trừ toàn bộ key). Nếu thuật toán của bác an toàn trong giả thiết này, nó sẽ càng an toàn hơn khi có vài tham số nào đó hắn không biết.

Bởi vậy, tui thích công thức trước đây của bác hơn:

plaintext[ i ] ^ ciphertext[ i ] ^ key[ f(i) ] == 0 (1)

Và cũng bởi vậy, tui nghĩ công thức mới của bác nên sửa như thế này thì hợp lý hơn

plaintext + ciphertext + f(key) == 0 (2)

Có thể (1) không an toàn, nhưng vì là trường hợp riêng của (2), nó vẫn là hướng đi có lý để dẫn tới một thuật toán an toàn, có dạng (2).

(Cảnh báo: cả 2 công thức trên đều lạc đề. Đề bài là ciphertext ^ plaintext ^ key == 0.)