VPN અને વેબ માટે એક જ જાહેર હોસ્ટ: ભૂમિકાઓ કેવી રીતે વિભાજિત કરવી

એક જ મશીન ત્રણેય જરૂરિયાતો એકસાથે પૂરી કરી શકે: ટનલ સમાપ્ત કરવી, HTTPS નો જવાબ આપવો અને બે ખાનગી LAN વચ્ચે ફોરવર્ડ કરવું. તે વાજબી છે કે નહીં તે ત્રણ બાબતો પર આવે છે જે તમે કાગળ પર નક્કી કરી શકો: જાહેર સરનામું કોનું છે, દરેક પોર્ટ અને પ્રોટોકોલની જોડી કોની છે, અને કઈ પ્રક્રિયાને પેકેટ ફોરવર્ડ કરવાની પરવાનગી છે. આ સાચાં હોય તો સહિયારું હોસ્ટ સામાન્ય છે. ખોટાં હોય તો તમે એવી સેવા પર સપ્તાહાંત પસાર કરશો જે સ્વચ્છ રીતે શરૂ થાય છે અને કદી જવાબ આપતી નથી.

આગળ જે આવે છે તે નિર્ણય પ્રક્રિયા છે, બાંધકામની પત્રક નહીં. દરેક પગલું એ ચકાસણી પર પૂરું થાય છે જે સાબિત કરે છે કે હમણાં ઉમેરેલી ભૂમિકા ખરેખર અલગ છે.

પોર્ટ પહેલાં સરનામાનો માલિક પસંદ કરો

ટનલનો અંતિમ બિંદુ અને વેબ સર્વર કર્નલ શેર કરી શકે છે; એક જ સરનામું, પોર્ટ અને પ્રોટોકોલ એકસાથે શેર કરવો તે છે જે નિષ્ફળ જાય છે. WireGuard સામાન્ય રીતે UDP 51820 લે છે, OpenVPN UDP 1194 અથવા TCP 443 લે છે, અને વેબ સર્વર TCP 443 લે છે. જે જોડી દુખે છે તે HTTPSની બાજુમાં TCP 443 પર OpenVPN છે, કારણ કે બંનેને એક જ સોકેટ જોઈએ છે અને કર્નલ તે પહેલાં બંધાયેલાને આપે છે. ફક્ત આગળનું ડિમલ્ટિપ્લેક્સર, જેમ કે sslh અથવા TLSથી જાણકાર પ્રોક્સી, તેમને એ પોર્ટ શેર કરવા દે છે, અને તે એવો ઘટક ઉમેરે છે જેની નિષ્ફળતા ફાયરવોલ સમસ્યા જેવી જ લાગે છે.

કંઈ પણ બદલતા પહેલાં માલિકોને જુઓ: ss -lntup દરેક સાંભળતા સોકેટનું સ્થાનિક સરનામું, પોર્ટ અને પ્રક્રિયા છાપે છે. બે હરોળ જે 0.0.0.0:443 દર્શાવે છે તેનો અર્થ છે કે બીજી સેવા કદી બંધાઈ નહીં, તેની init સ્ક્રિપ્ટ કેટલી ખુશ હતી તે ગમે તે હોય. બ્રિજિંગ માલિકને પણ ખસેડે છે. જ્યારે eth0 સાથે જોડાય છે br0, IP br0 પર જાય છે અને દરેક ફાયરવોલ નિયમ જે eth0 નામ લે છે તે મેળ ખાવાનું બંધ કરે છે, તેથી સેવાઓને બ્રિજ પર બાંધો અને ખાતરી કરો ip -br addr થી.

