Network

環境変数 シェル起動時にネットワーク設定からプロキシ設定を環境変数に読み出すようにしている場合、GUIで設定すればOK。 export HTTP_PROXY=http://proxy.example.com:8080/ export HTTPS_PROXY=http://proxy.example.com:8080/ export NO_PROXY=localhost,127.0.0.0/8,::1 NO_PROXYには必ずlocalhost/ローカルループバックアドレスを設定しておくこと（無限ループする）。 ビルド https://github.com/wadahiro/go-transproxy git clone https://github.com/wadahiro/go-transproxy.git cd go-transproxy/ make ls go-transproxy/bin/transproxy # check network device name ifconfig ~/transproxy/pf.conf MacBookの無線LANカード：en0 Mac miniなどの場合はNIC名が異なる場合があるので注意。 Packets = "proto tcp from en0 to {!192.168.0.0/16}" rdr pass log on lo0 $Packets port 80 -> 127.0.0.1 port 3129 rdr pass log on lo0 $Packets port 443 -> 127.0.0.1 port 3130 pass out on en0 route-to lo0 inet $Packets port {80, 443} keep state 有効化 sudo pfctl -ef ~/transproxy/pf.conf transproxy -disable-iptables 無効化 # stop transproxy process (Ctrl+C) # reset pf configs sudo pfctl -df /etc/pf.conf Macでプロキシとの戦いに疲れたので、透過型プロキシを導入してみた - Qiita

/etc/sudoers Defaults env_keep+="HTTP_PROXY" Defaults env_keep+="HTTPS_PROXY" Defaults env_keep+="NO_PROXY" 環境変数 export HTTP_PROXY=http://proxy.example.com:8080/ export HTTPS_PROXY=http://proxy.example.com:8080/ export NO_PROXY=localhost,127.0.0.0/8,::1 NO_PROXYには必ずlocalhost/ローカルループバックアドレスを設定しておくこと（無限ループする）。 デスクトップの場合はGUI設定でOK。 /usr/local/bin/transproxy https://github.com/wadahiro/go-transproxy /usr/local/bin/transproxy-start #!/bin/bash set -eu # iptables -t nat -I OUTPUT -p tcp --dport 53 -j REDIRECT --to-ports 3131 # iptables -t nat -I OUTPUT -p udp --dport 53 -j REDIRECT --to-ports 3131 iptables -t nat -I OUTPUT -p tcp --dport 80 -j REDIRECT --to-ports 3129 iptables -t nat -I OUTPUT -p tcp --dport 443 -j REDIRECT --to-ports 3130 transproxy -disable-iptables # -dns-over-https-enabled /usr/local/bin/transproxy-stop #!/bin/bash set -eu # iptables -t nat -D OUTPUT -p tcp --dport 53 -j REDIRECT --to-ports 3131 # iptables -t nat -D OUTPUT -p udp --dport 53 -j REDIRECT --to-ports 3131 iptables -t nat -D OUTPUT -p tcp --dport 443 -j REDIRECT --to-ports 3130 iptables -t nat -D OUTPUT -p tcp --dport 80 -j REDIRECT --to-ports 3129 iptablesのルールを書き換えるため、実行時にはroot権限が必要。 ...

