NAT կամ կամրջված VM ցանց. որը կրում է VPN երթևեկությունը

NAT հյուրերը վարձում են հոսթի թունելը միայն այն դեպքում, երբ հաճախորդը թունելավորում է ըստ երթուղու. կամրջված հյուրերը իրենք են երթուղավորում. Փորձարկեք հյուրին, ապա ընտրեք համապատասխան ռեժիմը.

Կամրջումը և NAT-ը նույն հյուրին ձեր VPN-ին միացնելու երկու եղանակ չեն. նրանք որոշում են թե ումն են հյուրի փաթեթները նախքան թունելի մեջ մտնելը։ NAT ռեժիմում հիպերվիզորը վերագրում է հյուրի երթևեկությունը և ուղարկում այն հոսթի կողմի կոդից, այնպես որ հյուրը գնում է այն երթուղով, որը հոսթը տալիս է այդ կոդին։ Կամրջված ռեժիմում հյուրը ստանում է իր սեփական ինքնությունը կապի շերտում ֆիզիկական հատվածում և ընտրում իր լռելյայն դարպասը, ինչը հոսթի թունելը դարձնում է անկարևոր նրա համար, բացառությամբ այն դեպքի, երբ LAN-ի երթուղիչն է թունելավորում։ Ես դադարեցի VM-ը դիտարկել որպես VPN-ի վրա գտնվող և սկսեցի դիտարկել որպես հարց այն մասին, թե ուր է ուղղված այդ հյուրի լռելյայն երթուղին։ Ներքևի թեստը տևում է մի քանի րոպե մեկ ռեժիմի համար և լուծում է այն առանց գուշակությունների։

NAT-ը հյուրին պահում է հիպերվիզորի կոդի հետևում, որտեղ գործում են հոսթի երթուղիները

VirtualBox-ում NAT հյուրը նստում է 10.0.2.0/24-ում, վիրտուալ դարպասը 10.0.2.2-ում, DNS փոխանցիչը 10.0.2.3-ում, և սեփական երթուղի չունի դեպի ֆիզիկական ցանց։ Ելքային փաթեթները վերցնում է NAT շարժիչը, վերագրում է դրանք այնպես, որ աղբյուրը հոսթը լինի, և փոխանցում է հոսթի IP կույտին։ Այնտեղից հյուրի երթևեկությունը հոսթի հոսք է, և երթուղու որոնումը կատարվում է ըստ նպատակակետի. լրիվ թունելի հաճախորդը, որը տեղադրում է 0.0.0.0/1 և 128.0.0.0/1 հոսթի վրա, բռնում է այն առանց երբևէ իմանալու, որ VM գոյություն ունի։ Oracle-ի VirtualBox ցանցերի գլուխը թվարկում է այս լռելյայն արժեքները, եթե ուզում եք հաստատել հասցեները ձեր կառուցվածքում։

libvirt-ի լռելյայն ցանցը հասնում է նույն տեղը 192.168.122.0/24-ից, որտեղ dnsmasq-ը բաժանում է վարձույթներ, և հոսթը դիմակավորում է ենթացանցը, այնպես որ հյուրի փաթեթները նորից հասնում են հոսթի երթուղավորման որոշմանը։ Բացառությունը հաճախորդն է, որն ընտրում է երթևեկությունը ըստ գործընթացի, ոչ թե ըստ երթուղու։ Եթե բաժանված թունելի ցանկը պարունակում է միայն ձեր զննարկիչը և ուրիշ ոչինչ, NAT շարժիչը այդ ցանկում չէ, և հյուրը հեռանում է մեքենայից առանց թունելի, մինչ հոսթի զննարկիչը դեռ ծածկված է երևում։ Նույն ենթացանցը, հակառակ արդյունքը։

Կամրջումը հյուրին տալիս է իր սեփական տեղը ֆիզիկական LAN-ում

Կամրջված հյուրին տրվում է վիրտուալ ցանցային քարտ, որը միացված է իրական ադապտերին, ստանում է իր MAC հասցեն և վերցնում է DHCP վարձույթ ֆիզիկական ցանցից։ Նրա լռելյայն դարպասը LAN-ի երթուղիչն է, ոչ հիպերվիզորը, և նրա կադրերը դուրս են գալիս լարի վրա այդ ադապտերով։ Հոսթի թունելի երթուղիները ապրում են հոսթի աղյուսակում և երբեք չեն հարցվում, որովհետև հյուրի կադրերը երբեք չեն մտնում հոսթի IP կույտ։