એ જ માલિકી નિયમ વર્ચ્યુઅલ મશીનો સાથે ઊભા થતા એક આશ્ચર્યને સમજાવે છે. એ જ LAN પરના ગેસ્ટની અંદર ચાલતો ટનલ સર્વર ગેસ્ટનું સરનામું રાખે છે, તેથી હોસ્ટના પોતાના સરનામા તરફના જોડાણો હોસ્ટ પર જ રહે છે અને ગેસ્ટની ટનલ તેમને કદી જોતી નથી, ક્લાયન્ટ પ્રોફાઇલ શું કહે તે ગમે તે હોય.

બે LAN વચ્ચે રૂટ કરો અથવા એક બાજુ NAT કરો

બે LAN જે એકબીજાને જોતા નથી તે દરેક જાહેર હોસ્ટને ડાયલ કરી શકે છે, જે પછી ટનલ વચ્ચે ફોરવર્ડ કરે છે. તે રૂટેડ ડિઝાઇનને ત્રણ વસ્તુઓ જોઈએ: ફોરવર્ડિંગ ચાલુ, દરેક દૂરના પ્રીફિક્સ તરફ રૂટ, અને ફોરવર્ડિંગ નીતિ જે ટ્રાન્ઝિટને પસાર થવા દે. sysctl -w net.ipv4.ip_forward=1 પહેલાને આવરે છે, ip route add 10.20.0.0/24 dev wg1 બીજાને, અને nftables લીટી જેવી કે nft add rule inet filter forward iifname "wg0" oifname "wg1" accept ત્રીજાને.

સ્રોત NAT ઉમેરવા સરળ અને ડિબગ કરવા કઠિન છે. માસ્કરેડિંગ ક્લાયન્ટનું સરનામું ફરીથી લખે છે, તેથી દૂરની બાજુ હબને જુએ છે, સાચા હોસ્ટને નહીં, અને તેના એક્સેસ નિયમો અને લોગ એટ્રિબ્યુશન માટે નકામા બની જાય છે. જ્યારે બંને નેટવર્ક તમારા હોય ત્યારે રૂટ કરો. જ્યારે એક બાજુ ત્રીજા પક્ષની હોય જે પરત રૂટ ઉમેરશે નહીં, ત્યારે NAT એ વિકલ્પ છે જે આ અઠવાડિયે શિપ થાય છે. કોઈપણ રીતે, સરનામા યોજના લખો, કારણ કે બે ઓવરલેપિંગ /24 ને કોઈ પણ રૂપરેખાંકન રૂટ કરી શકતું નથી.

લેપટોપ માટે ઇન્ટરનેટ એક્ઝિટ તરીકે કામ કરવાનું એ વાત કે તે જ બોક્સ આવતી ટનલ સમાપ્ત કરે તેને રોકતું નથી. ફક્ત ઓવરલેપિંગ સરનામાં જ રોકે છે, અને તેથી જ સરનામા યોજના એ દસ્તાવેજ છે જે મહત્ત્વનો છે.

બે ભૂમિકાઓ બંધ હોય ત્યારે વિભાજનની કસોટી કરો

ઉપયોગી કસોટી બાદબાકી છે: બે ભૂમિકા બંધ કરો અને ખાતરી કરો કે ત્રીજી હજી જવાબ આપે છે. ટનલ સેવા બંધ હોય ત્યારે વેબ વિનંતી પૂરી થવી જોઈએ, અને વેબ સર્વર બંધ હોય ત્યારે ટનલ હેન્ડશેક પૂરો થવો જોઈએ. જો બંને ફક્ત ત્યારે જ કામ કરે જ્યારે બધું ચાલે, તો તમારી પાસે આકસ્મિક અવલંબન છે, જેમ કે સહિયારું ફાયરવોલ કોષ્ટક, ભૂલી ગયેલો રૂટ અથવા ખોટા સરનામા તરફ દોરતું નામ.

