Llwybro traffig y gwesteiwr drwy VPN mewn VM: chwe gwiriad

Chwe gwiriad, wedi eu rhedeg mewn trefn, sy'n penderfynu a all VM weithredu fel porth VPN i'w westeiwr ei hun. Nid yw'r hypervisor yn gwneud dim o hyn drosoch: y gwestai sy'n berchen ar y tiwnel, y gwesteiwr sy'n berchen ar lwybr, a llwybro cyffredin yw'r rhwydwaith rhyngddynt. Rwy'n cadw'r rhestr oherwydd bod hepgor un cam bob amser yn rhoi'r un symptom, distawrwydd, lle mae'r gwesteiwr yn pingio'r gwestai yn llawen ac yn cyrraedd dim byd mewnol.

Dechreuwch gyda'r rheswm. Naill ai dim ond y tu mewn i'r gwestai y mae'r cleient corfforaethol yn gosod, neu mae polisi'n ei gadw yno, ac mae arnoch o hyd angen y gweinydd adeiladu mewnol o'r gwesteiwr. Os caniateir cleient ei hun i'r gwesteiwr, gwnewch hynny yn lle: mae un tiwnel ar y gwesteiwr yn curo dwy rwydwaith a NAT bob tro.

Gwiriad 1: mae ar y gwesteiwr angen cyswllt y gall roi cyfeiriad iddo

Rhaid i'r gwesteiwr feddu ar ryngwyneb yn yr un rhagddodiad â ail gyfaddasydd y gwestai. Mae host-only yn VirtualBox, host-only neu VMnet cyfaddas yn VMware Workstation, pont fewnol neu ddyfais tap yn QEMU/KVM, a switsh Internal yn Hyper-V i gyd yn gymwys. Gwestai 192.168.56.2, gwesteiwr 192.168.56.1, rhagddodiad 192.168.56.0/24 yw'r cynllun a ddefnyddiaf mewn labordai.

Mae rhwydweithio modd defnyddiwr QEMU (-netdev user, y backend SLIRP diofyn) a NAT VirtualBox yn methu'r gwiriad hwn yn llwyr. Mae pecynnau'r gwestai yn cyrraedd proses dirprwy ar y gwesteiwr, felly nid yw'r gwesteiwr byth yn gweld dyfais sy'n cario cyfeiriadau'r gwestai ac nid oes ganddo ddim i gyfeirio llwybr ato. Yr un stori yw Default Switch Hyper-V. Os yw ping 192.168.56.2 o'r gwesteiwr yn methu, stopiwch: ni fydd unrhyw lwybr a ychwanegir yn ddiweddarach yn ei drwsio.

Gwiriad 2: mae'r gwestai yn anfon ymlaen ac yn cyfieithu

Mae pecynnau o'r gwesteiwr yn cyrraedd â chyfeiriad ffynhonnell host-only a chyrchfan fewnol, felly rhaid i'r gwestai eu hanfon ymlaen ac yna eu cuddio y tu ôl i gyfeiriad ei diwnel. Ar westai Linux mae hynny'n golygu anfon ymlaen, pâr FORWARD accept, a source NAT tuag at y tiwnel:

sudo sysctl -w net.ipv4.ip_forward=1
sudo iptables -A FORWARD -i eth1 -o tun0 -j ACCEPT
sudo iptables -A FORWARD -i tun0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT
sudo iptables -t nat -A POSTROUTING -s 192.168.56.0/24 -o tun0 -j MASQUERADE

Y rheol MASQUERADE yw'r rhan y mae pobl yn ei gadael allan. Anaml y gŵyr llwybryddion corfforaethol fod 192.168.56.0/24 yn bodoli; gyda'r rheol, mae gweinyddion mewnol yn gweld cyfeiriad tiwnel y gwestai ac yn ateb iddo, ac mae'r ateb yn dod o hyd i'w ffordd yn ôl at y gwestai.

Mae gwestai Windows yn fwy trwsgl. Mae IPEnableRouter=1 o dan SYSTEM\CurrentControlSet\Services\Tcpip\Parameters yn troi anfon ymlaen ymlaen heb gyfieithu, felly dim ond lle mae llwybro corfforaethol eisoes yn pwyntio'n ôl at eich rhagddodiad host-only y mae'n gweithio. Mae Internet Connection Sharing yn cyfieithu, ond mae'n ailrifo'r cyfaddasydd a rennir i 192.168.137.1, felly darllenwch y cyfeiriad a gymerodd mewn gwirionedd cyn ysgrifennu llwybrau'r gwesteiwr.

Gwiriad 3: mae llwybrau'r gwesteiwr yn enwi'r gwestai, nid y tiwnel

Anfonwch dim ond y rhagddodiaid sydd eu hangen ar y gwesteiwr drwy'r gwestai. Ar Linux mae un llwybr fesul rhagddodiad yn ddigon ac mae'n gwrthdroi'n lân:

sudo ip route add 10.20.0.0/16 via 192.168.56.2
ip route get 10.20.30.40

Ar Windows y cyfateb yw route add 10.20.0.0 mask 255.255.0.0 192.168.56.2. Gadewch -p allan tra byddwch yn profi o hyd, fel bod llwybr gwael yn marw wrth ailgychwyn, ac ychwanegwch ef unwaith y bydd y llwybr yn gweithio. Peidiwch â dileu llwybr diofyn y gwesteiwr oni bai y dylai pob cymhwysiad ar y gwesteiwr ddefnyddio'r tiwnel; os tiwnel llawn sydd wir yn ofynnol, ychwanegwch y ddau lwybr /1 a chadwch y llwybr uniongyrchol i rwydwaith y hypervisor:

