Вопросы Теги

LibreSwan IKEv1 XAUTH VPN-сервер - так близко, но так далеко

Вот диаграмма моей ситуации в стиле ASCII 

      192.168.10.0/24
             |
  +---+  .7  |
  | A |------+                       _____
  +---+      |                      (     )
             | .254 +---+ Ext IP   (       )
             +----Ri| R |Re-------(  cloud  )
             |      +---+          (       )\      iPhone
             |        \             (_____)  \      +---+
                       \                      ------|   |
                        \                           | B |
                         \           192.168.11.80  |   |
                          +------VPN-Tunnel---------|   |
                             IKEv1 XAUTH with PSK   +---+

Legend:
   A  - Windows 7
   R  - CentOS 6.9 acting as a router and iptables firewall,
        with LibreSwan installed
   Ri - Internal interface of R
   Re - External interface of R
   B  - An iPhone SE with iOS 10 configured to use what Apple
        calls "IPSEC" (Cisco) VPN

System R уже много лет является работающим межсетевым экраном маршрутизатора / iptables в режиме моста.

Мне нужно иметь возможность использовать клиент удаленного рабочего стола MS для iOS для входа в систему A с устройства iOS B и решил настроить VPN-сервер на R.

Вы вполне можете спросить «Почему бы просто не использовать SSH-клиент с переадресацией портов вместо этого». ? У вас был бы действительно хороший аргумент, и это то, что я делал раньше, но где-то около iOS 6 Apple перестала разрешать фоновым приложениям поддерживать сетевые соединения открытыми, что сделало фоновый туннель SSH невозможным. Ни один из текущих SSH-клиентов, которые утверждают, что поддерживает переадресацию портов, не может поддерживать соединение открытым в фоновом режиме более 90 секунд, поэтому для достижения моей цели требуется VPN.

Я настроил все, используя инструкции из LibreSwan

Сводка проблемы

VPN-соединение работает нормально, но маршрутизация от B к A кажется прерванной, в то время как все остальное, включая маршрутизацию от A к B, похоже, работает.

Ping Matrix 

            To
           A  Ri  Re  B
        A  -  y   y   y
  From  R  y  -   -   y
        B  N  y   y   -

Другими словами, каждый может пинговать всех, КРОМЕ B не может пинговать но где-то около iOS 6 Apple перестала разрешать фоновым приложениям сохранять сетевые соединения открытыми, что сделало фоновый SSH-туннель невозможным. Ни один из текущих SSH-клиентов, которые утверждают, что поддерживает переадресацию портов, не может поддерживать соединение открытым в фоновом режиме более 90 секунд, поэтому для достижения моей цели требуется VPN.

Я настроил все, используя инструкции из LibreSwan

Сводка проблемы

VPN-соединение работает нормально, но маршрутизация от B к A кажется прерванной, в то время как все остальное, включая маршрутизацию от A к B, похоже, работает.

Ping Matrix 

            To
           A  Ri  Re  B
        A  -  y   y   y
  From  R  y  -   -   y
        B  N  y   y   -

Другими словами, каждый может пинговать всех, ЗА ИСКЛЮЧЕНИЕМ B не может пинговать но где-то около iOS 6 Apple перестала разрешать фоновым приложениям сохранять сетевые соединения открытыми, что сделало фоновый SSH-туннель невозможным. Ни один из текущих SSH-клиентов, которые утверждают, что поддерживает переадресацию портов, не может поддерживать соединение открытым в фоновом режиме более 90 секунд, поэтому для достижения моей цели требуется VPN.

Я настроил все, используя инструкции из LibreSwan

Сводка проблемы

VPN-соединение работает нормально, но маршрутизация от B к A кажется прерванной, в то время как все остальное, включая маршрутизацию от A к B, похоже, работает.

Ping Matrix 

            To
           A  Ri  Re  B
        A  -  y   y   y
  From  R  y  -   -   y
        B  N  y   y   -

Другими словами, каждый может пинговать всех, КРОМЕ B не может пинговать кто-либо в сети 192.168.10.0/24, но все еще может ping внутренний сетевой адрес R.

Вот ipsec.conf : 

