Konstantin Matyukhin -> list @ Thu, 24 Aug 2017 10:40:03 +0200:
> Ох, извини. Я все перепутал. В stretch пришлось патчить. В jessie как раз
> все работает.
Не получается... Я сейчас покажу конфиги и чуть-чуть логи, вдруг
понятно, что не так? На самом деле уверенности в том, что на том конце
ожидают именно этого, нет. Винда работает, но что там себе думает
винда... sensitive parts replaced, разумеется.
/etc/ipsec.conf, по документации от StrongSwan:
config setup
conn krys
fragmentation=yes
dpdaction=restart
keyexchange=ikev1
type=transport
right=x.y.z.t
rightsubnet=%dynamic[/1701]
leftauth=psk
rightauth=psk
auto=add
/etc/ipsec.secrets:
x.y.z.t : PSK "********"
Тут интересно, что конструкция не видит PSK, приписанную к имени хоста,
если имя в адрес резолвится, а обратно, нет. Некоторое время долбился об
это.
После ipsec start в логе
Aug 29 20:02:05 silver charon: 00[DMN] Starting IKE charon daemon (strongSwan
5.2.1, Linux 3.16.0-4-amd64, x86_64)
Aug 29 20:02:05 silver charon: 00[CFG] loading ca certificates from
'/etc/ipsec.d/cacerts'
Aug 29 20:02:05 silver charon: 00[CFG] loading aa certificates from
'/etc/ipsec.d/aacerts'
Aug 29 20:02:05 silver charon: 00[CFG] loading ocsp signer certificates from
'/etc/ipsec.d/ocspcerts'
Aug 29 20:02:05 silver charon: 00[CFG] loading attribute certificates from
'/etc/ipsec.d/acerts'
Aug 29 20:02:05 silver charon: 00[CFG] loading crls from '/etc/ipsec.d/crls'
Aug 29 20:02:05 silver charon: 00[CFG] loading secrets from '/etc/ipsec.secrets'
Aug 29 20:02:05 silver charon: 00[CFG] loaded IKE secret for x.y.z.t
Aug 29 20:02:05 silver charon: 00[LIB] loaded plugins: charon aes rc2 sha1 sha2
md5 random nonce x509 revocation const
raints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl fips-prf
gmp agent xcbc hmac gcm attr kernel-netlink resolve socket-default stroke updown
Aug 29 20:02:05 silver charon: 00[LIB] unable to load 3 plugin features (3 due
to unmet dependencies)
Aug 29 20:02:05 silver charon: 00[LIB] dropped capabilities, running as uid 0,
gid 0
Aug 29 20:02:05 silver charon: 00[JOB] spawning 16 worker threads
Aug 29 20:02:05 silver charon: 16[CFG] received stroke: add connection 'krys'
Aug 29 20:02:05 silver charon: 16[CFG] left nor right host is our side,
assuming left=local
Aug 29 20:02:05 silver charon: 16[CFG] added configuration 'krys'
С виду вроде нормально.
После ipsec up krys в терминале
initiating Main Mode IKE_SA krys[1] to x.y.z.t
generating ID_PROT request 0 [ SA V V V V V ]
sending packet: from 192.168.4.13[500] to x.y.z.t[500] (272 bytes)
received packet: from x.y.z.t[500] to 192.168.4.13[500] (124 bytes)
parsed ID_PROT response 0 [ SA V V ]
received DPD vendor ID
received NAT-T (RFC 3947) vendor ID
generating ID_PROT request 0 [ KE No NAT-D NAT-D ]
sending packet: from 192.168.4.13[500] to x.y.z.t[500] (372 bytes)
received packet: from x.y.z.t[500] to 192.168.4.13[500] (356 bytes)
parsed ID_PROT response 0 [ KE No NAT-D NAT-D ]
local host is behind NAT, sending keep alives
generating ID_PROT request 0 [ ID HASH ]
sending packet: from 192.168.4.13[4500] to x.y.z.t[4500] (76 bytes)
received packet: from x.y.z.t[4500] to 192.168.4.13[4500] (92 bytes)
parsed ID_PROT response 0 [ ID HASH N(INITIAL_CONTACT) ]
IKE_SA krys[1] established between 192.168.4.13[192.168.4.13]...x.y.z.t[x.y.z.t]
scheduling reauthentication in 10161s
maximum IKE_SA lifetime 10701s
generating QUICK_MODE request 2738774603 [ HASH SA No ID ID NAT-OA NAT-OA ]
sending packet: from 192.168.4.13[4500] to x.y.z.t[4500] (252 bytes)
received packet: from x.y.z.t[4500] to 192.168.4.13[4500] (156 bytes)
parsed QUICK_MODE response 2738774603 [ HASH SA No ID ID ]
CHILD_SA krys{1} established with SPIs c7e58289_i 7ae4a942_o and TS
192.168.4.13/32 === x.y.z.t/32[l2f]
connection 'krys' established successfully
в логе
Aug 29 20:02:16 silver charon: 11[CFG] received stroke: initiate 'krys'
Aug 29 20:02:16 silver charon: 13[IKE] initiating Main Mode IKE_SA krys[1] to
x.y.z.t
Aug 29 20:02:16 silver charon: 13[ENC] generating ID_PROT request 0 [ SA V V V
V V ]
Aug 29 20:02:16 silver charon: 13[NET] sending packet: from 192.168.4.13[500]
to x.y.z.t[500] (272 bytes)
Aug 29 20:02:16 silver charon: 08[NET] received packet: from x.y.z.t[500] to
192.168.4.13[500] (124 bytes)
Aug 29 20:02:16 silver charon: 08[ENC] parsed ID_PROT response 0 [ SA V V ]
Aug 29 20:02:16 silver charon: 08[IKE] received DPD vendor ID
Aug 29 20:02:16 silver charon: 08[IKE] received NAT-T (RFC 3947) vendor ID
Aug 29 20:02:16 silver charon: 08[ENC] generating ID_PROT request 0 [ KE No
NAT-D NAT-D ]
Aug 29 20:02:16 silver charon: 08[NET] sending packet: from 192.168.4.13[500]
to x.y.z.t[500] (372 bytes)
Aug 29 20:02:17 silver charon: 14[NET] received packet: from x.y.z.t[500] to
192.168.4.13[500] (356 bytes)
Aug 29 20:02:17 silver charon: 14[ENC] parsed ID_PROT response 0 [ KE No NAT-D
NAT-D ]
Aug 29 20:02:17 silver charon: 14[IKE] local host is behind NAT, sending keep
alives
Aug 29 20:02:17 silver charon: 14[ENC] generating ID_PROT request 0 [ ID HASH ]
Aug 29 20:02:17 silver charon: 14[NET] sending packet: from 192.168.4.13[4500]
to x.y.z.t[4500] (76 bytes)
Aug 29 20:02:17 silver charon: 01[NET] received packet: from x.y.z.t[4500] to
192.168.4.13[4500] (92 bytes)
Aug 29 20:02:17 silver charon: 01[ENC] parsed ID_PROT response 0 [ ID HASH
N(INITIAL_CONTACT) ]
Aug 29 20:02:17 silver charon: 01[IKE] IKE_SA krys[1] established between
192.168.4.13[192.168.4.13]...x.y.z.t[x.y.z.t]
Aug 29 20:02:17 silver charon: 01[IKE] scheduling reauthentication in 10161s
Aug 29 20:02:17 silver charon: 01[IKE] maximum IKE_SA lifetime 10701s
Aug 29 20:02:17 silver charon: 01[ENC] generating QUICK_MODE request 2738774603
[ HASH SA No ID ID NAT-OA NAT-OA ]
Aug 29 20:02:17 silver charon: 01[NET] sending packet: from 192.168.4.13[4500]
to x.y.z.t[4500] (252 bytes)
Aug 29 20:02:17 silver charon: 15[NET] received packet: from x.y.z.t[4500] to
192.168.4.13[4500] (156 bytes)
Aug 29 20:02:17 silver charon: 15[ENC] parsed QUICK_MODE response 2738774603 [
HASH SA No ID ID ]
Aug 29 20:02:17 silver charon: 15[IKE] CHILD_SA krys{1} established with SPIs
c7e58289_i 7ae4a942_o and TS 192.168.4.13/32 === x.y.z.t/32[l2f]
Aug 29 20:02:17 silver charon: 15[ENC] generating QUICK_MODE request 2738774603
[ HASH ]
Aug 29 20:02:17 silver charon: 15[NET] sending packet: from 192.168.4.13[4500]
to x.y.z.t[4500] (60 bytes)
А вот дальше странно:
Aug 29 20:02:41 silver charon: 13[IKE] sending keep alive to x.y.z.t[4500]
Aug 29 20:02:47 silver charon: 08[IKE] sending DPD request
Aug 29 20:02:47 silver charon: 08[ENC] generating INFORMATIONAL_V1 request
2751735170 [ HASH N(DPD) ]
Aug 29 20:02:47 silver charon: 08[NET] sending packet: from 192.168.4.13[4500]
to x.y.z.t[4500] (92 bytes)
Aug 29 20:03:07 silver charon: 01[IKE] sending keep alive to x.y.z.t[4500]
Aug 29 20:03:17 silver charon: 11[IKE] sending DPD request
Aug 29 20:03:17 silver charon: 11[ENC] generating INFORMATIONAL_V1 request
4036527951 [ HASH N(DPD) ]
Aug 29 20:03:17 silver charon: 11[NET] sending packet: from 192.168.4.13[4500]
to x.y.z.t[4500] (92 bytes)
и так по циклу. Смущает, что ничего не received.
/etc/xl2tpd/xl2tpd.conf:
[lac krysl2tp]
lns = x.y.z.t
refuse chap = yes
refuse pap = yes
require authentication = yes
ppp debug = yes
pppoptfile = /etc/ppp/peers/krysl2tp
length bit = yes
Вот по xl2tpd документации не нашел. Вообще. Строил по примерам, что
есть в /usr/share/doc/xl2tpd.
/etc/ppp/peers/krysl2tp:
name some_login
remotename remote
ipparam remote
ipcp-accept-local
ipcp-accept-remote
noccp
noauth
crtscts
idle 1800
mtu 1410
mru 1410
nodefaultroute
debug
lock
proxyarp
connect-delay 5000
/etc/ppp/chap-secrets:
some_login * some_password *
После bash -c 'echo "c krysl2tp" > /run/xl2tpd/l2tp-control' в логе
Aug 29 20:04:34 silver xl2tpd[4028]: Connecting to host x.y.z.t, port 1701
Aug 29 20:04:39 silver xl2tpd[4028]: Maximum retries exceeded for tunnel 6825.
Closing.
Aug 29 20:04:39 silver xl2tpd[4028]: Connection 0 closed to x.y.z.t, port 1701
(Timeout)
Aug 29 20:04:44 silver xl2tpd[4028]: Unable to deliver closing message for
tunnel 6825. Destroying anyway.
Судя по тому, что я вижу, до pppd дело не доходит. Ругань вываливается
быстро, т.е. с того конца, видимо, не глухо, а refused.
Хотелось бы разобраться, что за фигня, но читать протокольные пакеты
глазами, особенно если они шифруются, ресурса нет. Может, я тупо что-то
известное не вписал или вписал не так?
