NFS TCP kaudu OpenVPN UDP-tunnelis: kaks transporti
Paigaldusprotokoll ja tunneliprotokoll on eraldi seaded. Kirjutage mõlemad üles ja otsustage seejärel, kas tõrge kuulub failiteenuse või kandja juurde.
NFS-i vestluse, mis kasutab TCP-d, vedamine tunnelis, mis veab UDP-d, on täiesti järjekindel, ja see ajab inimesi segadusse, sest nimetab korraga kahte transporti. TCP on failiteenuse vestlus kliendi ja NFS-serveri vahel. UDP on krüpteeritud kandja VPN-i lõpp-punktide vahel. Kumbki ei ütle teise kohta midagi.
Kirjutage mõlemad eraldi üles enne, kui hakkate midagi siluma; enamik neist juhtumitest algab sellest, et keegi muudab vale kihti.
Kaks kihti, kaks seadet
Paigaldusvalik proto=tcp kirjeldab, kuidas NFS-klient NFS-serveriga räägib. VPN-profiili säte proto udp kirjeldab, kuidas tunneli lõpp-punktid vahetavad kapseldatud pakette. Paigaldusvaliku muutmine ei muuda tunnelit ja tunneli transpordi muutmine ei muuda seda, mille osas NFS-klient kokku leppis. Kinnitage tegelikud paigaldusvalikud käsuga nfsstat -m, mitte fstab-rea järgi, ja kinnitage VPN-i transport profiilist, mida tegelikult kasutatakse.
Seejärel kirjutage need juhtumi märkmetesse kahe eraldi väljana. Näiline paranemine on jälgitav ainult siis, kui märge ütleb, milline kiht muutus.
Sirvimine ei ole hulklugemine
Kataloogi loend tõestab, et mõned toimingud said tehtud. See ei tõesta, et pikaajaline lugemine, kirjutamine, lukustus või salvestuskiht lõpeb samades tingimustes. Suure faili keskel tekkiv tõrge on teistsugune tähelepanek kui paigaldus, mis ei õnnestu kunagi, ja need osutavad eri kihtidele.
Kirjeldage ebaõnnestuvat toimingut täpselt: tee, suund, tõrke ligikaudne punkt ja viimane oluline sündmus kliendi, serveri ja VPN-i logides. Seejärel võrrelge, kus liiklus jätkub ja kus see peatub.
MTU on hüpotees, mitte diagnoos
Paketi suurusest sõltuv kadu on tõeline võimalus, kui tunnel veab suuri segmente, ja see tekitab täpselt mustri, kus sirvimine töötab ja lugemine takerdub. See muster ei tõesta siiski MTU-probleemi, sest sama kuju ilmneb siis, kui server on aeglane, tulemüür lõpetab pika ühenduse ajalõpu tõttu või ketas on hõivatud. Kontrollige hüpoteesi juhitava katsega, selle asemel et MTU-d kõikjal alandada ja võitu kuulutada.
Ajalõpp iseenesest ei ütle midagi selle kohta, kas UDP tuleks välja vahetada. See on sümptom, millel on mitu võimalikku omanikku.
Muutke korraga ühte muutujat
Transpordi võrdlemisel hoidke NFS-i töökoormus ja kõik muud seaded muutumatuna. Paigaldustranspordi, tunneliprotokolli ja MTU muutmine samas hooldusaknas annab tulemuse, mida keegi ei saa omistada. Käivitage sama failitoiming enne ja pärast ning kirjutage tulemus igal sammul üles.
Hoidke varasemad väärtused ka piletis. Kui muudatus teeb asjad hullemaks, peaks tagasipöördumine olema dokumenteeritud number, mitte kellegi mälestus sellest, kuidas varem oli.
Lugege seda kihti, mis ei töötanud
Kui tunnel on püsti ja NFS-päring ootab, siis VPN ei ebaõnnestunud; ebaõnnestus failiteenus. Kui tunnel langes, on NFS-päringu ebaõnnestumine tagajärg, mitte põhjus. Mõlema kihi logiridade kõrvutamine on kiireim viis nende kahe juhtumi eristamiseks ja see on parem kui failihaldurist oletamine.
Kirjutage järeldus kahe lausena, üks kihi kohta. Sellest piisab, et järgmine inimene saaks testi korrata, ilma et ta peaks uuesti tuletama, milline transport on milline.