Prijava uspije, naslovna stranica portala se iscrta, a zatim widget na nadzornoj ploči ili izvještaj ostane na waiting for host dok preglednik ne odustane. Javni sajtovi se cijelo vrijeme učitavaju normalno i nijedan akreditiv se nije promijenio. Dolazak malih odgovora dok veliki zapinju potpis je plafona veličine paketa, a ne pravila pristupa. Potvrdite to čitanje prije nego što u profilu promijenite bilo što drugo.

Odvojite problem veličine od problema politike

Počnite tako što ćete isključiti odbijanje. Da vas je gateway odbio, veza bi odmah propala umjesto da napola učita stranicu. Tunel koji se podigne i zatim zapne samo na većim prijenosima govori vam da vanjska putanja ne može nositi unutrašnji paket.

Mehanizam je enkapsulacija. Svaki unutrašnji paket dobija zaglavlja tunela, pa korisni teret koji stane u fizičku vezu postaje vanjski paket koji više ne staje, a sve što nosi bit do-not-fragment odbacuje se bez odgovora koji preglednik može protumačiti.

Izmjerite plafon DF sondama

Izmjerite plafon umjesto da ga pogađate. Šaljite sonde koje odbijaju fragmentaciju i smanjujte teret korak po korak dok se odgovor ne vrati, počevši od naredbe poput ping -M do -s 1472 host. Odgovor koji se žali da je potrebna fragmentacija dok je DF postavljen znači da je vrijednost još previsoka. Ponovite na 1462, zatim na 1452, i zaustavite se na prvoj veličini koja vrati odgovor. Zapišite broj zajedno s hostom koji ste sondirali, jer odgovor pripada toj putanji, a ne protokolu općenito.

Sondirajte adresu na koju tunel stvarno šalje promet. Vanjska sonda prema javnom imenu gatewaya i unutrašnja sonda prema internom serveru mjere različite hopove, a ICMP filtriranje na bilo kojoj može učiniti da zdrava putanja izgleda pokvareno.

Primijenite vrijednost na uređaj tunela

Primijenite rezultat na sučelje koje je klijent stvorio, a ne na Wi-Fi adapter. Na Linux klijentu to je ip link set dev tun0 mtu 1300 , a zatim ip link show tun0 da potvrdite da je vrijednost prihvaćena. Koristite ono ime uređaja koje klijent prijavi, jer se ono mijenja s implementacijom i s tim kako je tunel izgrađen.

Smanjenje MTU-a tunela skraćuje teret koji nosi svaki paket, pa ukupna propusnost malo pada, i to je cijena toga da veliki odgovori ne završe u crnoj rupi. Manji broj nije automatski sigurniji. Promjena fizičkog adaptera umjesto toga raspršuje štetu na svaku vezu na tom spoju, dok preveliki unutrašnji paketi ostaju jednako preveliki.

Najprije upotrijebite klijentove vlastite MTU zahtjeve

Kada vi kontrolirate poziv, klijent može zatražiti veličinu umjesto da bude naknadno zakrpan. --mtu traži MTU tunela od servera, a --base-mtu objavljuje MTU donje putanje kako bi gateway mogao izvesti broj tunela. Oba su zahtjevi, a klijentov priručnik ne obećava da će gateway uvažiti bilo koji od njih.

Ta razlika određuje vaš redoslijed rada. Najprije pokušajte zahtjev i pregledajte sučelje koje on proizvede, a zatim se vratite na lokalno postavljanje uređaja ako vrijednost koju je gateway odabrao još zapinje.

Provjerite prijenosom koji je propao, zatim ga učinite trajnim

Lokalna promjena ip link traje dok klijent ponovno ne izgradi tunel, što se događa pri sljedećem ponovnom povezivanju ili nastavku. Stavite vrijednost tamo gdje veza počinje: omotač koji pokreće klijent i zatim podešava uređaj, systemd jedinica s korakom ExecStartPost, ili klijentova opcija kada je gateway prihvati. Držite je uz profil u sustavu za kontrolu verzija da sljedeća osoba može vidjeti zašto je broj tamo.

Testirajte zahtjevom koji je propao, a ne naslovnom stranicom. Otvorite izvještaj, povucite privitak ili pokrenite dohvat repozitorija koji je zapeo, i zabilježite točno gdje se zaustavlja ako se još zaustavlja. Stranica koja se iscrta nakon promjene dokazuje malo, jer se iscrtavala i prije.

Ako isti prijenos zapne na istom mjestu, teorija o MTU-u nije dokazana. Snimite promet na tunelu i provjerite koja strana prestaje slati prije nego što ponovno promijenite broj, i držite prethodnu vrijednost zabilježenu da vraćanje ostane jedna naredba.

Povezani članci