ipipou: მეტი, ვიდრე უბრალოდ დაშიფრული გვირაბი

რას ვეუბნებით IPv6-ის ღმერთს?

ეს ასეა, დღეს ჩვენ იგივეს ვიტყვით დაშიფვრის ღმერთსაც.

აქ ვისაუბრებთ არადაშიფრულ IPv4 გვირაბზე, მაგრამ არა "თბილ ნათურაზე", არამედ თანამედროვე "LED"-ზე. და ასევე არის ნედლი სოკეტები, რომლებიც ციმციმებენ აქ და მიმდინარეობს მუშაობა მომხმარებლის სივრცეში პაკეტებით.

არსებობს N გვირაბის პროტოკოლები ყველა გემოვნებისა და ფერისთვის:

• მოდური, მოდური, ახალგაზრდული WireGuard
• მრავალფუნქციური, როგორიცაა შვეიცარიული დანები, OpenVPN და SSH
• ძველი და არა ბოროტი GRE
• ყველაზე მარტივი, სწრაფი, სრულიად დაშიფრული IPIP
• აქტიურად ვითარდება ჯენივე
• ბევრი სხვა.

მაგრამ მე პროგრამისტი ვარ, ამიტომ N-ს მხოლოდ წილადით გავზრდი და რეალური პროტოკოლების შემუშავებას კომერსანტის დეველოპერებს ვუტოვებ.

ერთ დაუბადებელში პროექტირასაც ახლა ვაკეთებ არის ის, რომ მივაღწიო მასპინძლებს NAT-ის უკან გარედან. ამისთვის ზრდასრულთა კრიპტოგრაფიის პროტოკოლების გამოყენებით, ვერ შევძელი განცდა, რომ ეს იყო ქვემეხიდან ბეღურების სროლა. იმიტომ რომ გვირაბი უმეტესწილად გამოიყენება მხოლოდ NAT-e-ში ხვრელების გასაკეთებლად, შიდა ტრაფიკი, როგორც წესი, ასევე დაშიფრულია, მაგრამ ისინი მაინც იხრჩობიან HTTPS-ში.

გვირაბის გაყვანის სხვადასხვა პროტოკოლების შესწავლისას, ჩემი შინაგანი პერფექციონისტის ყურადღება ისევ და ისევ მიიპყრო IPIP-ზე მისი მინიმალური ზედნადების გამო. მაგრამ მას აქვს ერთი და ნახევარი მნიშვნელოვანი ნაკლი ჩემი ამოცანებისთვის:

• ის მოითხოვს საჯარო IP-ებს ორივე მხრიდან,
• და არანაირი ავთენტიფიკაცია თქვენთვის.

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

და შემდეგ ერთ დღეს, სტატიების კითხვისას მშობლიური მხარდაჭერილი გვირაბები Linux-ში შემხვდა FOU (Foo-over-UDP), ე.ი. რაც არ უნდა იყოს, გახვეული UDP-ში. ჯერჯერობით მხარდაჭერილია მხოლოდ IPIP და GUE (Generic UDP Encapsulation).

„აი ვერცხლის ტყვია! მარტივი IPIP ჩემთვის საკმარისია“. - Ვიფიქრე.

ფაქტობრივად, ტყვია არ იყო მთლიანად ვერცხლისფერი. UDP-ში ინკაპსულაცია წყვეტს პირველ პრობლემას - შეგიძლიათ დაუკავშირდეთ NAT-ის მიღმა კლიენტებს გარედან წინასწარ დაყენებული კავშირის გამოყენებით, მაგრამ აქ IPIP-ის შემდეგი ნაკლის ნახევარი ყვავის ახალ შუქზე - ნებისმიერს კერძო ქსელიდან შეუძლია დამალვა ხილულის მიღმა. საჯარო IP და კლიენტის პორტი (სუფთა IPIP-ში ეს პრობლემა არ არსებობს).

ამ ერთნახევარი პრობლემის გადასაჭრელად შეიქმნა კომუნალური პროგრამა იპიპოუ. ის ახორციელებს სახლში შექმნილ მექანიზმს დისტანციური ჰოსტის ავთენტიფიკაციისთვის, ბირთვის FOU მუშაობის შეფერხების გარეშე, რომელიც სწრაფად და ეფექტურად დაამუშავებს პაკეტებს ბირთვის სივრცეში.

