Éin NIC eller to? Å avgjere grensesnittoppsettet til ein VPN-server

Éin fysisk adapter er nok for mange VPN-tenarar, og det er heller ikkje ei universell løysing. Den krypterte sambindinga kjem inn på den adapteren, VPN-prosessen dekrypterer ho, og deretter går den indre trafikken ut gjennom eit virtuelt grensesnitt før han når ein lokal teneste eller eit ruta LAN. Om det verkar avheng av tre vilkår: kvar målet ligg, om LAN-et har ein returveg til klientpoolen, og om éi delt fysisk lenkje gjev deg den isolasjonen du påstår. Svar på dei tre, og talet på adapterar følgjer.

Dei tre vilkåra som avgjer det

Det første vilkåret er målet. Ei teneste på sjølve VPN-verten er berre tilgjengeleg gjennom tunellgrensesnittet, medan ein vert på LAN-et krev videresending og ein returveg. Det andre vilkåret er den returvegen, fordi LAN-eininga må vita korleis ho når klientpoolen, anten via ei rute eller via omsetjing på serveren.

Det tredje vilkåret er separasjon. Éin adapter tyder at kvar pakke, kryptert eller ikkje, deler ei lenkje og vanlegvis éi retningslinjekjede, så ein isolasjonspåstand som avheng av separat maskinvare blir ikkje oppfylt av eitt grensesnitt. Det er eit faktum om vegen, ikkje om korleis operativsystemet er konfigurert. Du kan framleis filtrera tunneltrafikken, men du kan ikkje påstå ei grense du ikkje har.

Ingen av dei tre handlar om talet på portar på kabinettet. Dei handlar om ruting, eigarskap til adressene og kor mykje designet avheng av fysisk separasjon.

To adapterar er framleis eit legitimt val når fysiske soner, separate opplenkjer, gjennomstrøyming eller ein gjenopprettingsveg utanfor bandet rettferdiggjer det. Det er konkrete krav, og dei er verd å skriva ned før nokon bestiller maskinvare.

Når tenesta køyrer på VPN-verten

Det enklaste tilfellet treng ingen videresending i det heile. Daemonen tek imot pakkane til klienten på tunellgrensesnittet og gjev dei til ein lokal socket, og svaret kjem tilbake same vegen. For verten er klientpooladressa ei ekte lokal adresse.

To ting må likevel stemma: tenesta må lytta på ei adresse tunnelen kan nå, og brannmuren til verten må godta trafikk som kjem inn på tunellgrensesnittet. Begge er synlege i kommandoane nedanfor.

ss -lntup | grep -E "5432|8080"
ip -brief addr show
ip route get 10.8.0.6 from 10.8.0.1

Å binda ei teneste berre til den offentlege adressa, eller å filtrera tunellgrensesnittet ved ein feil, gjev ei sambinding som når verten og deretter døyr. Det ser ut som ein VPN-feil og er vanlegvis eit socket- eller brannmurval.

Når målet ligg på LAN-et

Det er her eit design med éin adapter får rykte for å vera kinkig. Serveren må videresenda pakkane til klienten mot LAN-et, og LAN-eininga må senda svar tilbake til klientpoolen. Anten ber du poolen som ei rute på LAN-et, eller du omset kildeadressa på serveren slik at svar kjem tilbake til serveren sjølv.

Begge svara er legitime og dei feilar på ulike måtar. Ei returrute held den opphavlege klientadressa synleg for målet, noko som er bra for loggar og dårleg for brannmurreglar som føreset LAN-adresser. Omsetjing held LAN-et enkelt og skjuler identiteten til klienten for målet.

sysctl net.ipv4.ip_forward
nft list ruleset | grep -A4 'chain forward'
ip route show table main | grep 10.8.0

Ein asymmetrisk veg er det klassiske symptomet: førespurnaden til klienten kjem inn, svaret går ut via ein annan ruter, og sambindinga fell på tid utan feil i nokon av endane. Ta opp trafikk på begge sider før du konkluderer noko om tunnelen.

Kvifor eit alias ikkje lagar ei ny sone

Å leggja ei ny adresse på same adapteren, eller å laga eit dummy-grensesnitt for å etterlikna ein ekstra port, endrar svært lite. Pakkane går framleis ut gjennom same fysiske lenkja, same svitsjporten og vanlegvis same brannmurkjeda, så det oppstår inga ny grense mellom dei. Det er konfigurasjonskomfort, ikkje segmentering. Å handsama det som ei sonegrense er måten ein isolasjonspåstand berre overlever på papiret.

Ei separat sone krev ein reell separasjon i vegen, og det er kravet ein ny adapter oppfyller. Viss ein regel avheng av at trafikk mot VPN aldri deler kringkastingsdomene med trafikk mot LAN, kan éin kabel ikkje gje den eigenskapen, same korleis verten er adressert.

Der eit produkt dokumenterer ein topologi med fleire grensesnitt for ein bestemd modus, følg dokumentasjonen til produktet i staden for å finna på ein omveg. Leverandørar endrar òg dei støtta topologiane mellom utgjevingar, som er ein annan grunn til å lesa den gjeldande rettleiinga og ikkje eit gammalt vegvisarskjermbilete.

Sjekk oppsettet mot trafikken du tillèt

List opp trafikkklassane serveren skal bera: klient til vert, klient til LAN, vert til LAN og den krypterte ytre sambindinga. Kvar klasse har ei kjelde, eit mål og eit grensesnitt, og oppsettet må oppfylla alle fire samstundes. Eit design som handterer tre av dei, er vanlegvis det som genererer billettar.

Stadfest deretter dei faktiske grensesnitta og den faktiske opptaka, ikkje diagrammet i designdokumentet. Kommandoane nedanfor skriv ut båe visingane.

ip -brief addr
ip route
tcpdump -ni any udp port 51820 -c 5
tcpdump -ni tun0 -c 5

Viss opptaka utanfrå viser den krypterte trafikken og opptaka innanfrå viser den dekrypterte trafikken på tunellgrensesnittet medan den fysiske adapteren ber begge, gjer éin NIC jobben. Viss opptaka innanfrå er tom, ligg problemet i tunnelen eller i videresendingsreglane, ikkje i talet på adapterar. Avgjer topologien ut frå dei to opptaka og rutetabellen, så har neste endring noko å målast mot.