SSH SSH2_MSG_KEX_ECDH_REPLY-n blokeatzen da: ez da beti MTU

Tunela martxan dago, bannerra iristen da eta bezeroak gako-trukearen erantzunaren zain dagoela dioen mezua inprimatzen du. Bilaketa-emaitzek zuzenean MTU-ra eramaten dute, eta batzuetan zuzena da. Sarritan ez: erantzuna inoiz bidali ez zelako, bezeroak ezin izan zuelako gako-fitxategi bat irakurri edo bi muturrak inoiz ez zirelako algoritmo batean ados jarri. Lerroak bezeroak zer itxaroten duen deskribatzen du, ez zergatik hasi zen itxaronaldia. Sintoma gisa hartu eta hiru kausak bereizi edozein tamaina aldatu aurretik.

Irakurri arrastoa ea erantzunik espero zen ikusteko

Irteera zehatzak isiltasunaren aurreko azken urrats arrakastatsua erakusten du. Zerbitzariaren protokolo-bannerra iritsi bada, TCP funtzionatzen ari da eta urruneko muturra bizi da; irekitako galdera pakete zehatz bati zer gertatu zitzaion da. Bannerraren ondorengo minutu bateko isiltasuna bide-arazo bat dirudi. Gako-truke metodo bateragarririk ezari buruzko mezua politika-arazoa da. Zerbitzariak saioa ixtearekin amaitzen den itxaronaldi luzeak zerbitzariak amore eman zuela esan nahi du, eta haren erregistroak zergatia azaltzen du.

Azken kasuan, irakurri zerbitzariaren autentifikazio-erregistroa bezeroa ukitu aurretik. Bezeroak ezin du zerbitzariak inoiz bidali ez zuen erabaki bat ikusi.

Zergatik erantzun txiki bat oraindik handiegia izan daitekeen

Gako-trukearen erantzunak normalean txiki-txikiak dira, beraz tamaina erruduntzea okerra dirudi. Ostalari-ziurtagiriekin erantzuna ez da txikia, zerbitzariaren ziurtagiri-katea daramalako. Horrek saioan tunelaren karga erabilgarria gaindi dezakeen lehen paketea bihurtzen du. Bide-MTUaren aurkikuntza-feedbacka ibilbidean zehar nonbait galtzen denean, bidaltzaileak sartzen ez den paketea behin eta berriz berbidaltzen du, eta bezeroak betiko itxaroten du lerro berean.

Zehaztu tamaina suposatu ordez. Irakurri tunelaren MTU ip link show tun0 erabiliz, eta gero bidali zatitu behar ez diren probeak: ping -4 -M do -s 1352 host, karga txikiagoez errepikatuta. Tamaina jakin batean hutsetik arrakastara aldatzea froga da; hutsegite uniformeak ICMP iragazita dagoela iradokitzen du eta ez dizu ezer esaten.

Behin-behineko murrizketak teoria azkar baieztatzen du, eta bertsio iraunkorra profilean edo tunela aurrera eramaten duen routerrean MSS muga gisa doa:

sudo ip link set dev tun0 mtu 1200
sudo iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Tamaina-arazoa imitatzen duten bi kausak

Bezeroak irakurri ezin duen gako-fitxategi batek itxaronaldi bera sortzen du, abisurik gabe irteera zehatzean ere. known_hosts-en eredu batek erraz egiten du: CA gako publiko bat seinalatzen duen @cert-authority sarrera, kontu bakarrak irakur dezakeena. Fitxategiaren jabe den kontua konektatzen da, eta beste kontu guztiak blokeatzen dira. Hutsegiteak ostalaria beharrean erabiltzailea jarraitzen badu, egiaztatu fitxategi-moduak pakete-tamainen aurretik.

Eguneraketa batek bi muturrek lehenago partekatzen zuten algoritmoa ere kendu dezake. Ainguratu zerbitzariak oraindik eskaintzen duen metodo bat diagnostiko gisa: ssh -oKexAlgorithms=ecdh-sha2-nistp521 user@host. Berehala arrakasta duen konexioak bidea ondo dagoela frogatzen du, eta konponketa bi aldeetako negoziazio-politikari dagokio.

Idaztea merezi duten hiru datu

Idatzi tunelaren MTU edozein aldaketaren aurretik eta ondoren, fitxategi handi baten kopia tamaina errepikagarri batean huts egiten duen eta tunel bereko ziurtagiririk gabeko ostalari bat berdin blokeatzen den. Hiru behaketa horiek tamaina baimenetatik eta negoziaziotik bereizten dute komando-meta bat baino azkarrago.

Horiek ere eragozten diote hurrengo pertsonari MTU jaistea inoiz tamainari buruzkoa izan ez zen akats batengatik.

Irudiak oraindik argi ez badago, probatu tunel bereko bigarren bezero batetik. Konektatzen den bezeroak akatsa bidetik lehenengo makinaren konfiguraziora eramaten du.