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 આધારિત અન્ય ફાયરવોલ તેમની પોતાની ઇન્ટરફેસ સેટિંગ્સ હેઠળ સમકક્ષ નિયંત્રણ આપે છે, તેથી મેનુ માર્ગ ન હોય તોપણ તર્ક લાગુ પડે છે.