ჩვენ არ გვჭირდება თქვენი სცენარი!

კარგი, თუ იცით კლიენტის საჯარო პორტი და IP (მაგალითად, ყველა მის უკან არსად მიდის, NAT ცდილობს პორტების 1-ში 1-ში დახატვას), შეგიძლიათ შექმნათ IPIP-over-FOU გვირაბი შემდეგი ბრძანებები, ყოველგვარი სკრიპტების გარეშე.

სერვერზე:

# Подгрузить модуль ядра FOU
modprobe fou

# Создать IPIP туннель с инкапсуляцией в FOU.
# Модуль ipip подгрузится автоматически.
ip link add name ipipou0 type ipip 
    remote 198.51.100.2 local 203.0.113.1 
    encap fou encap-sport 10000 encap-dport 20001 
    mode ipip dev eth0

# Добавить порт на котором будет слушать FOU для этого туннеля
ip fou add port 10000 ipproto 4 local 203.0.113.1 dev eth0

# Назначить IP адрес туннелю
ip address add 172.28.0.0 peer 172.28.0.1 dev ipipou0

# Поднять туннель
ip link set ipipou0 up

კლიენტზე:

modprobe fou

ip link add name ipipou1 type ipip 
    remote 203.0.113.1 local 192.168.0.2 
    encap fou encap-sport 10001 encap-dport 10000 encap-csum 
    mode ipip dev eth0

# Опции local, peer, peer_port, dev могут не поддерживаться старыми ядрами, можно их опустить.
# peer и peer_port используются для создания соединения сразу при создании FOU-listener-а.
ip fou add port 10001 ipproto 4 local 192.168.0.2 peer 203.0.113.1 peer_port 10000 dev eth0

ip address add 172.28.0.1 peer 172.28.0.0 dev ipipou1

ip link set ipipou1 up

სადაც

• ipipou* — ადგილობრივი გვირაბის ქსელის ინტერფეისის სახელი
• 203.0.113.1 - საჯარო IP სერვერი
• 198.51.100.2 - კლიენტის საჯარო IP
• 192.168.0.2 — კლიენტის IP მინიჭებული ინტერფეისისთვის eth0
• 10001 - ადგილობრივი კლიენტის პორტი FOU-სთვის
• 20001 - საჯარო კლიენტის პორტი FOU-სთვის
• 10000 - საჯარო სერვერის პორტი FOU-სთვის
• encap-csum — ენკაფსულირებული UDP პაკეტებისთვის UDP გამშვები ჯამის დამატების ვარიანტი; შეიძლება შეიცვალოს noencap-csumრომ აღარაფერი ვთქვათ, მთლიანობას უკვე აკონტროლებს გარე კაფსულაციის ფენა (მაშინ როცა პაკეტი გვირაბშია)
• eth0 — ლოკალური ინტერფეისი, რომლითაც იქნება მიბმული ipip გვირაბი
• 172.28.0.1 — კლიენტის გვირაბის ინტერფეისის IP (პირადი)
• 172.28.0.0 — IP გვირაბის სერვერის ინტერფეისი (პირადი)

სანამ UDP კავშირი ცოცხალია, გვირაბი მუშა მდგომარეობაში იქნება, მაგრამ თუ გაფუჭდება, გაგიმართლებს - თუ კლიენტის IP: პორტი იგივე რჩება - იცოცხლებს, თუ შეიცვლება - გატყდება.

ყველაფრის უკან დაბრუნების უმარტივესი გზაა ბირთვის მოდულების განტვირთვა: modprobe -r fou ipip

მაშინაც კი, თუ ავთენტიფიკაცია არ არის საჭირო, კლიენტის საჯარო IP და პორტი ყოველთვის არ არის ცნობილი და ხშირად არაპროგნოზირებადი ან ცვალებადია (დამოკიდებულია NAT ტიპზე). თუ გამოტოვებთ encap-dport სერვერის მხარეს, გვირაბი არ იმუშავებს, ის საკმარისად ჭკვიანი არ არის დისტანციური კავშირის პორტის მისაღებად. ამ შემთხვევაში, ipipou-საც შეუძლია დაგეხმაროთ, ან WireGuard-მა და მისმა მსგავსებმა შეიძლება დაგეხმაროთ.

