Folgjende sprong yn in VPN-rûte: wêrom’t de poarte lokaal berikber wêze moat

In rûte nei in VPN-netwurk draacht twa adressen dy’t maklik te betiizjen binne: it bestimmingsprefiks dat it pakket berikke wol en de folgjende sprong dy’t it ien stap tichterby bringt. Op in LAN-host moat dy folgjende sprong in router wêze dy’t jo wier op deselde skeakel berikke kinne. It fiere VPN-adres is gjin folgjende sprong, hoe kreas’t it ek past by de bestimming dy’t jo yn ’t sin hawwe.

Dizze hânlieding behannelet it gewoane gefal: in laptop op 192.168.20.0/24, in VPN-poarte mei in LAN-adres fan 192.168.20.5 en in fierm netwurk 10.70.0.0/24 efter dy poarte. Alle hjirûnder opdrachten geane derfan út dat jo op ’e laptop binne, útsein as oars sein wurdt.

Twa adressen, ien rûte

De bedoelde ynstjoer is 10.70.0.0/24 via 192.168.20.5. It prefiks seit wêr’t it pakket hinne giet; it via-adres seit wa’t it derhinne draacht. De kearn wegeret in rûte te ynstallearjen wêrfan’t er de poarte net troch de ynterface berikke kin dy’t jo neame, en dy wegering is it hiele punt: in folgjende sprong dy’t de tunnel nedich hat om berikber te wêzen, kin net de folgjende sprong wêze dy’t de tunnel bout.

Dus de earste kontrôle is net «wurket de poarte» mar «is de poarte op dizze skeakel». It eigen subnet fan ’e laptop, syn ARP- of buorman-ynstjoer en de ynterface yn ’e rûte moatte allegear oerienkomme. In adres dat allinnich binnen 10.70.0.0/24 bestiet, kin de bestimming fan in twadde rûte wêze, mar nea it via fan ’e earste.

Wêr’t de folgjende sprong de poarte oan ferbynt

It ynstallearjen fan ’e rûte op ’e laptop beslút allinnich de earste oerdracht. Dêrnei hat de poarte syn eigen paad nedich: trochstjoere oan, in tunnelrûte foar 10.70.0.0/24 en elk tagongsbelied dat regelet wa’t it brûke mei. Op Linux is dat net.ipv4.ip_forward=1 plus in tunnelrûte; in brânmuorre derfoar hat in regel nedich dy’t de trochstjoerde stream talit.

De weromrjochting is it diel dat minsken ferjitte. De fiere kant moat in rûte werom hawwe nei 192.168.20.0/24, of it ûntwerp moat de boarne fan ’e laptop oersette yn eat dat de fiere kant ken. In ping dy’t wurket fan ’e poarte bewiist dat de poarte it fiere netwurk berikke kin; it seit neat oer de fraach oft de pakketten fan ’e laptop de reis werom oerlibje.

Kontrolearje de syktocht fan ’e host dy’t stjoert

Freegje de kearn hokker folgjende sprong er kieze soe, en lês de ynterface yn it antwurd:

ip route get 10.70.0.10
ip route show 10.70.0.0/24
ip neigh show 192.168.20.5

As de syktocht de poarte en de LAN-ynterface rapportearret, is it earste skonken ynsteld sa’t bedoeld wie. As er it tunnelapparaat rapportearret, is eat earder yn ’e tabel mear spesifyk en wint. As de rûte hielendal net ynstallearje wol, seit de kearn dat de poarte net berikber is, en dy melding is nuttiger as hokker pakketopname dan ek.

Werhelje de test dan fan ’e goede plak. In fersyk dat op ’e poarte makke wurdt, brûkt it eigen boarne-adres fan ’e poarte, wat in ûntbrekkende weromrûte of in belied dat allinnich beskate boarnen talit, ferbergje kin. De hânlieding foar ip-route skiedt bestimming, poarte en de onlink-oerskriuwing, en de oerskriuwing is it wurdich te begripen foardat jo him brûke.

Brûk onlink net om berikberens te ferrifeljen

onlink seit tsjin de kearn dat er de berikberens-kontrôle foar in poarte oerslaan moat en dochs derhinne stjoere moat. It makket gjin paad, lost gjin ARP op foar in adres dat der net is, en lit in fiere router net antwurdzje op jo Ethernet-segmint. It is legitime foar poarten dy’t antwurdzje mar net yn in ferbûn subnet sitte, en it is in falstrik as it brûkt wurdt om in flater te smoarjen dy’t jo net útlizze hawwe.

As de rûte allinnich mei onlink ynstallearret, is de folgjende fraach wêrom’t de poarte net is dêr’t jo tinke. In ferkeard VLAN, in twadde adres op ’e ferkearde ynterface of in typflater yn ’e lêste oktet meitsje dit allegear, en elk fan harren brekt ek it werompaad sadree’t it ferkear begjint te streamen.

Punt-nei-punt-tunnels binne gjin Ethernet

In tunnelapparaat docht gjin ARP en hat faak gjin sinfol subnet fan buorlju. Syn rûtes sjogge der faak út as 10.70.0.0/24 dev tun0, sûnder hokker via dan ek, om’t de peer it iennige oare einpunt is. It kopiearjen fan in LAN-styl via yn dy tabel jout in rûte dy’t de kearn ôfwize kin of, slimmer, ien dy’t wiist nei in adres dêr’t de peer nea op antwurdet.

Hâld de twa modellen apart yn ’e hânlieding: in LAN-rûte hat in berikbere poarte, in tunnelrûte hat in ynterface en in peer. WireGuard, OpenVPN en IPsec jouwe allegear wat oare foarmen, dus skriuw de foarm op dy’t jo wier brûkt hawwe ynstee fan fan ien host te generalisearjen.

Foegje ta, befêstigje, rol werom

De hiele feroaring is trije opdrachten en ien kontrôle, en it moat yn dy folchoarder opskreaun wurde:

sudo ip route add 10.70.0.0/24 via 192.168.20.5
ip route get 10.70.0.10
ping -c 3 10.70.0.10
sudo ip route del 10.70.0.0/24 via 192.168.20.5

Befêstigje it paad, befêstigje ien bestimming, en hâld dan de wiskje-rige ree foar it gefal dat de feroaring de host ûnberikber makket op in manier dy’t jo net foarsjoen hiene. As de rûte in werstart oerlibje moat, set him dan yn ’e netwurkkonfiguraasje fan ’e host ynstee fan yn in shell-profyl, en test de werstart foardat jo derop fertrouwe. In rûte dy’t allinnich bestiet yn ’e shell dy’t him tafoege hat, is in rûte dy’t jo twa kear debugge sille.