Virtio पर pfSense: ऑफ़लोड बंद होने तक TCP ठहर जाता है

एक क्लाइंट बताता है कि टनल जुड़ती है, पिंग जवाब देता है, लॉगिन पेज लोड होता है, और फिर हर प्रयास में ट्रांसफ़र उसी जगह जम जाता है। यह पैटर्न पहले ही बहुत कुछ कह देता है: पहुँच काम करती है और लगातार थ्रूपुट नहीं। फ़ायरवॉल खोलने से पहले पता लगाएँ कि VPN इस विफलता में है ही या नहीं। उसी गेटवे से बिना टनल के बड़ा TCP भेजें; अगर वह भी जम जाए, तो OpenVPN कभी शामिल ही नहीं था।

virtio नेटवर्क कार्ड वाले pfSense गेस्ट के पास ठीक इसी आकार में विफल होने का बहुत अच्छा कारण है।

छोटे पैकेट निकल जाते हैं, भारी TCP अटक जाता है

हैंडशेक, DNS जवाब और ICMP प्रतिध्वनियाँ छोटी होती हैं और आमतौर पर निकल जाती हैं। लगातार ट्रांसफ़र गेस्ट को खंडित करने पर मजबूर करते हैं, और वहीं क्षतिग्रस्त ऑफ़लोड पथ सामने आता है। खराबी का सममित होना ज़रूरी नहीं: बाहर जाने वाला ट्रैफ़िक साफ़ रह सकता है जबकि अंदर आने वाला गिर जाए, या उलटा, इसलिए उपयोगकर्ता लॉगिन कर सकता है और फिर पहले बड़े जवाब पर अटक सकता है। चूँकि वही क्लाइंट किसी दूसरे गेटवे से काम करता है, दोष नए घटक पर डाला जाता है।

इसलिए टनल के बिना गेटवे की जाँच करें। कुछ सेकंड चल सके इतनी बड़ी LAN-से-WAN डाउनलोड काफ़ी है, और यह किसी भी सेटिंग बदलाव से पहले करनी चाहिए ताकि बाद की तुलना का कोई अर्थ हो।

ऑफ़लोड वास्तव में क्या वादा करता है

virtio पैरावर्चुअल है: होस्ट और गेस्ट काम बाँटते हैं, होस्ट चेकसम और खंडन क्षमताओं की घोषणा करता है और उम्मीद करता है कि गेस्ट वह पूरा करे जो उसने शुरू किया। अगर गेस्ट का स्टैक ऐसा नहीं करता, तो फ़्रेम अधूरे चेकसम के साथ निकलते हैं या होस्ट उन्हें गिरा देता है। एम्युलेटेड E1000 सरल और धीमा मॉडल देता है जिसमें pfSense में एक भी बदलाव के बिना समस्या गायब हो जाती है। क्षमता की बातचीत हर डिवाइस के लिए अलग होती है, जो समझाती है कि क्यों एक गेस्ट महीनों चलता है जबकि उसका फिर से बनाया गया जुड़वाँ पहले ही दिन विफल हो जाता है।

तय किया गया सेट हाइपरवाइज़र संस्करण और चुने गए NIC मॉडल पर निर्भर करता है, केवल आपके आयात किए गए कॉन्फ़िगरेशन पर नहीं।

एक चेकबॉक्स virtio रखता है

pfSense इंटरफ़ेस में, सिस्टम फिर उन्नत फिर नेटवर्किंग में हार्डवेयर चेकसम ऑफ़लोड अक्षम करें नाम का चेकबॉक्स है। इसे चुनने पर गेस्ट सॉफ़्टवेयर में चेकसम गिनता है, जो pfSense के पीछे का FreeBSD स्टैक पैरावर्चुअल डिवाइस से जो अपेक्षा करता है उससे मेल खाता है। उसी पेज पर दो संबंधित विकल्प हार्डवेयर TCP खंडन ऑफ़लोड और हार्डवेयर बड़े रिसीव ऑफ़लोड को कवर करते हैं। जब हैंडशेक सफल हों पर भारी ट्रांसफ़र न हों, तब इन्हीं की ओर जाएँ।

बदलाव करते समय NIC को virtio ही रहने दें। E1000 पर जाने से VM के पूरे जीवनकाल में हर पैकेट पर CPU जलता है और होस्ट विरासत में पाने वाले किसी भी व्यक्ति से कॉन्फ़िगरेशन की समस्या छिप जाती है, जो थोड़े धीमे पर अनुमानित डेटा पथ से बदतर सौदा है।

अभी जो लागत स्वीकार की है उसे मापें

सॉफ़्टवेयर चेकसमिंग काम को गेस्ट में ले जाती है, इसलिए यह मानने के बजाय कि इसकी कोई कीमत नहीं, बाद में थ्रूपुट मापें। छोटी VM पर दंड वास्तविक है, पर वह दिखाई देता और स्थिर है, खामोश नुकसान के विपरीत। पहले और बाद में इंटरफ़ेस त्रुटि काउंटर और गेस्ट का कर्नेल लॉग तुलना करें। ब्रिज को फ़िल्टर करने वाला हाइपरवाइज़र अलग साक्ष्यों वाली अलग खराबी है, और कोई भी ऑफ़लोड झंडा उसे ठीक नहीं करेगा।

हर परीक्षण में एक चीज़ बदलें और मेन्यू पथ, जिस बॉक्स पर टिक किया और जो संख्या मापी, उसे लिखें। अगले फिर से बनाए गए गेस्ट का सामना करने वाले को तीनों चाहिए होंगे।

BSD आधारित अन्य फ़ायरवॉल अपनी इंटरफ़ेस सेटिंग्स के अंतर्गत समतुल्य नियंत्रण देते हैं, इसलिए तर्क तब भी लागू होता है जब मेन्यू पथ नहीं होता।