Định cấu hình CNTT nhanh: Xây dựng mạng riêng ảo với FreeS / WAN

Bài tham khảo dành cho sinh viên chuyên ngành ATTT như PTIT, KMA … về cấu hình FreeSwan hay OpenSwan.

Tài liệu tham khảo của PACKT OPENSWAN

Xem cách ghép các mảnh ghép khác nhau để xây dựng máy chủ VPN FreeS / WAN trên Linux.
FreeS / WAN là một bản triển khai của IPSec, giao thức bảo mật IP của Linux. IPSec thực hiện mã hóa và xác thực ở cấp độ IP, cho phép mã hóa bất kỳ và tất cả dữ liệu được truyền qua IP, thay vì chỉ một giao thức cấp cao hơn cụ thể, như với ssh hoặc ssl .

Trong bài này, tôi sẽ giới thiệu cho bạn công nghệ đằng sau FreeS / WAN cũng như xây dựng phần mềm, cấu hình FreeS / WAN, tạo khóa, khởi động và dừng kết nối cũng như kiểm tra kết nối.

Các thành phần và sử dụng FreeS / WAN
Các thành phần cốt lõi của FreeS / WAN bao gồm:

  • · AH (Authentication Header) cung cấp dịch vụ xác thực mức gói.
  • · ESP (Encapsulate Security Payload) cung cấp mã hóa cộng với xác thực.
  • · IKE (Internet Key Exchange) thương lượng các thông số kết nối, bao gồm cả các khóa, cho hai loại còn lại.
  • · KLIPS (kernel IPSec) thực hiện xử lý AH, ESP và gói tin bên trong hạt nhân.
  • · Pluto (một trình nền IKE) thực hiện IKE, đàm phán kết nối với các hệ thống khác.
  • · Các tập lệnh khác nhau cung cấp giao diện của quản trị viên cho máy móc.

IPSec tùy chọn?
IPSec là tùy chọn cho IPV4, phiên bản giao thức hiện tại, nhưng nó bắt buộc đối với IPV6. Dự án FreeS / WAN đang làm việc để triển khai IPSec cho ngăn xếp IPV6 của Linux.


Vì IPSec ở cấp IP nên nó có thể bảo mật bất kỳ loại lưu lượng nào, nhưng hai cách triển khai phổ biến nhất là thiết lập mạng riêng ảo (VPN) giữa hai trang web trên mạng công cộng và ở quy mô nhỏ hơn, kết nối người dùng máy tính xách tay từ xa với văn phòng tại nhà trên Internet.

Giao thức IPSec được thiết kế để cho phép các triển khai khác nhau tương tác với nhau, với VPN Consortium làm việc để khuyến khích sự hợp tác giữa các nhà cung cấp.

FreeS / WAN được biết là có thể tương tác với:

  • · BSD IPSec
  • · Windows 2000 IPSec
  • · PGPNet
  • · Safenet SoftPK
  • · Bộ định tuyến của Cisco

Một khái niệm bổ sung được cung cấp bởi FreeS / WAN là “mã hóa cơ hội”, trong đó hai máy chủ IPSec bất kỳ có thể mã hóa lẫn nhau và sẽ làm như vậy bất cứ khi nào các gói chuyển qua giữa chúng. Nhóm FreeS / WAN cho rằng điều này có thể khuyến khích việc sử dụng mã hóa trên hầu hết lưu lượng truy cập Internet, nếu ý tưởng này được bắt kịp và các quản trị viên mạng thực hiện nó. Kỹ thuật này dựa vào việc sử dụng DNS để cung cấp các khóa RSA cần thiết để mã hóa kết nối. Mặc dù tôi sẽ không trình bày sâu hơn ở đây, nhưng để biết thêm thông tin, hãy xem tài liệu HowTo , tài liệu này đề cập đến việc triển khai mã hóa cơ hội. Tất nhiên, các IP và tường lửa được phân bổ động có thể làm cho việc triển khai IPSec có vấn đề, vì nó được thiết kế cho lược đồ IP cố định, end-to-end, nhưng những vấn đề này có thể được giải quyết.

Tôi đã để chìa khóa ở đâu?
Giống như tất cả các lược đồ mã hóa, IPSec dựa trên khái niệm khóa. Nếu bạn muốn, chìa khóa là một chữ ký cho phép bên ở đầu kia của kết nối biết bạn là ai và cả hai bên đều có thể tin tưởng vào giao tiếp. Tất nhiên, chìa khóa có thể bị mất hoặc bị đánh cắp và trong trường hợp đó, một bên không đáng tin cậy có thể điều chỉnh liên lạc.