config setup
        protostack=netkey

        logfile=/var/log/pluto.log

        interfaces="%defaultroute"
        dumpdir=/var/run/pluto/
        nat_traversal=yes
        virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12,%v4:25.0.0.0/8,%v4:100.64.0.0/10,%v6:fd00::/8,%v6:fe80::/10,%v4:!192.168.10.0/24
        keep_alive=60

conn xauth-psk
    authby=secret
    pfs=no
    auto=add
    rekey=no
    left=%defaultroute
    leftsubnet=0.0.0.0/0
    rightaddresspool=192.168.11.80-192.168.11.90
    right=%any
    cisco-unity=yes
    modecfgdns1=192.168.10.254
    leftxauthserver=yes
    rightxauthclient=yes
    leftmodecfgserver=yes
    rightmodecfgclient=yes
    modecfgpull=yes
    xauthby=file
    ike-frag=yes
    ikev2=never

Вывод ipsec verify : 

Verifying installed system and configuration files

Version check and ipsec on-path                         [OK]
Libreswan 3.15 (netkey) on 2.6.32-696.10.1.el6.x86_64
Checking for IPsec support in kernel                    [OK]
 NETKEY: Testing XFRM related proc values
         ICMP default/send_redirects                    [OK]
         ICMP default/accept_redirects                  [OK]
         XFRM larval drop                               [OK]
Pluto ipsec.conf syntax                                 [OK]
Hardware random device                                  [N/A]
Two or more interfaces found, checking IP forwarding    [OK]
Checking rp_filter                                      [OK]
Checking that pluto is running                          [OK]
 Pluto listening for IKE on udp 500                     [OK]
 Pluto listening for IKE/NAT-T on udp 4500              [OK]
 Pluto ipsec.secret syntax                              [OK]
Checking 'ip' command                                   [OK]
Checking 'iptables' command                             [OK]
Checking 'prelink' command does not interfere with FIPSChecking for obsolete ipsec.conf options                 [OK]
Opportunistic Encryption                                [DISABLED]

Вывод ipsec look : 

janus.localdomain Thu Sep  7 20:01:38 PDT 2017
XFRM state:
src xxx.xxx.45.71 dst xxx.xxx.94.61
        proto esp spi 0xde18dd2e reqid 16397 mode tunnel
        replay-window 32 flag 20
        auth hmac(sha1) 0x23faf136fcde2c1b8c31f4cc9fea0003fa2985d2
        enc cbc(aes) 0x04c42120ad0357f2406c5a9fdfe3f5ad8fcc45c3ed3aa69aeb1f010f996e3a10
        encap type espinudp sport 42703 dport 4500 addr 0.0.0.0
src xxx.xxx.94.61 dst xxx.xxx.45.71
        proto esp spi 0x0aa354d9 reqid 16397 mode tunnel
        replay-window 32 flag 20
        auth hmac(sha1) 0x3ecfa164b8455dfca08b985c8e1b326adba2fa2a
        enc cbc(aes) 0xb81e5bfa39b63e493fcce3b2104ee5f2dd2f81fe8a45ec7665dd182493e525f9
        encap type espinudp sport 4500 dport 42703 addr 0.0.0.0
XFRM policy:
src 0.0.0.0/0 dst 192.168.11.80/32
        dir out priority 3104 ptype main
        tmpl src xxx.xxx.94.61 dst xxx.xxx.45.71
                proto esp reqid 16397 mode tunnel
src 192.168.11.80/32 dst 0.0.0.0/0
        dir fwd priority 3104 ptype main
        tmpl src xxx.xxx.45.71 dst xxx.xxx.94.61
                proto esp reqid 16397 mode tunnel
src 192.168.11.80/32 dst 0.0.0.0/0
        dir in priority 3104 ptype main
        tmpl src xxx.xxx.45.71 dst xxx.xxx.94.61
                proto esp reqid 16397 mode tunnel
src ::/0 dst ::/0 proto ipv6-icmp type 135
        dir fwd priority 1 ptype main
src ::/0 dst ::/0 proto ipv6-icmp type 135
        dir in priority 1 ptype main
src ::/0 dst ::/0 proto ipv6-icmp type 136
        dir out priority 1 ptype main
src ::/0 dst ::/0 proto ipv6-icmp type 136
        dir fwd priority 1 ptype main
src ::/0 dst ::/0 proto ipv6-icmp type 136
        dir in priority 1 ptype main
