PCI製Wi-Fiマルチポケットルータ MZK-MF300D [小技(Linux)]
会社でスマホを使ってAdobeのShadowとかいうソフトと連携してデザインの開発作業をしたいんだけど…と言われ、事務所内の社内ネットワークにWi-Fiで接続するのはちょっとどーなのよ…と文句を言いたい気持ちをぐっとこらえ、やむなくプラネックス(PCI)製の激安な「Wi-Fiマルチポケットルータ」 MZK-MF300D なるものを買ってきた。
どうやら、スマホのWi-FiアドレスとAdobe Shadowとかいうソフトの入っているPCとが同じネットワークにある必要があるらしく、「そうしてくれ」との強い要望を受けたので、MZK-MF300Dをマニュアルガン無視でアクセスポイントモードに切り替えてセットアップ。ネットワークの設定、マルチAPの無効化、無線の設定、管理者パスワードの変更などなどを経てセットワークに接続。スマホでアクセスが出来ることを確認して引き渡した。
ところが!
「あの~。開発環境にアクセスできないんですけど~。」
という知らせが。どうも、DNSで名前解決が出来ないらしい。
アクセスポイントの設定を見直すが、よくよく見て見ると、そもそもDNSサーバのアドレスを入れる項目がどこにもない。でも、なにやらDNSは引けてる。
はあ?
どうやらMZK-MF300Dはどこか我々の知らないところに立っているDNSを参照しているもよう。社内ネットワークとかの内部DNSを見せる事はこのままでは出来ないようだ。
しかし、開発環境とかテスト環境とかいうものは外部に曝す訳にはいかないじゃないか。
そこで…iptablesでアクセス経路をひん曲げてやればよくね?
と、思い立ち以下のような作戦を立案した。
①MZK-MF300Dの全てのトラフィックを、どこか他のサーバで一旦全部受け取る
↓
②iptablesでマスカレード、本来のデフォルトゲートウェイに中継してやる
↓
③でも53/tcp、53/udpだけはDNSサーバに向かってパケットの飛び先を曲げてしまう
こうすれば、MZK-MF300Dの馬鹿DNSは騙されてくれることだろう!!
と、妄想したのだ。
ちと手頃なサーバが他に居なかったので、「セキュリティ的にちょっとどうよ!?」という懸念はあるものの、一先ず社内のDNSサーバにMZK-MF300Dのトラフィックを総受けしてもらう役割も担当してもらうこととした。
後日、忘れてなければ直す!(たぶん)
というわけで、そのDNSサーバな子で以下実行。
手順1:/etc/sysctl.confに「net.ipv4.ip_forward = 1」を書く。
手順2:sysctl -p 実行
手順3:service iptables start 実行
手順4:Wi-Fiから来たトラフィックを全部本来のデフォルトゲートウェイに飛ばすため以下実行
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
手順5:MZK-MF300Dの内蔵馬鹿DNSからの問い合わせを、社内DNSサーバで解決するため、パケットをぶんどる設定を入れるため以下実行
iptables -t nat -A PREROUTING -s (MZK-MF300Dのアドレス) -p tcp --dport 53 -j DNAT --to (社内DNSサーバのアドレス):53
iptables -t nat -A PREROUTING -s (MZK-MF300Dのアドレス) -p udp --dport 53 -j DNAT --to (社内DNSサーバのアドレス):53
で、念のためMZK-MF300Dを再起動。
Wi-Fiアクセスから適当な社内サーバの名前をnslookup するとちゃんと解決できた。(殺気はダメだった)
というわけで一先ず問題解決っぽい。デザイナーの人も大丈夫ですと言っているので大丈夫なのだろう。
教訓:安物買いのなんとやら。会社で使うものはもっとちゃんとした物を買いましょう。(笑)
どうやら、スマホのWi-FiアドレスとAdobe Shadowとかいうソフトの入っているPCとが同じネットワークにある必要があるらしく、「そうしてくれ」との強い要望を受けたので、MZK-MF300Dをマニュアルガン無視でアクセスポイントモードに切り替えてセットアップ。ネットワークの設定、マルチAPの無効化、無線の設定、管理者パスワードの変更などなどを経てセットワークに接続。スマホでアクセスが出来ることを確認して引き渡した。
ところが!
「あの~。開発環境にアクセスできないんですけど~。」
という知らせが。どうも、DNSで名前解決が出来ないらしい。
アクセスポイントの設定を見直すが、よくよく見て見ると、そもそもDNSサーバのアドレスを入れる項目がどこにもない。でも、なにやらDNSは引けてる。
はあ?
どうやらMZK-MF300Dはどこか我々の知らないところに立っているDNSを参照しているもよう。社内ネットワークとかの内部DNSを見せる事はこのままでは出来ないようだ。
しかし、開発環境とかテスト環境とかいうものは外部に曝す訳にはいかないじゃないか。
そこで…iptablesでアクセス経路をひん曲げてやればよくね?
と、思い立ち以下のような作戦を立案した。
①MZK-MF300Dの全てのトラフィックを、どこか他のサーバで一旦全部受け取る
↓
②iptablesでマスカレード、本来のデフォルトゲートウェイに中継してやる
↓
③でも53/tcp、53/udpだけはDNSサーバに向かってパケットの飛び先を曲げてしまう
こうすれば、MZK-MF300Dの馬鹿DNSは騙されてくれることだろう!!
と、妄想したのだ。
ちと手頃なサーバが他に居なかったので、「セキュリティ的にちょっとどうよ!?」という懸念はあるものの、一先ず社内のDNSサーバにMZK-MF300Dのトラフィックを総受けしてもらう役割も担当してもらうこととした。
後日、忘れてなければ直す!(たぶん)
というわけで、そのDNSサーバな子で以下実行。
手順1:/etc/sysctl.confに「net.ipv4.ip_forward = 1」を書く。
手順2:sysctl -p 実行
手順3:service iptables start 実行
手順4:Wi-Fiから来たトラフィックを全部本来のデフォルトゲートウェイに飛ばすため以下実行
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
手順5:MZK-MF300Dの内蔵馬鹿DNSからの問い合わせを、社内DNSサーバで解決するため、パケットをぶんどる設定を入れるため以下実行
iptables -t nat -A PREROUTING -s (MZK-MF300Dのアドレス) -p tcp --dport 53 -j DNAT --to (社内DNSサーバのアドレス):53
iptables -t nat -A PREROUTING -s (MZK-MF300Dのアドレス) -p udp --dport 53 -j DNAT --to (社内DNSサーバのアドレス):53
で、念のためMZK-MF300Dを再起動。
Wi-Fiアクセスから適当な社内サーバの名前をnslookup するとちゃんと解決できた。(殺気はダメだった)
というわけで一先ず問題解決っぽい。デザイナーの人も大丈夫ですと言っているので大丈夫なのだろう。
教訓:安物買いのなんとやら。会社で使うものはもっとちゃんとした物を買いましょう。(笑)
コメント 0