ત્રણ આદેશો તે કસોટીને મૂર્ત બનાવે છે. curl -sk --resolve example.test:443:203.0.113.10 https://example.test/ સાબિત કરે છે કે સ્થાનિક શ્રોતા બાહ્ય DNS વિના જવાબ આપે છે, wg show ક્લાયન્ટ પર સાબિત કરે છે કે હેન્ડશેક પૂરો થયો, અને tcpdump -ni any port 51820 હબ પર રૂટિંગ સમસ્યાને કી સમસ્યાથી અલગ કરે છે. કેપ્ચરમાં કદી ન દેખાતો હેન્ડશેક હોસ્ટ પહેલાં જ મૃત્યુ પામ્યો: પ્રદાતાનો ફાયરવોલ, ખોટું જાહેર સરનામું અથવા રસ્તામાં NAT નિયમ.

ફોરવર્ડ થતા LAN માટે બાદબાકી પુનરાવર્તિત કરો. એક પીઅર ડિસ્કનેક્ટ હોય ત્યારે હબ આરપારનો પિંગ નિષ્ફળ થવો જોઈએ; તે ફરી જોડાય ત્યારે પિંગ કોઈ નિયમને સ્પર્શ્યા વિના પુનઃપ્રાપ્ત થવો જોઈએ. ટનલ ફરી શરૂ કર્યા પછી જ પુનઃપ્રાપ્ત થતો પિંગ પહોંચની ક્ષમતા તરફ નહીં, નીતિ તરફ દોરે છે, અને તે બીજું સુધારણું છે.

ભૂમિકાઓ ઘટાડતી વખતે નિયમ સમૂહ વાંચનીય રાખો. nft list ruleset તમને ખરેખર જોઈતી દરેક દિશા માટે એક સ્વીકાર નિયમ દર્શાવવો જોઈએ, અને બધું સ્વીકારતી ફોરવર્ડ શૃંખલા વિભાજન નથી, તે કાર્યરત ડેમો છે.

ફક્ત IPv6 ઍક્સેસ લાઇન અને IPv4 સેવાઓ

કેટલીક ઍક્સેસ લાઇન ફક્ત IPv6 પહોંચ આપે છે, અને સેવાઓ હજી IPv4 પર પ્રકાશિત કરવી પડે છે. ટનલ પોતે એ કુટુંબ પર જાય છે જે હજી ટ્રાફિક પસાર કરે છે, જ્યારે પ્રકાશિત સેવા ટનલની અંદરના સરનામા પર બેસે છે. તે સામાન્ય ધારણાને ઉલટાવે છે અને શાંતિથી દેખરેખ તોડે છે: IPv4 માર્ગ માટે લખાયેલ ફાયરવોલ નિયમ કે અપટાઇમ ચકાસણી હવે એવા ઇન્ટરફેસ પર નજર રાખે છે જે કંઈ વહન કરતું નથી.

દરેક કુટુંબને અલગથી અજમાવો curl -4 અને curl -6 થી, કારણ કે એક સફળ વિનંતી તમે ન અજમાવેલા માર્ગ વિશે કંઈ કહેતી નથી. પોર્ટની માલિકી કુટુંબો વચ્ચે બદલાતી નથી, પણ શ્રોતા બદલાય છે: ss -lntup IPv4 અને IPv6 સોકેટને અલગ હરોળમાં સૂચિબદ્ધ કરે છે, અને 0.0.0.0:443 આવરતું નથી [::]:443 જ્યાં સુધી પ્રક્રિયાએ ડ્યુઅલ-સ્ટેક સોકેટ માંગ્યું ન હોય.

એક કુટુંબ પર જવાબ આપતી અને બીજા પર ઇનકાર કરતી સેવા સામાન્ય રીતે શ્રોતાની સમસ્યા છે, રૂટિંગની નહીં. ડિઝાઇન પૂર્ણ કહેતા પહેલાં ખાતરી કરો કે દરેક ભૂમિકા પોતાનું સરનામું કે પોર્ટ ધરાવે છે, ફોરવર્ડિંગ ચાલુ અને મંજૂર છે, અને અન્ય બે બંધ હોવા છતાં દરેક ભૂમિકા હજી જવાબ આપે છે.