src ::/0 dst ::/0 proto ipv6-icmp type 135
        dir out priority 1 ptype main
src ::/0 dst ::/0
        dir 4 priority 0 ptype main
src ::/0 dst ::/0
        dir 3 priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
        dir 4 priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
        dir 3 priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
        dir 4 priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
        dir 3 priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
        dir 4 priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
        dir 3 priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
        dir 4 priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
        dir 3 priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
        dir 4 priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
        dir 3 priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
        dir 4 priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
        dir 3 priority 0 ptype main
XFRM done
IPSEC mangle TABLES
NEW_IPSEC_CONN mangle TABLES
ROUTING TABLES
192.168.10.0/24 dev eth0  proto kernel  scope link  src 192.168.10.254
xxx.xxx.45.0/21 dev eth1  proto kernel  scope link  src xxx.xxx.94.61
169.254.0.0/16 dev eth0  scope link  metric 1002
169.254.0.0/16 dev eth1  scope link  metric 1003
default via xxx.xxx.45.1 dev eth1
unreachable ::/96 dev lo  metric 1024  error -113 mtu 65536
unreachable ::ffff:0.0.0.0/96 dev lo  metric 1024  error -113 mtu 65536
unreachable 2002:a00::/24 dev lo  metric 1024  error -113 mtu 65536
unreachable 2002:7f00::/24 dev lo  metric 1024  error -113 mtu 65536
unreachable 2002:a9fe::/32 dev lo  metric 1024  error -113 mtu 65536
unreachable 2002:ac10::/28 dev lo  metric 1024  error -113 mtu 65536
unreachable 2002:c0a8::/32 dev lo  metric 1024  error -113 mtu 65536
unreachable 2002:e000::/19 dev lo  metric 1024  error -113 mtu 65536
unreachable 3ffe:ffff::/32 dev lo  metric 1024  error -113 mtu 65536
fe80::/64 dev eth0  proto kernel  metric 256  mtu 1500
fe80::/64 dev eth1  proto kernel  metric 256  mtu 1500
NSS_CERTIFICATES

Certificate Nickname                                         Trust Attributes
                                                             SSL,S/MIME,JAR/XPI

pluto.log записи для соединения 