როგორ მუშაობს იგი?

კლიენტი (რომელიც ჩვეულებრივ NAT-ის უკან დგას) ხსნის გვირაბს (როგორც ზემოთ მოცემულ მაგალითში) და აგზავნის ავთენტიფიკაციის პაკეტს სერვერზე ისე, რომ მან მოახდინოს გვირაბის კონფიგურაცია თავის მხარეს. პარამეტრებიდან გამომდინარე, ეს შეიძლება იყოს ცარიელი პაკეტი (მხოლოდ იმისთვის, რომ სერვერმა დაინახოს საჯარო IP: კავშირის პორტი), ან მონაცემებით, რომლითაც სერვერს შეუძლია კლიენტის იდენტიფიცირება. მონაცემები შეიძლება იყოს მარტივი საიდუმლო ფრაზა მკაფიო ტექსტში (ანალოგია HTTP Basic Auth-თან) ან სპეციალურად შექმნილი მონაცემები, ხელმოწერილი პირადი გასაღებით (მსგავსია HTTP Digest Auth-ის მხოლოდ უფრო ძლიერი, იხილეთ ფუნქცია client_auth კოდში).

სერვერზე (საჯარო IP-ის მხარეს), როდესაც ipipou იწყება, ის ქმნის nfqueue queue handler-ს და აკონფიგურირებს ქსელის ფილტრს ისე, რომ საჭირო პაკეტები იგზავნება იქ, სადაც უნდა იყოს: პაკეტები, რომლებიც ახდენენ კავშირს nfqueue რიგთან და [თითქმის] ყველა დანარჩენი პირდაპირ მიდის მსმენელზე FOU.

მათთვის, ვინც არ იცის, nfqueue (ან NetfilterQueue) არის განსაკუთრებული რამ მოყვარულთათვის, რომლებმაც არ იციან ბირთვის მოდულების შემუშავება, რაც netfilter-ის გამოყენებით (nftables/iptables) საშუალებას გაძლევთ გადამისამართოთ ქსელის პაკეტები მომხმარებლის სივრცეში და დაამუშავოთ ისინი იქ გამოყენებით. ხელთ არსებული პრიმიტიული ნიშნავს: შეცვალეთ (სურვილისამებრ) და დააბრუნეთ იგი ბირთვში, ან გადააგდეთ იგი.

ზოგიერთი პროგრამირების ენისთვის არის შეკვრა nfqueue-სთან მუშაობისთვის, bash-ისთვის არ იყო (ჰეჰ, გასაკვირი არ არის), მე მომიწია პითონის გამოყენება: ipipou იყენებს NetfilterQueue.

თუ შესრულება არ არის კრიტიკული, ამ ნივთის გამოყენებით შეგიძლიათ შედარებით სწრაფად და მარტივად მოაწყოთ საკუთარი ლოგიკა პაკეტებთან მუშაობისთვის საკმაოდ დაბალ დონეზე, მაგალითად, შექმენით ექსპერიმენტული მონაცემთა გადაცემის პროტოკოლები, ან აკონტროლოთ ადგილობრივი და დისტანციური სერვისები არასტანდარტული ქცევით.

Raw სოკეტები მუშაობენ ხელიხელჩაკიდებულებმა nfqueue-სთან, მაგალითად, როდესაც გვირაბი უკვე კონფიგურირებულია და FOU უსმენს სასურველ პორტს, თქვენ ვერ შეძლებთ პაკეტის გაგზავნას იმავე პორტიდან ჩვეულებრივი გზით - ის დაკავებულია, მაგრამ თქვენ შეგიძლიათ აიღოთ და გაუგზავნოთ შემთხვევით გენერირებული პაკეტი პირდაპირ ქსელის ინტერფეისში ნედლეული სოკეტის გამოყენებით, თუმცა ასეთი პაკეტის გენერირებას ცოტა მეტი დამუშავება დასჭირდება. აი, როგორ იქმნება ავტორიზაციის მქონე პაკეტები ipipou-ში.