server$ sudo apt install bind9 使用中のDNSサーバの確認 クライアントに設定されているDNSサーバはnmcliコマンドで確認できる。 $ nmcli device show | grep DNS IP4.DNS[1]: 8.8.8.8 IP4.DNS[2]: 8.8.4.4 IP4.DNS[3]: 1.1.1.1 Command-line to list DNS servers used by my system - Ask Ubuntu 用語 BIND DNSサーバー構築 | CentOSサーバー構築入門 コンテンツサーバ（権威サーバ） あるゾーン（DNSにおける名前の管理単位）に関する名前解決要求（非再帰問い合わせ）を受け取り、自身が管理するゾーンならば名前解決結果を、委任情報を持つゾーンならば委任先の権威サーバ情報を応答する。 ルートゾーン（FQDN: .）を管理するルートサーバは、TLD（例えば jp.）の権威サーバへの委任情報を持つ。 ゾーン情報において、NSレコードにより指定される。 JPRS用語辞典｜ルートゾーン JPRS用語辞典｜権威サーバー（権威DNSサーバー） JPRS用語辞典｜ネームサーバー（DNSサーバー） キャッシュサーバ（フルサービスリゾルバ） クライアントから名前解決要求（再帰問い合わせ）を受け取り、 コンテンツサーバへ反復的に名前解決要求（反復問い合わせ）を送ることで任意のドメイン名の名前解決を行う。 JPRS用語辞典｜フルサービスリゾルバー（キャッシュDNSサーバー） 例えばhoge.example.jp.というドメインの名前解決要求を受け取ったとき、 ルートサーバ.への非再帰問い合わせによりjp.権威サーバへの委任情報を取得する。 jp.権威サーバへの非再帰問い合わせによりexample.jp.権威サーバへの委任情報を取得する。 example.jp.権威サーバへの非再帰問い合わせによりhoge.example.jp.のIPアドレスを取得する、のような流れで反復的に問い合わせを行うことでhoge.example.jp.の名前解決を行う。 ISPの提供するDNSサーバや会社などの組織内DNSサーバ、GoogleやCloudflareなどが提供するパブリックDNSがある。 ASCII.jp：DNSによる名前解決の仕組みを理解しよう (1/2) 回送 プロキシのように、受け取った名前解決要求を他のDNSサーバに送り、 応答を返す。 /etc/bind/named.conf.options 自身が管理していない情報（ゾーン、委任情報）に関する問い合わせについて、 他のDNSサーバ（フルサービスリゾルバ）に問い合わせを回送するように設定する。 「再帰問い合わせ」と「非再帰問い合わせ」の違いを教えてください：DNS Tips - ＠IT BIND DNSサーバー構築 | CentOSサーバー構築入門 フォワード（回送） : お父さんのためのDNS講座 デフォルト設定ファイル options { directory "/var/cache/bind"; // If there is a firewall between you and nameservers you want // to talk to, you may need to fix the firewall to allow multiple // ports to talk. See http://www.kb.cert.org/vuls/id/800113 // If your ISP provided one or more IP addresses for stable // nameservers, you probably want to use them as forwarders. // Uncomment the following block, and insert the addresses replacing // the all-0's placeholder. // forwarders { // 0.0.0.0; // }; //======================================================================== // If BIND logs error messages about the root key being expired, // you will need to update your keys. See https://www.isc.org/bind-keys //======================================================================== dnssec-validation auto; auth-nxdomain no; # conform to RFC1035 listen-on-v6 { any; }; }; 変更点 forwarders { 8.8.8.8; 8.8.4.4; 1.1.1.1; }; 初歩から解説！BINDでシンプルDNSサーバー構築【構築編】｜ 開発者ブログ ｜ 株式会社アイソルート 確認 server$ systemctl restart bind9.service client$ dig @192.168.x.x aoirint.com ... ;; ANSWER SECTION: aoirint.com. 3600 IN A 185.199.108.153 aoirint.com. 3600 IN A 185.199.111.153 aoirint.com. 3600 IN A 185.199.109.153 aoirint.com. 3600 IN A 185.199.110.153 ... digコマンドの使い方 - Qiita /etc/bind/named.conf.local DNSサーバの管理するゾーンの名前と対応する設定ファイル（ゾーンファイル）を設定する。 ...

SSHポートフォワーディング：踏み台による中継接続 SSHポートフォワーディングには、 ローカルポートフォワーディング、 リモートポートフォワーディングの2種類があります。 sshポートフォワーディング - Qiita ローカルポートフォワーディングでは、 SSHサーバ側から見えるネットワークポートを SSHクライアント側に転送することができます。 例えば、ファイアウォール（NAT）に守られたネットワーク（ネットワークA）内にあるWebサーバ（ホストX）に 外部ネットワーク（ネットワークB）にあるクライアント（ホストY）から接続したいとき、 踏み台となる、ネットワークBから接続可能なSSHサーバ（ホストZ）がネットワークA内にあれば、 ホストYがホストZにSSH接続することで、 ホストXのWebサーバのネットワークポートに、 ホストYの指定したポートから接続できるようになります （「ホスト」は「各ネットワークに接続した、NICに割り当てられたIPアドレス」に対応）。 [email protected]: $ ssh [email protected] -L "127.0.0.1:10080:hostX.networkA.example:80" [email protected]: $ wget http://127.0.0.1:10080/index.html I am "hostX.networkA.example:80". リモートポートフォワーディングでは、 SSHクライアント側から見えるネットワークポートを SSHサーバ側に転送することができます。 先の例でいうと、ホストXがネットワークBに接続していて、 ファイアウォール（NAT）によってネットワークAにあるホストZから接続できないとき、 ホストYがホストZにSSH接続することで、ホストZからホストXに接続できるようになります。 [email protected]: $ ssh [email protected] -R "127.0.0.1:10080:hostX.networkB.example:80" [email protected]: $ wget http://127.0.0.1:10080/index.html I am "hostX.networkB.example:80". この方法は、ネットワーク内のあるホストにSSH接続ができる環境さえあれば、 VPNや他のTCPプロキシをセットアップするより簡単に隠されたネットワークにアクセスすることができるように思います。 ポートプロキシサーバ：2種類のSSHポートフォワーディングの組み合わせ ここで、別の構成のネットワークについても考えてみます。 新しくネットワークCを導入して、 ホストXはNAT内のネットワークC（hostX.networkC.example）、 ホストYはNAT内のネットワークB（hostY.networkB.example）、 ホストZはネットワークB、Cからともに接続可能なネットワークA（hostZ.networkA.example） という構成を考えてみます。 この構成で、ホストYからホストXに接続可能な環境を作るには、次のような手順が考えられます。 ホストXからホストZにSSH接続し、リモートポートフォワーディングによってホストZ上の"ポートQ"をホストX上の"ポートP"に転送する ホストYからホストZにSSH接続し、ローカルポートフォワーディングによってホストY上の"ポートR"をホストZ上の"ポートQ"に転送する これにより、ホストYは、自身のポートRを使って、ホストXのポートPに接続することができます。 もしホストXに物理的にアクセスできない環境でも、 あらかじめホストXをホストZに常時接続するように設定しておけば、 その接続（ポートQからポートPへの転送）が生きている限り、好きなタイミングでホストYからホストXに接続（ポートRからポートQへの転送、すなわちポートRからポートPへの転送）することができます。 SSH Port Forwardingを使ったPort Proxy Server in Docker 前項のポートプロキシサーバの問題として、次の3つを考えました。 ...

User (Desktop): Settings > Network > Network Proxy Settings > Network > Network Proxy > Manualに設定する。 自動的に環境変数HTTP_PROXY, HTTPS_PROXYにスキームが追加された状態で設定される。 HTTP Proxy: proxy port HTTPS Proxy: proxy port Ignore Hosts: localhost, 127.0.0.0/8, ::1（プライベートネットワーク・組織内ネットワークのIPアドレス範囲またはドメインも追加する） curlやwget、pipなど主要コマンドは 注意点として、別ユーザとしてコマンドを実行すると環境変数が引き継がれない。 例えばsudo curlしたときにプロキシに接続しにいかない。 /etc/sudoers sudoでコマンドを実行したとき、実行時シェルに設定されている環境変数を引き継ぐようにする。 sudoersは書き込み禁止になっているためvisudoで編集する。 # run as root visudo -f /etc/sudoers Defaults env_keep+="HTTP_PROXY" Defaults env_keep+="HTTPS_PROXY" Defaults env_keep+="NO_PROXY" Defaults env_keep+="EDITOR" /etc/environment システム全体の環境変数として設定される。影響範囲が大きいので注意。 デスクトップユーザではSettings側の設定（Disabledなら設定されない）が優先されるようだった。 HTTP_PROXY=http://proxy:port HTTPS_PROXY=http://proxy:port NO_PROXY=localhost, 127.0.0.0/8, ::1 apt: /etc/apt/apt.conf Acquire::http::proxy "http://proxy:port"; Acquire::https::proxy "http://proxy:port"; Snap: systemctl edit snapd.service /etc/systemd/system/snapd.service.d/override.confにsystemdの設定ファイルを作成する。 ...