Sep  7 20:14:39: packet from xxx.xxx.45.71:18317: received Vendor ID payload [RFC 3947]
Sep  7 20:14:39: packet from xxx.xxx.45.71:18317: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike]
Sep  7 20:14:39: packet from xxx.xxx.45.71:18317: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-08]
Sep  7 20:14:39: packet from xxx.xxx.45.71:18317: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-07]
Sep  7 20:14:39: packet from xxx.xxx.45.71:18317: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-06]
Sep  7 20:14:39: packet from xxx.xxx.45.71:18317: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-05]
Sep  7 20:14:39: packet from xxx.xxx.45.71:18317: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-04]
Sep  7 20:14:39: packet from xxx.xxx.45.71:18317: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03]
Sep  7 20:14:39: packet from xxx.xxx.45.71:18317: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02]
Sep  7 20:14:39: packet from xxx.xxx.45.71:18317: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n]
Sep  7 20:14:39: packet from xxx.xxx.45.71:18317: received Vendor ID payload [XAUTH]
Sep  7 20:14:39: packet from xxx.xxx.45.71:18317: received Vendor ID payload [Cisco-Unity]
Sep  7 20:14:39: packet from xxx.xxx.45.71:18317: received Vendor ID payload [FRAGMENTATION 80000000]
Sep  7 20:14:39: packet from xxx.xxx.45.71:18317: received Vendor ID payload [Dead Peer Detection]
Sep  7 20:14:39: "xauth-psk"[7] xxx.xxx.45.71 #5: enabling possible NAT-traversal with method RFC 3947 (NAT-Traversal)
Sep  7 20:14:39: "xauth-psk"[7] xxx.xxx.45.71 #5: responding to Main Mode from unknown peer xxx.xxx.45.71
Sep  7 20:14:39: "xauth-psk"[7] xxx.xxx.45.71 #5: transition from state STATE_MAIN_R0 to state STATE_MAIN_R1
Sep  7 20:14:39: "xauth-psk"[7] xxx.xxx.45.71 #5: STATE_MAIN_R1: sent MR1, expecting MI2
Sep  7 20:14:39: "xauth-psk"[7] xxx.xxx.45.71 #5: NAT-Traversal: Result using RFC 3947 (NAT-Traversal) sender port 18317: peer be
hind NAT
Sep  7 20:14:39: "xauth-psk"[7] xxx.xxx.45.71 #5: transition from state STATE_MAIN_R1 to state STATE_MAIN_R2
Sep  7 20:14:39: "xauth-psk"[7] xxx.xxx.45.71 #5: STATE_MAIN_R2: sent MR2, expecting MI3
Sep  7 20:14:39: "xauth-psk"[7] xxx.xxx.45.71 #5: ignoring informational payload IPSEC_INITIAL_CONTACT, msgid=00000000, length=28
Sep  7 20:14:39: | ISAKMP Notification Payload
Sep  7 20:14:39: |   00 00 00 1c  00 00 00 01  01 10 60 02
Sep  7 20:14:39: "xauth-psk"[7] xxx.xxx.45.71 #5: Main mode peer ID is ID_IPV4_ADDR: '10.148.35.161'
Sep  7 20:14:39: "xauth-psk"[7] xxx.xxx.45.71 #5: switched from "xauth-psk"[7] xxx.xxx.45.71 to "xauth-psk"
Sep  7 20:14:39: "xauth-psk"[8] xxx.xxx.45.71 #5: deleting connection "xauth-psk" instance with peer xxx.xxx.45.71 {isakmp=#0/ip
sec=#0}
Sep  7 20:14:39: "xauth-psk"[8] xxx.xxx.45.71 #5: transition from state STATE_MAIN_R2 to state STATE_MAIN_R3
Sep  7 20:14:39: "xauth-psk"[8] xxx.xxx.45.71 #5: new NAT mapping for #5, was xxx.xxx.45.71:18317, now xxx.xxx.45.71:42703
Sep  7 20:14:39: "xauth-psk"[8] xxx.xxx.45.71 #5: STATE_MAIN_R3: sent MR3, ISAKMP SA established {auth=PRESHARED_KEY cipher=aes_2
56 integ=OAKLEY_SHA2_256 group=MODP2048}
Sep  7 20:14:39: | event EVENT_v1_SEND_XAUTH #5 STATE_MAIN_R3
Sep  7 20:14:39: "xauth-psk"[8] xxx.xxx.45.71 #5: XAUTH: Sending Username/Password request (XAUTH_R0)
Sep  7 20:14:54: XAUTH: User jhg: Attempting to login
Sep  7 20:14:54: XAUTH: passwd file authentication being called to authenticate user jhg
Sep  7 20:14:54: XAUTH: password file (/etc/ipsec.d/passwd) open.
Sep  7 20:14:54: XAUTH: checking user(jhg:xauth-psk)
Sep  7 20:14:54: XAUTH: User jhg: Authentication Successful
Sep  7 20:14:55: "xauth-psk"[8] xxx.xxx.45.71 #5: XAUTH: xauth_inR1(STF_OK)
Sep  7 20:14:55: "xauth-psk"[8] xxx.xxx.45.71 #5: transition from state STATE_XAUTH_R1 to state STATE_MAIN_R3
Sep  7 20:14:55: "xauth-psk"[8] xxx.xxx.45.71 #5: STATE_MAIN_R3: sent MR3, ISAKMP SA established
Sep  7 20:14:55: "xauth-psk"[8] xxx.xxx.45.71 #5: Unsupported modecfg long attribute INTERNAL_ADDRESS_EXPIRY received.
Sep  7 20:14:55: "xauth-psk"[8] xxx.xxx.45.71 #5: Unsupported modecfg long attribute APPLICATION_VERSION received.
Sep  7 20:14:55: "xauth-psk"[8] xxx.xxx.45.71 #5: Unsupported modecfg long attribute MODECFG_BANNER received.
Sep  7 20:14:55: "xauth-psk"[8] xxx.xxx.45.71 #5: Unsupported modecfg long attribute MODECFG_DOMAIN received.
Sep  7 20:14:55: "xauth-psk"[8] xxx.xxx.45.71 #5: Unsupported modecfg long attribute CISCO_SPLIT_DNS received.
Sep  7 20:14:55: "xauth-psk"[8] xxx.xxx.45.71 #5: Unsupported modecfg long attribute CISCO_SPLIT_INC received.
Sep  7 20:14:55: "xauth-psk"[8] xxx.xxx.45.71 #5: Unsupported modecfg long attribute CISCO_SPLIT_EXCLUDE received.
Sep  7 20:14:55: "xauth-psk"[8] xxx.xxx.45.71 #5: Unsupported modecfg long attribute CISCO_DO_PFS received.
Sep  7 20:14:55: "xauth-psk"[8] xxx.xxx.45.71 #5: Unsupported modecfg long attribute CISCO_SAVE_PW received.
Sep  7 20:14:55: "xauth-psk"[8] xxx.xxx.45.71 #5: Unsupported modecfg long attribute CISCO_FW_TYPE received.
Sep  7 20:14:55: "xauth-psk"[8] xxx.xxx.45.71 #5: Unsupported modecfg long attribute CISCO_BACKUP_SERVER received.
Sep  7 20:14:55: "xauth-psk"[8] xxx.xxx.45.71 #5: Unsupported modecfg long attribute CISCO_UNKNOWN_SEEN_ON_IPHONE received.
Sep  7 20:14:55: "xauth-psk"[8] xxx.xxx.45.71 #5: modecfg_inR0(STF_OK)
Sep  7 20:14:55: "xauth-psk"[8] xxx.xxx.45.71 #5: transition from state STATE_MODE_CFG_R0 to state STATE_MODE_CFG_R1
Sep  7 20:14:55: "xauth-psk"[8] xxx.xxx.45.71 #5: STATE_MODE_CFG_R1: ModeCfg Set sent, expecting Ack
Sep  7 20:14:55: "xauth-psk"[8] xxx.xxx.45.71 #5: the peer proposed: 0.0.0.0/0:0/0 -> 192.168.11.80/32:0/0
Sep  7 20:14:55: "xauth-psk"[8] xxx.xxx.45.71 #6: responding to Quick Mode proposal {msgid:9b886838}
Sep  7 20:14:55: "xauth-psk"[8] xxx.xxx.45.71 #6:     us: 0.0.0.0/0===xxx.xxx.94.61[MS+XS+S=C]
Sep  7 20:14:55: "xauth-psk"[8] xxx.xxx.45.71 #6:   them: xxx.xxx.45.71[10.148.35.161,+MC+XC+S=C]===192.168.11.80/32
Sep  7 20:14:55: "xauth-psk"[8] xxx.xxx.45.71 #6: transition from state STATE_QUICK_R0 to state STATE_QUICK_R1
Sep  7 20:14:55: "xauth-psk"[8] xxx.xxx.45.71 #6: STATE_QUICK_R1: sent QR1, inbound IPsec SA installed, expecting QI2 tunnel mode
 {ESP/NAT=>0x0e7958fe <0xbbd3b5cf xfrm=AES_256-HMAC_SHA1 NATOA=none NATD=xxx.xxx.45.71:42703 DPD=passive XAUTHuser=jhg}
