История изменений
Исправление nerve, (текущая версия) :
ipsec в openbsd работает так:
- ты задаешь Security Associations (SAs). это точки, между которыми будет установлен туннель.
- затем ты задаешь потоки Flows. они определяют что будет направляться в туннель, то есть между чем и чем этот туннель будет использоваться. обычно это приватные сети, которые расположены за SAs.
после настройки и запуска этого можно увидеть, как потоки. так и туннели:
# ipsecctl -sa
FLOWS:
flow esp in from 192.168.1.0/24 to 192.168.2.0/24 peer x.y.z.a type require
flow esp in from 192.168.2.0/24 to 192.168.1.0/24 peer x.y.z.a type require
SAD:
esp tunnel from x.y.z.a to a.b.c.d spi 0xblabla auth hmac-sha2-512 enc blowfish
esp tunnel from a.b.c.d to x.y.z.a spi 0xablabl auth hmac-sha2-512 enc blowfish
# netstat -rn | grep Encap -A5
Encap:
Source Port Destination Port Proto SA(Address/Proto/Type/Direction)
192.168.1.0/24 0 192.168.2.0/24 0 0 x.y.z.a/esp/require/in
192.168.2.0/24 0 192.168.1.0/24 0 0 x.y.z.a/esp/require/out
каноничное описание процесса из мана:
If we apply ESP in transport mode to the above packet, we will get: [IP header] [ESP header] [TCP header] [data...] Everything after the ESP header is protected by whatever services of ESP we are using (authentication/integrity, replay protection, confidentiality). This means the IP header itself is not protected. If we apply ESP in tunnel mode to the original packet, we would get: [IP header] [ESP header] [IP header] [TCP header] [data...] Again, everything after the ESP header is cryptographically protected. Notice the insertion of an IP header between the ESP and TCP header. This mode of operation allows us to hide who the true source and destination addresses of a packet are (since the protected and the unprotected IP headers don't have to be exactly the same). A typical application of this is in Virtual Private Networks (or VPNs), where two firewalls use IPsec to secure the traffic of all the hosts behind them. For example:
Net A <----> Firewall 1 <--- Internet ---> Firewall 2 <----> Net B
Firewall 1 and Firewall 2 can protect all communications between Net A and Net B by using IPsec in tunnel mode, as illustrated above. This implementation makes use of a virtual interface, enc0, which can be used in packet filters to specify those packets that have been or will be processed by IPsec. NAT can also be applied to enc# interfaces, but special care should be taken because of the interactions between NAT and the IPsec flow matching, especially on the packet output path. Inside the TCP/IP stack, packets go through the following stages:
UL/R -> [X] -> PF/NAT(enc0) -> IPsec -> PF/NAT(IF) -> IF UL/R <-------- PF/NAT(enc0) <- IPsec <- PF/NAT(IF) <- IF
With IF being the real interface and UL/R the Upper Layer or Routing code. The [X] stage on the output path represents the point where the packet is matched against the IPsec flow database (SPD) to determine if and how the packet has to be IPsec-processed. If, at this point, it is determined that the packet should be IPsec-processed, it is processed by the PF/NAT code. Unless PF drops the packet, it will then be IPsec-processed, even if the packet has been modified by NAT.
Исправление nerve, :
ipsec в openbsd работает так:
- ты задаешь Security Associations (SAs). это точки, между которыми будет установлен туннель.
- затем ты задаешь потоки Flows. они определяют что будет направляться в туннель, то есть между чем и чем этот туннель будет использоваться. обычно это приватные сети, которые расположены за SAs.
после настройки и запуска этого можно увидеть, как потоки. так и туннели:
# ipsecctl -sa
FLOWS:
flow esp in from 192.168.1.0/24 to 192.168.2.0/24 peer x.y.z.a type require
flow esp in from 192.168.2.0/24 to 192.168.1.0/24 peer x.y.z.a type require
SAD:
esp tunnel from x.y.z.a to a.b.c.d spi 0xblabla auth hmac-sha2-512 enc blowfish
esp tunnel from a.b.c.d to x.y.z.a spi 0xablabl auth hmac-sha2-512 enc blowfish
# netstat -rn | grep Encap -A5
Encap:
Source Port Destination Port Proto SA(Address/Proto/Type/Direction)
192.168.1.0/24 0 192.168.2.0/24 0 0 x.y.z.a/esp/require/in
192.168.2.0/24 0 192.168.1.0/24 0 0 x.y.z.a/esp/require/out
каноничное описание процесса из мана: If we apply ESP in transport mode to the above packet, we will get: [IP header] [ESP header] [TCP header] [data...] Everything after the ESP header is protected by whatever services of ESP we are using (authentication/integrity, replay protection, confidentiality). This means the IP header itself is not protected. If we apply ESP in tunnel mode to the original packet, we would get: [IP header] [ESP header] [IP header] [TCP header] [data...] Again, everything after the ESP header is cryptographically protected. Notice the insertion of an IP header between the ESP and TCP header. This mode of operation allows us to hide who the true source and destination addresses of a packet are (since the protected and the unprotected IP headers don't have to be exactly the same). A typical application of this is in Virtual Private Networks (or VPNs), where two firewalls use IPsec to secure the traffic of all the hosts behind them. For example:
Net A <----> Firewall 1 <--- Internet ---> Firewall 2 <----> Net B
Firewall 1 and Firewall 2 can protect all communications between Net A and Net B by using IPsec in tunnel mode, as illustrated above. This implementation makes use of a virtual interface, enc0, which can be used in packet filters to specify those packets that have been or will be processed by IPsec. NAT can also be applied to enc# interfaces, but special care should be taken because of the interactions between NAT and the IPsec flow matching, especially on the packet output path. Inside the TCP/IP stack, packets go through the following stages:
UL/R -> [X] -> PF/NAT(enc0) -> IPsec -> PF/NAT(IF) -> IF UL/R <-------- PF/NAT(enc0) <- IPsec <- PF/NAT(IF) <- IF
With IF being the real interface and UL/R the Upper Layer or Routing code. The [X] stage on the output path represents the point where the packet is matched against the IPsec flow database (SPD) to determine if and how the packet has to be IPsec-processed. If, at this point, it is determined that the packet should be IPsec-processed, it is processed by the PF/NAT code. Unless PF drops the packet, it will then be IPsec-processed, even if the packet has been modified by NAT.
Исходная версия nerve, :
ipsec в openbsd работает так:
- ты задаешь Security Associations (SAs). это точки, между которыми будет установлен туннель.
- затем ты задаешь потоки Flows. они определяют что будет направляться в туннель, то есть между чем и чем этот туннель будет использоваться. обычно это приватные сети, которые расположены за SAs.
после настройки и запуска этого можно увидеть, как потоки. так и туннели:
# ipsecctl -sa
FLOWS:
flow esp in from 192.168.1.0/24 to 192.168.2.0/24 peer x.y.z.a type require
flow esp in from 192.168.2.0/24 to 192.168.1.0/24 peer x.y.z.a type require
SAD:
esp tunnel from x.y.z.a to a.b.c.d spi 0xblabla auth hmac-sha2-512 enc blowfish
esp tunnel from a.b.c.d to x.y.z.a spi 0xablabl auth hmac-sha2-512 enc blowfish
# netstat -rn | grep Encap -A5
Encap:
Source Port Destination Port Proto SA(Address/Proto/Type/Direction)
192.168.1.0/24 0 192.168.2.0/24 0 0 x.y.z.a/esp/require/in
192.168.2.0/24 0 192.168.1.0/24 0 0 x.y.z.a/esp/require/out
If we apply ESP in transport mode to the above packet, we will get: [IP header] [ESP header] [TCP header] [data...] Everything after the ESP header is protected by whatever services of ESP we are using (authentication/integrity, replay protection, confidentiality). This means the IP header itself is not protected. If we apply ESP in tunnel mode to the original packet, we would get: [IP header] [ESP header] [IP header] [TCP header] [data...] Again, everything after the ESP header is cryptographically protected. Notice the insertion of an IP header between the ESP and TCP header. This mode of operation allows us to hide who the true source and destination addresses of a packet are (since the protected and the unprotected IP headers don't have to be exactly the same). A typical application of this is in Virtual Private Networks (or VPNs), where two firewalls use IPsec to secure the traffic of all the hosts behind them. For example:
Net A <----> Firewall 1 <--- Internet ---> Firewall 2 <----> Net B
Firewall 1 and Firewall 2 can protect all communications between Net A and Net B by using IPsec in tunnel mode, as illustrated above. This implementation makes use of a virtual interface, enc0, which can be used in packet filters to specify those packets that have been or will be processed by IPsec. NAT can also be applied to enc# interfaces, but special care should be taken because of the interactions between NAT and the IPsec flow matching, especially on the packet output path. Inside the TCP/IP stack, packets go through the following stages:
UL/R -> [X] -> PF/NAT(enc0) -> IPsec -> PF/NAT(IF) -> IF UL/R <-------- PF/NAT(enc0) <- IPsec <- PF/NAT(IF) <- IF
With IF being the real interface and UL/R the Upper Layer or Routing code. The [X] stage on the output path represents the point where the packet is matched against the IPsec flow database (SPD) to determine if and how the packet has to be IPsec-processed. If, at this point, it is determined that the packet should be IPsec-processed, it is processed by the PF/NAT code. Unless PF drops the packet, it will then be IPsec-processed, even if the packet has been modified by NAT.