NAT på VPN-tenaren eller på rutaren? Begge kan fungere

Å merke ei tilkoping som standardrute på ein berbar PC er trinnet alle hugsar, og det er nettopp det som ikkje endrar noko på gatewayen. Klienten sender no internettførespurnadane inn i tunnelen; om dei forlèt bygget, avheng av vidaresending, eit omsetjingspunkt og ein returveg som når den private adressa til klienten. To ordningar kan levera alle tre, dei plasserer arbeidet på ulike stader, og begge feilar på same stille måten når ingen eig svarretninga. Å velja mellom dei er eit spørsmål om kven som bør sjå klientbassenget.

Myten: ei klientrute byggjer utgangen

Tvinga tunnelering er ein policy på klientsida: han avgjer at trafikken går til VPN-adapteren i staden for den fysiske. Microsofts dokumentasjon om VPN-ruting skildrar den delinga og åtferda, og det er ei utsegn om rutetabellen til klienten, ikkje om vidaresendingsreglane til tenaren. Frå klienten sitt synspunkt er tunnelen der internett bur; frå gatewayen sitt synspunkt kom det ein pakke frå ei adresse som ingen lenger oppe nokon gong har høyrt om. Ingen av sidene er feilkonfigurert kvar for seg, og difor ser feilen ut som ein øydelagd tenar for personen ved den berbare PC-en.

Det avviket er heile problemet som resten av denne artikkelen løyser. Noko må gjera den private adressa til klienten returnerbar, og valet er kvar.

Teikn svarvegen fyrst

Skriv ned ruta med ekte adresser før du rører ei innstilling, og merk av dei to moglege omsetjingspunkta på henne. Dette laboratoriet brukar eit VPN-basseng på 10.70.0.0/24 med éin klient på 10.70.0.37, ei tenar-LAN-adresse på 172.16.40.10, ein rutar på 172.16.40.1 og ein offentleg utgang på 203.0.113.40.

client 10.70.0.37 -- tunnel --> RRAS 172.16.40.10 -- LAN --> router 172.16.40.1 --> 203.0.113.40
                                  (translate here?)                             (or here?)

Tenaren som allereie surfar på internett bevisar berre sin eigen veg. Ein pakke som blir vidaresend på vegner av ein klient, er ei anna avgjerd, teken av vidaresendingspolicyen på same maskin, og det er den som vanlegvis manglar. Å merke dei tre avgjerds punkta på diagrammet held samtalen om eitt av dei om gongen.

Alternativ A: omset på VPN-tenaren

Her omset tenaren kjelda til klienten til si eiga LAN-adresse før han gir pakken vidare til rutaren, og rutaren brukar si vanlege omsetjing på veg ut. På svaret gjenopprettar mappinga til rutaren tenaradressa, og mappinga til tenaren gjenopprettar klientadressa. To tilstandsfulle omsetjingar i serie er normale og gjennomførbare, føresett at begge blir registrerte; rutaren treng aldri ei rute til bassenget, og det er det tiltalande med denne ordninga.

Get-RemoteAccess | Select-Object VpnS2SInterface, RoutingDomain
Get-NetNat | Select-Object Name, InternalIPInterfaceAddressPrefix

Bruk desse lesingane for å sjå kva tenaren allereie har i staden for å anta at det finst ein NAT. Ein Linux-masquerade-regel kopiert frå ein blogg er ikkje ein Windows-konfigurasjon, og ei løyve i brannmuren til verten for VPN-lyttaren er ikkje same policy som løyve til å vidaresenda ein førespurnad frå ein klient. Stadfest vidaresendingsrolla til tenaren frå hans eigen administrasjonsflate, og sjå deretter på omsetjinga separat, fordi dei to ofte blir aktiverte av ulike delar av ein utrulling.

Alternativ B: flytt bassenget til rutaren

I den andre ordninga vidaresender tenaren den verkelege kjeldeadressa til klienten, og rutaren omset henne. Det held klientbassenget synleg ved kanten, noko som hjelper om rutaren er der trafikkpolicy, logging eller inspeksjon bur. Det tyder òg at rutaren treng ei returrute for 10.70.0.0/24 som peikar på 172.16.40.10, pluss ein internettpolicy som faktisk omfattar det prefikset; ei regel skriven for LAN-subnettet strekkjer seg ikkje stille til bassenget.

Vel dette når kanten-eininga er den tiltenkte policyeigaren og kan godta eit anna prefiks i ruting- og omsetjingstabellane sine. Vel omsetjinga på tenarsida når bassenget skal bli verande usynleg lenger oppe og rutaren ikkje blir administrert av same team. Ingen av alternativa blir antyda av noka avkryssingsboks på klienten, og ingen av dei er tryggare generelt; dei plasserer synlegheit og vedlikehald på ulike stader.

Gjer DNS, IPv6 og aksept eksplisitt

Adresseomsetjing løyser ikkje namneoppslag. Klienten kan bruka ein resolver som blir levert med VPN-profilen, ein privat resolver for bestemte namnerom eller ein godkjend offentleg, og ein utilgjengeleg resolver under den policyen vil halda fram med å feila etter at rutinga verkar. Test eit namn og ei adresse kvar for seg, slik at dei to feila aldri smeltar saman i éin rapport.

IPv6 treng sitt eige avsnitt i designet. Ei fungerande IPv4-omsetjing seier ingenting om korvidt IPv6-klientar har ei rute, ei gyldig offentleg kjelde eller ein policy som blokkerer dei når tunnelen fell. Å la det vera usagt tyder at halvparten av klientane stille går utanom gatewayen medan den andre halvparten verkar.

For aksept, følg éin tillaten klientførespurnad og svaret hans over begge grensene, og skriv ned kva adresse kvar grense bør sjå i det augneblinken. Den registreringa er det som gjer den neste bassengendringa til ei fem minutts endring i staden for ein diskusjon om kven som eig den manglande returruta. Oppbevar registreringa saman med klientprofilen i staden for i ein billett, sidan profilen er det den neste ingeniøren finn fyrst.