Khóa có thể được chuyển theo cách thủ công giữa các mạng bằng thư được mã hóa hoặc một số phương pháp khác hoặc hệ thống có thể được cấu hình để tạo và chuyển khóa tự động, thay thế khóa định kỳ. Nhóm FreeS / WAN đề xuất tạo khóa tự động; bằng cách sử dụng phương pháp này, bạn được đảm bảo rằng các khóa sẽ được thay đổi định kỳ và mọi sự cố rò rỉ sẽ chỉ tồn tại trong một khoảng thời gian cố định trước khi các khóa thay đổi. Đối với khóa tự động, “bí mật được chia sẻ” hoặc khóa công khai phải tồn tại để hai hệ thống có thể thỏa thuận kết nối an toàn.

Nhận FreeS / WAN
Nếu bạn đủ may mắn để sử dụng bản phân phối bao gồm FreeS / WAN, thì việc cài đặt một gói từ đĩa CD của bạn và thực hiện một chút công việc thiết lập có thể dễ dàng như cài đặt một gói từ đĩa CD. Rõ ràng, các bản phân phối có trụ sở tại Hoa Kỳ không thể bao gồm nó do các quy định về mã hóa xuất khẩu, nhưng một số bản phân phối Linux có trụ sở bên ngoài Hoa Kỳ bao gồm FreeS / WAN, với sự hỗ trợ được tích hợp trong hạt nhân chứng khoán. Tuy nhiên, hãy lưu ý rằng mặc dù hỗ trợ hạt nhân và các tiện ích IPSec được tích hợp trong bản phân phối, chúng có thể không hoạt động đầy đủ. Tôi đã dành vài giờ khắc phục sự cố thiết lập IPSec cho đến khi tôi phát hiện ra trong kho lưu trữ thư rằng bản phân phối mà tôi đang sử dụng đã gửi một bản triển khai bị hỏng.

Tôi sẽ phác thảo các bước bạn cần thực hiện để đưa FreeS / WAN vào một máy chủ hiện có, đề phòng trường hợp xấu nhất. Nếu bạn đã có nó dưới dạng gói dựng sẵn, bạn có thể bỏ qua các bước thiết lập thích hợp.

Điều kiện tiên quyết
Theo bài viết này, phiên bản mới nhất của FreeS / WAN là 1.92 . Tệp đã tải xuống sẽ có tên LATEST.tar.gz và nó yêu cầu:

  • ·         Gcc hoặc egcs (trình biên dịch C)
  • · Một trình lắp ráp / liên kết thích hợp
  • ·         Làm và  (công cụ biên dịch)
  • ·         Glibc
  • ·         Gmp (Gnu MultiPrecision Library)
  • ·         Ncurses (dành cho cấu hình hạt nhân dựa trên menu, thân thiện hơn)
  • · Nguồn hạt nhân (FreeS / WAN với cả hạt nhân dòng 2.2 và 2.4)

Nguồn hạt nhân của bạn thường sẽ nằm trong / usr / src / linux . Những người dùng FreeS / WAN khuyên bạn nên bỏ khai báo tarball FreeS / WAN trong / usr / src , nơi bạn sẽ kết thúc với thư mục / usr / src / freeswan-version (với phiên bản là số phiên bản của nguồn FreeS / WAN mà bạn đã truy xuất) . Để làm như vậy, hãy làm như sau, dưới dạng root:

  • · Di chuyển tệp LATEST.tar.gz sang / usr / src
  • · Bỏ mở tệp .gz bằng tar xvzf LATEST.tar.gz

Kernel
Đảm bảo xây dựng, cài đặt và kiểm tra kernel của bạn trước khi thêm FreeS / WAN. Để biết thêm thông tin về cách biên dịch hạt nhân của bạn, hãy xem Jack Wallen, Tính năng hàng ngày của Jr. “Biên dịch (hoặc biên dịch lại) hạt nhân Linux của bạn.”

Ở mức tối thiểu, bạn sẽ cần hỗ trợ mạng, bao gồm hỗ trợ cho card mạng của bạn. Bạn cũng có thể nên bật:

  • · CONFIG_IP_ADVANCED_ROUTER = y
  • · CONFIG_SYSCTL = y
  • · CONFIG_PROC_FS = y

Ghi chú của người biên tập
Các tùy chọn trên sẽ xuất hiện như được liệt kê khi chạy lệnh make config . Nếu bạn đang chạy lệnh make menuconfig hoặc lệnh make xconfig , bạn sẽ chọn chúng từ các menu.


Khởi động với nhân mới của bạn và đảm bảo rằng mạng bên dưới hoạt động như bình thường và bạn có thể ping và truy cập vào máy ở đầu kia của VPN được đề xuất mà không cần IPSec.

Bây giờ bạn có thể quay lại và xây dựng FreeS / WAN.

Xây dựng FreeS / WAN
Bước đầu tiên trong việc xây dựng ứng dụng là chuyển cd vào thư mục /usr/src/freeswan-1.9.2 , như sau:
cd /usr/src/freeswan-1.9.2

