Wêrom OpenConnect-siden hingje oant jo de MTU fan de tunnel ferleegje
Lytse antwurden komme oan, grutte stjerre. Mjitte it plafond fan it paad mei DF-probes, set de grutte op it tunnelapparaat en soargje dat de wearde in werferbining oerlibbet.
Oanmelde slagget, de foarside fan it portaal wurdt tekene, en dan bliuwt in dashboard-widget of in rapport op waiting for host stean oant de browser it opjout. Iepenbiere siden lade de hiele tiid normaal, en gjin inkel oanmeldgegevens is feroare. Dat lytse antwurden oankomme wylst grutte fêstrinne is de sinjatuer fan in plafond foar pakketgrutte en net fan in tagongsregel. Befêstigje dy lêzing foardat jo eat oars yn it profyl feroarje.
Skied in grutteprobleem fan in beliedsprobleem
Begjin mei it útsluten fan in ôfwizing. Hie de gateway jo wegere, dan soe de ferbining daliks mislearre wêze ynstee fan in side heal te laden. In tunnel dy't omheech komt en dan allinnich by gruttere oerdrachten fêstrint, fertelt jo dat it bûtenpaad it binnenpakket net drage kin.
It meganisme is ynkapseling. Elk binnenpakket krijt tunnelkoppen, sadat in lading dy't yn 'e fysike link past in bûtenpakket wurdt dat der net mear yn past, en alles wat it do-not-fragment-bit draacht wurdt weilitten sûnder antwurd dat de browser ynterpretearje kin.
Mjitte it plafond mei do-not-fragment-probes
Mjitte it plafond ynstee fan it te rieden. Stjoer probes dy't fragmintaasje wegerje en ferleegje de lading stap foar stap oant der in antwurd weromkomt, te begjinnen mei in opdracht lykas ping -M do -s 1472 host. In antwurd dat kleit dat fragmintaasje nedich is wylst DF ynsteld is, betsjut dat de wearde noch te heech is. Werhelje op 1462, dan 1452, en stop by de earste grutte dy't weromkomt. Skriuw it getal op tegearre mei de host dy't jo probearre hawwe, want it antwurd heart by dat paad en net by it protokol yn 't algemien.
Probearje it adres dêr't de tunnel echt ferkear nei stjoert. In bûtenprobe tsjin 'e iepenbiere namme fan 'e gateway en in binnenprobe tsjin in ynterne tsjinner mjitte ferskate hops, en ICMP-filtering op ien fan beiden kin in sûn paad brutsen lykje litte.
Pas de wearde op it tunnelapparaat ta
Pas it resultaat ta op 'e ynterface dy't de klient makke hat, net op 'e Wi-Fi-adapter. Op in Linux-klient is dat ip link set dev tun0 mtu 1300 folge troch ip link show tun0 om te befêstigjen dat de wearde oannaam is. Brûk hokker apparaatnamme de klient ek meldt, want dy feroaret mei de ymplemintaasje en mei hoe't de tunnel boud is.
It ferleegjen fan 'e tunnel-MTU krimpt de lading dy't elk pakket draacht, sadat de trochset wat sakket, en dat is de priis om grutte antwurden net yn in swart gat te smiten. In lytser getal is net automatysk feiliger. It feroarjen fan 'e fysike adapter ferspriedt de skea oer elke ferbining op dy link wylst te grutte binnenpakketten like te grut bliuwe.
Brûk earst de eigen MTU-fersiken fan 'e klient
As jo de oanrop beheare, kin de klient om in grutte freegje ynstee fan efterôf patcht te wurden. --mtu freget in tunnel-MTU by de tsjinner oan, en --base-mtu ferklearret de MTU fan it ûnderlizzende paad sadat de gateway it tunnelsifer ôfliede kin. Beide binne fersiken, en de hânlieding fan 'e klient ûnthjit net dat de gateway ien fan beiden earje sil.
Dat ferskil bepaalt jo wurkfolchoarder. Probearje earst it fersyk en besjoch de ynterface dy't it opleveret, en fal dan werom op it lokaal ynstellen fan it apparaat as de wearde dy't de gateway keas noch fêstrint.
Ferifiearje mei de oerdracht dy't mislearre, en meitsje it dan duorsum
In lokale ip link feroaring hâldt oant de klient de tunnel op 'e nij bout, wat by de folgjende werferbining of fuortsetting bart. Set de wearde dêr't de ferbining begjint: in wrapper dy't de klient rint en dan it apparaat oanpast, in systemd-ienheid mei in ExecStartPost-stap, of de kliïntopsje as de gateway dy akseptearret. Hâld it neist it profyl yn ferzjearegeling sadat de folgjende persoan sjocht wêrom't it getal dêr stiet.
Test mei it fersyk dat mislearre, net mei de foarside. Iepenje it rapport, helje de taheakke op of rin de repository-fetch dy't hong, en notearje krekt wêr't it stopt as it noch stopt. In side dy't nei de feroaring tekene wurdt, bewiist net folle, want dy waard ek earder tekene.
As deselde oerdracht op itselde punt fêstrint, is de MTU-teory ûnbewiisd. Fange ferkear op 'e tunnel en kontrolearje hokker kant ophâldt mei stjoeren foardat jo it getal wer feroarje, en hâld de foarige wearde fêstlein sadat in weromrôljen ien opdracht bliuwt.