Դա կտրում է երկու ուղղությամբ։ mDNS-ը և SMB-ով զննումը սկսում են աշխատել, որովհետև հյուրը տեսնում է LAN-ի հեռարձակման երթևեկությունը, և հյուրը հասանելի է դառնում նույն հատվածի այլ մեքենաներից առանց հոսթի հրդեհային պատի միջև։ Կամրջումը նաև ճանապարհ չէ հյուրին գոյություն ունեցող թունելով մղելու համար. VM-ը հոսթի WireGuard կամ OpenVPN ինտերֆեյսին միացնելը այն չէ, ինչ VirtualBox-ը կամ libvirt-ը կանի ձեզ համար։ Եթե կամրջված հյուրը պետք է անցնի թունելով, թունելը պետք է ավարտվի ինչ-որ տեղ այդ LAN-ում։

Թեստը, որն ավարտում է վեճը

Անցկացրեք նույն ստուգումները երկու ռեժիմում և գրի առեք պատասխանները։

  • Հոսթի վրա curl -s https://ifconfig.me-ը տալիս է հանրային v4 հասցեն։
  • Հյուրում նույն հրամանը, գումարած ip route-ը Linux-ում կամ Get-NetRoute -DestinationPrefix 0.0.0.0/0-ը Windows-ում լռելյայն դարպասի համար։
  • Լուծիչի ինքնությունը՝ resolvectl status կամ cat /etc/resolv.conf հյուրում, տեսնելու համար՝ արդյոք այն ուղղված է 10.0.2.3-ին, թե LAN սերվերին։
  • Հասցեների ընտանիք՝ ip -6 addr show scope global և մեկ v6 հարցում, որովհետև v4 թունելը ոչինչ չի ասում գլոբալ v6 հասցեի մասին, որը հյուրը կարող է ունենալ։

Համընկնող հանրային հասցեները նշանակում են, որ հյուրը հոսթի ուղու վրա է։ Հյուրի հասցեն, որը համընկնում է LAN-ի սովորական ելքին, նշանակում է, որ այդպես չէ։ Այն քայլը, որը մարդիկ բաց են թողնում, հսկիչն է. իջեցրեք հոսթի թունելը և կրկնեք հյուրի հարցումը։ Եթե հյուրը շարունակում է զննարկել, այն երբեք կախված չի եղել հոսթի թունելից, ինչ էլ որ ռեժիմի անունը հուշի։ NAT ռեժիմում հյուրը պետք է կորցնի ինտերնետը, երբ հոսթի թունելը իջեցված է, բացառությամբ երբ հաճախորդը կարգավորված է թույլատրել առանց թունելի երթևեկություն, ինչը ինքնին արժե իմանալ։

Երկու ազդանշան ստում են։ Հաջող ping-ը ապացուցում է հասանելիությունը, ոչ թե ելքի ուղին։ Եվ DNS-ը կարող է պատասխանվել 10.0.2.3 փոխանցիչի կողմից հոսթի լուծիչի միջոցով, մինչ TCP-ն այլ երթուղի է վերցնում, և այդպես ստացվում է էջ, որը բեռնվում է, և մուտք, որը երբեք չի ավարտվում։

Որ ռեժիմն է համապատասխանում աշխատանքին

Ռեժիմը երթուղավորման որոշում է, այնպես որ ընտրեք այն ըստ պահանջի, ոչ թե ըստ սովորության։

RequirementMode that fits
Every guest flow must exit through the host tunnelNAT, with a host client that tunnels by route, verified from inside the guest
The guest needs its own VPN account or profileBridged, or NAT with a client running inside the guest, not both
The guest must serve SSH, SMB, or a dev server to the LANBridged; NAT needs a port forward, which does not change the outbound path
The guest must stay invisible to the LANNAT; a bridged guest is another host on the segment
The guest needs a real public IPv6 addressBridged; VirtualBox NAT mode has no IPv6 forwarding
Isolation from the LAN with access to the hostHost-only adapter, not NAT