Sep  7 20:14:55: "xauth-psk"[8] xxx.xxx.45.71 #6: transition from state STATE_QUICK_R1 to state STATE_QUICK_R2
Sep  7 20:14:55: "xauth-psk"[8] xxx.xxx.45.71 #6: STATE_QUICK_R2: IPsec SA established tunnel mode {ESP/NAT=>0x0e7958fe <0xbbd3b5
cf xfrm=AES_256-HMAC_SHA1 NATOA=none NATD=xxx.xxx.45.71:42703 DPD=passive XAUTHuser=jhg}

Подведем итог: VPN подключается и аутентифицирует OK, никаких ошибок или чего-либо подозрительного в pluto.log или / var / log / secure , но клиент B не может перенаправить свои пакеты в подсеть A, хотя хост A может пинговать B.

Я попытался изменить строку interfaces в ʻipsec. conf 'на 

    interfaces="%defaultroute ipsec0=eth0"

, но это не повлияло и не привело к созданию интерфейса с именем ipsec0 .

Вопрос

Что мне нужно изменить в моей конфигурации, чтобы маршрутизация работала правильно, чтобы B мог связываться с хостами во внутренней подсети?

Дополнительное примечание / Дополнительная информация

Я заметил, что маршрутизация пакетов к удаленному VPN-клиенту и от него, похоже, не включает обычные механизмы маршрутизации. Не существует адаптеров ipsecn , показанных командой ip , поэтому я думаю, что пока не понимаю, как взаимодействуют ipsec и маршрутизация.