Khi bạn đã ở trong thư mục đó, chạy lệnh này:
make oldgo


Tùy chọn “Make”
Bạn cũng có thể sử dụng make ogo , menugo và xgo , cho phép bạn thực hiện lại cấu hình hạt nhân của mình. Oldgo chỉ cần thêm các tùy chọn FreeS / WAN vào cấu hình mới nhất của bạn và tiến hành xây dựng.


Tại thời điểm này, bạn có thể làm làm kinstall trong FreeS / WAN thư mục hoặc, nếu bạn cảm thấy thoải mái hơn khi làm các bước chính mình, thực hiện như sau:
cd ../linux
làm cho
thực hiện cài đặt
làm modules
make modules_install

Cấu hình FreeS / WAN
Trước bạn bắt đầu thiết lập IPSec giữa hai máy cổng, hãy đảm bảo kiểm tra mạng bên dưới và đảm bảo rằng các máy có thể giao tiếp với bất kỳ phần mềm nào bạn muốn bọc trong mã hóa. Bằng cách này, bạn sẽ không lãng phí thời gian để khắc phục sự cố sai. Bạn sẽ cần bật chuyển tiếp IP để IPSec hoạt động, như sau:
echo 1> / proc / sys / net / ipv4 / ip_ionary

Để kích hoạt vĩnh viễn nó, thông thường, một cài đặt trong / etc / sysconfig / network(đối với các hệ thống dựa trên Red Hat) phải được thay đổi thành true, như sau:
FORWARD_IPV4 = false

thành
FORWARD_IPV4 = true

Trước khi bật vĩnh viễn, hãy đảm bảo rằng bạn đã thiết lập tường lửa thích hợp để không chuyển các gói một cách bừa bãi.

Tạo khóa
Cả hai máy sẽ cần khóa trong /etc/ipsec.secrets hoặc có thể là /etc/freeswan/ipsec.secrets . Nếu bạn đã tạo từ nguồn như đã mô tả trước đây, thì một bộ khóa phải được tạo cho bạn và nếu bạn đang sử dụng các tệp nhị phân từ bản phân phối của mình, bạn cũng có thể có tệp này được lưu trữ trước.

Nếu bạn muốn tạo một cặp khóa mới, hãy sử dụng lệnh sau, trong đó nbitsbằng số bit bạn muốn sử dụng trong cặp khóa (ví dụ: 256, 1024, 2048):
ipsec rsasigkey nbits

Bạn sẽ nhận được kết quả như thế này . Bạn sẽ bọc nó trong phần sau:
RSA {
INSERT OUTPUT OF KEY PAIR GENERATION HERE
               }

Sau đó, cắt và dán nó vào tệp ipsec.secrets .

Để thử nghiệm, bạn có thể tạo một tệp ipsec.secrets tầm thường và không sử dụng mã hóa RSA, như sau:
192.168.192.2 192.168.192.3: PSK “yourlittlesecret”

Cấu hình
cuối cùng Các cấu hình cuối cùng yêu cầu chỉnh sửa /etc/ipsec.conf . Điều này được tạo sẵn với cấu hình mẫu, bạn có thể sao chép và chỉnh sửa cho phù hợp với tình huống của mình.

Bạn có thể chỉ định dòng giao diện bằng ánh xạ thích hợp, chẳng hạn như:
interface = “ipsec0 = eth0”
    interface = “ipsec0 = eth0 ipsec1 = ppp0”

Hoặc bạn có thể để nó là % defaultroute.

Theo mặc định, các mục gỡ lỗi được đặt thành không. Nếu bạn đang gặp sự cố, hãy thay đổi chúng thành tất cả và bạn sẽ nhận được nhiều thông tin trong / var / log / messages và / var / log / secure . Cuối cùng, một tập hợp các giá trị mặc định được sử dụng cho tất cả các kết nối, nếu không được chỉ định trong khối kết nối.

Lưu ý khối xác thực RSA. Nếu bạn chỉ có authby = rsasig và không trái / phải rsasigkeycác mục nhập, IPSec sẽ nhận khóa từ DNS và nếu DNS không được thiết lập để gửi khóa tới IPSec, kết nối sẽ ngừng hoạt động ngay lập tức.

Bạn cũng nên sử dụng một cái gì đó hợp lý để đặt tên cho các kết nối của mình, tốt nhất là một cái tên sẽ hỗ trợ bạn gỡ lỗi. Bằng cách đặt tên cho kết nối giống như leftmachine-rightmachine, bạn sẽ có một lời nhắc nhở về những gì kết nối được cho là đang hoàn thành. Ngoài ra, đừng nhầm lẫn bởi danh pháp “trái” và “phải”. Bất kể bạn đang định cấu hình đầu nào của kết nối, “left” luôn đề cập đến cùng một máy, cổng “left”. (Hoặc trong trường hợp đơn giản nhất, cổng bên trái là máy duy nhất ở cuối kết nối đó.)

