Konteinerā HTTPS iekaras uzņēmuma VPN? Pārbaudiet DTLS kāju

Konteinerā aiz uzņēmuma VPN DNS tiek atrisināts, pieteikšanās lapa ielādējas, veselības galapunkts atbild, un tad HTTPS pieprasījums iekaras, līdz beidzas laiks. Attēla pārbūve un starpniekservera mainīgo maiņa neko nemaina, jo bojātā daļa nav attēlā. Klients autentificējas pa vienu transportu un lielus datus pārvieto pa citu, un bojāts ir tikai otrais.

Divi transporti, viens mulsinošs simptoms

Uz TLS balstīts uzņēmuma klients parasti autentificējas pa parastu TLS savienojumu un pēc tam sesijai vienojas par otru uz UDP balstītu datu kanālu. Kad šī otrā kāja darbojas, uzlabojas caurlaidspēja un latentums. Kad tā tiek filtrēta vai neietilpst ceļā, viss pirms lielās pārsūtīšanas izdodas, un pati pārsūtīšana apstājas, kas ir tieši iepriekš aprakstītais modelis.

Konteiners šīs sarunas nemaina; tas maina ceļu, pa kuru iet ārējie paketes. Resursdators pārtulko konteinera plūsmu, tāpēc UDP datagrammas iziet no cita avota porta nekā klienta lokālā ligzda un atgriežas caur tulkošanas ierakstu, kas beidzas ar daudz īsāku taimeri nekā izveidota TCP plūsma. Ja tunelis darbojas resursdatorā un neizdodas konteinerā, salīdziniet šīs divas plūsmas, pirms vainojat lietojumprogrammu. Šis salīdzinājums izšķir vairāk nekā jebkura attēla pārbūve.

Izlemiet ar eksperimentu, nevis intuīciju

Lētākais eksperiments izslēdz UDP datu kanālu un atkārto pieprasījumu. Izmantojiet komandrindas klientu, nevis darbvirsmas ietvaru, lai karodziņš tiešām tiktu piemērots: openconnect vpn.example.net --user=you --interface=tun0 --no-dtls. Ja pieprasījums, kas iekārās, tagad pabeidzas, problēma bija DTLS kāja un pārējais bija troksnis.

Apstipriniet rezultātu abos virzienos no tā paša konteinera: viens liels pieprasījums ar karodziņu un viens bez. Uzvedības izmaiņas, kas seko karodziņam, ir pierādījums; lapa, kas beidzot ielādējas, nav.

Ja karodziņš to salabo, izlemiet kāpēc

Trīs nosacījumi rada vienu un to pašu simptomu, un tiem vajadzīgas atšķirīgas atbildes. Ceļš var pilnībā filtrēt UDP, kas karodziņu padara par pareizo pastāvīgo atbildi šim tīklam. Ceļš var atļaut UDP, bet izmest lielas datagrammas, kas norāda uz MTU, nevis filtrēšanu. Vai arī ceļš var būt tik zudumiem bagāts, ka UDP kāja darbojas sliktāk nekā TCP, un tas ir jaudas, nevis sasniedzamības lēmums.

Atšķiriet tos, pirms dokumentējat apiešanas risinājumu. Filtrēšana iztur jebkuru pakešu izmēru, MTU problēmas parādās tikai virs sliekšņa, un zudumi izpaužas kā atkārtota sūtīšana un mainīgs aizture, nevis tīra iekāršanās. Katrs tests sašaurina cēloni, nemainot klienta konfigurāciju.

Pārbaudiet paketes izmēru, pirms atstājat apiešanas risinājumu

Ja cēlonis ir izmērs, tuneļa saskarne pieņem paketes, ko ceļš nevar nest, un problēma atgriežas jebkurā transportā, tiklīdz pieaug lietderīgā slodze. Salīdziniet saskarnes: ip link show tun0 resursdatorā, pēc tam docker network inspect bridge, lai nolasītu tīkla opcijās ierakstīto MTU. Konteinera tilts, kas joprojām ir 1500 baitos zem tuneļa, kurš nes mazāk, ir ierasts atradums.

Pētiet uz augšu no zināma laba izmēra ar aizlieguma sadalīt testu tuneļa iekšpusē, pēc tam pazeminiet konteinera tīkla MTU vai savelciet TCP MSS tunelī. Jebkurš no labojumiem bieži atkal padara UDP ceļu lietojamu un novērš karodziņa vajadzību, kas ir labāks iznākums, ja filtrēšana nav cēlonis.

Izlemiet, ko esat gatavs apmainīt

Ar izslēgtu datu kanālu tunelis nes savu slodzi TCP savienojuma iekšpusē. Tīrā ceļā tas ir tikai lēnāk; zudumiem bagātā ceļā viens pazaudēts segments aizkavē visu aiz tā un ārējā atkārtotā sūtīšana konkurē ar iekšējo. Šī maiņa der interaktīvai izstrādei un maziem API izsaukumiem, un slikti der lielām pārsūtīšanām vai garām sesijām mobilajos tīklos.

Lai kuru variantu izvēlētos, pierakstiet, kādu transportu tunelis beigās izmantoja un kāpēc. Konteiners, kas klusi paļaujas uz karodziņu, ko kāds pievienoja pirms mēnešiem, ir nākamā avārija, un tas, kurš to atkļūdos, nezinās, vai karodziņš bija filtrēšanas apiešana vai MTU eksperimenta palieka.