Առաջին տողն այն է, որտեղ մարդիկ ընկնում են. NAT-ը գումարած լրիվ թունելի հոսթ հաճախորդը իսկապես ծածկում է հյուրին, բայց միայն այնքան ժամանակ, քանի դեռ հաճախորդը թունելավորում է ըստ երթուղու, և հոսթի վերին կապը հենց այդ թունելն է։ Տեղափոխեք հաճախորդը միայն զննարկիչի թույլատրված ցանկի մեջ, և ծածկույթը անհետանում է առանց որևէ սխալի ոչ մի տեղ։ Չորրորդ տողը հակառակ սխալն է. հարմարության համար կամրջված հյուր, որն անաղմուկ սկսում է պատասխանել SMB-ին կամ SSH-ին գրասենյակի LAN-ում։

Անհաջողություններ, որոնք բարդում են VPN-ի վրա

Windows-ում NAT թարգմանությունը կատարվում է VirtualBox VM գործընթացի ներսում, ուստի յուրաքանչյուր հավելվածի հաճախորդ պետք է իր ցանկում ունենա հենց այդ պատկերը, այլ ոչ թե վիրտուալ մեքենաների ընդհանուր կանոն։ Երբ հաճախորդի թարմացումը վերակառուցում է իր գործընթացների ցանկը, NAT հյուրերն առաջինն են կորցնում ծածկույթը, և հաշվետվությունը կարդացվում է որպես VM, որը հասնում է LAN-ին, բայց ոչ ինտերնետին, մինչ հոսթը կարգին է։

Wi-Fi-ին կամրջելը մյուս դասականն է։ Մուտքի կետերը հազվադեպ են փոխանցում օտար աղբյուրի MAC-ով կադրեր, ուստի wlan0-ի վրա կամուրջը կամ ամբողջովին ձախողվում է, կամ աշխատում է այնքան ժամանակ, մինչև AP-ի հաճախորդների մեկուսացումը սկսի գցել այն։ VirtualBox-ը դեռ կառաջարկի անլար ադապտերը իր ցանկում։ Եթե հոսթը Wi-Fi-ի վրա է, և հյուրը պետք է կամրջվի, պլանավորեք փորձարկել այն, ոչ թե ենթադրել։

MTU-ն երրորդն է։ Կամրջված հյուրը պահպանում է LAN-ի 1500 բայթանոց MTU-ն, և եթե այն աշխատեցնում է իր WireGuard հաճախորդը 1420-ով, մեծ TLS բարևձեռքերը կանգ են առնում, մինչ փոքր հարցումները հաջողվում են։ NAT-ի տակ հոսթի թունելի MTU-ն հոսթի խնդիրն է, բայց հյուրը դեռ հավատում է 1500-ին, և don't-fragment բիթով UDP-ն նույն կերպ անհետանում է։

Գրանցեք ռեժիմը և նորից ստուգեք ամեն ադապտերի փոփոխությունից հետո

Գրանցեք ռեժիմը, հոսթի ինտերֆեյսը, որն օգտագործում է կամուրջը, հյուրի լռելյայն դարպասը, նրա լուծիչը և նրա v4 ու v6 ելքային հասցեները։ Այդ գրառումն է, որ հաջորդ անհաջողությունը դարձնում է էժան. երբ նոթբուքը դոկից տեղափոխվում է Wi-Fi, կամրջված հյուրը հետևում է կամրջին մեկ այլ ֆիզիկական ադապտերի և կարող է վարձույթ ստանալ այլ ենթացանցում, մինչ NAT հյուրը պահում է իր 10.0.2.x հասցեն և լուռ ժառանգում է այլ վերին կապ։

Տոմսը փակելուց առաջ հաստատեք այս ամենից յուրաքանչյուրը։

  • Հյուրի ելքային հասցեն տարբերվում է հոսթի ելքային հասցեից, ուստի այն հոսթի թունելի վրա չէ։
  • Լուծիչը 10.0.2.3 փոխանցիչն է կամ LAN սերվեր, և դուք գիտեք, թե որն է պատասխանել։
  • Հյուրում գլոբալ v6 հասցե չկա, եթե թունելի նախագիծը միայն v4 է։
  • Հոսթի թունելը իջեցված վիճակում հյուրը դադարում է զննարկել, կամ հիմա գիտեք, որ այն երբեք կախված չի եղել դրանից։
  • Հյուրը չի տեսնում LAN-ի հեռարձակման երթևեկություն, որն իրեն չի վերաբերում։

Առնչվող հոդվածներ