Sao chép khối này và sử dụng nó làm mẫu để tạo các kết nối của riêng bạn,


Thử nghiệm với ipsec.conf
Đừng cố nhận xét các dòng hiện có và thêm các dòng trùng lặp trong khi bạn thử nghiệm với ipsec.conf . IPSec sẽ không chấp nhận điều đó và sẽ đưa ra các thông báo như “Tham số không nằm trong một phần — đang hủy bỏ.” Để làm cho vấn đề tồi tệ hơn, nếu bạn khởi động IPSec bằng một tập lệnh init , bạn thậm chí không thấy những thông báo này; bạn sẽ cần kiểm tra / var / log / messages sau khi nhận được thông báo FAILED từ init script.


Các auto = tham số có thể được nhận xét ra với một trong hai add hoặc bắt đầu . Bằng cách xác định nó là add , tham số plutoload của % search về cơ bản sẽ thực hiện lệnh này:
ipsec auto –add connection-name

Nếu bạn sử dụng auto = start , kết nối sẽ không chỉ được thêm vào mà còn được khởi động. Nếu bạn muốn các kết nối đường hầm được hiển thị khi khởi động, bạn có thể nên bật cài đặt này. Nếu kết nối dành cho máy quay số, bạn có thể để nó ở dạng thêm và để những người quay số, hoặc Road Warriors, như chúng được gọi trong tài liệu FreeS / WAN, hiển thị kết nối.


Webmin Webmin cũng cung cấp giao diện thân thiện hơn với cấu hình FreeS / WAN, nhưng không phải tất cả các tính năng cấu hình đều được triển khai đầy đủ. Webmin có thể được bao gồm trong bản phân phối của bạn.


Bắt đầu và dừng
Khi bạn đã có thông tin cấu hình của mình, bạn cần tải các mô-đun hạt nhân và khởi động trình nền pluto , như sau:
khởi động cài đặt ipsec

Nếu bạn cần dừng ipsec , hãy chạy lệnh này:
dừng cài đặt ipsec

Nếu bạn cần khởi động lại ipsec , sử dụng lệnh này:
khởi động lại thiết lập ipsec Bản

phân phối của bạn cũng có thể đã thiết lập initscript trong /etc/rc.d/init.d để dừng và khởi động các dịch vụ IPSec khi khởi động và tắt máy, và bạn có thể sử dụng tập lệnh này để khởi động theo cách thủ công và dừng lại, như sau:
/etc/rc.d/init.d/ipsec start
/etc/rc.d/init.d/ipsec stop

Nếu không có kết nối nào của bạn được thiết lập để thêmhoặc bắt đầu , không có quá nhiều điều sẽ xảy ra tại thời điểm này, nhưng bạn sẽ thấy mô-đun hạt nhân, ipsec , đã được tải và trình nền pluto đang chạy. Bạn cũng nên bây giờ nhìn thấy giao diện ipsec0 khi chạy ifconfig hoặc tuyến đường và một cái gì đó như thế này từ ipsec Whack lệnh:
[root @ xoăn / root] # ipsec Whack -status
000 giao diện ipsec0 / eth0 192.168.192.3
000 
000 

Bây giờ nếu bạn thêm các kết nối, như vậy:
[root @ curl freeswan] # ipsec auto –add cur-larry,

bạn có thể sử dụng lệnh whack để xem trạng thái kết nối mới.

Cuối cùng, bạn có thể đưa kết nối lên . Cả hai bên cần thêm kết nối, nhưng chỉ một bên cần đưa nó lên .

Khi
ngắt kết nối, cả hai bên cần thực hiện bằng lệnh này: [root @ curl freeswan] # ipsec auto –down cur-larry

Đối với hai máy trên cùng một mạng không có cổng vào, các máy là mục nhập trái và phải trong ipsec.conf , và bạn có thể để trống leftsubnet, leftnexthop, rightsubnet và rightnexthop nếu không có máy trung gian nào cần thiết để định tuyến gói tin giữa hai máy. Một tệp cấu hình rất tầm thường có thể là một cái gì đó như thế này (sử dụng ví dụ bí mật tầm thường ở trên):
config setup
   # if eth0 được kết nối với lan
   interface = “ipsec0 = eth0”
   klipsdebug = none
   plutodebug = none
   plutoload =% search
   plutostart =% search
conn larry-
   cur authby = secret
   auto = add
   type = tunnel
   left = 192.168.192.2
   right = 192.168. 192,3
   keyingtries = 0
   keyexchange = ike
   keylife = 8h
   PFS = yes

Đối với một thiết lập Road Warrior với một IP động, bạn không biết số IP của máy kết nối của trước, vì vậy bạn cần để có thể xác định máy tính và thiết lập định tuyến một cách nhanh chóng. Kết nối nhanh chóng như vậy có thể đạt được với cấu hình ipsec.conf sau :

