Impossibile connettersi a determinati siti HTTPS


12

Mi sono appena trasferito in un nuovo appartamento e con la connessione a Internet tramite un router e sto scoprendo che non riesco a collegarmi a parecchi siti che utilizzano SSL.

Ad esempio, cercando di connettersi a PayPal:

curl -v https://paypal.com
* About to connect() to paypal.com port 443 (#0)
*   Trying 66.211.169.3... connected
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* Unknown SSL protocol error in connection to paypal.com:443 
* Closing connection #0
curl: (35) Unknown SSL protocol error in connection to paypal.com:443 

curl -v -ssl https://paypal.com dà lo stesso risultato.

Per alcuni siti funziona:

curl -v https://www.google.com
* About to connect() to www.google.com port 443 (#0)
*   Trying 74.125.235.112... connected
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server key exchange (12):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using ECDHE-RSA-RC4-SHA
* Server certificate:
*    subject: C=US; ST=California; L=Mountain View; O=Google Inc; CN=www.google.com
*    start date: 2011-10-26 00:00:00 GMT
*    expire date: 2013-09-30 23:59:59 GMT
*    common name: www.google.com (matched)
*    issuer: C=ZA; O=Thawte Consulting (Pty) Ltd.; CN=Thawte SGC CA
*    SSL certificate verify ok.
> GET / HTTP/1.1
> User-Agent: curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3
> Host: www.google.com
> Accept: */*
> 
< HTTP/1.1 302 Found
< Location: https://www.google.co.jp/
  .
  .
  .

Sto usando Ubuntu 12.04, anche con Windows 7 installato. Questi siti funzionano su Windows :(

Non sono sicuro che queste informazioni siano utili, ma ho eseguito ifconfige ottenuto quanto segue:

eth0      Link encap:Ethernet  HWaddr 1c:c1:de:bc:e2:4f  
          inet6 addr: 2408:c3:7fff:991:686b:8d18:81b3:8dd1/64 Scope:Global
          inet6 addr: 2408:c3:7fff:991:1ec1:deff:febc:e24f/64 Scope:Global
          inet6 addr: fe80::1ec1:deff:febc:e24f/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:87075 errors:0 dropped:0 overruns:0 frame:0
          TX packets:54522 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:78167937 (78.1 MB)  TX bytes:10016891 (10.0 MB)
          Interrupt:46 Base address:0x4000 

eth1      Link encap:Ethernet  HWaddr ac:81:12:0d:93:80  
          inet6 addr: fe80::ae81:12ff:fe0d:9380/64 Scope:Link
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:498
          TX packets:0 errors:26 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
          Interrupt:17 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:630 errors:0 dropped:0 overruns:0 frame:0
          TX packets:630 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:39592 (39.5 KB)  TX bytes:39592 (39.5 KB)

ppp0      Link encap:Point-to-Point Protocol  
          inet addr:180.57.228.200  P-t-P:118.23.8.175  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1492  Metric:1
          RX packets:39631 errors:0 dropped:0 overruns:0 frame:0
          TX packets:22391 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:3 
          RX bytes:43462054 (43.4 MB)  TX bytes:2834628 (2.8 MB)

Ho eseguito PING:

ping www.paypal.com
PING e6166.b.akamaiedge.net (184.31.66.234) 56(84) bytes of data.
64 bytes from a184-31-66-234.deploy.akamaitechnologies.com (184.31.66.234): icmp_req=1 ttl=54 time=15.3 ms
64 bytes from a184-31-66-234.deploy.akamaitechnologies.com (184.31.66.234): icmp_req=2 ttl=54 time=15.0 ms
64 bytes from a184-31-66-234.deploy.akamaitechnologies.com (184.31.66.234): icmp_req=3 ttl=54 time=15.2 ms
64 bytes from a184-31-66-234.deploy.akamaitechnologies.com (184.31.66.234): icmp_req=4 ttl=54 time=17.2 ms
64 bytes from a184-31-66-234.deploy.akamaitechnologies.com (184.31.66.234): icmp_req=5 ttl=54 time=16.6 ms
64 bytes from a184-31-66-234.deploy.akamaitechnologies.com (184.31.66.234): icmp_req=6 ttl=54 time=16.7 ms
64 bytes from a184-31-66-234.deploy.akamaitechnologies.com (184.31.66.234): icmp_req=7 ttl=54 time=14.8 ms
^C
--- e6166.b.akamaiedge.net ping statistics ---
7 packets transmitted, 7 received, 0% packet loss, time 6009ms
rtt min/avg/max/mdev = 14.878/15.890/17.214/0.901 ms

E senza www:

ping paypal.com
PING paypal.com (66.211.169.66) 56(84) bytes of data.
^C
--- paypal.com ping statistics ---
303 packets transmitted, 0 received, 100% packet loss, time 302265ms

TRACEROUTE:

traceroute www.paypal.com
traceroute to www.paypal.com (184.31.66.234), 30 hops max, 60 byte packets
 1  118.23.8.175 (118.23.8.175)  8.424 ms  8.404 ms  8.540 ms
 2  118.23.10.121 (118.23.10.121)  8.212 ms  8.189 ms  8.162 ms
 3  122.1.164.213 (122.1.164.213)  9.405 ms  11.359 ms  13.469 ms
 4  60.37.55.165 (60.37.55.165)  8.049 ms  8.072 ms  8.040 ms
 5  118.23.168.89 (118.23.168.89)  8.574 ms  8.549 ms  8.558 ms
 6  210.163.230.238 (210.163.230.238)  8.667 ms  7.605 ms  7.545 ms
 7  xe-4-0-0.a21.osakjp01.jp.ra.gin.ntt.net (61.213.169.218)  18.255 ms  18.232 ms xe-3-0-0.a21.osakjp01.jp.ra.gin.ntt.net (61.213.162.206)  19.042 ms
 8  * * *
 9  * * *
   .
   .
   .
29  * * *
30  * * *

senza www:

traceroute paypal.com
traceroute to paypal.com (66.211.169.66), 30 hops max, 60 byte packets
 1  118.23.8.175 (118.23.8.175)  5.607 ms  5.674 ms  5.875 ms
 2  118.23.10.121 (118.23.10.121)  5.468 ms  5.453 ms  5.576 ms
 3  122.1.164.213 (122.1.164.213)  7.595 ms  10.062 ms  11.660 ms
 4  60.37.55.165 (60.37.55.165)  5.684 ms  5.660 ms  5.635 ms
 5  60.37.27.90 (60.37.27.90)  5.960 ms  5.924 ms  5.898 ms
 6  ae-11.r20.tokyjp01.jp.bb.gin.ntt.net (129.250.12.197)  86.468 ms  30.960 ms  30.899 ms
 7  as-1.r20.sttlwa01.us.bb.gin.ntt.net (129.250.4.189)  161.185 ms  144.343 ms  132.410 ms
 8  ae-1.r05.sttlwa01.us.bb.gin.ntt.net (129.250.5.47)  139.008 ms  127.377 ms  139.050 ms
 9  xe-0.sprint.sttlwa01.us.bb.gin.ntt.net (129.250.9.190)  116.006 ms  104.306 ms  115.954 ms
10  144.232.1.153 (144.232.1.153)  141.046 ms  129.870 ms  140.991 ms
11  sl-crs2-sj-0-5-2-0.sprintlink.net (144.232.18.204)  131.271 ms  131.248 ms  142.544 ms
12  sl-st31-sj-0-15-0-0.sprintlink.net (144.232.8.151)  129.543 ms  141.575 ms  141.066 ms
13  * * *
14  * * *
    .
    .
    .
29  * * *
30  * * *

Il tcpdump:

1   0.000000    114.178.88.59   66.211.169.66   TCP 76  37374 > https [SYN] Seq=0 Win=14520 Len=0 MSS=1452 SACK_PERM=1 TSval=68855 TSecr=0 WS=64
2   0.136291    66.211.169.66   114.178.88.59   TCP 80  https > 37374 [SYN, ACK] Seq=0 Ack=1 Win=4356 Len=0 MSS=1460 WS=1 TSval=3608913175 TSecr=68855 SACK_PERM=1
3   0.136322    114.178.88.59   66.211.169.66   TCP 68  37374 > https [ACK] Seq=1 Ack=1 Win=14528 Len=0 TSval=68889 TSecr=3608913175
4   0.137409    114.178.88.59   66.211.169.66   SSL 309 Client Hello
5   0.274446    66.211.169.66   114.178.88.59   SSL 95  [TCP Previous segment lost] Continuation Data
6   0.274469    114.178.88.59   66.211.169.66   TCP 80  [TCP Dup ACK 4#1] 37374 > https [ACK] Seq=242 Ack=1 Win=14528 Len=0 TSval=68923 TSecr=3608913175 SLE=2881 SRE=2908
7   7.117833    91.189.89.76    114.178.88.59   TLSv1   142 Application Data, Application Data
8   7.118823    114.178.88.59   91.189.89.76    TLSv1   216 Application Data, Application Data, Application Data, Application Data
9   7.393725    91.189.89.76    114.178.88.59   TCP 68  https > 41264 [ACK] Seq=75 Ack=149 Win=146 Len=0 TSval=875420654 TSecr=70634
10  60.301444   66.211.169.66   114.178.88.59   TCP 56  https > 37374 [RST, ACK] Seq=2908 Ack=242 Win=4597 Len=0

Questo è un ISP giapponese e anche se mi sto collegando con un cavo al modem / router, devo aggiungere un nome utente e una password, ma con la connessione "Wired" di Ubuntu non sono riuscito ad aggiungerli. La mia coinquilina mi ha detto di creare una connessione OCN ma non sono sicuro che sia un nome di un tipo di rete o solo la compagnia giapponese ... ma dopo aver visto il suo computer abbiamo scoperto che era una connessione PPPoE. Dopo aver cercato su Google ho imparato che per creare una connessione PPPoE avrei dovuto creare una connessione DSL e che avrei potuto aggiungere una password e un nome utente. Ho anche cambiato la connessione "Wired" per non connettermi automaticamente.

Ottengo lo stesso problema se collego direttamente al modem.

Ho provato a cambiare DSL MTU in 500, 1500, 1492 e 1482 ma non ha fatto differenza.

Inoltre, per qualche motivo Ubuntu non rileva sempre la connessione, a volte devo riavviare per collegarla.


questi siti non si aprono solo con curlo non si aprono anche con altri browser?
Adempewolff,

Non si aprono affatto, stavo solo cercando di scoprire dove si trova il problema ...
mind.blank

@ mind.blank - Cosa ti offre il browser quando provi a connetterti? Se non ottieni nulla dalla finestra principale, prova a installare Firebug (se usi Firefox; se usi Chrome, ha gli strumenti di sviluppo integrati), aprilo e attiva la console e le schede di rete e vedi se ci sono eventuali errori, quindi segnalarli qui.
Shauna,

Stavi usando il router prima o è nuovo? Inoltre, non hai fatto nulla di stupido e non hai aggiornato i tuoi pacchetti ssl o qualcosa da un'installazione predefinita? Sto accedendo bene a tutti quei siti (beh, almeno attraverso il mio proxy, la Cina blocca casualmente il protocollo ssl altrimenti), quindi immagino che il problema sia nel router o in un pacchetto aggiornato / installato.
Adempewolff,

@Shauna Sto usando Chrome e sta dicendo Error 7 (net::ERR_TIMED_OUT): The operation timed out. FireFox continua a provare a caricare ma non lo fa mai (la pagina non cambia). Console e Network non mi danno nulla ...
mind.blank

Risposte:


11

Questa è una vecchia domanda, ma per chi arriva qui tramite Google, questo sarà di aiuto. Il problema è che la frammentazione su SSL è errata e rompe il protocollo. Se si utilizza PPPOE, l'MTU normale nel modem router / DSL / via cavo è 1492. È troppo alto e causerà la frammentazione. 1476 è il numero magico che funzionerà con la maggior parte dei siti. Alcuni siti utilizzano diverse implementazioni SSL quindi 1480 potrebbe funzionare, o addirittura 1488. Per la MAGGIOR compatibilità, l'MTU sul lato WAN del dispositivo di rete (router, modem, ecc.) Dovrebbe essere 1476.


1
Non vedo come la frammentazione spezzerà SSL. I pacchetti frammentati verranno riassemblati dai router in IPv4. SSL si verifica su TCP, a un livello in cui non si dovrebbe notare questo. Penso che questo abbia a che fare con i valori MTU, ma non credo che la tua spiegazione sia valida. Penso che abbia a che fare con impostazioni MTU non sincronizzate su entrambe le estremità, con conseguente riassemblaggio errato di pacchetti frammentati. Il numero magico potrebbe funzionare nel tuo caso, ma non per altri.
gertvdijk,

Il bit DF (Dont Fragment) è sempre impostato sul traffico SSL in base alla progettazione: la frammentazione è un buco nella sicurezza. Un pacchetto SSL frammentato verrà eliminato il 99,9% delle volte. Un MTU troppo basso sul traffico PPoE causerà la frammentazione.
regretoverflow il

Questo è successo a me con il sito Web PayPal. Ho provato a sistemarmi con MTU 1476 e non ha funzionato, ma con 1480 ha funzionato. Grazie!
giocoso

Ho trascorso dalle 6 alle 14 cercando di risolvere questo problema fino a quando non ho trovato la tua risposta. Molto apprezzato!
WayBehind

1
mucca sacra! Questo mi ha permesso di sudo yum install docker-engineaggiungere il repo yum.dockerproject.org su un box CentOS 7: sudo ip link set mtu 1476 dev enp6s0per abbassare l'MTU dal suo valore predefinito da 1500 a 1476. Ho grattato la testa per un giorno cercando di capire perché yum.dockerproject.org era accessibile tramite https da altri nodi sulla stessa rete.
jwd630,

3

Ecco un paio di cose da provare:

  1. Controlla le impostazioni della tua scheda di rete. Nessuna delle tue interfacce eth mostra indirizzi IPv4. Assicurati di aver attivato IPv4 (potrebbe essere necessario ristabilire la connessione con il router per rinnovare l'IP). Se il problema persiste, provare a disattivare il supporto IPv6 e vedere se questo fa la differenza. Per fare ciò, fai clic con il pulsante destro del mouse sull'icona di rete accanto all'orologio (su una connessione Ethernet, è una coppia di frecce, una rivolta verso l'alto, l'altra verso il basso) e selezionando "Modifica connessioni ...". Nella scheda "Impostazioni IPv4", assicurati che sia impostato su "Automatico (DHCP)". Se vuoi disattivare IPv6, vai alla sua scheda e impostalo su "Ignora".

  2. Controlla se riesci a connetterti ai siti usando altri metodi. A cosa pingrisponde per i siti ai quali non è possibile connettersi? Che ne dici di un traceroute(potresti dover installare traceroute per usarlo, FYI)? Le loro risposte potrebbero aiutarti a risolvere il problema. Se non riescono ad accedere ai server dell'URL, potrebbe trattarsi di un problema DNS (tuttavia, se riescono ad accedere ai server dell'URL, ma vengono quindi rilasciati, potrebbe significare solo che quei comandi sono bloccati).

  3. Bypassa il router. Se il tuo router e il tuo modem sono due macchine diverse, prova a collegare il tuo computer direttamente al tuo modem e vedi se questo cambia qualcosa.

  4. Riavvia il modem e il router. A volte fanno semplicemente schifo.

  5. Riavvia il tuo computer. A volte fanno semplicemente schifo.

  6. Prova un altro computer. Se ne hai uno, un altro computer funziona dove questo fallisce? In caso contrario, potrebbe essere qualcosa con il tuo computer specifico.

  7. Svuota la cache del computer, i cookie, ecc. A volte, i cookie di sessioni errate, la cache, ecc. Possono interferire con la connessione a un sito (ho avuto questo problema con Google qualche tempo fa). Eliminali e ricomincia da capo e vedi cosa ottieni.

  8. Disconnetti tutte le connessioni VPN. Il protocollo Point-to-Point viene spesso utilizzato per VPN (interfaccia PPP) e le VPN possono interferire con la connessione ai siti. Assicurati di non essere connesso facendo clic con il tasto destro sull'icona della rete accanto all'orologio, trovando la voce "Connessioni VPN" e assicurandoti che nessun elenco sia selezionato (se non hai una voce di menu "Connessioni VPN", allora non ne ho impostato uno). Se ci sono dei segni di spunta, allora sei connesso ad esso, disconnettiti da esso.

Ricorda: non tutto ciò che fai si tradurrà in un semplice "lavoro o fallimento", qualsiasi cambiamento nella reazione del server alla tua richiesta ci dirà qualcosa. Quindi, se esegui una delle operazioni precedenti e ricevi un nuovo messaggio, non dimenticare di aggiornare la tua domanda.


1) Spiacente, non sono sicuro di come fare entrambe queste cose. cyberciti.biz/faq/setting-up-an-network-interfaces-file - non sono sicuro di quali indirizzi IP aggiungere. 2) Ho aggiunto entrambi quelli nella domanda originale. 3) Vedrò se ho quell'opzione domani (modem ecc. È nella stanza di Roomate). 4) Come sopra, anche se almeno ho riavviato il router. 5) Provato alcune volte. 6) Non ho un altro comp con Ubuntu, queste connessioni funzionano comunque quando passo a Windows. 7) Ho provato quello.
mind.blank,

@ mind.blank Non devi fare nulla del genere nel link. Basta fare clic con il tasto destro sull'icona di rete accanto all'orologio e selezionare "Modifica connessioni ...". Fare clic sulla connessione e selezionare "Modifica" e selezionare la scheda "Impostazioni IPv4" e assicurarsi che sia impostato su "Automatico (DHCP)". Poi vai alla scheda "Impostazioni IPv6" e assicurarsi che "Richiedi l'indirizzamento IPv6 per questa connessione al completo" è un controllati. Salva e riconnetti. Se / quando si desidera disattivare IPv6, tornare alla scheda Impostazioni IPv6 e modificare "Automatico" in "Ignora".
Shauna,

In Connessioni di rete> DSL> Modifica, le impostazioni IPv4 sono su "Automatico (PPPoE)" e non è presente alcuna scheda IPv6 ...
mind.blank

2

Ho visto questo comportamento due volte in pratica per il quale ho trovato le seguenti soluzioni.

  • Alcuni computer della rete locale stavano tentando con successo un attacco man-in-the-middle. Stava falsificando l'ARP del gateway, reindirizzando così tutto il traffico attraverso questa macchina, modificando le richieste e altre cose brutte. La macchina stava eseguendo Windows e si è rivelata infetta da malware dannoso. Non appena questa macchina è stata scollegata fisicamente dalla rete, i sintomi sono scomparsi.
  • Un problema MTU sul tuo o su un altro gateway. In IPv4 i gateway sono responsabili della frammentazione e del riassemblaggio dei pacchetti IP sulla rete se la dimensione dei frame delle reti per le quali sta instradando il traffico non è la stessa. Per le connessioni DSL che utilizzano PPPoE / PPPoA la dimensione MTU è generalmente inferiore ai 1500 byte sul lato LAN. Anche i router intermedi falliscono ed è necessario abilitare il Clamping MSS TCP sul router. Ho sempre avuto bisogno di impostare questo sulla connessione del mio precedente ISP, ma stava risolvendo molto più dei semplici problemi relativi a SSL. Controlla se il tuo modem / router ha tale opzione. Considera questo come una soluzione alternativa.
  • Probabilmente ero in una rete che eseguiva un proxy trasparente per passare anche il traffico SSL, ma per qualche motivo non riuscivo a TLSv1. La stessa richiesta ha funzionato quando si utilizza una connessione VPN. spaventoso
    Prova a correre curlcon l'opzione --sslv3. Se questo lo risolve, allora puzza.

Cose generali da provare:

  • Controlla se stai eseguendo l'ultimo firmware sul tuo modem / router. In caso contrario, prova ad aggiornare.
  • Cattura il traffico utilizzando tcpdumpo Whireshark e fallo analizzare (pubblicalo qui per esempio).

      # 1. start the dump
    $ sudo tcpdump -w httpstrafficdump.pcap -i eth0 -s 0 port 443
      # 2. open a new terminal window and do your HTTPS request there (curl/browser)
      # 3. end tcpdump (Ctrl+C)
      # 4. open the file in wireshark
    $ wireshark httpstrafficdump.pcap
    

    Se stai perdendo ripetutamente errori di riassemblaggio o il segmento precedente , questo è un chiaro segno della perdita di pacchetti causata da una dimensione MTU errata.
    Tuttavia, il traffico HTTPS è crittografato e difficile da analizzare dal traffico di rete da solo.

Modificare:

Dal tuo tcpdump la radice del problema SSL è chiara: TCP Previous segment lost. La risoluzione dei problemi generali di rete dovrebbe essere applicata qui, ma potrebbe essere al di fuori dell'ambito della rete locale e un problema con l'ISP.


Ho provato a eseguire il ricciolo con --sslv3e ancora non funziona. Inoltre ho provato a catturare il dump ma non sembra funzionare? tcpdump: WARNING: eth0: no IPv4 address assigned 0 packets captured 6 packets received by filter 0 packets dropped by kernel- Non sono sicuro di come assegnare l'IPv4 ... Domani dovrò provare il resto perché si sta facendo tardi e il mio cervello non funziona bene. Grazie per il vostro aiuto a tutti finora!
mind.blank,

@ mind.blank Per te è ppp0un'interfaccia anziché la eth0quale mi fa pensare: Perché hai bisogno di PPP per una connessione quando usi un router?
gertvdijk,

La normale connessione "Wired" non ha rilevato nulla. Ora ho aggiunto il tcpdump in fondo alla mia domanda con alcuni dettagli in più sul perché sto usando PPPoE. Inoltre, se hai bisogno di ulteriori informazioni dalla discarica, per favore dimmelo.
mind.blank,

@ mind.blank Il dump è molto utile, ma non punta a una soluzione. Vedi la mia risposta aggiornata.
Gertvdijk,

0

Salve a tutti, questo è marcovaleriof dall'Italia, recentemente abbiamo avuto un problema simile al vostro: tutta la nostra macchina Linux non poteva più connettersi a qualsiasi sito Web https mentre Android o Windows Device non avevano problemi. Il problema era un disallineamento mtu tra il nostro router DSL che aveva una lunghezza di 1492 mtu e il mtu Linux predefinito che è 1500. In realtà, emettendo questo comando come root

ifconfig wlan0 mtu 1492 up

(in inglese questo set Il valore mtu dell'interfaccia di rete - wlan0 nel mio caso - a 1492 di lunghezza) ha eliminato il problema, grazie! Spero che questo possa aiutare qualcuno.


-2

Grazie per tutto il tuo aiuto, il problema è finalmente risolto!

Stavo cercando di limitare l'MTU per vedere se sarebbe stato d'aiuto e ho finito per usare pppoeconfla connessione PPPoE poiché limita l'MTU per me. Ho quindi disabilitato la connessione DSL che ho usato in precedenza.

Per chiunque abbia un problema simile, puoi provare questa soluzione digitando sudo ppoeconfe seguendo le istruzioni. Quindi è possibile connettersi con pon adsl-providere disconnettersi conpoff

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.