sudo ip route add 0.0.0.0/1 via 192.168.56.2
sudo ip route add 128.0.0.0/1 via 192.168.56.2

Ar westeiwr Windows, gwiriwch fetrig y rhyngwyneb hefyd. Mae llwybr a ychwanegwyd pan oedd y cyfaddasydd host-only wedi'i anablu yn aros yn y tabl ond byth yn cario traffig, a gall ail gyfaddasydd â metrig is ennill y chwiliad am yr un rhagddodiad.

Gwiriad 4: mae DNS yn dilyn y llwybr, nid diofyn y tiwnel

Mae llwybrau'n symud pecynnau; y datryswr sy'n penderfynu pa enwau sy'n cynhyrchu pecynnau. Cyfyngwch y datryswr corfforaethol i'r parth corfforaethol yn lle disodli datryswr y gwesteiwr, a'i gyfeirio at weinydd DNS y mae'r llwybr newydd eisoes yn ei gyrraedd. Gyda systemd-resolved ar y gwesteiwr:

resolvectl dns eth1 10.20.0.53
resolvectl domain eth1 '~corp.example.com'

Ar Windows mae cofnod yn nhabl polisi datrysiad enwau yn gwneud yr un gwaith: Add-DnsClientNrptRule -Namespace ".corp.example.com" -NameServers 10.20.0.53. Os yw'r gwestai yn rhedeg ei ddatryswr ei hun ar y cyfeiriad host-only, defnyddiwch y cyfeiriad hwnnw yn lle, ond dim ond ar ôl cadarnhau ei fod yn ateb ar 192.168.56.2 yn hytrach na loopback.

Yna gwiriwch yr MTU cyn beio DNS am dudalennau araf. Mae rhyngwyneb y tiwnel yn llai na rhyngwyneb 1500 beit y gwesteiwr, felly mae gwesteiwr sy'n anfon segmentau maint llawn â'r did DF wedi'i osod yn eu gweld yn cael eu gollwng yn rhywle y tu mewn i'r gwestai. Y symptom clasurol yw ping sy'n gweithio a chymhwysiad gwe mewnol sy'n tagu ar ôl yr ysgwyd llaw TLS. Clampiwch MSS yn llwybr anfon ymlaen y gwestai:

sudo iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Gwiriad 5: gwiriwch o'r ddau ben

O'r gwesteiwr, dylai traceroute neu tracert i gyfeiriad mewnol ddangos 192.168.56.2 fel y naid gyntaf, nid y porth corfforol. Yn y gwestai, gwyliwch yr un ymgais yn gadael: mae tcpdump -ni any host 10.20.30.40 yn dangos y cais a anfonwyd ymlaen ar ochr host-only a'r un a gyfieithiwyd ar y tiwnel. Mae cais sy'n mynd allan, yn dychwelyd ac yn gadael y gwesteiwr yn dawel o hyd yn pwyntio at y llwybr dychwelyd.

Mae dwy fethiant yn cyfrif am y rhan fwyaf o hynny. Naill ai nid yw tiwnel y gwestai yn cario llwybr yn ôl ar gyfer y rhagddodiad host-only oherwydd bod y rheol NAT ar goll, neu mae llwybr y gwesteiwr yn pwyntio at gyfeiriad nad yw'r gwestai yn ei ddal mwyach ar ôl ailgychwyn. Ailddarllenwch y cyfeiriadau gyda ip -br addr a ip route get yn lle ymddiried yn nodiadau'r sesiwn ddiwethaf.

Gwiriad 6: gwnewch iddo oroesi ailgychwyn ac uwchraddio'r hypervisor

Cadwch y ddwy hanner yn barhaol: cyfluniad llwybr netplan neu NetworkManager ar y gwesteiwr, route add ... -p ar Windows, a net.ipv4.ip_forward=1 yn /etc/sysctl.d/ ynghyd â set o reolau mur tân sy'n ail-lwytho yn y gwestai. Tynnwch snapshot o'r gwestai unwaith y bydd'r cyfluniad yn gwirio, cyn i ddiweddariad nesaf y cleient corfforaethol gyrraedd.

Mae rhwydweithiau host-only yn cael eu hailrifo pan fydd hypervisor yn ail-greu ei gyfaddaswyr, sy'n dileu pob llwybr a rheol NAT a adeiladwyd ar 192.168.56.0/24 yn ddistaw. Ar ôl uwchraddio, ailredwch y tri gwiriad cyntaf mewn trefn; mae hynny'n costio munud ac yn dal yr achos lle mae gan y gwesteiwr ei lwybr o hyd tra bo'r gwestai wedi symud i is-rwydwaith newydd.

Mae angen pas ei hun ar IPv6. Nid yw rheolau ip6tables, cofnodion AAAA ac ail deulu llwybrau'r gwesteiwr yn dilyn cyfluniad IPv4, a bydd gwasanaeth corfforaethol y gellir ei gyrraedd dros IPv6 yn edrych yn barhaol wedi torri tra bo IPv4 yn gweithio.

Pas neu fethu, mewn trefn: gall y gwesteiwr bingio cyfeiriad host-only y gwestai; mae'r gwestai yn anfon ymlaen ac yn gwneud MASQUERADE tuag at y tiwnel; mae ip route get yn dychwelyd y gwestai fel porth ar gyfer y rhagddodiad mewnol; mae enwau corfforaethol yn datrys drwy'r datryswr cyfyngedig; mae traceroute yn dangos y gwestai yn gyntaf; ac mae'r un chwe ateb yn goroesi ailgychwyn.