Road Warrior’sipsec.conf (đoạn trích):
conn Road-Central
       left =% defaultroute
       leftsubnet =
       leftnexthop =
       right = 172.35.55.8
       rightsubnet = 192.168.2.0 / 24
       rightnexthop = 172.35.55.1
       auto = start

Host gateway’s ipsec.conf (đoạn trích):
conn Road -Central
       left = 0.0.0.0
       leftsubnet =
       leftnexthop =
       right = 172.35.55.8
       rightsubnet = 192.168.2.0 / 24
       rightnexthop = 172.35.55.1
       auto = thêm

Nhiều biến thể khác trên các lược đồ cơ bản này tồn tại. Các FreeS / WAN tài liệubao gồm những điều này và nhiều chi tiết khác. Các kho lưu trữ danh sách gửi thư có thể tìm kiếm có giá trị vài năm cũng có sẵn, bao gồm nhiều vấn đề triển khai cụ thể. Nếu bạn gặp sự cố, hãy xem Câu hỏi thường gặp để biết nhiều vấn đề phổ biến và giải pháp.


Cần thêm thông tin?
Dưới đây là liên kết để hướng dẫn thực hiện người dùng cung cấp tốt: IPSec cấu hình thực tiễn và năng động IPSec và FreeS / WAN


Kiểm tra kết nối
Nếu đầu ra ipsec whack của bạn trông tốt, bây giờ bạn có thể kết nối với máy khác thông qua telnet hoặc bất kỳ giao thức nào khác, giống như bạn có thể trước khi thiết lập đường hầm. Sự khác biệt là bây giờ, thông tin liên lạc của bạn được mã hóa tại cổng thông qua đường hầm IPSec. Nếu bạn không thể ping máy ở đầu kia của VPN, rất có thể cấu hình của bạn đã xảy ra lỗi. Đừng để bị lừa bởi khả năng ping giữa hai máy cổng vì kết nối này không sử dụng đường hầm được mã hóa. Tham khảo Câu hỏi thường gặp đã đề cập trước đó để biết một số sự cố thường gặp.

Nếu bạn muốn kiểm tra xem các gói tin đã được mã hóa thực sự hay chưa, bạn có thể đặt một máy dò tìm trên mạng giữa các cổng và theo dõi lưu lượng bằng cách sử dụngtcpdump .


Từ tài liệu FreeS / WAN
Ngoại trừ một số thông tin tiêu đề, các gói hoàn toàn không thể hiểu được. Đầu ra của mã hóa tốt trông giống hệt như nhiễu ngẫu nhiên. Để biết thêm tài liệu về FreeS / WAN, hãy xem phần Giới thiệu về FreeS / WAN .


Bạn có thể đưa dữ liệu dễ nhận biết vào các gói ping bằng một cái gì đó như sau:
ping -p feedfacedeadbeef 11.0.1.1

Feedfacedeadbeef là một mẫu thập lục phân hợp pháp dễ dàng chọn ra từ các kết xuất hex. Nếu dữ liệu có thể nhận dạng của bạn trông giống như rác, thì kết nối của bạn thực sự được mã hóa.

Kết luận
Đây là phần giới thiệu ngắn gọn về FreeS / WAN. Mạng và VPN có nhiều dạng khác nhau, từ đơn giản đến phức tạp và việc thêm các đường hầm VPN vào hỗn hợp có thể tạo ra một số phiên khắc phục sự cố thú vị.

Các trang web đã đề cập trước đây và kho lưu trữ thư FreeS / WAN bao gồm rất nhiều ví dụ cụ thể. Rất có thể điều gì đó sẽ ở đó gần với những gì bạn đang cố gắng hoàn thành, vì vậy hãy tận dụng sự khôn ngoan của những người đã đi trước bạn. Với tư cách là quản trị viên, bạn có nghĩa vụ làm mọi thứ có thể để bảo vệ dữ liệu và thông tin liên lạc của công ty và người dùng của bạn và FreeS / WAN có thể là một công cụ khác để thêm vào kho vũ khí của bạn.

Xem bài gốc nếu việc chuyển ngữ không ổn định.

See how to put together the various pieces of the puzzle to build a FreeS/WAN VPN server on Linux.
FreeS/WAN is a Linux implementation of IPSec, the IP security protocol. IPSec implements encryption and authentication at the IP level, which allows encryption of any and all data transferred via IP, rather than just a particular higher-level protocol, as with ssh or ssl.

In this Daily Drill Down, I’ll introduce you to the technology behind FreeS/WAN as well as building the software, configuring FreeS/WAN, generating keys, starting and stopping the connections, and testing the connections.