ვინაიდან ipipou ამუშავებს მხოლოდ პირველ პაკეტებს კავშირიდან (და მათ, ვინც მოახერხა რიგში გაჟონვა კავშირის დამყარებამდე), შესრულება თითქმის არ იტანჯება.

როგორც კი ipipou სერვერი მიიღებს დამოწმებულ პაკეტს, იქმნება გვირაბი და ყველა შემდგომი პაკეტი კავშირში უკვე მუშავდება ბირთვის მიერ nfqueue-ს გვერდის ავლით. თუ კავშირი ვერ მოხერხდა, მაშინ შემდეგი პაკეტის პირველი პაკეტი გაიგზავნება nfqueue რიგში, პარამეტრებიდან გამომდინარე, თუ ეს არ არის ავთენტიფიკაციის მქონე პაკეტი, მაგრამ ბოლო დამახსოვრებული IP და კლიენტის პორტიდან, მისი გადაცემა შესაძლებელია. ჩართული ან გაუქმებული. თუ ავთენტიფიცირებული პაკეტი მოდის ახალი IP-დან და პორტიდან, გვირაბი ხელახლა არის კონფიგურირებული მათი გამოსაყენებლად.

ჩვეულებრივ IPIP-over-FOU-ს აქვს კიდევ ერთი პრობლემა NAT-თან მუშაობისას - შეუძლებელია UDP-ში ჩასმული ორი IPIP გვირაბის შექმნა იგივე IP-ით, რადგან FOU და IPIP მოდულები საკმაოდ იზოლირებულია ერთმანეთისგან. იმათ. წყვილი კლიენტი ერთიდაიგივე საჯარო IP-ს უკან ვერ შეძლებს ამ გზით ერთსა და იმავე სერვერთან ერთდროულად დაკავშირებას. Მომავალში, ალბათ, ის მოგვარდება ბირთვის დონეზე, მაგრამ ეს არ არის გარკვეული. იმავდროულად, NAT პრობლემების გადაჭრა შესაძლებელია NAT-ით - თუ მოხდება, რომ IP მისამართების წყვილი უკვე დაკავებულია სხვა გვირაბით, ipipou გააკეთებს NAT-ს საჯაროდან ალტერნატიულ კერძო IP-მდე, voila! - თქვენ შეგიძლიათ შექმნათ გვირაბები პორტების ამოწურვამდე.

იმიტომ რომ კავშირის ყველა პაკეტი არ არის ხელმოწერილი, მაშინ ეს მარტივი დაცვა დაუცველია MITM-ის მიმართ, ასე რომ, თუ კლიენტსა და სერვერს შორის გზაზე იმალება ბოროტმოქმედი, რომელსაც შეუძლია ტრაფიკის მოსმენა და მისი მანიპულირება, მას შეუძლია გადამისამართოს ავტორიზებული პაკეტები. სხვა მისამართი და შექმენით გვირაბი არასანდო ჰოსტისგან.

თუ ვინმეს აქვს იდეები იმის შესახებ, თუ როგორ უნდა გამოსწორდეს ეს ტრაფიკის ძირითადი ნაწილის ბირთვში დატოვებისას, არ მოგერიდოთ საუბარი.

სხვათა შორის, ენკაფსულაცია UDP-ში ძალიან კარგად დაამტკიცა. IP-ზე ინკაფსულაციასთან შედარებით, ის ბევრად უფრო სტაბილურია და ხშირად უფრო სწრაფია UDP სათაურის დამატებითი ზედნადების მიუხედავად. ეს გამოწვეულია იმით, რომ ინტერნეტში ჰოსტების უმეტესობა კარგად მუშაობს მხოლოდ სამი ყველაზე პოპულარული პროტოკოლით: TCP, UDP, ICMP. ხელშესახებ ნაწილს შეუძლია მთლიანად გააუქმოს ყველაფერი, ან დაამუშავოს უფრო ნელა, რადგან ის ოპტიმიზებულია მხოლოდ ამ სამისთვის.

