PPPoE経由のLinuxで選択したhttpsサイトにアクセスできない

インターネット接続は、プロバイダーへの直接LAN接続でした。当時、WindowsとUbuntuの両方ですべてが正常にロードされました（デュアルブート）。しかし、しばらく前に、ユーザー名とパスワードを使用してダイヤル（PPPoE）を要求するようになりました。ゲートウェイ、サブネットマスク、IP、DNSサーバーはすべて同じままでした。しかし、それ以降、Windowsでそのような問題は発生していませんが、Ubuntuで特定のWebサイトを閲覧することができませんでした。いくつかのウェブサイトの例-Ovi のサインインページ（share.ovi.comは正常にロードし、nokia.comは正常にロードします）、Live Mail（Chrome（ium）およびOperaで動作しますが、Firefox（3.6および4の両方）では動作しません）Mozilla アドオンWebサイトおよびその他のランダムWebサイト。

ロードされないウェブサイトの一部はタイムアウトメッセージを表示し、一部のウェブサイト（mozアドオンなど）では、ブラウザは終了せずにロードを試行し続けます（何時間もそれを残しましたが、何も変わっていないことに気付きませんでした）起こる）。

DNSサーバーをパブリックサーバーに変更しようとしました。私ものFedoraのLiveCDからの起動を試してみましたし、その後、（とさえOpenDNSののものに）ものにDNSを変更しますが、まったく同じことが起こります。この問題の原因となっているLinux自体の一部の構成に本質的に問題があるのは何ですか？

なぜこれが起こっているのか、どのように修正できるのか誰もが知っていますか？

注：この質問はSUにクロスポストされていますが、回答はありません。

更新：他の誰かが同様の問題を抱えていることをここで見ただけで、NetworkManager.confファイルをに入れることで解決しました/etc/NetworkManager。そのファイルには何が必要ですか？

MTU問題の症状があります。一部のTCP接続がフリーズし、特定のコマンドまたはURLに対して多少の再現性がありますが、全体的なパターンは容易に識別できません。明白な症状は、インタラクティブなsshセッションはうまく機能するが、ファイル転送はほとんど常に失敗することです。さらに、pppoeは、ホームユーザーにとってMTU問題の最大の原因です。そこで、MTUチェックを処方します。

それは何ですか？M aximum T ransmission U NITは、ネットワーク・リンク上のパケットの最大サイズです。MTUはトランスポート媒体ごとに異なります。たとえば、有線イーサネットとwifi（802.11）には異なるMTUがあり、ATMリンク（長距離インフラストラクチャのほとんどを構成します）にはそれぞれ独自のMTUがあります。 PPPOEはカプセル化されたプロトコルです。つまり、すべてのパケットは数バイトのヘッダーとそれに続く基礎となるパケットで構成されているため、ヘッダーのサイズ分だけ最大パケットサイズが小さくなります。 IPでは、ルーターが次のホップに対して大きすぎることを検出した場合、パケットを断片化できますが、これは常に機能するとは限りません。理論的には、適切なMTUを発見する必要があります自動的に、しかしこれはまた常に機能しません。特に、グーグルは、Network ManagerがMTUディスカバリーから取得したMTU情報に常に適切に対応するとは限らないことを示唆していますが、影響を受けるバージョンや問題のあるユースケースはわかりません。

それを測定する方法。tracepathLinux 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を使用してインターネット接続を最適化する方法。

設定方法（決定したMTU、およびeth0ネットワークインターフェイスの名前で1454を置き換えます）

• 一度限り（Linux）：実行 ifconfig eth0 mtu 1454
• 永久に（DebianやUbuntuなどの誘導体、場合には、ネットワークマネージャを使用していない）：編集を/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://....1つです。

PPPoEの変更がこれに影響する理由はわかりませんが、おそらくISPが一度に複数の変更を行ったため、間違った変更を責めていることになります。

ハードウェアルーターを追加してみます。ISPのモデル番号で特に推奨されているものです。ISPの希望どおりにPPPoE接続をネゴシエートする可能性が高いだけでなく、SSL接続の問題も解決する可能性があります。

差し迫った問題が解決しない場合でも、いくつかの副次的な利点があります。

まず、ハードウェアファイアウォールはセキュリティの層を追加します。ファイアウォールの背後にあるマシンへの接続を許可する必要がある場合は、PortForward.comで、使用する可能性のあるすべてのルーターのポート転送ガイドを参照してください。

第二に、ほとんどのホームルーターでは、インターネット接続を複数のPCと共有できます。

クロム（およびクロム）でもこれとまったく同じ問題がありました。これはWebkitの問題だと思っていました。永続的な解決策は見つかりませんでしたが、そのエラーコードを（実際の値なしで）Googleで検索すると、多くの人が同じ問題を抱えていることがわかります。特定のWebサイトに接続されているタブを閉じて、キャッシュとCookieなどをすべてクリアすることで、一時的に機能させることができました。

私は解決策を見つけられず、それからfirefoxに戻りました。