Components and use of FreeS/WAN
The core components of FreeS/WAN include the following:

  • ·        AH (Authentication Header) provides a packet-level authentication service.
  • ·        ESP (Encapsulating Security Payload) provides encryption plus authentication.
  • ·        IKE (Internet Key Exchange) negotiates connection parameters, including keys, for the other two.
  • ·        KLIPS (kernel IPSec) implements AH, ESP, and packet handling within the kernel.
  • ·        Pluto (an IKE daemon) implements IKE, negotiating connections with other systems.
  • ·        Various scripts provide an administrator’s interface to the machinery.

IPSec optional?
IPSec is optional for IPV4, the current protocol version, but it’s required for IPV6. The FreeS/WAN project is working toward implementing IPSec for the Linux IPV6 stack.


Because IPSec is at the IP level, it can secure any type of traffic, but the two most common implementations are establishing a virtual private network (VPN) between two sites across a public network and, on a smaller scale, connecting remote laptop users to the home office across the Internet.

The IPSec protocol is designed to allow different implementations to interoperate, with the VPN Consortium working to encourage cooperation among vendors.

FreeS/WAN is known to be able to interoperate with:

  • ·        BSD IPSec
  • ·        Windows 2000 IPSec
  • ·        PGPNet
  • ·        Safenet SoftPK
  • ·        Cisco routers

An additional concept provided by FreeS/WAN is that of “opportunistic encryption,” with which any two IPSec servers can encrypt each other and will do so whenever packets pass between them. The FreeS/WAN team thinks this could encourage using encryption on most Internet traffic, should the idea catch on and network administrators implement it. The technique relies on using DNS to provide the RSA keys needed to encrypt the connection. Although I won’t be covering it further here, for more information, see the HowTo document, which covers implementation of opportunistic encryption. Of course, dynamically allocated IPs and firewalls can make IPSec implementation problematic, as it is designed for an end-to-end, fixed IP scheme, but these issues can be worked around.

Where did I leave my keys?
Like all encryption schemes, IPSec relies on the concept of keys. A key is a signature, if you will, that allows the party at the other end of the connection to know you are who you claim to be and that both parties can trust the communication. Of course, keys can be lost or stolen, and in that case, an untrusted party may tune in on the communication.

Keys can be manually transferred between networks either by encrypted mail or some other method, or the systems can be configured to generate and transfer keys automatically, replacing the keys periodically. The FreeS/WAN team recommends automatic key generation; by using this method, you’re assured that the keys will be changed at regular intervals, and any leak will only exist for a fixed period of time before the keys change. For automatic keying, either “shared secrets” or public keys must exist for the two systems to be able negotiate the secure connection.

Getting FreeS/WAN
If you’re lucky enough to be using a distribution that includes FreeS/WAN, it may be as easy as installing a package from your CD and doing a little setup work. Apparently, U.S.-based distributions cannot include it due to encryption export regulations, but several Linux distributions that are based outside of the United States include FreeS/WAN, with support built into the stock kernel. Be aware, though, that even though kernel support and the IPSec utilities are built into the distribution, they may not be fully functional. I spent several hours troubleshooting an IPSec setup until I found out in the mail archives that the distribution I was using had shipped a broken implementation.

I’ll outline the steps you would need to take to include FreeS/WAN in an existing server, as a worst-case scenario. If you already have it as a prebuilt package, you can just skip to the appropriate setup steps.

Prerequisites
As of this writing, the latest version of FreeS/WAN is 1.92. The downloaded file will be called LATEST.tar.gz and it requires:

  • ·        gcc or egcs (C compiler)
  • ·        An appropriate assembler/linker
  • ·        make and patch (compiler tools)
  • ·        glibc
  • ·        gmp (Gnu MultiPrecision Library)
  • ·        ncurses (for a friendlier, menu-based kernel config)
  • ·        Kernel source (FreeS/WAN with both 2.2 and 2.4 series kernels)

Your kernel source will normally reside in /usr/src/linux. The FreeS/WAN folks recommend untarring the FreeS/WAN tarball in /usr/src, where you will end up with the /usr/src/freeswan-version directory (with version being the version number of the FreeS/WAN source you retrieved). To do so, do the following, as root:

  • ·        Move the LATEST.tar.gz file to /usr/src
  • ·        Untar the .gz file with tar xvzf LATEST.tar.gz

Kernel
Be sure to build, install, and test your kernel before adding FreeS/WAN. For more information on compiling your kernel, take a look at Jack Wallen, Jr.’s Daily Feature ”Compiling (or recompiling) your Linux kernel.”

As a minimum, you’ll want networking support, including support for your network card. You should also probably enable:

  • ·        CONFIG_IP_ADVANCED_ROUTER=y
  • ·        CONFIG_SYSCTL=y
  • ·        CONFIG_PROC_FS=y

Editor’s note
The above options will appear as listed when running the make config command. If you’re running the make menuconfig or the make xconfig commands, you’ll be selecting them from menus.


Boot with your new kernel and make sure the underlying networking works as it should and that you can ping and access the machine at the other end of your proposed VPN without IPSec in place.