მაგალითად, ამიტომაა, რომ QUICK, რომელზედაც დაფუძნებულია HTTP/3, შეიქმნა UDP-ის თავზე და არა IP-ზე.

კარგი, საკმარისი სიტყვებია, დროა ვნახოთ, როგორ მუშაობს ეს "რეალურ სამყაროში".

ბრძოლა

გამოიყენება რეალური სამყაროს მიბაძვისთვის iperf3. რეალობასთან სიახლოვის ხარისხის თვალსაზრისით, ეს დაახლოებით იგივეა, რაც Minecraft-ში რეალური სამყაროს მიბაძვა, მაგრამ ახლა ეს ასე იქნება.

კონკურსის მონაწილეები:

• საცნობარო მთავარი არხი
• ამ სტატიის გმირი არის ipipou
• OpenVPN ავთენტიფიკაციით, მაგრამ დაშიფვრის გარეშე
• OpenVPN ყოვლისმომცველი რეჟიმში
• WireGuard PresharedKey-ის გარეშე, MTU=1440-ით (მხოლოდ IPv4-დან)

ტექნიკური მონაცემები გეკებისთვის
მეტრიკა მიიღება შემდეგი ბრძანებებით:

კლიენტზე:

UDP

CPULOG=NAME.udp.cpu.log; sar 10 6 >"$CPULOG" & iperf3 -c SERVER_IP -4 -t 60 -f m -i 10 -B LOCAL_IP -P 2 -u -b 12M; tail -1 "$CPULOG"
# Где "-b 12M" это пропускная способность основного канала, делённая на число потоков "-P", чтобы лишние пакеты не плодить и не портить производительность.

TCP

CPULOG=NAME.tcp.cpu.log; sar 10 6 >"$CPULOG" & iperf3 -c SERVER_IP -4 -t 60 -f m -i 10 -B LOCAL_IP -P 2; tail -1 "$CPULOG"

ICMP შეყოვნება

ping -c 10 SERVER_IP | tail -1

სერვერზე (აწარმოებს ერთდროულად კლიენტთან):

UDP

CPULOG=NAME.udp.cpu.log; sar 10 6 >"$CPULOG" & iperf3 -s -i 10 -f m -1; tail -1 "$CPULOG"

TCP

CPULOG=NAME.tcp.cpu.log; sar 10 6 >"$CPULOG" & iperf3 -s -i 10 -f m -1; tail -1 "$CPULOG"

გვირაბის კონფიგურაცია

იპიპოუ
სერვერზე
/etc/ipipou/server.conf:

server
number 0
fou-dev eth0
fou-local-port 10000
tunl-ip 172.28.0.0
auth-remote-pubkey-b64 eQYNhD/Xwl6Zaq+z3QXDzNI77x8CEKqY1n5kt9bKeEI=
auth-secret topsecret
auth-lifetime 3600
reply-on-auth-ok
verb 3

systemctl start ipipou@server

კლიენტი
/etc/ipipou/client.conf:

client
number 0
fou-local @eth0
fou-remote SERVER_IP:10000
tunl-ip 172.28.0.1
# pubkey of auth-key-b64: eQYNhD/Xwl6Zaq+z3QXDzNI77x8CEKqY1n5kt9bKeEI=
auth-key-b64 RuBZkT23na2Q4QH1xfmZCfRgSgPt5s362UPAFbecTso=
auth-secret topsecret
keepalive 27
verb 3

systemctl start ipipou@client

openvpn (დაშიფვრის გარეშე, ავთენტიფიკაციით)
სერვერზე

openvpn --genkey --secret ovpn.key  # Затем надо передать ovpn.key клиенту
openvpn --dev tun1 --local SERVER_IP --port 2000 --ifconfig 172.16.17.1 172.16.17.2 --cipher none --auth SHA1 --ncp-disable --secret ovpn.key

კლიენტი

openvpn --dev tun1 --local LOCAL_IP --remote SERVER_IP --port 2000 --ifconfig 172.16.17.2 172.16.17.1 --cipher none --auth SHA1 --ncp-disable --secret ovpn.key

