Virtio मा pfSense: offload बन्द नभएसम्म TCP रोकिन्छ

एक ग्राहकले जानकारी दिन्छ: टनेल जोडिन्छ, पिङले जवाफ दिन्छ, लगइन पृष्ठ लोड हुन्छ, र त्यसपछि हरेक प्रयासमा स्थानान्तरण उही ठाउँमा जम्छ। यो ढाँचाले पहिले नै धेरै भन्छ: पहुँच काम गर्छ र निरन्तर थ्रुपुट गर्दैन। फायरवाल खोल्नुअघि VPN यो विफलतामा छुच्चै संलग्न छ कि छैन पत्ता लगाउनुहोस्। त्यही गेटवेबाट मार्गमा टनेल नराखी ठूलो TCP पठाउनुहोस्; त्यो पनि जम्यो भने OpenVPN कहिल्यै संलग्न थिएन।

virtio नेटवर्क कार्ड प्रयोग गर्ने pfSense गेस्टलाई ठ्याक्कै त्यही आकारमा असफल हुन धेरै राम्रो कारण छ।

साना प्याकेट जान्छन्, ठूलो TCP अड्किन्छ

ह्यान्डसेक, DNS जवाफ र ICMP प्रतिध्वनि साना हुन्छन् र सामान्यतया जान्छन्। निरन्तर स्थानान्तरणले गेस्टलाई खण्डीकरण गर्न बाध्य बनाउँछ, र त्यहीँ क्षतिग्रस्त offload मार्ग देखा पर्छ। खराबी सममित हुनु आवश्यक छैन: बाहिर जाने ट्राफिक सफा हुँदा भित्र आउने खस्न सक्छ, वा उल्टो, त्यसैले प्रयोगकर्ता लगइन गर्न सक्छ र त्यसपछि पहिलो ठूलो प्रतिक्रियामा अड्किन सक्छ। त्यही ग्राहक अर्को गेटवेबाट काम गर्ने भएकाले दोष नयाँ घटकमा थोपारिन्छ।

त्यसैले टनेलबिना गेटवे परीक्षण गर्नुहोस्। केही सेकेन्ड चल्न सक्ने ठूलो LAN-बाट-WAN डाउनलोड पर्याप्त हुन्छ, र कुनै पनि सेटिङ परिवर्तनअघि गर्नुपर्छ, ताकि पछिको तुलना अर्थपूर्ण होस्।

offload ले वास्तवमा के वाचा गर्छ

virtio प्याराभर्चुअल हो: होस्ट र गेस्ट काम बाँड्छन्, होस्टले चेकसम र खण्डीकरण क्षमता घोषणा गर्छ र गेस्टले सुरु गरेको कुरा पूरा गर्ने अपेक्षा गर्छ। गेस्टको स्ट्याकले त्यसो नगरे फ्रेम अपूर्ण चेकसमसहित बाहिर जान्छन् वा होस्टले तिनलाई फ्याँक्छ। इमुलेटेड E1000 सरल र ढिलो मोडेल दिन्छ, जसमा pfSense मा एक पनि परिवर्तन बिना समस्या हराउँछ। क्षमता वार्ता हरेक यन्त्रका लागि छुट्टै हुन्छ, जसले एउटा गेस्ट महिनौं चल्ने र त्यसको पुनर्निर्मित जोडी पहिलो दिनमै असफल हुने कुरा बुझाउँछ।

वार्ता गरिएको समूह हाइपरभाइजर संस्करण र छानिएको NIC मोडेलमा निर्भर छ, तपाईंले आयात गरेको कन्फिगरेसनमा मात्र होइन।

एउटा चेकबक्सले virtio राख्छ

pfSense इन्टरफेसमा, सिस्टम त्यसपछि उन्नत त्यसपछि नेटवर्किङमा हार्डवेयर चेकसम offload अक्षम गर्नुहोस् नामको चेकबक्स छ। त्यो चिन्ह लगाउँदा गेस्टले सफ्टवेयरमा चेकसम गणना गर्छ, जुन pfSense पछाडिको FreeBSD स्ट्याकले प्याराभर्चुअल यन्त्रबाट अपेक्षा गर्नेसँग मेल खान्छ। उही पृष्ठका दुई सम्बन्धित विकल्पले हार्डवेयर TCP खण्डीकरण offload र हार्डवेयर ठूलो प्राप्ति offload समेट्छन्। ह्यान्डसेक सफल भई ठूला स्थानान्तरण नभएको बेला तिनतिर जानुहोस्।

परिवर्तन गर्दा NIC लाई virtio नै राख्नुहोस्। E1000 मा जाँदा VM को सम्पूर्ण आयुभर हरेक प्याकेटमा CPU जल्छ र होस्ट उत्तराधिकारमा पाउने जोसुकैबाट कन्फिगरेसन समस्या लुकाउँछ, जुन अलि ढिलो तर अनुमानयोग्य डेटा मार्गभन्दा नराम्रो सौदा हो।

भर्खरै स्वीकार गरेको लागत नाप्नुहोस्

सफ्टवेयर चेकसमिङले काम गेस्टभित्र सार्छ, त्यसैले केही लागत छैन भन्ने मान्नुको सट्टा पछि थ्रुपुट नाप्नुहोस्। सानो VM मा दण्ड वास्तविक हुन्छ, तर त्यो देखिन्छ र स्थिर हुन्छ, साइलेन्ट हानिको विपरीत। पहिले र पछि इन्टरफेस त्रुटि काउन्टर र गेस्टको कर्नेल लग तुलना गर्नुहोस्। ब्रिज फिल्टर गर्ने हाइपरभाइजर फरक प्रमाणसहितको छुट्टै खराबी हो, र कुनै offload झन्डाले त्यसलाई निको पार्दैन।

हरेक परीक्षणमा एउटा कुरा बदल्नुहोस् र मेनु मार्ग, चिन्ह लगाएको बक्स र नापिएको संख्या लेख्नुहोस्। अर्को पुनर्निर्मित गेस्टको सामना गर्नेलाई तीनवटै चाहिन्छ।

BSD आधारित अन्य फायरवालहरूले आफ्नै इन्टरफेस सेटिङमा समान नियन्त्रण दिन्छन्, त्यसैले मेनु मार्ग नभए पनि तर्क लागू हुन्छ।