AndroidでCISCO 841MJにIPSec接続してみる その3 （2017/10/03）

双方のプロポーザルを合致させることで、ISAKMP SAまでは接続できることを確認できました。しかし、Android上では、接続ボタンを押下→失敗しましたと瞬時に表示されます。まだまだこれからですね。

ISAKMP: (0):Checking ISAKMP transform 1 against priority 1 policy
ISAKMP: (0):      life type in seconds
ISAKMP: (0):      life duration (basic) of 28800
ISAKMP: (0):      encryption AES-CBC
ISAKMP: (0):      keylength of 256
ISAKMP: (0):      auth XAUTHInitPreShared
ISAKMP: (0):      hash SHA256
ISAKMP: (0):      default group 5
ISAKMP: (0):atts are acceptable. Next payload is 3
ISAKMP: (0):Acceptable atts:actual life: 86400
ISAKMP: (0):Acceptable atts:life: 0
ISAKMP: (0):Basic life_in_seconds:28800

理論上はフェーズ2のXauth認証セクションに入っているはずですが、デバッグログには無数のXauthの文字列が表示され、ちゃんとセクションが進行しているのかよく分かりません。

ちなみにデバッグログは重要な情報源としての魔法の文字列ですが、私が理解できるのは1〜2割程度です。基本的に内部制御コードの羅列のため、素人が読んで分かるものではありませんし、無理に読もうとは思いません。
でも大丈夫です。デバッグログは、処理シーケンスとしてあるべき文字列が表示されているか、また、それに関連するキーワードとしてOK/NG/Success/Fail/match/mismatchなどが表示されていないか、という点を押さえればなんとかなります。

その2に書いたフェーズ1プロポーザルの不一致については、does not match policy、atts are not acceptableといった表示で判断できました。
今、手元にあるデバッグログからXauthの文字列は読み取れるので、Xauthのセクションに到達していることは分かりますが、OKやNGといった関連キーワードが読み取れず、行き詰まってしまいました。

そんな時に私が試してみることは、意図的に変化を発生させることです。具体的には、Xauthのユーザ認証がOKとなるデバッグログと、認証がNGとなった場合（わざとパスワードを間違える）のデバッグログを取得し、Diffツールで比較してみました。
もし双方のデバッグログに変化がなければ、Xauthシーケンスには達しているものの、根本的な問題が残っており、ユーザ認証は行われていないということが言えますし、明らかな変化が見えるのであれば、ユーザ認証の成功によって、さらにその次のシーケンスに進んでいるということが言えます。

･･･結果は、明らかな違いがありました。
つまり、ちゃんとユーザ認証の判定まで行われているということです。

確かによくよくデバッグログを眺めてみると、認証が成功している方はMODE_CFGセクションに突入しているような痕跡が見えました。そうなると、今度はMODE_CFG周りのコンフィグを作り込めば良いのです。

ISAKMP: (2008):checking request:
ISAKMP: (2008):client configuration address    IP4_ADDRESS
ISAKMP: (2008):    IP4_NETMASK
ISAKMP: (2008):    IP4_DNS
ISAKMP: (2008):    IP4_NBNS
ISAKMP: (2008):    MODECFG_BANNER
ISAKMP: (2008):    DEFAULT_DOMAIN
ISAKMP: (2008):    SPLIT_DNS
ISAKMP: (2008):    SPLIT_INCLUDE
ISAKMP: (2008):    INCLUDE_LOCAL_LAN
ISAKMP: (2008):    APPLICATION_VERSION

その4へ続く。

タグ：cisco IPsec