openvpn (დაშიფვრით, ავთენტიფიკაციით, UDP-ის საშუალებით, ყველაფერი, როგორც მოსალოდნელია)
კონფიგურირებულია გამოყენებით openvpn-მართვა

მავთულის დაცვა
სერვერზე
/etc/wireguard/server.conf:

[Interface]
Address=172.31.192.1/18
ListenPort=51820
PrivateKey=aMAG31yjt85zsVC5hn5jMskuFdF8C/LFSRYnhRGSKUQ=
MTU=1440

[Peer]
PublicKey=LyhhEIjVQPVmr/sJNdSRqTjxibsfDZ15sDuhvAQ3hVM=
AllowedIPs=172.31.192.2/32

systemctl start wg-quick@server

კლიენტი
/etc/wireguard/client.conf:

[Interface]
Address=172.31.192.2/18
PrivateKey=uCluH7q2Hip5lLRSsVHc38nGKUGpZIUwGO/7k+6Ye3I=
MTU=1440

[Peer]
PublicKey=DjJRmGvhl6DWuSf1fldxNRBvqa701c0Sc7OpRr4gPXk=
AllowedIPs=172.31.192.1/32
Endpoint=SERVER_IP:51820

systemctl start wg-quick@client

დასკვნები

ნესტიანი მახინჯი ნიშანი
სერვერის CPU დატვირთვა არ არის ძალიან საჩვენებელი, რადგან... ბევრი სხვა სერვისი მუშაობს, ზოგჯერ ისინი ჭამს რესურსებს:

proto bandwidth[Mbps] CPU_idle_client[%] CPU_idle_server[%]
# 20 Mbps канал с микрокомпьютера (4 core) до VPS (1 core) через Атлантику
# pure
UDP 20.4      99.80 93.34
TCP 19.2      99.67 96.68
ICMP latency min/avg/max/mdev = 198.838/198.997/199.360/0.372 ms
# ipipou
UDP 19.8      98.45 99.47
TCP 18.8      99.56 96.75
ICMP latency min/avg/max/mdev = 199.562/208.919/220.222/7.905 ms
# openvpn0 (auth only, no encryption)
UDP 19.3      99.89 72.90
TCP 16.1      95.95 88.46
ICMP latency min/avg/max/mdev = 191.631/193.538/198.724/2.520 ms
# openvpn (full encryption, auth, etc)
UDP 19.6      99.75 72.35
TCP 17.0      94.47 87.99
ICMP latency min/avg/max/mdev = 202.168/202.377/202.900/0.451 ms
# wireguard
UDP 19.3      91.60 94.78
TCP 17.2      96.76 92.87
ICMP latency min/avg/max/mdev = 217.925/223.601/230.696/3.266 ms

## около-1Gbps канал между VPS Европы и США (1 core)
# pure
UDP 729      73.40 39.93
TCP 363      96.95 90.40
ICMP latency min/avg/max/mdev = 106.867/106.994/107.126/0.066 ms
# ipipou
UDP 714      63.10 23.53
TCP 431      95.65 64.56
ICMP latency min/avg/max/mdev = 107.444/107.523/107.648/0.058 ms
# openvpn0 (auth only, no encryption)
UDP 193      17.51  1.62
TCP  12      95.45 92.80
ICMP latency min/avg/max/mdev = 107.191/107.334/107.559/0.116 ms
# wireguard
UDP 629      22.26  2.62
TCP 198      77.40 55.98
ICMP latency min/avg/max/mdev = 107.616/107.788/108.038/0.128 ms

20 Mbps არხი

არხი 1 ოპტიმისტურ გბ/წმ-ზე

ყველა შემთხვევაში, ipipou საკმაოდ ახლოს არის საბაზო არხთან შესრულებით, რაც შესანიშნავია!

დაშიფრული openvpn გვირაბი ორივე შემთხვევაში საკმაოდ უცნაურად იქცეოდა.

თუ ვინმე აპირებს მის გამოცდას, საინტერესო იქნება გამოხმაურების მოსმენა.

შეიძლება IPv6 და NetPrickle იყოს ჩვენთან ერთად!

წყარო: www.habr.com