Now you can go back and build FreeS/WAN.

Building FreeS/WAN
The first step in building the application is to cd to the /usr/src/freeswan-1.9.2 directory, like so:
cd /usr/src/freeswan-1.9.2

Once you’re in that directory, run this command:
make oldgo


“Make” options
You can also use make ogomenugo, and xgo, which allow you to redo your kernel config. Oldgo just adds the FreeS/WAN options to your latest config and proceeds with the build.


At this point, you can either do make kinstall in the FreeS/WAN directory or, if you’re more comfortable doing the steps yourself, do the following:
cd ../linux
make
make install
make modules
make modules_install

Configuring FreeS/WAN
Before you begin to set up IPSec between two gateway machines, be sure to test the underlying network and make sure the machines can communicate with any software you want to wrap in the encryption. This way, you won’t waste time troubleshooting the wrong problem. You’ll need to enable IP forwarding for IPSec to work, like so:
echo 1 > /proc/sys/net/ipv4/ip_forward

To permanently enable it, typically, a setting in /etc/sysconfig/network (for Red Hat-based systems) must be changed to true, like so:
FORWARD_IPV4=false

to
FORWARD_IPV4=true

Before permanently enabling it, be sure you have appropriate firewalling set up so you’re not indiscriminately passing packets.

Generating keys
Both machines will need keys in /etc/ipsec.secrets or possibly /etc/freeswan/ipsec.secrets. If you built from the source as described previously, a set of keys should have been created for you, and if you’re using binaries from your distribution, you may have this file prepopulated also.

If you want to generate a new key pair, use the following command, where nbits equals the number of bits you want to use in the key pair (i.e., 256, 1024, 2048):
ipsec rsasigkey nbits

You’ll end up getting output something like this. You would wrap this in the following:
: RSA          {
INSERT OUTPUT OF KEY PAIR GENERATION HERE
               }

Then, cut and paste it into the ipsec.secrets file.

For testing, you could create a trivial ipsec.secrets file and not use RSA encryption, like so:
192.168.192.2 192.168.192.3: PSK “yourlittlesecret”

Final configurations
The last configurations entail editing /etc/ipsec.conf. This is prepopulated with a sample configuration, which you can copy and edit to suit your situation.

You can specify the interfaces line with an appropriate mapping, such as:
interfaces=”ipsec0=eth0″
    interfaces=”ipsec0=eth0 ipsec1=ppp0″

Or you can leave it as %defaultroute.

By default, the debugging entries are set to none. If you’re having problems, change them to all and you’ll get lots of information in /var/log/messages and /var/log/secure. Finally, a set of default values is used for all connections, if not specified in the connection block.

Note the RSA authentication block. If you just have authby=rsasig and no left/right rsasigkey entries, IPSec will expect to receive keys from DNS, and if DNS isn’t set up to send keys to IPSec, the connection will abort immediately.

You should also use something reasonable to name your connections, preferably a name that will assist you in debugging. By naming the connection something like leftmachine-rightmachine, you’ll have a reminder of what the connection is supposed to be accomplishing. Also, don’t get confused by the “left” and “right” nomenclature. No matter which end of the connection you’re configuring, “left” always refers to the same machine, the “left” gateway. (Or in the simplest case, the left gateway is the only machine at that end of the connection.)

Copy this block and use it as a template to create your own connections, giving them unique names.


Experimenting with ipsec.conf
Don’t try to comment out existing lines and add duplicate ones while you experiment with ipsec.conf. IPSec won’t tolerate it and will give messages like “Parameter is not within a section—aborting.” To make matters worse, if you start IPSec with an init script, you don’t even see these messages; you’ll need to check /var/log/messages after you get a FAILED message from the init script.


The auto= parameter can be commented out with either add or start. By defining it as add, the plutoload parameter of %search will do essentially this command:
ipsec auto –add connection-name

If you use auto=start, the connection will not only be added but will also be started up. If you want tunneled connections brought up at boot, you should probably enable this setting. If the connection is for a dial-up machine, you may want to leave it as add and let the dial-ins, or Road Warriors, as they are called in the FreeS/WAN docs, bring up the connection.


Webmin
Webmin also offers a friendlier interface to FreeS/WAN configuration, but not all of the configuration features are fully implemented. Webmin may be included with your distribution.


Starting and stopping
Once you have your configuration information in place, you need to load the kernel modules and start up the pluto daemon, like so:
ipsec setup start

If you need to stop ipsec, run this command:
ipsec setup stop

If you need to restart ipsec, use this command:
ipsec setup restart

Your distribution may also have set up an initscript in /etc/rc.d/init.d to stop and start IPSec services at boot and shutdown, and you can use this script to manually start and stop, like so:
/etc/rc.d/init.d/ipsec start
/etc/rc.d/init.d/ipsec stop

