Linux上の一部のhttpsサイトにPPPoE
私のインターネット接続は、以前はプロバイダーへの直接LAN接続でした。その当時、すべてがWindowsとUbuntuの両方で正常にロードされました（デュアルブート）。しかし、少し前に、ユーザー名とパスワードを使用してダイヤル（PPPoE）する必要が出てきました。ゲートウェイ、サブネットマスク、IP、DNSサーバーはすべて同じままでした。しかし、それ以来、私はUbuntuで特定のWebサイトを閲覧することができませんでしたが、Windowsではそのような問題は発生していません。ウェブサイトの例は次のとおりです- Oviのサインインページ （ただし、share.ovi.comは正常にロードされ、nokia.comは正常にロードされます）、 Live Mail （Chrome（ium）で動作）およびOperaただし、Firefox（3.6と4の両方）を除く））Mozilla アドオンWebサイト およびその他のランダムなWebサイト。
ロードしないWebサイトの一部はタイムアウトメッセージを表示し、一部のWebサイト（mozアドオンなど）では、ブラウザーは終了せずにロードを試行し続けます（何時間もそうしたままにしましたが、何も変わったことに気づきませんでした）起こります）。
DNSサーバーをパブリックサーバーに変更してみました。 Fedora LiveCDから起動してthen DNSをそれらに（さらにはOpenDNSのDNSに）変更してみましたが、まったく同じことが起こります。この問題を引き起こしているLinux自体の一部の構成で本質的に何が問題になっているのでしょうか？
なぜこれが起こっているのか、そしてそれをどのように修正できるのか知っていますか？
注：この質問はSUで クロスポスト になっていますが、応答はありません。
更新：ただ見た here 他の誰かが同様の問題を抱えていて、NetworkManager.confファイル/etc/NetworkManager。そのファイルには何が必要ですか？
[〜＃〜] mtu [〜＃〜] 問題の症状があります：いくつかTCP接続がフリーズし、特定のコマンドまたはURLで再現性はありますが、全体的なパターンは簡単に識別できません。対話型のsshセッションは正常に機能しますが、ファイル転送はほとんどの場合失敗します。ユーザーのためのMTU問題の原因なので、MTUチェックを規定します。
それは何ですか？maximumtransmissionunitは、ネットワークリンク上のパケットの最大サイズです。 MTUは、トランスポートメディアによって異なります。有線イーサネットとwifi（802.11）には異なるMTUがあり、 [〜＃〜] atm [〜＃〜] リンク（長距離インフラストラクチャのほとんどを構成します）にはそれぞれ独自のMTUがあります。 [〜＃〜] pppoe [〜＃〜] はカプセル化されたプロトコルです。つまり、すべてのパケットは数バイトのヘッダーとその後に続くパケットで構成されているため、最大パケットサイズがヘッダーのサイズ。 [〜＃〜] ip [〜＃〜] ルーターは、パケットが次のホップには大きすぎることを検出した場合にパケットをフラグメント化できますが、これが常に機能するとは限りません。理論的には、適切なMTUを検出する必要があります 自動的に 。ただし、これも常に機能するとは限りません。特にグーグルは、Network ManagerがMTUディスカバリーから取得したMTU情報に対して常に適切に動作するとは限らないことを示唆していますが、影響を受けるバージョンや問題のあるユースケースはわかりません。
測定方法Linuxから tracepath をお持ちの場合 iputils 、_tracepath 8.8.8.8_を実行して、GoogleのDNSサーバーへのパス上のMTUを確認します。 tracerouteのバージョンに_--mtu_オプションがある場合は、_traceroute -n --mtu 8.8.8.8_を実行します。その他のオプションについては 自分と宛先IP間のMTUを検出する を参照してください。
自動化ツールがないため、手動で測定できます。特定のサイズのpingパケットを、それらに応答する外部ホストに送信してみてください。 _ping -c 1 -s 42 8.8.8.8_（Linuxの場合、他のシステムでは、pingコマンドのドキュメントを参照してください）。パケットは十分に小さい42の値で通過するはずです（42が機能しない場合、何かがpingをブロックしています。）。値が大きい場合、パケットは通過しません。 1464は、インフラストラクチャの制限部分がローカルイーサネットネットワークである場合の典型的な最大値です。運が良ければ、送信するパケットが大きすぎると、Frag needed and DF set (mtu = 1492)のようなメッセージが表示されます。運が悪い場合は、最大値が見つかるまで値を試してみて、28を追加します（_-s_はペイロードサイズを指定し、それに加えて28バイトのヘッダーがあります）。 Ubuntuフォーラムの MTUおよびRWINを使用してインターネット接続を最適化する方法 も参照してください。
設定方法（1454は決定したMTUで置き換え、_eth0_はネットワークインターフェイスの名前で置き換えます）
- 一度限り（Linux）：_
ifconfig eth0 mtu 1454_を実行します - 永続的に（DebianおよびUbuntuなどの派生物、Network Managerを使用していない場合）：_
/etc/network/interfaces_を編集します。ネットワークインターフェイスのエントリの直後（_iface eth0 …_ディレクティブの後）に、_pre-up ifconfig $IFACE mtu 1454_を含む行を追加します。または、IPアドレスが静的な場合は、_mtu 1454_ディレクティブに_iface eth0 inet static_パラメーターを追加できます。 永久に（DebianおよびUbuntuなどの派生物、Network Managerの有無にかかわらず）：次の内容で_
/etc/network/if-pre-up.d/mtu_というスクリプトを作成し、世界中で実行可能にします（_chmod a+rx_）：_
#!/bin/sh ifconfig $IFACE mtu 1454_
その他のリソース
- 確実に信頼できない接続を診断する方法 （特に Mike Penningtonの回答 ）ここで説明する単純な測定と制限のアプローチが機能しない場合は、役立つかもしれません。
中心的な問題はSSLに関係しているようです。問題のあるURLはすべてhttps://....個。
PPPoEへの変更がこれに影響する理由はわかりませんが、ISPが一度に複数の変更を行い、間違った変更のせいになっている可能性があります。
ハードウェアルーターを追加してみます。ISPのモデル番号で特に推奨されています。 ISPが望むとおりにPPPoE接続をネゴシエートするだけでなく、SSL接続の問題も解決する可能性があります。
それがあなたの差し迫った問題を助けない場合でも、それからいくつかの副次的な利益を得ることができます。
まず、ハードウェアファイアウォールによってセキュリティの層が追加されます。ファイアウォールの背後にあるマシンへの接続を許可する必要がある場合は、 PortForward.com を参照して、使用する可能性のあるすべてのルーターのポート転送ガイドを確認してください。
次に、ほとんどのホームルーターでは、インターネット接続を複数のPCと共有できます。
私はこれとまったく同じ問題をクロム（およびクロム）で抱えていました。 Webkitの問題だと思いました。私は永久的な解決策を見つけたことはありませんが、そのエラーコード（実際の値なし）をググると、多くの人が同じ問題を抱えていることがわかります。特定のWebサイトに接続されているタブを閉じ、キャッシュとCookieとすべてをクリアすることで、一時的に機能させることができました。
私は解決策を見つけたことがないので、Firefoxに戻りました。