Маршрутизатор / брандмауэр R включил маскировку для исходящего трафика:

iptables-restore Раздел таблицы NAT ( eth1 - внешний адаптер) 

*nat
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A POSTROUTING -o eth1 -j MASQUERADE

iptables-restore входной фильтр : 

*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]

-A INPUT   -i lo   -j ACCEPT
-A INPUT   -i eth0 -j ACCEPT
-A INPUT   -i eth1 -j INPUT_FILTER

:INPUT_FILTER - [0:0]
-A INPUT_FILTER -m state --state ESTABLISHED,RELATED -j ACCEPT
-A INPUT_FILTER -p udp --dport  500 -j ACCEPT
-A INPUT_FILTER -p udp --dport 1701 -j ACCEPT
-A INPUT_FILTER -p udp --dport 4500 -j ACCEPT
-A INPUT_FILTER -p udp -m policy --dir in --pol ipsec -m udp --dport 1701 -j ACCEPT
-A INPUT_FILTER -p 50 -j ACCEPT
-A INPUT_FILTER -p 51 -j ACCEPT
-A INPUT_FILTER -j DROP

Но поскольку нет адаптеров VPN, я не уверен, что бы здесь изменить.

1
задан 8 September 2017 в 20:22
1 ответ

Решение этой проблемы демонстрирует критическую важность наличия правильной ментальной модели происходящего.

Проще говоря, туннель ipsec работал просто отлично, но мне нужно было настроить некоторые правила брандмауэра как на маршрутизаторе (R выше), так и на Windows-машине (A выше).

Я предполагал/догадывался, что ipsec предоставляет некий виртуальный сетевой интерфейс для представления туннеля, но по каким-то причинам я не мог его увидеть, и не знал, где его найти. В конце концов я нашел команду

ipsec_tncfg (5) - lists IPSEC virtual interfaces attached to real interfaces

но запуск дал

[jhg@janus ~]$ sudo ipsec tncfg
/usr/libexec/ipsec/tncfg: NETKEY does not support virtual interfaces.

После некоторого методического анализа потока пакетов у меня появилось озарение:

ipsec полностью скрывает себя, и весь туннельный трафик выглядит так, как будто он поступает из внешнего мира, но с адресами частных источников RFC-1918.

Обычно вы никогда не увидите входящий трафик с адресом источника RFC-1918, и моя цепочка iptables FORWARD была настроена на бесшумное бросание всего, что не было -состоянием RELATED,ESTABLISHED.

Итак, Простой ответ - добавить в цепочку FORWARD правило, позволяющее пересылать пакеты из диапазона адресного пула. В формате iptables- restore:

# THIS IS A TEMPORARY HACK TO DEMONSTRATE THAT IT FIXES THE ISSUE
# IN A PRODUCTION ENVIRONMENT THIS WOULD BE A SECURITY RISK
-A FORWARD_FILTER -i eth1 -s 192.168.11.64/26 -o eth0 -d 192.168.10.0/24 -j ACCEPT

я понимаю, что это относительно небольшой (но ненулевой) риск для безопасности, так как теперь он позволяет кому-то разместить неавторизованный хост в подсети у моего провайдера, настроенный в диапазоне 192.168.11.64/26, и пройти мимо моего брандмауэра. Я также знаю, что в iptables есть возможность ограничить эту дыру только ipsec (--m policy --pol ipsec ...), но я должен прочитать man-страницу и провести некоторые исследования. Если я не могу заставить это работать, это отдельный вопрос. Когда он заработает, я вернусь и обновлю ответ.

Это не совсем сработало, пакеты теперь доходили до хоста А, но на них не было ответа. Но это было легко объяснить, потому что Windows Firewall не распознавал подсеть адресного пула, поэтому добавление правила брандмауэра там, наконец, заставило все работать, как и ожидалось.

Далее нужно переместить адресный пул на наложение части внутренней подсети локальной сети, чтобы я мог обойтись без правила Windows Firewall. Но это на другой день.

0
ответ дан 4 December 2019 в 04:38

Теги

Похожие вопросы