If none of your connections were set to add or start, not too much will be happening at this point, but you should see the kernel module, ipsec, loaded and the pluto daemon running. You should also now see the ipsec0 interface when running ifconfig or route and something like this from the ipsecwhack command:
[root@curly /root]# ipsec whack –status
000 interface ipsec0/eth0 192.168.192.3
000 
000 

Now if you add the connection, like so:
[root@curly freeswan]# ipsec auto –add curly-larry

you can use the whack command to see the new connection status.

Finally, you can bring the connection up. Both sides need to add the connection, but only one needs to bring it up.

When taking the connection down, both sides need to do so using this command:
[root@curly freeswan]# ipsec auto –down curly-larry

For two machines on the same network with no gateway, the machines are the left and right entries in ipsec.conf, and you can leave the leftsubnet, leftnexthop, rightsubnet, and rightnexthop blank if there are no intermediate machines required to route packets between the two machines. A very trivial configuration file could be something like this (using the trivial secrets example from above):
config setup
   # if eth0 is connected to lan
   interfaces=”ipsec0=eth0″
   klipsdebug=none
   plutodebug=none
   plutoload=%search
   plutostart=%search
conn larry-curly
   authby=secret
   auto=add
   type=tunnel
   left=192.168.192.2
   right=192.168.192.3
   keyingtries=0
   keyexchange=ike
   keylife=8h
   pfs=yes

For a Road Warrior setup with a dynamic IP, you don’t know the connecting machine’s IP number in advance, so you need to be able to identify the machine and set up the routing on the fly. Such on-the-fly connecting can be achieved with the following ipsec.conf configuration:

Road Warrior’s ipsec.conf (excerpt):
conn Road-Central
       left=%defaultroute
       leftsubnet=
       leftnexthop=
       right=172.35.55.8
       rightsubnet=192.168.2.0/24
       rightnexthop=172.35.55.1
       auto=start

Host gateway’s ipsec.conf (excerpt):
conn Road-Central
       left=0.0.0.0
       leftsubnet=
       leftnexthop=
       right=172.35.55.8
       rightsubnet=192.168.2.0/24
       rightnexthop=172.35.55.1
       auto=add

Many other variations on these basic schemes exist. The FreeS/WAN documentation covers these and many more in great detail. Several years worth of searchable mailing-list archives are available, too, which cover a lot of specific implementation issues. Should you run into a problem, see the FAQ for many of the common issues and solutions.


Need more information?
Here are links to good user-provided implementation guidelines: IPSec practical configurations and Dynamic IPSec and FreeS/WAN


Testing the connection
If your ipsec whack output looked good, you should now be able to connect to the other machine via telnet or any other protocol, just as you could before setting up the tunnel. The difference is that now, your communications are encrypted at the gateway through the IPSec tunnel. If you can’t ping the machine at the other end of the VPN, most likely something is wrong with your configuration. Don’t be misled by the ability to ping between the two gateway machines, as this connection does not use the encrypted tunnel. Refer to the FAQ mentioned earlier for a number of common problems.

If you wanted to test whether or not the packets were truly encrypted, you could put a sniffer machine on the network between the gateways and monitor the traffic using tcpdump.


From the FreeS/WAN documentation
Except for some of the header information, packets should be utterly unintelligible. The output of good encryption looks exactly like random noise. For more documentation on FreeS/WAN, take a look at the Introduction to FreeS/WAN.


You can put recognizable data in the ping packets with something like this:
ping -p feedfacedeadbeef 11.0.1.1

Feedfacedeadbeef is a legal hexadecimal pattern that is easy to pick out of hex dumps. If your recognizable data looks like garbage, your connection is truly encrypted.

Conclusion
This Daily Drill Down is a brief introduction to FreeS/WAN. Networks and VPNs come in a variety of forms, from the simple to the very complex, and adding VPN tunnels to the mix can make for some interesting troubleshooting sessions.

The sites mentioned previously and the FreeS/WAN mail archives cover a lot of specific examples. Chances are something will be there that is close to what you’re trying to accomplish, so take advantage of the wisdom of those who have walked the trail before you. It’s your obligation as an administrator to do everything you can to protect your company’s and users’ data and communications, and FreeS/WAN can be yet another tool to add to your arsenal.

Tài liệu tham khảo của PACKT OPENSWAN

Trả lời

Please log in using one of these methods to post your comment:

WordPress.com Logo

Bạn đang bình luận bằng tài khoản WordPress.com Đăng xuất /  Thay đổi )

Google photo

Bạn đang bình luận bằng tài khoản Google Đăng xuất /  Thay đổi )

Twitter picture

Bạn đang bình luận bằng tài khoản Twitter Đăng xuất /  Thay đổi )

Facebook photo

Bạn đang bình luận bằng tài khoản Facebook Đăng xuất /  Thay đổi )

Connecting to %s