OpenVPN se local teenoor die tonneladres: twee verskillende sokke

Die kliënt weier om te begin en kla dat hy nie ’n plaaslike adres kan bind nie, en die ooglopende oplossing lyk soos om dit na die tonneladres te wys wat hy verwag om te ontvang. Dit kan nie werk nie, en die rede is die moeite werd om te verstaan: voordat die tonnel bestaan, is daar geen binne-adres nie, en die sok wat die bediener kontak, moet eerste bestaan. Twee verskillende adresse is hier betrokke, en net een daarvan kan plaaslik gekies word.

Die bindfout noem ’n plaaslike adres

Wanneer OpenVPN sê dat hy nie ’n plaaslike adres kan bind nie, praat hy van die vervoersok: die UDP- of TCP-eindpunt wat die versleutelde verbinding na die eweknie dra.

’n Eksplisiete local-opdrag vra die daemon om daardie sok aan ’n spesifieke plaaslike adres te bind. Die adres moet bestaan in die netwerk-naamruimte waar die proses loop, en dit moet toewysbaar wees op die oomblik wanneer die kliënt begin.

’n Openbare adres wat by ’n router of ’n wolkerand vertaal word, is nie ’n plaaslike adres wat die daemon kan bind nie, al is dit die adres wat die bediener sien. Daardie onderskeid verduidelik waarom een profiel by die huis werk en op ’n wolke-instansie faal. Dit verduidelik ook waarom die toevoeging van die openbare adres aan ’n loopback-koppelvlak nie help nie, want die vervoer sou dan vanaf ’n adres vertrek waarna die netwerk nie kan terugkeer nie. Lees die koppelvlaklys voordat jy die profiel wysig.

Wat local en remote eintlik kies

remote noem die eweknie om te kontak. local bind die nabye punt van dieselfde sok. nobind laat die bedryfstelsel beide die plaaslike adres en die poort kies, en daarom werk kliënte agter tuisrouters gewoonlik sonder enige van die twee opdragte.

Nie een van die opdragte het iets met die adres binne die tonnel te doen nie.

In ’n houer of ’n netwerk-naamruimte geld dieselfde reël met nouer grense: die gasheer se adresse is nie binne teenwoordig nie, so ’n local-lyn wat uit die gasheer se konfigurasie gekopieer is, faal om ’n heeltemal ander rede as ’n verkeerde adres.

ip -brief address show
ip route get 203.0.113.10

Die binne-adres kom van die bediener

Die adres binne die tonnel word onderhandel of toegewys nadat die beheerkanaal tot stand gekom het. Met ’n dinamiese poel besluit die bediener dit tydens die verbinding, en met kliëntspesifieke konfigurasie kan dit per identiteit vasgestel word.

Om local met ’n binne-adres te skryf, vra nie die bediener om daardie adres toe te wys nie. In die beste geval faal die bind; in die slegste geval vind die kliënt ’n onverwante gasheeradres met dieselfde waarde en begin dit vir die vervoer gebruik.

Die koppelvlakke wat jy moet lees, verskil ook. ifconfig-parameters en poelkonfigurasie beskryf die binnekant, terwyl remote, local, proto en nobind die buitekant beskryf. Om die twee lyste apart te hou, verduidelik byna elke verwarrende voorbeeld wat jy op ’n forum sal vind. Die OpenVPN 2.6-handleiding dokumenteer hulle om daardie rede in aparte afdelings.

Die lokval: ’n volle tonnel wat sy eie vervoer vasvang

Sodra die tonnel op is en die verstekroete dra, mag die pakkette wat dit onderhou nie daarin gerouteer word nie. Dit is ’n routeringsprobleem eerder as ’n adresseringsprobleem, en die daemon hanteer dit deur ’n meer spesifieke roete na die bediener se eie adres deur die oorspronklike poort te installeer.

As jy die vervoer aan ’n spesifieke plaaslike adres vaspen en later die pad verander wat daardie adres gebruik, kan die buitenste verbinding verdwaal terwyl die binnekant geconfigureerd bly. Die tonnel hou aan om verbind te rapporteer omdat die binnekant reg is. Net die vervoer is stukkend, en daarom lees die logboeke soos teenstrydighede.

Simptome lyk dan soos ’n tonnel wat verbind en vries, of een wat in ’n lus weer verbind sonder ’n nuttige fout. Kontroleer die roete vir die eweknie se adres voordat jy enigiets binne die tonnel kontroleer, en bevestig dat die plaaslike adres wat jy gebind het steeds aan die koppelvlak behoort wat jy verwag het.

’n Gewoonte wat die verwarring voorkom

Lees elke adres in ’n profiel en besluit watter laag dit behoort voordat jy dit wysig.

As dit die verre punt van die vervoer noem of die nabye punt daarvan bind, is dit ’n buite-adres en moet dit voor die begin bestaan. As dit beskryf wat binne die tonnel gebeur, kom dit van die bediener of van die topologie, en geen plaaslike opdrag kan dit vervang nie.

Skryf die twee lyste in die ontplooiingsnotas langs die profiel. Die volgende probleemoplossingsessie begin dan met die laag eerder as met ’n raaiskoot.